Bug 699705 (gen3-rendering-limit)

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* output of the dmesg command, and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

Also that attached /var/log/Xorg.0.log is from the session when the monitor failed to connect, right? If not, please attach such log.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 495084 [details]
dmesg when monitor not working properly after drm.debug=0x04

Created attachment 495085 [details]
/var/log/messages when monitor not working properly after drm.debug=0x04

Created attachment 495086 [details]
/var/log/Xorg.0.log when monitor not working properly after drm.debug=0x04

I could not find .conf files inside /etc/X11:
[root@notepeter X11]# pwd
/etc/X11
[root@notepeter X11]# find
.
./applnk
./fontpath.d
./fontpath.d/default-ghostscript
./fontpath.d/liberation-fonts
./fontpath.d/fonts-default
./xorg.conf.d
./xorg.conf.d/00-system-setup-keyboard.conf
./prefdm
./Xmodmap
./Xresources
./xinit
./xinit/Xclients
./xinit/xinitrc
./xinit/xinputrc
./xinit/xinput.d
./xinit/xinput.d/none.conf
./xinit/xinput.d/xcompose.conf
./xinit/xinput.d/im-cedilla.conf
./xinit/xinput.d/ibus.conf
./xinit/xinput.d/xim.conf
./xinit/Xclients.d
./xinit/xinitrc-common
./xinit/Xsession
./xinit/xinitrc.d
./xinit/xinitrc.d/zz-liveinst.sh
./xinit/xinitrc.d/50-xinput.sh
./xinit/xinitrc.d/00-start-message-bus.sh
./xinit/xinitrc.d/xdg-user-dirs.sh
./xinit/xinitrc.d/localuser.sh


Please let me know if I sent correct files and if more files are needed.

Regards,

Peter

This is expected, if unfortunate.  The initial configuration heuristic places monitors horizontally adjacent.  That makes your total display wider than 2048, which is the maximum size that the 3D engine in the 945 can render to.

This should be fixable, if not fixed, by xserver changes to allow each output to have its own memory allocation instead of sharing a single large one, and modifying the compositor to be aware of this.  Hopefully that will land by Fedora 16.

Thank you very much for the attention!

Up to Fedora 16 is there any workaround for this? Can the autoprobe be turned off?

Regards,

Peter

*** Bug 710293 has been marked as a duplicate of this bug. ***

Thank you for looking into this.  If there's something I can help with, let me know.  (I can test, investigate, and write some code, but I don't know much about X or drivers :'( )

*** Bug 768289 has been marked as a duplicate of this bug. ***

*** Bug 769659 has been marked as a duplicate of this bug. ***

