Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Intel Gen3 rendering limits are pitiful|
|Component:||xorg-x11-drv-intel||Assignee:||Adam Jackson <ajax>|
|Status:||ASSIGNED ---||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||25||CC:||ajax, aquarichy, davem, drizt, dwmw2, jonathan.underwood, mikhail.v.gavrilov, nathanael, nekohayo, orion, support, tomek, xgl-maint|
|Target Milestone:||---||Keywords:||Reopened, Triaged|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-07 10:41:28 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description peter.senna 2011-04-26 08:22:48 EDT
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 http://reviews.cnet.com/laptops/toshiba-satellite-u205-s5067/4507-3121_7-32327362.html External Monitor: Samsung SyncMaster 2232BW Plus http://www.newegg.com/Product/Product.aspx?Item=N82E16824001310 Version-Release number of selected component (if applicable): xorg-x11-drv-intel-2.14.0-5.fc15.x86_64 How reproducible: 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. Actual results: Expected results: Additional info:
Comment 1 Matěj Cepl 2011-04-26 17:10:04 EDT
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.
Comment 2 peter.senna 2011-04-26 19:48:16 EDT
Created attachment 495084 [details] dmesg when monitor not working properly after drm.debug=0x04
Comment 3 peter.senna 2011-04-26 19:49:37 EDT
Created attachment 495085 [details] /var/log/messages when monitor not working properly after drm.debug=0x04
Comment 4 peter.senna 2011-04-26 19:50:41 EDT
Created attachment 495086 [details] /var/log/Xorg.0.log when monitor not working properly after drm.debug=0x04
Comment 5 peter.senna 2011-04-26 19:54:01 EDT
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
Comment 6 Adam Jackson 2011-04-27 11:38:39 EDT
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.
Comment 7 peter.senna 2011-04-29 13:11:24 EDT
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
Comment 8 Adam Jackson 2011-06-06 11:08:35 EDT
*** Bug 710293 has been marked as a duplicate of this bug. ***
Comment 9 Richard Schwarting 2011-06-06 11:13:22 EDT
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 :'( )
Comment 10 Adam Jackson 2011-12-20 15:12:07 EST
*** Bug 768289 has been marked as a duplicate of this bug. ***
Comment 11 Adam Jackson 2012-01-03 14:06:03 EST
*** Bug 769659 has been marked as a duplicate of this bug. ***
Comment 12 Raphael Groner 2012-01-03 16:44:43 EST
(In reply to comment #11) I use Fedora 16 for bug #769659. Can you please set Version of this bug to 16?
Comment 13 Raphael Groner 2012-01-03 17:00:05 EST
(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.
Comment 14 Mikhail 2012-04-23 22:43:18 EDT
Why did not anyone post this bug in upstream?
Comment 15 Raphael Groner 2012-04-24 08:52:34 EDT
(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).
Comment 16 Mikhail 2012-04-24 09:43:59 EDT
I know what windows driver not have this restriction of hardware capabilities.
Comment 17 Mikhail 2012-04-24 09:53:43 EDT
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).
Comment 18 Richard Schwarting 2012-06-11 07:56:04 EDT
Still occurs in Fedora 17. Adam, you said separate memory allocations would hopefully land in F16. Is anyone still working on that?
Comment 19 Mikhail 2012-07-05 10:05:20 EDT
Does anyone here?
Comment 20 Mikhail 2012-07-07 08:57:07 EDT
Comment 21 Fedora End Of Life 2012-08-07 10:41:33 EDT
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
Comment 22 Raphael Groner 2012-08-07 13:13:27 EDT
This bug should be reopened. Upstream is aware and I can't see any available patch.
Comment 23 Adam Jackson 2012-08-20 11:49:42 EDT
Indeed it should.
Comment 24 Adam Jackson 2012-08-20 11:50:00 EDT
*** Bug 846369 has been marked as a duplicate of this bug. ***
Comment 25 Adam Jackson 2012-08-20 11:50:20 EDT
*** Bug 846365 has been marked as a duplicate of this bug. ***
Comment 26 Phil 2012-10-05 00:24:59 EDT
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.
Comment 27 Adam Jackson 2012-10-16 16:49:06 EDT
*** Bug 866250 has been marked as a duplicate of this bug. ***
Comment 28 Adam Jackson 2012-10-16 16:54:25 EDT
(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.
Comment 29 Phil 2012-10-17 09:30:08 EDT
Thank you for responding. I appreciate it. Any word on whether per-crtc pixmaps will eradicate the issue completely?
Comment 30 Phil 2012-10-17 09:32:06 EDT
Also, will this apply to x86 and not just 64-bit?
Comment 31 Adam Jackson 2012-11-14 16:40:47 EST
(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.
Comment 32 Phil 2012-11-14 19:10:00 EST
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
Comment 33 Adam Jackson 2013-01-04 16:20:33 EST
*** Bug 866232 has been marked as a duplicate of this bug. ***
Comment 34 Fedora End Of Life 2013-04-03 15:11:18 EDT
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
Comment 35 Richard Schwarting 2013-06-21 22:45:26 EDT
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. ;_;
Comment 36 Jonathan Underwood 2013-07-29 13:30:36 EDT
I am hitting this with an i915 based laptop with Fedora 19 - plugging in an external monitor causes gnome shell to crash. Ugly.
Comment 37 Nathanael Noblet 2013-10-07 18:24:45 EDT
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?
Comment 38 Nathanael Noblet 2013-10-16 16:45:10 EDT
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...
Comment 39 Jan Kurik 2015-07-15 11:16:15 EDT
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
Comment 40 Fedora End Of Life 2016-11-24 05:31:11 EST
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.