Red Hat Bugzilla – Bug 699705
Intel Gen3 rendering limits are pitiful
Last modified: 2016-01-13 18:06:03 EST
Created attachment 494892 [details]
Xorg log when booting with external monitor.
Description of problem:
When my notebook is booting connected to the external monitor trough VGA output, something happens with the Intel driver and Gnome tells me that it is starting in backwards compatibility mode. If I connect external monitor after login, and configure it using "System Settings -> Displays" then it works as expected.
This is not new issue. I had similar problem with Debian and Centos using same monitor but different hardware with Intel GPU.
Not sure if this is Xorg or Kernel issue.
My hardware with Fedora 15:
Toshiba Satellite U205-S5067
External Monitor: Samsung SyncMaster 2232BW Plus
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Connect the monitor to VGA output of the notebook while the notebook is off.
2. Power on the monitor, then the notebook with Fedora 15
3. Log in. Gnome3 will inform about backward compatibility.
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
[root@notepeter X11]# find
Please let me know if I sent correct files and if more files are needed.
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?
*** 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
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?
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:
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
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.
*** 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:
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
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: