Max GL texture size can break multi-head

Here's the promised photo showing the EeePC and it's external monitor and their funky garbledness...

I can confirm this bug as I have observed it on every system I've tested Oneiric Alpha 3 on, this includes about 30 laptops of different makes and models, with chipsets from Intel, NVidia and AMD. Here are my observations:

1- On Intel N10 systems, such as the Eee PC 1001 reported by Jeff, I get the exact same corrupted pattern he describes. Note that there are already bugs covering compiz-related problems with external displays on N10-based systems (bug 807161 and bug 790824) so in that particular case we might actually be looking at two problems.

2- On other Intel systems I get a different pattern: the external screen is entirely black, except for the top panel, and the built-in display shows a "dead zone" on the top fourth of the screen, while the bottom 3/4ths are alive and well. I'm attaching a screenshot of the internal display of an affected Intel machine.

3- On NVidia systems I get blocks of solid white or blue, with specks of other colors scattered about. I'll try to get and attach a picture of this.

4- Here's the interesting bit: it happens only when running Unity. If I select Ubuntu 2d upon login, external screen functionality works fine. On my Ubuntu 2d system I did ps wwuxa |grep compiz and compiz seems to be running, so it would indeed appear to be Unity3D-related.

I confirmed this on an Oneiric A3 installation, fully dist-upgraded as of today, August 11th.

Please let me know if I should attach logs, perform some more tests, or maybe split this into different bugs, though it seems clear to me that this happens everywhere with two screens.

Importance: Critical as it has a "severe impact on a large portion of Ubuntu users", potentially everyone needing to connect a laptop to an external display, be it a monitor or a projector. Driving external displays is a big use case for portable computers. This happens on every tested laptop when connecting an external screen, and while the workaround is to use Unity 2d, it should be ensured that the primary desktop environment for Ubuntu works for this vast group of users.

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

This may be fixed in recent updates. I noted this on every laptop I've tested this week, but today, on the latest test system, a Lenovo L512 with integrated Intel graphics, this did not happen with either external VGA or DisplayPort. This system was installed and updated freshly this morning.

Nope... just rechecked on two freshly updated EeePCs. both display the corruption issue. The L512 is the only system I've tried so far that did not exhibit this behaviour.

FTR, external display working fine here with compiz (Intel Arrandale).

pitti: I wonder... of all the systems I tested that failed due to this issue, only ONE was successful, and that was a Lenovo L512. I wonder if there's something to that, if now you have a working system as well.

The problem has been further investigated and it was found to be due to an installation issue, as later confirmed by the various testers working on this issue.

What was the installation issue? I personally observed this on 10 different systems, all installed the same way with the default install options for Ubuntu. If this is due to something in the way we were installing, it would be good to know how to prevent that in the future.

Ok, it looks like this will be relatively easy; there's already support for failing to configure displays when the framebuffer gets bigger than the maximum virtual size. Adding a check to fail when the framebuffer gets bigger than the max GL texture size *should* be straightforward.

Status changed to 'Confirmed' because the bug affects multiple users.

I've got a patch for this; I'm cleaning it up and will propose a merge.

El dt 27 de 09 de 2011 a les 16:13 +1000, en/na Christopher James Halse
Rogers va escriure:
> Bug https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/824099
> requests a string freeze exception request for gnome-desktop3's XRandR
> support. The workaround for this bug requires that gnome-desktop
> refuses to configure a multi-head display with a size exceeding
> GL_MAX_TEXTURE_SIZE when Unity is running. This requires a new error
> message in gnome-rr-config.c, which will be shown to the user,
> explaining why their configuration request has been rejected and what
> they can do about it.
>
> Thanks,
> Chris Halse Rogers.
>

Thanks for notifying translators and documenters, Chris.

It makes sense to me if the error message is necessary and if it only
means adding a new string and not changing existing ones, so +1 from the
translations side, unless there is any objection.

Translators, this means adding the following string:

"Requested size (%d, %d) exceeds 3D hardware limit (%d, %d).\n"
"You must either rearrange the displays so that they fit within a (%d, %
d) square\n"
"or select the Ubuntu 2D session at login.")"

Cheers,
David.

--
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanella.wordpress.com
www.identi.ca/dplanella / www.twitter.com/dplanella

This is a rather big and not yet widely tested patch, but the only option we have right now to prevent people from breaking their screen config, so we need to take it. The error prone bits are in the separate callout, so the impact of bugs there is indeed rather limited.

Thanks for working on this, Chris!

This bug was fixed in the package gnome-desktop3 - 3.2.0-0ubuntu2

