Ubuntu
xorg-server package

MASTER: max texture size prevents compiz from running

Bug #555641 reported by Gazs on 2010-04-05

This bug report is a duplicate of: Bug #824099: Max GL texture size can break multi-head. Edit Remove

This bug affects 14 people

Affects		Status	Importance	Assigned to	Milestone
	compiz (Ubuntu)	Confirmed	Undecided	Unassigned
	xorg-server (Ubuntu)	Triaged	Wishlist	Unassigned

Bug Description

[Problem]
Running compiz with dual-head enabled on certain graphics cards does not work. Compiz either errors out and refuses to run, or else fails with a black screen.

Compiz displays the desktop as a 3D texture. The maximum texture size is determined by the hardware capabilities of the particular graphics card. Some older or lower end cards have a limitation of 2048x2048, which means if you set up a side-by-side arrangement, the sum of the horizontal resolutions could exceed 2048.

Some example max texture limits:

Radeon Xpress 200M: 2048x2048
Radeon X1600/X1900: 4096 x 4096
Radeon HD 2400: 8192 x 8192
Radeon HD 2600/4670/4850/4870: 8192 x 8192
GeForce 7300/7600: 4096 x 4096
Quadro FX 4500: 4096 x 4096
GeForce 8600/880/9400/9600/120/130/285: 8192 x 8192
Quadro FX 4800: 8192 x 8192
i945: 2048 x 2048
GMA 950: 2048 x 2048
GMA X3100: 2048 x 2048

[Workarounds]
A. If monitors are rectangular, arrange them above/below instead of left/right

B. Turn off compiz

[Original Report]
I'm using a Lenovo S10-2 netbook (Intel GMA950 chipset, 1024x600 internal resolution). When I connect a VGA display (Samsung SyncMaster 757NF) and set it to span, both screens go black with only the mouse cursor visible.

The secondary display works fine if I set it to 832x624 or lower (but this is not really an acceptable option with the size of the display, etc)

Using Ubuntu lucid with all updates. This bug was present in karmic as well.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: xorg 1:7.5+3ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-19.28-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-19-generic i686
NonfreeKernelModules: wl
Architecture: i386
Date: Mon Apr 5 12:44:50 2010
DkmsStatus:
bcmwl, 5.60.48.36+bdcom, 2.6.32-19-generic, i686: installed
bcmwl, 5.60.48.36+bdcom, 2.6.31-20-generic, i686: installed
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
MachineType: LENOVO 20027
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-19-generic root=UUID=8776efb2-cf16-456a-850a-5ade325b538a ro quiet splash
ProcEnviron:
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: xorg
dmi.bios.date: 10/02/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 1ACN21WW(V1.12)
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: Mariana2
dmi.board.vendor: LENOVO
dmi.board.version: Base Board Version
dmi.chassis.asset.tag: Chassis Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: Chassis Manufacturer
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnLENOVO:bvr1ACN21WW(V1.12):bd10/02/2009:svnLENOVO:pn20027:pvrLenovoIdeaPadS10-2:rvnLENOVO:rnMariana2:rvrBaseBoardVersion:cvnChassisManufacturer:ct10:cvrChassisVersion:
dmi.product.name: 20027
dmi.product.version: Lenovo IdeaPad S10-2
dmi.sys.vendor: LENOVO
system:
distro: Ubuntu
codename: lucid
architecture: i686
kernel: 2.6.32-19-generic

See original description

Tags:

Revision history for this message

Gazs (gazs) wrote on 2010-04-05:

BootDmesg.txt Edit (47.5 KiB, text/plain; charset="utf-8")
CurrentDmesg.txt Edit (3.2 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (4.5 KiB, text/plain; charset="utf-8")
GdmLog.txt Edit (29.3 KiB, text/plain; charset="utf-8")
GdmLog1.txt Edit (28.4 KiB, text/plain; charset="utf-8")
GdmLog2.txt Edit (29.5 KiB, text/plain; charset="utf-8")
Lspci.txt Edit (12.0 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (491 bytes, text/plain; charset="utf-8")
PciDisplay.txt Edit (1.2 KiB, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (1.4 KiB, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (1.4 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (2.9 KiB, text/plain; charset="utf-8")
RelatedPackageVersions.txt Edit (231 bytes, text/plain; charset="utf-8")
UdevDb.txt Edit (122.2 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (247.4 KiB, text/plain; charset="utf-8")
XorgLog.txt Edit (32.9 KiB, text/plain; charset="utf-8")
XorgLogOld.txt Edit (32.5 KiB, text/plain; charset="utf-8")
Xrandr.txt Edit (17.5 KiB, text/plain; charset="utf-8")
glxinfo.txt Edit (16.4 KiB, text/plain; charset="utf-8")
monitors.xml.txt Edit (1.4 KiB, text/plain; charset="utf-8")
setxkbmap.txt Edit (233 bytes, text/plain; charset="utf-8")
xdpyinfo.txt Edit (19.1 KiB, text/plain; charset="utf-8")
xkbcomp.txt Edit (47.4 KiB, text/plain; charset="utf-8")

Bryce Harrington (bryce) on 2010-04-05

affects:

xorg (Ubuntu) → xorg-server (Ubuntu)

Bryce Harrington (bryce) on 2010-04-05

Changed in xorg-server (Ubuntu):
status:	New → Confirmed

Revision history for this message

Bryce Harrington (bryce) wrote on 2010-04-07:

Does it work properly if you disable desktop effects?

affects:	xorg-server (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
Changed in xserver-xorg-video-intel (Ubuntu):
status:	Confirmed → Incomplete

Revision history for this message

Gazs (gazs) wrote on 2010-04-07:

Yes, then I can use all possible resolutions, up to the display's native 1600x1200

Revision history for this message

Bryce Harrington (bryce) wrote on 2010-04-08:

Okay yeah... so what's going on there is that your hardware has a rendering buffer unit which supports textures up to a certain maximum size, which in the case of the GMA950 is only 2048x2048. Compiz renders the entire desktop as a single texture, so the max texture size is a limitation that affects dual-head cases.

A workaround is instead of putting the monitors side-by-side to make them one-above-the-other.

This won't be fixed at the distro level or in compiz (it's a hardware limitation), so I'm marking this wontfix. The solution will ultimately come when X.org upstream brings back Xinerama-mode so that you can have multiple screens each smaller than the max texture size, but stitched together in a way that allows multi-screen desktop layouts.

For more info see: http://wiki.compiz.org/FAQ#Root_window_is_larger_than_maximum_texture_size

summary:	- cannot set resolution on secondary display above 823x624 + MASTER: max texture size prevents compiz from running
affects:	xserver-xorg-video-intel (Ubuntu) → xorg-server (Ubuntu)
Changed in xorg-server (Ubuntu):
importance:	Undecided → Wishlist
status:	Incomplete → Triaged

Bryce Harrington (bryce) on 2010-04-08

description:

updated

Bryce Harrington (bryce) on 2010-04-08

description:

updated

Revision history for this message

Gazs (gazs) wrote on 2010-04-08:

Thanks for figuring this out.

Revision history for this message

Travis Watkins (amaranth) wrote on 2010-04-13:

Actually this is a "fix" for this in the compiz C++ version (which might even be released someday). When it detects a window is larger than max texture size it falls back to (iirc) copySubBuffer and splits the texture in to two or more pieces. This is much slower than using the texture_from_pixmap system but is usually only needed for the desktop window which does not change much.

Ideally Xorg would sort this out though which I believe is the point of the 'shatter' work.

Revision history for this message

Travis Watkins (amaranth) wrote on 2010-04-13:

Err, there is a "fix", rather.

Revision history for this message

Kory (postmako) wrote on 2010-05-20:

Attached is the modified patch Edit (6.6 KiB, text/plain)

I noticed that in the source the developer checks for res >= maxTextureSize. There is a problem with this because it should be res > maxTextureSize. I modified patch 060 in the compiz package because my maxTextureSize is 2048x2048 but my screen res is 2048x1536. So compiz says it is unable to run but when I modified the source and rebuilt it with res > maxTextureSize then everything works fine. So whomever works on this needs to modify the logic to be greater than rather than greater than or equal to as I have done to patch 060.
Thanks,
Kory

Revision history for this message

Robert Hooker (sarvatt) wrote on 2010-05-20:

Kory: Are you on ATI? There is a problem on Intel at least where a single monitor at 2048xwhatever does not work and it was causing a large amount of bug reports where things were unusable and black on first boot because of it, thats why it was changed to >= maxTextureSize (the bug number is in the compiz changelog)

There is work being done to get around this in the future with xrandr 1.4 though as well, but it is some time off. A snippet out of the protocol change:

+1.4 Introduction to version 1.4 of the extension
+
+Version 1.4 adds a couple more capabilities to further expose the
+underlying hardware to clients
+
+ • Per-crtc pixmaps. This provides for multiple scan-out buffers
+ which applications can create and assign to arbitrary collections
+ of crtcs. These pixmaps can be associated with a window for use
+ with OpenGL or drawn to directly.
+
+ • RRSetCrtcConfigs request. This supplies a set of
+ crtc configurations to the server that must be applied together
+ or not at all. This can reduce screen flicker while also
+ providing the server a complete configuration for appropriate
+ resource management.
+

Bryce Harrington (bryce) on 2011-04-14

description:

updated

Bryce Harrington (bryce) on 2011-04-26

description:

updated

Revision history for this message

Robert Hooker (sarvatt) wrote on 2011-08-03:

#10

The xserver side of this (xrandr 1.4) did not make it into xserver 1.11 even and most likely will not make it into Ubuntu until the 12.10 time frame given that if it is even completed for 1.12 that will be released pretty late into the LTS cycle unfortunately.

Launchpad Janitor (janitor) on 2011-08-17

Changed in compiz (Ubuntu):
status:	New → Confirmed

Revision history for this message

toobuntu (toobuntu) wrote on 2011-09-13:

#11

I am not convinced this is really a duplicate of Bug #824099. There are no thick slanted lines, etc.

Revision history for this message

Rena Kunisaki (i-am-inuyasha) wrote on 2011-09-14:

#12

I think bug #824099 might be related to framebuffer size (plugging in the extra screen makes the display area bigger) and may well be the same issue as bug #789385, whereas this bug relates to max texture size. The former limits the size of your total display area, whereas the latter limits the size of individual windows (which unfortunately includes the root window which occupies the entire display area anyway).