(In reply to comment #11)
I use Fedora 16 for bug #769659. Can you please set Version of this bug to 16?

(In reply to comment #6)
> That makes your total display wider than 2048, which is the maximum size that the 3D engine in the 945 can render to.

Confirmed. When I set each resolution to 1024x768 on both monitors, composition of Xfce works well.

Why did not anyone post this bug in upstream?

(In reply to comment #14)
> Why did not anyone post this bug in upstream?
Is it really a bug? I understand it like that it is more a restriction of hardware capabilities, isn't it? Okay, you could overcome the issue of resolution with some special tricks in memory management, but memory is not available without limits.
For me, it's a WORKSFORME when the fact is known that the resolution of all screens in summary can not go higher than 2048 in width (see comment #6).

I know what windows driver not have this restriction of
hardware capabilities.

Before Fedora on my work computer was installed Windows XP. And my two monitors with resolution 1440x900 worked fine with hardware acceleration (Open GL and Direct 3D).

Still occurs in Fedora 17.

Adam, you said separate memory allocations would hopefully land in F16.  Is anyone still working on that?

Does anyone here?

https://bugs.freedesktop.org/show_bug.cgi?id=51751

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This bug should be reopened.

Upstream is aware and I can't see any available patch.

Indeed it should.

*** Bug 846369 has been marked as a duplicate of this bug. ***

*** Bug 846365 has been marked as a duplicate of this bug. ***

Is any work being done on this? It's a very common chipset. I'm on my thrid laptop with it...Using multiple monitors under these conditions is painful to say the least.

*** Bug 866250 has been marked as a duplicate of this bug. ***

(In reply to comment #26)
> Is any work being done on this? It's a very common chipset. I'm on my thrid
> laptop with it...Using multiple monitors under these conditions is painful
> to say the least.

Yes, though not as rapidly as I'd like.  The idea we're looking at for X is a thing called "per-crtc pixmaps" in a new version of the RANDR protocol, combined with an updated compositor that knows how to use them.  There was a proposal for that for xserver 1.13 that didn't make the release.  I'll check into its current status.

Thank you for responding. I appreciate it.

Any word on whether per-crtc pixmaps will eradicate the issue completely?

Also, will this apply to x86 and not just 64-bit?

(In reply to comment #29)
> Thank you for responding. I appreciate it.
> 
> Any word on whether per-crtc pixmaps will eradicate the issue completely?

The compositor (gnome-shell, or whatever else you're using) will need to be updated to take advantage of the feature, and per-crtc pixmaps won't suddenly eliminate GL rendering limits; if you're trying to quake fullscreen it's only going to create one window, and that one window will still be limited.

(In reply to comment #30)
> Also, will this apply to x86 and not just 64-bit?

Per-crtc pixmaps would be an arch-independent feature.  Most gen3 chips aren't even 64-bit capable anyway.

Thanks for responding Adam.

(In reply to comment #31)
> (In reply to comment #29)
> > Thank you for responding. I appreciate it.
> > 
> > Any word on whether per-crtc pixmaps will eradicate the issue completely?
> 
> The compositor (gnome-shell, or whatever else you're using) will need to be
> updated to take advantage of the feature, and per-crtc pixmaps won't
> suddenly eliminate GL rendering limits; if you're trying to quake fullscreen
> it's only going to create one window, and that one window will still be
> limited.
I think the general concesus would be that gaming with this chipset is overzelous to say the least. This is more of a business-class requirement to have multiple displays showing lots of info ;)
> 
> (In reply to comment #30)
> > Also, will this apply to x86 and not just 64-bit?
> 
> Per-crtc pixmaps would be an arch-independent feature.  Most gen3 chips
> aren't even 64-bit capable anyway.
Okay. No problem there.

Again, thank you for the response. I just feel like this is something that requires attention.

Phil

*** Bug 866232 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

I'm curious whether there's much progress on this front.

Are there any pointers to where the relevant work to be done is, so interested parties could see if they have time to help out? :D

I basically barely see GNOME Shell, since I always have to switch to metacity+gnome-panel to work with my second monitor. ;_;

I am hitting this with an i915 based laptop with Fedora 19 - plugging in an external monitor causes gnome shell to crash. Ugly.

I have the same issue. What I find odd is that these same machines with F15 and F17 did not exhibit these problems. Is there a workaround? I tried installing gnome-classic-session but that didn't help as it seems that still uses gnome-shell.

For example in our particular case I don't need the initial screens to default to span. Mirror is the preferred setting in our case. Would that help with this particular problem?

So to avoid the crash I've modified the ~/.config/monitors.xml and added a configuration section so for example for one of our use cases I added this

<configuration>
      <clone>no</clone>
      <output name="LVDS1">
          <vendor>AUO</vendor>
          <product>0x61d2</product>
          <serial>0x00000000</serial>
      </output>
      <output name="VGA1">
          <vendor>ACR</vendor>
          <product>0x0011</product>
          <serial>0x80700223</serial>
          <width>1024</width>
          <height>768</height>
          <rate>60</rate>
          <x>0</x>
          <y>0</y>
          <rotation>normal</rotation>
          <reflect_x>no</reflect_x>
          <reflect_y>no</reflect_y>
          <primary>yes</primary>
      </output>
  </configuration>

So when I plugged that monitor in with that serial number etc it disables the netbook screen and sets the other monitor resolution. I imagine this would help others in this situation. One thing I was hoping to find out is how to get the vendor/product/serial strings/numbers in there. The way I got that monitors.xml modified was to set the display to 800x600 so that when I plugged in it didn't crash. (I had also installed MATE earlier and plugged in other monitors in various configurations - not sure if that helped allow it not to crash). In any case now when I plug in my monitor I don't get a crash...

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.