compiz starts with a blank screen on a 2048x1152 monitor due to hw limit with textures > 2048

forgot to say, with a different monitor with 1024x768 resolution it works just perfectly in Karmic.

Same to me with composite in kubuntu in 2048x1152. With 1024x768 resolution works fine.

Same thing on Ubuntu Karmic Koala with a Dell 23" 2048x1152.

Using metacity it works.

For me reconfigures the screen size lower than the maximum 3D texture size 2048 helps.

# xrandr --fb 2046x1152

Running glxgears with window width greater then 2048 there is an black window...

good tip Sebastian, I can now resize the screen with "xrandr --fb 2040x1152" (it prefers an 8 pixel boundary) followed by restarting compiz with "compiz --replace" to get a working system with just 8 pixels of corruption on the far right.

Trouble is that even if you sacrifice some pixels to get it working, if you maximise a window it tries to make the window 2048 wide, exceeds the max texture size and screen size and compiz collapses in a heap.

quoted from the top of this page: "This bug affects you and 5 other people"

I'm going to go a little off topic and state the obvious, because this has to be fixed. This bug directly affects thousands of people. 6 of them have seen this page in 4 months. Nearly all affected users and would-be users have seen A BLANK SCREEN, and have given up on Ubuntu.

The real bug is that, with this increasingly common hardware configuration, Compiz is turned on by default, and nothing is ever displayed. No error report is generated. The installation process goes nowhere, or an upgrade results in an unusable computer.

This is from the point of view of a user. If you're trying out an alternative to Microsoft Windows (see Bug #1) and don't have expert help, the result is COMPLETE USABILITY FAILURE.

This rant continues here: http://technophobe.net/lucid_lynx/#compiz_bug_comment

I suggest posting further off-topic comments here: http://mnotes.spodcast.net/2010/01/ubuntu-2048x1152-blank-screen-bug-fix.html

The scenario to trigger the bug is quite clear, intel graphics, max texture size 2048 and a monitor of exactly 2048 horizontal resolution. Any higher and Compiz won't start and it falls back to metacity, any lower and it works fine. Compiz tests to see if the resolution is <= max texture size.
It would be good to get some guidance as to where the bug is, and what should be done about it. If Compiz were adjusted to work only on resolutions strictly less than max texture it would avoid the black screen problem. As Compiz demonstrably works fine on Jaunty it would be great to have these monitors working on intel chipsets under Karmic/Lucid, but if that won't be supported at least lets make it not have the black screen failure mode.

better upstream bug - and it might have a fix!

not fixed in Lucid daily CD AMD64 from yesterday.

tried Lucid alpha 3 fully updated to today, still happens. Installed the xorg-edgers ppa and upgraded, still happens.

can we just get compiz to not load and fall back to metacity if the resolution is equal to max texture size please. At the moment I think it runs if the resolution is less than or equal to max texture size lets change it to a strict less than to prevent the black screen.

Hmm, well the upstreamed bug is closed as believed fixed. Maybe you should reopen it and elaborate on the remaining problem?

Meanwhile, your recommendation to make compiz not start up if it detects this situation is a good one, I'll forward this to the compiz team.

I took another look at this as part of handling bug #556631.

In Karmic, /usr/bin/compiz was a shell script, which included a check for max texture size:

check_texture_size()
{
        # Check how many screens we've got and iterate over them
        N=$(xdpyinfo | grep -i "number of screens" | sed 's/.*[^0-9]//g')
        for i in $(seq 1 $N); do
            verbose "Checking screen $i"
            TEXTURE_LIMIT=$(glxinfo -l | grep GL_MAX_TEXTURE_SIZE | sed -n "$i s/^.*=[^0-9]//g p")
            RESOLUTION=$(xdpyinfo | grep -i dimensions: | sed -n -e "$i s/^ *dimensions: *\([0-9]*x[0-9]*\) pixels.*/\1/ p")
            VRES=$(echo $RESOLUTION | sed 's/.*x//')
            HRES=$(echo $RESOLUTION | sed 's/x.*//')
            verbose "Comparing resolution ($RESOLUTION) to maximum 3D texture size ($TEXTURE_LIMIT): ";
            if [ $VRES -gt $TEXTURE_LIMIT ] || [ $HRES -gt $TEXTURE_LIMIT ]; then
                verbose "Failed.\n"
         return 1;
            fi
            verbose "Passed.\n"
        done
        return 0
}

It appears that as of 1:0.8.4-0ubuntu4 in lucid, the checks that the compiz wrapper had been doing have moved to the compiz binary itself:

bryce@blumonc:~$ cat /etc/lsb-release ; file /usr/bin/compiz
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu lucid (development branch)"
/usr/bin/compiz: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

compiz (1:0.8.4-0ubuntu4) lucid; urgency=low
...
  [ Travis Watkins ]
  * debian/patches/060_move_checks_to_compiz.patch:
    - add all relevant checks from compiz-manager to compiz itself
      Compiz already checks for almost everything it needs so there is no
      need to check twice.

So the texture size check appears to be occurring in this chunk of the patch:

@@ -244,13 +246,21 @@
     CompFBConfig *config = &screen->glxPixmapFBConfigs[depth];
     int attribs[7], i = 0;

+ if (width > screen->maxTextureSize || height > screen->maxTextureSize)
+ {
+ compLogMessage ("core", CompLogLevelWarn,
+ "Exceeded max texture size");
+
+ launchFallbackWM ();
+ }
+
     if (!config->fbConfig)
     {
  compLogMessage ("core", CompLogLevelWarn,
    "No GLXFBConfig for depth %d",
    depth);

- return FALSE;
+ launchFallbackWM ();
     }

     attribs[i++] = GLX_TEXTURE_FORMAT_EXT;

So that all looks like it should work... You should get an error message "Exceeded max texture size" in your compiz log

While the tone of comment #8 is entirely inappropriate, I agree with its assessment that, if indeed this is a regression with compiz, it is quite serious and needs attention soon

I *think* the problem may be that this code:

+ if (width > screen->maxTextureSize || height > screen->maxTextureSize)

needs to be:

+ if (width >= screen->maxTextureSize || height >= screen->maxTextureSize)

I uploaded a new compiz now with the change suggested in comment #17. I don't have the required hardware to test it myself, please let me know if it works and stops compiz from running.

This bug was fixed in the package compiz - 1:0.8.4-0ubuntu15

---------------
compiz (1:0.8.4-0ubuntu15) lucid; urgency=low

  * debian/patches/060_move_checks_to_compiz.patch:
    - improve the maxTextureSize check to test for >= instead of
      just > (thanks to bryceh) LP: #428769
 -- Michael Vogt <email address hidden> Thu, 08 Apr 2010 09:22:03 +0200

fix confirmed using the Lucid RC desktop AMD64 cd. Compiz does not start and the desktop is displayed fine, with no desktop effects.

Umm... I don't know about anyone else but I just installed 1:0.8.4-0ubuntu15.1 from lucid-proposed, and its not working. Same problem, except mine is with dual monitors. I max at 2048x2048, and I set my resolution to (total) 2048x768. Still getting "compiz (core) - Warn: Exceeded max texture size"

Here's the progression

lordquackstar@quackdesk-linux:~$ ./compiz-check

Gathering information about your system...

Distribution: Ubuntu 10.04
Desktop environment: GNOME
Graphics chip: ATI Technologies Inc RV410 [Radeon X700 (PCIE)]
Driver in use: radeon
Rendering method: AIGLX

Checking if it's possible to run Compiz on your system...

Checking for texture_from_pixmap... [ OK ]
Checking for non power of two support... [ OK ]
Checking for composite extension... [ OK ]
Checking for FBConfig... [ OK ]
Checking for hardware/setup problems... [ OK ]

lordquackstar@quackdesk-linux:~$ compiz --replace
WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug!
compiz (core) - Warn: Exceeded max texture size

Launching fallback window manager

@Leon you have an ATI card, not an Intel card. I suggest you file a new bug.

This is not a bug fix (in my opinion) it is a workaround which is just covering up the real problem.
I am unable to start Compiz on a 945 with 2048*1152 resolution presumably because of this 'fix'.
As the max texture size is 2048*2048, Compiz should be able to run with this resolution, it does not exceed the max texture size. What is the real issue here, has the cause been identified?

OK Sorry about that, I just did a clean install of 10.10, and it works. Happy Days :)