After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 646280 - Maximum 3D size limitations
Maximum 3D size limitations
Product: gnome-settings-daemon
Classification: Core
Component: xrandr
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
: 595839 645087 657431 702049 704810 730210 (view as bug list)
Depends on: 688252
Reported: 2011-03-30 21:50 UTC by Owen Taylor
Modified: 2019-03-20 10:53 UTC
See Also:
GNOME target: ---
GNOME version: ---

0001-Set-_GNOME_MAX_SCREEN_SIZE-on-the-root-window.patch (3.69 KB, patch)
2012-08-23 14:53 UTC, Adam Jackson
reviewed Details | Review

Description Owen Taylor 2011-03-30 21:50:41 UTC
The Intel GM945 chipset is very common, and has a limitation that the maximum 3D rendered area is 2048 pixels wide. Which isn't wide enough to handle a 1024x600 netbook + a 1280x1024 monitor.

Mesa is pretty good about automatically falling back to software rendering, so the observed effect is that if you plug in such a monitor, things become dead slow and your system becomes unusable.


Here's a plan for how we should handle this case:

 * gnome-session-check-accelerated should query GL_MAX_RENDERBUFFER_SIZE_EXT and set the result as a property on the root window. ( _GNOME_MAX_SCREEN_SIZE)

 * When in non-fallback mode, the xrandr code in gnome-settings-daemon should check this property and then only pick monitor configurations that fit within GL_MAX_RENDERBUFFER_SIZE_EX. Ordering of the initial default configuration should be:

 - As currently, if it fits
 - Mirrored displays if that would result in a resolution of at least 1024x600
 - Otherwise, only the primary monitor with the secondary output off

 * The panel should respect the same limitations, so if you try to enable the one monitor, then the other monitor turns off and the primary switches to the on monitor.

The reasons for doing the query in gnome-session-check-accelerated are:

 - It already has the code to set up a glx context and query stuff from it
 - It's very important that this code doesn't run unless 
   gnome-session-check-accelerated passed, since GLX crashing on
   initialization is reasonable common and we want to handle it gracefully.
Comment 1 Adam Jackson 2012-08-23 14:53:28 UTC
Created attachment 222234 [details] [review]

This should implement the gnome-session half of it, at least.  The code is in check-accelerated-helper not check-accelerated, since the former is the one where we hide GLX setup.

Tested on a Thinkpad T500:

$ DISPLAY=:0 glxinfo | grep renderer
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset 
$ DISPLAY=:0 xprop -root | grep _GNOME
$ DISPLAY=:0 ltrace /usr/libexec/gnome-session-check-accelerated-helper |& grep GetInteger
glGetIntegerv(3379, 0x602104, 0x37fe7b0778, 0xfbad000c, 1) = 8192
glGetIntegerv(34024, 0x602108, 2, 0x7ff12c445155, 300731) = 8192
Comment 2 Ray Strode [halfline] 2012-08-23 20:22:00 UTC
Review of attachment 222234 [details] [review]:

::: tools/gnome-session-check-accelerated-helper.c
@@ +286,2 @@
         if (_is_gl_renderer_blacklisted (renderer) != 0)
                 goto out;

If we fail here max_renderbuffer_size == 0 and max_texture_size == 0

@@ +297,3 @@
+        if (glGetError() != GL_NO_ERROR)
+                max_renderbuffer_size = -1;

if we fail here, they equal -1.

@@ +411,1 @@
                 return 1;

in both cases

@@ +414,3 @@
+            if (size < DisplayWidth (display, screen) &&
+                size < DisplayHeight (display, screen)) {
+                    return 1;

we fail, so it's not a problem in practice, but it's a little sloppy (not that you did it first).  I would prefer a preliminary commit that:

- uses -1 (or 0) everywhere for "it didn't work"

and another preliminary commit that

@@ +471,3 @@
         if (_is_max_texture_size_big_enough (display) != 0) {

makes this function return true instead of of 0 for success.  The whole "leave the code cleaner than you found it mantra" (if you're up for it)

Then your commit on top (though I have some more comments coming)
Comment 3 Ray Strode [halfline] 2012-08-23 20:25:11 UTC
Review of attachment 222234 [details] [review]:

::: tools/gnome-session-check-accelerated-helper.c
@@ +411,3 @@
                 return 1;
+        for (screen = 0; screen < ScreenCount(display); screen++) {

we actually only allow ScreenCount == 1 elsewhere in the code, since shell isn't capable of working in zaphod set ups right now. So, I wouldn't add this loop.

In theory the loop future proofs the code, but if that's the spirit of the change then it should be in a preliminary commit that adds the loop everywhere screen is used, and then a small incremental commit for just this part.

@@ +412,3 @@
+        for (screen = 0; screen < ScreenCount(display); screen++) {
+            if (size < DisplayWidth (display, screen) &&

this should say || not && since we want to fail if either dimension is too small
Comment 4 Ray Strode [halfline] 2012-08-23 20:25:29 UTC
(thanks for looking into this btw)
Comment 5 André Klapper 2012-09-10 15:56:08 UTC
As per comments on desktop-devel-list, this will likely not get fixed "unless somebody with such a card writes a patch and tests it."
So help is welcome.

Adam: Do you have time to update your patch as per last comments?
Comment 6 Bastien Nocera 2012-11-13 13:57:24 UTC
Comment on attachment 222234 [details] [review]

Updated the patch and moved it to gnome-session bug 688252
Comment 7 Bastien Nocera 2012-11-13 17:55:17 UTC
I filed bug 688270 against gnome-session so that it tries hard, on startup, to create a working display configuration if the spanning setup is causing problems for example.

This bug will stay as the bug to handle the UI bits not allowing you to create a broken configuration.
Comment 8 Bastien Nocera 2013-06-12 09:15:59 UTC
*** Bug 702049 has been marked as a duplicate of this bug. ***
Comment 9 Adam Williamson 2013-06-12 16:38:51 UTC
God *damn* it, what is with things being impossible to search in GNOME Bugzilla? I never, ever, ever, ever, EVER find the bug my bug is a dupe of, despite searching through the BGO search and Google Is there a special anti-search plugin or something? :) I even search for '2048 pixels', which is right there in the description of this bug, and didn't find it.
Comment 10 Bastien Nocera 2013-06-12 16:55:31 UTC isn't indexed by Google or any other search engines.
Comment 11 Adam Williamson 2013-06-12 17:39:41 UTC
Best not continue off-topic for too long, but that seems unfortunate. I find Bugzilla's own search to be slow and not particularly good (see above). I search RH bugzilla using google more than I use the in-built search, and usually with better results.
Comment 12 Bastien Nocera 2013-06-13 10:03:42 UTC
*** Bug 595839 has been marked as a duplicate of this bug. ***
Comment 13 Bastien Nocera 2013-06-13 10:05:19 UTC
*** Bug 645087 has been marked as a duplicate of this bug. ***
Comment 14 Bastien Nocera 2013-07-24 16:52:50 UTC
*** Bug 704810 has been marked as a duplicate of this bug. ***
Comment 15 Jonathan Underwood 2013-07-29 23:21:49 UTC
This is an absolute killer bug, rendering recent gnome unusable in a lot of scenarios with the ubiquitous 945 chipset. Is there a workaround that can be applied with currently released Gnome (3.6 and 3.8) while a proper fix is worked on?
Comment 16 Bastien Nocera 2013-07-30 07:04:20 UTC
(In reply to comment #15)
> This is an absolute killer bug, rendering recent gnome unusable in a lot of
> scenarios with the ubiquitous 945 chipset.

"Recent"? It never was capable of running higher resolutions in any version of gnome-shell.

> Is there a workaround that can be
> applied with currently released Gnome (3.6 and 3.8) while a proper fix is
> worked on?

Disconnect the external monitor, or use lower resolutions. The only thing fixing this bug would do is that it would lower the resolution or disconnect one of the monitors, it's not magically going to make your chipset handle larger textures and thus bigger screen sizes.
Comment 17 Bastien Nocera 2014-11-10 00:19:09 UTC
*** Bug 730210 has been marked as a duplicate of this bug. ***
Comment 18 el 2016-03-02 11:38:53 UTC
*** Bug 657431 has been marked as a duplicate of this bug. ***
Comment 19 GNOME Infrastructure Team 2019-03-20 10:53:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: