I would just like to say that I am concerned about this as well. I have tried stacking my displays vertically but it feels unnatural to the point of being unusable. I don't know much about the hardware or xorg limitations at play here but why is the maximum size constrainted to 2048 in any direction? why not 4194304 total pixels?

the work in in progress though slowly...

*** Bug 11939 has been marked as a duplicate of this bug. ***

It's a real hardware limitation, which was fixed in the 965 and later chipsets.  With a bunch of software we can work around it at a significant performance cost, and ajax has been working on that.

ajax is working on Shatter for this: http://linux.conf.au/programme/schedule/view_talk/76?day=friday

Regarding the 965 chipsets, 3D desktop works when the size is bigger than 2048x2048, with a caveat. I believe many users will be stuck with this and think that the 965 does not support hardware acceleration when > 2048x2048.

1. When the desktop size is bigger than 2048x2048 and you run 

$ compiz --replace &
Detected PCI ID for VGA: 
Checking for texture_from_pixmap: not present. 
Trying again with indirect rendering:
Checking for texture_from_pixmap: present. 
Checking for non power of two support: present. 
Checking for Composite extension: present. 
Comparing resolution (2304x800) to maximum 3D texture size (2048): Failed.
aborting and using fallback: /usr/bin/metacity 
$ _

Compiz does not start.

2. However, if you reduce the size (using xrandr) to something less than 2048x2048 and try again

$ compiz --replace &
Detected PCI ID for VGA: 
Checking for texture_from_pixmap: not present. 
Trying again with indirect rendering:
Checking for texture_from_pixmap: present. 
Checking for non power of two support: present. 
Checking for Composite extension: present. 
Comparing resolution (2048x768) to maximum 3D texture size (2048): Passed.
Checking for Software Rasterizer: Not present. 
Checking for nVidia: not present. 
Checking for FBConfig: present. 
Checking for Xgl: not present. 
/usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format
Starting gtk-window-decorator
$ _ 

Now, while the 3D desktop is activated, you can use xrandr to bring the resolution to the original full size (in my case, 2304x800), and the 3D desktop is still working.

Who should we bother to fix the test 'Comparing resolution (2304x800) to maximum 3D texture size (2048): Failed.' so that it does not fail with the 965?

This issue I'm  having with:
Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset

Is this considered pre-965? Will this fix apply to all intel chipsets then? I think quite a lot of people are interested in this being fixed, in fact for me and my colleagues I'd say it's the biggest limitation for our desktops.  Many beers for whoever can get this one taken care of :). Thanks a lot!

(In reply to comment #7)
> This issue I'm  having with:
> Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset
> 
> Is this considered pre-965? 

No. GM45 is supposed to work without this limitation. If you have such problem, please file a separate bug.

Just to re-open this one for a second - surely this can be worked around.

At the moment i'm running a 1440x900 monitor and a 1024x600 monitor 'stacked'. Could the logic be added to xorg to simply wrap the mouse differently, so that the virtual screen used remains 'vertical' but the mouse jumps up between co-ordinates in reaching the side of a screen, producing the effect of a wide horizontal screen in a vertical virtual desktop?

Does anyone know where the code is that handles this? Would it be an easy add or require major changes to the way Xorg does things?

Sorry - I know this is not a feature request forum, but it does seem a logical workaround.

D.

Is any real progress being made on this bug?  It's been open for two years and the only thing I've heard about it is that "ajax is working on Shatter for this".

As a user, I'm concerned what happens with > 2048 pixel setups in the next driver versions that rely on UXA and nothing else.  I've tried UXA before on my dual monitor configuration (1280x1024 VGA + 1024x768 laptop) and get rejected for DRI not being available.  (I'm not even trying to use Compiz - just DRI)

What will happen when I go to install Ubuntu Karmic, or use the xorg-edgers repository, and want to use dual monitors?  Fall back to VESA framebuffer drivers?

Forgive any ignorance here, please.  This is mostly an attempt by me to bring attention to (what is to me) a serious flaw in the drivers.  I'm surprised this bug hasn't garnered more attention, since a quick google will show you countless posts on forums of people who have this problem.

(In reply to comment #11)
> As a user, I'm concerned what happens with > 2048 pixel setups in the next
> driver versions that rely on UXA and nothing else. 

UXA is not supposed to change this bug, though UXA now has another problem in xserver (bug#21190).

This issue should have been fixed together with bug#21190 -- framebuffer has been increased to 4096 for i915/945 (with xf86-video-inte 2.8.0 and drm-intel-next kernel).

Is this really fixed? This has been marked as fixed because bug #21190 was also fixed, but I think that other bug was just related to supporting 4096x4096 *without* DRI.

For something that was hard and needed shatter, it's strange to fix it with a diff that replaces 2048 with 4096.

I am using 2.6.31.6 and Intel Driver Version 2.8.1 and I can now put a 1680x1050 monitor to the right of my netbook 1024x600 panel (combined res 2704x1050).
But the minute I do that, kwin disables compositing, and I cannot re-enable it.

If I put the monitor below or above the netbook panel (combined res 1680x1650) compositing keeps working.

(In reply to comment #14)
> Is this really fixed? This has been marked as fixed because bug #21190 was also
> fixed, but I think that other bug was just related to supporting 4096x4096
> *without* DRI.

It should work (including DRI) if you use a non-compositing window manager like gnome. So I believe this old bug should be closed.
 
> I am using 2.6.31.6 and Intel Driver Version 2.8.1 and I can now put a
> 1680x1050 monitor to the right of my netbook 1024x600 panel (combined res
> 2704x1050).
> But the minute I do that, kwin disables compositing, and I cannot re-enable it.

For the compositing window manager issue, let's track at bug#23718. 

(In reply to comment #15)
> (In reply to comment #14)
> > Is this really fixed? This has been marked as fixed because bug #21190 was also
> > fixed, but I think that other bug was just related to supporting 4096x4096
> > *without* DRI.
> 
> It should work (including DRI) if you use a non-compositing window manager like
> gnome. So I believe this old bug should be closed.
> 
> > I am using 2.6.31.6 and Intel Driver Version 2.8.1 and I can now put a
> > 1680x1050 monitor to the right of my netbook 1024x600 panel (combined res
> > 2704x1050).
> > But the minute I do that, kwin disables compositing, and I cannot re-enable it.
> 
> For the compositing window manager issue, let's track at bug#23718. 
> 

You are absolutely right. I was able to set a bigger-than 2048 resolution on my desktop, and then start openarena in windowed mode, and it still ran with DRI (up to 2047x2047). 

I didn't think to test it before because I thought the compositing being disabled meant I'd lost DRI, but I was wrong.

Marking this bug as verified then.