Bug 699705 - (gen3-rendering-limit) Intel Gen3 rendering limits are pitiful
Intel Gen3 rendering limits are pitiful
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
23
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
[cat:modesetting]
: Reopened, Triaged
: 710293 768289 769659 846369 866232 866250 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-26 08:22 EDT by peter.senna
Modified: 2016-01-13 18:06 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-07 10:41:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Xorg log when booting with external monitor. (38.82 KB, text/plain)
2011-04-26 08:22 EDT, peter.senna
no flags Details
dmesg when monitor not working properly after drm.debug=0x04 (123.29 KB, text/plain)
2011-04-26 19:48 EDT, peter.senna
no flags Details
/var/log/messages when monitor not working properly after drm.debug=0x04 (1.06 MB, text/plain)
2011-04-26 19:49 EDT, peter.senna
no flags Details
/var/log/Xorg.0.log when monitor not working properly after drm.debug=0x04 (38.83 KB, text/plain)
2011-04-26 19:50 EDT, peter.senna
no flags Details

  None (edit)
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 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

Note You need to log in before you can comment on or make changes to this bug.