---------------
gnome-desktop3 (3.2.0-0ubuntu2) oneiric; urgency=low

  * debian/patches/02_refuse_to_break_GL_compositors.patch:
    - Check whether Unity is running and if so refuse to configure a multi-head
      setup larger than GL_MAX_TEXTURE_SIZE. Works around breakage when using
      Unity on such a setup, which is as much as we can do to fix (LP: #824099)
      at this point. In 12.04 this should be dropped in favour of making Unity
      work properly.
  * debian/control.in:
    - Add libgl1-mesa-dev and dh-autoreconf to Build-Depends for above patch.
  * debian/rules:
    - Use dh-autoreconf to regenerate build system to pick up changes from
      patch.
 -- Christopher James Halse Rogers <email address hidden> Wed, 28 Sep 2011 20:08:59 +1000

The fix for this bug (in gnome-desktop3 3.2.0-0ubuntu2) seems to break my system: after getting the lightdm greeter and entering my user password to log in, I get a black screen, the screen flickers a few times like if X were crashing a few times. A few seconds later I do get the Unity interface but:

1. I see some things gone wrong in dmesg:

[ 41.741320] init: plymouth-stop pre-start process (1900) terminated with stat
us 1
[ 53.084817] init: lightdm main process (1271) killed by ABRT signal
[ 69.681566] show_signal_msg: 12 callbacks suppressed
[ 69.681570] check_gl_textur[2259]: segfault at 84 ip 080486bf sp bfa17a00 error 4 in check_gl_texture_size[8048000+1000]

2. Probably because of the message above about lightdm main process dying, I cannot logout (Unity is gone and nautilus stays running and in control of the root window).

I rebooted the machine twice to confirm. Downgrading libgnome-desktop-3-2 to 3.2.0-0ubuntu1 fixes the problem (rebooted after downgrading and didn't get the messages above).

I am sorry for the lack of details -- I just don't know what information might be useful to provide. I don't even know if I should be filing a new bug for this. Here's something to get started but I am happy to provide more information if requested:

* I am not using a multi-head setup when this happens (this is a laptop with a single screen).

* nVidia driver.

* Might not be X crashing. Instead, it seems like whatever is running on top of X (lightdm) is crashing. I do see the typical X-shaped cursor for a bit.

Cheers,

Eloy Paris.-

Ok. It's known that checking GL attributes might cause a crash, which is why it's done in a separate process, which shouldn't affect the main login sequence. Why is this stopping login, I wonder?

Does a file in /var/crash get generated when you try to login? That should contain useful debugging info.

I'm not able to reproduce this, and from the logs you've posted it looks like lightdm aborts well before the new gnome-desktop codepath is reached. Could you please try upgrading back to libgnome-desktop-3-2 3.2.0-0ubuntu2 to see whether this was caused by an unrelated issue that got fixed with a package install?

Could that be related to: https://bugs.launchpad.net/ubuntu/+source/nux/+bug/764044 ?

Hi Chris,

I upgraded back to libgnome-desktop-3-2 3.2.0-0ubuntu2 and I am no longer seeing the problem.

There are two other things that are different, though:

1. This time I turned the machine off instead of just doing a full restart. I don't know if this resets the hardware in some special way and makes the issue go away.

2. There were some package upgrades. There was nothing out of the ordinary with the possible exception of a unity upgrade.

In /var/crash, there was a core dump for check_gl_textur, but nothing else around the same time.

Cheers,

Eloy Paris.-

On Fri, 2011-09-30 at 11:17 +0000, Eloy Paris wrote:
> Hi Chris,
>
> I upgraded back to libgnome-desktop-3-2 3.2.0-0ubuntu2 and I am no
> longer seeing the problem.
>
> There are two other things that are different, though:
>
> 1. This time I turned the machine off instead of just doing a full
> restart. I don't know if this resets the hardware in some special way
> and makes the issue go away.
>
> 2. There were some package upgrades. There was nothing out of the
> ordinary with the possible exception of a unity upgrade.

I think I'll chalk this up as a broken package upgrade. I don't think
this is an issue with the libgnome-desktop-3-2 update.

If it looks like this is wrong, please feel free to report it here.

I should note that the description is somewhat inaccurate:
1) Multi-head isn't really the problem, just the easiest way to reproduce it. A single display with a high enough resolution can trigger it as well.
2) There are two separate limits: max texture size and max framebuffer size. The former can be worked around by breaking large windows into multiple textures, but this won't help the latter. GL init fails and all drawing operations do nothing, leaving the user with a display of random uninitialized VRAM (i.e. corrupted display, thick slanted lines, chunks of wallpaper etc).

This bug was fixed in the package gnome-desktop3 - 3.3.5-0ubuntu1

---------------
gnome-desktop3 (3.3.5-0ubuntu1) precise; urgency=low

  * Sync with Debian. Remaining changes:
  * New upstream release.
    - GnomeRR:
      - Use GDK to get work area
      - gnome_rr_screen_new() now creates a singleton for the specified
        GdkScreen
    - GnomePnpIds: Add object to get the vendor name from PNP IDs
  * debian/libgnome-desktop-3-2.symbols: Updated for above changes
  * debian/patches/02_refuse_to_break_GL_compositors.patch:
    - Check whether Unity is running and if so refuse to configure a multi-head
      setup larger than GL_MAX_TEXTURE_SIZE. Works around breakage when using
      Unity on such a setup, which is as much as we can do to fix (LP: #824099)
      at this point. In 12.04 this should be dropped in favour of making Unity
      work properly.
  * debian/control.in:
    - Add libgl1-mesa-dev and dh-autoreconf to Build-Depends for above patch.
    - Bump minimum xrandr to 1.3
  * debian/libgnome-desktop-3-2.install: Install check_gl_texture_size
  * debian/rules:
    - Use dh-autoreconf to regenerate build system to pick up changes from
      patch.
  * debian/watch: watch for unstable releases

gnome-desktop3 (3.2.1-3) unstable; urgency=low

  * Upload to unstable.
  * debian/control.in:
    - Tighten dependency on gnome-desktop3-data again.
    - Change section of gir1.2-gnomedesktop-3.0 to introspection.

gnome-desktop3 (3.2.1-2) experimental; urgency=low

  * debian/control.in:
    - Loosen the dependency on gnome-desktop-data for now such that
      libgnome-desktop-3-2 is installable in parallel with
      libgnome-desktop-3-0

gnome-desktop3 (3.2.1-1) experimental; urgency=low

  * New upstream release.
    - Link against -lm for sqrt. Closes: #640437
  * debian/watch:
    - Update to version 3.
    - Track .xz tarballs.
  * debian/control.in:
    - Use Section: libs for gir1.2-gnomedesktop-3.0.
    - Drop (Build-)Depends on libstartup-notification0-dev.
    - Add Build-Depends on libxext-dev.
    - Update Vcs-* URLs.
    - Bump Build-Depends on intltool to (>= 0.40.6).
  * debian/rules:
    - List missing files.
    - Include utils.mk for list-missing.
    - Drop clean-la.mk since we don't install any .la files.
  * debian/libgnome-desktop-3-dev.install:
    - Remove .a file, static libraries are no longer built by default.
  * Update libgnome-desktop-3 library package for the SONAME bump 0 → 2.
 -- Jeremy Bicha <email address hidden> Mon, 06 Feb 2012 13:25:25 -0500

Does the remainder of this bug then be essentially dupe with bug #830949?

Gnome display manager now shows a warning message and prevents the user form setting a resolution that is higher than the maximum supported.

I think it's unlikely this bug will ever be "solved", the warning is good enough. While it's possible to work around maximum texture size limitations, this does not come without overhead, and that's on old GPUs with limited performance to start with. All modern and most not-that-modern GPUs support at least 4096x4096 textures.

Jay told it's not possible to do in unity-3d with a reasonable amount of effort. We will keep the workaround for now

I investigated a little bit, here's what GPU generation brought 4K texture support, per manufacturer:

NVidia: GeForce FX series, released in 2003
AMD: Radeon X1000 series, released in 2005
Intel: this is the odd one out, again: GMA X4500, released in 2008

On a laptop that supports 3d unless an attempt is made to extend the desktop onto a second monitor, when the attempt to use the second monitor is made a dialog pops up saying that unity is not supported and that unity-2d should be used instead. Since that is no longer an option the message should be changed to one giving an indication of the workaround.

In my naivity I had assumed that this bug would be sorted by the use of llvmpipe in the same way that it is to be solved for hardware that does not support 3d in the first place. Is that not the case?

This needs to be re-opened on gnome-desktop3 as on Quantal the error message shown is no longer appropriate as unity-2d is not available. As well as changing the error message is it not the case that on Quantal the underlying problem can be solved by the use of llvmpipe? I keep asking this question but no-one has responded.

The existing message is

"Requested size (%d, %d) exceeds 3D hardware limit (%d, %d).\n"
"You must either rearrange the displays so that they fit within a (%d, % d) square\n"
"or select the Ubuntu 2D session at login.")"

Please note, compiz 0.9.8.0 (released yesterday and coming soon to quantal) will probably make this problem worse. That's because we use a single texture to blit the whole screen now. But there is a plan to fix that --> bug 1040478.

Fixing bug 1040478 should be considered a prerequisite to fixing this bug.

It's too late for Quantal now. Removing release team subscription.