Comment 15 for bug 745112

Roland, thanks for that.

Alright, here is what I think is happening. Arrandale graphics cards have a hardware limitation of a max texture buffer size of 4096x4096. What this means is that compositing will work only if the total screen width is 4096 or less. Over that, and the GPU can lock up or other weird things can occur.

My hypothesis is that when you are booting with the laptop docked, the internal laptop LVDS panel is disabled, so your total width is 1920+1920 which is <4096. However, when you boot with the laptop panel on and *then* dock, the kernel is adding the two monitors to the left or right of the laptop panel, resulting in 1920+1920+1440 which is >4096.

Looking at your monitors.xml, the first section shows HDMI2 and HDMI3 arranged side-by-side, and LVDS1 is also present and not disabled but not set to any particular position, so it is unclear how the kernel would position it in this case; perhaps it is adding it at +3840+0 which would fit with my hypothesis.

There are a few things you could test which might prove my hypothesis wrong:

a. This behavior should occur only with Unity/Compiz. If you boot Classic Desktop (No Effects), the system freeze should be unreproducible. (However, see below)

b. If in gnome-display-properties you arrange your LVDS to be positioned *below* your two main monitors, it should work in unity. Note you may need to delete your monitors.xml before making these settings.

c. If you disable your LVDS before docking (either using the GUI, or via 'xrandr --output LVDS1 --off') and then docking, the system shouldn't freeze. (I don't know if the external monitors will fire up in this case, but at least it won't trigger the freeze bug).

These may also give you some idea on working around the issue.

If those tests turn out correct, then this issue is basically a sub-case of bug #555641. However, I think that there could be some work done in gnome-display-properties to check max texture size before enabling configurations like this, if compiz is running.

Now, one other caveat. It appears that there is a separate unrelated bug that is common to Arrandale, that certain RANDR operations can sometimes result in a monitor being improperly blanked. So, that may add some confusion to your testing. But the way to tell these bugs apart is that your original bug results in a system lockup (a black screen with a mouse pointer, and no way to recover), whereas with this latter blanking bug, you won't see a mouse cursor and the monitor will appear to be not getting any signal. Possibly you may be able to work around this blanking issue via this command:

xset dpms force on

Anyway, sorry for the lengthy dissertation, but hopefully with this information you can help me nail down this bug. I have some thoughts on what steps to take to get resolution to this issue (and the blanking one) but let's see if you can prove my hypothesis before we get into all that.