Clipped area for multiple X screens with different dimensions

[Redundant and completely unnecessary to have this filed against the xorg as well as the other component]

Turns out it is a problem with Compiz.

Disabling Compiz and returning to Metacity clears the problem.

Conversation with Compiz developers on #compiz-fusion-dev confirming this is an issue with the latest release:

<IntuitiveNipple> With the Ubuntu Jaunty (1:0.7.9+git20090211-0ubuntu4) package, using two X screens of different dimensions, there is an out-of-bounds (black) region on the 2nd screen where desktop and windows can't go, but the mouse can. Is this known? I'm not finding anything in the bug-tracker.
<IntuitiveNipple> I'm just about to try latest git head just-in-case
<smspillaz> two X screens or two X outputs?
<smspillaz> screen != output
<IntuitiveNipple> two X screens (:0.0 and :0.1)
<smspillaz> I don't think we support two X screens of different dimentions
<smspillaz> start one compiz instance per screen with --only-current-screen
<crdlb> srsly? ouch
<IntuitiveNipple> It worked fine with previous versions... this appears as a regression when updating to Jaunty, at least.
<crdlb> don't try latest git head, btw
<smspillaz> We do support two _outputs_ of different dimentions
<smspillaz> crdlb++
<crdlb> depending on which one you use, you'll either get exactly the same thing you have
<crdlb> or a completely broken compiz
<smspillaz> IntuitiveNipple: nevertheless, you won't find much love in the current git head
<IntuitiveNipple> There's photo's attached to the Ubuntu bug report if it'd help: https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/331918
<smspillaz> IntuitiveNipple: we've dropped multi-screen support completely ;-)
<IntuitiveNipple> smspillaz: That's a shame
<smspillaz> multi-screen was an X hack
<crdlb> lol, don't phrase it that way
<crdlb> IntuitiveNipple: it'll just always use --only-current-screen, essentially
<smspillaz> If you want multi-screen, start one compiz instance per screen
<crdlb> "an X hack"?
<smspillaz> pretty much
<IntuitiveNipple> smspillaz: So, that suggests the Ubuntu start-up scripts will need to change then
<crdlb> there's nothing hacky about it, it's just lots of work with very little testing
<smspillaz> it's been mostly superseeded by xrandr 1.2, twinview, xinerama etc
<crdlb> IntuitiveNipple: that's not in 0.8
<crdlb> oh ...
<crdlb> except for the whole using two GPUs part ...
<smspillaz> IntuitiveNipple: multi-screen support is still in 0.8 but it is probably broken, that is because no developers actually can be bothered to test it because it is such a pain to set up
<IntuitiveNipple> So, should I open a bug for this?
<smspillaz> you can, but I don't think it will be fixed unless someone sits down and does the work to set up multi-screen ;-)
<smspillaz> IntuitiveNipple: you can use --only-current-screen now though (and have two compiz instances)
<crdlb> if it worked in 0.7.8, it might be a simple regression that could be fixed in a future 0.8 release
<smspillaz> it works better that way
<IntuitiveNipple> smspillaz: Is that going to confuse GDM ? I notice CCSM offers to configure both screens as before... was hoping there was going to be a relatively simple tweak there :)
<smspillaz> what does gdm have to do with ccsm?
<smspillaz> ok, so they both use gtk ;-)
<IntuitiveNipple> nothing... it's called a sentence; joins unrelated by correlating statemen...

The conversation moved on to a different but related issue, multiple screen scenarios, and I thought it worth recording here for future reference:

<smspillaz> IntuitiveNipple: out of curiousity, is there any reason to use multi-screen instead of multi-output?
<IntuitiveNipple> smspillaz: I'm not sure... what's the difference!? My aim is to have two independent views. This is the way the setup-tools have always done it.
<IntuitiveNipple> On this system, it's nvidia. I've done the same on a Matrox G450 too.
<smspillaz> IntuitiveNipple: with multi-output it is easier to have different output sizes, compiz handles it better and you can move windows between outputs
<IntuitiveNipple> Okay. The idea is *not* to be able to move windows between displays.
<IntuitiveNipple> I don't want xinerama/twinview
<crdlb> then I guess you're set :)
<smspillaz> why would you want that?
<IntuitiveNipple> Why do you prefer chocolate to bananas? :)
* smspillaz tried multi-screen once, it had more bugs than a fluro lantern
<smspillaz> IntuitiveNipple: I guess we could *emulate* that functionality by writing a plugin that doesn't allow you to move windows between outputs ;-)
<IntuitiveNipple> I use xdmx to run 4 screens (the other two on a 2nd PC) from the one PC
<smspillaz> ah interesting
<IntuitiveNipple> smspillaz: I think that might confuse some apps though since the screen size would be a larger 'virtual' and so windows placed beyond the right side of the primary screen would, if the other displays weren't in use, disappear.
<smspillaz> that is probably the reason you have multi-screen then ;-)
<IntuitiveNipple> In my scenario, I use a laptop. When I'm at home-base I want as many screens as possible but when travelling I only have the one.
<IntuitiveNipple> When I used twinview/xinerama the problem was that windows I'd had previously on the extra displays would remember their coordinates and when loaded, would be unreachable :)
<smspillaz> that is a bug worth filing
<IntuitiveNipple> You mean... it now has a 'use case' ?
<smspillaz> no, the fact that when you disconnect outputs windows become unreachable
<smspillaz> that shouldn't happen
<smspillaz> I don't know if there is an output disconnected event though that we can hook
IntuitiveNipple> That is a more general problem with metacity too, so I assumed it was an application-specific thing going on.
<IntuitiveNipple> There is a nuance to that though - very often the laptop will be running dual screens when the session starts. At some point it'll get suspended or hibernated and I'll go mobile. When it resumes it's still in the same user session with my work as it was, and unless I log-out/log-in it won't figure out the external display is no longer attached.

Using the advice I tried using:

DISPLAY=:0.1 compiz --only-current-screen

which, because 'compiz' is a script, results in the final command:

/usr/bin/compiz.real --ignore-desktop-hints --loose-binding --replace --only-current-screen core ccp

The result is that the screen is taken over but the same effect is apparent - there is a black area on the bottom of the screen that corresponds with the difference in screen heights of the two displays. Photograph #3 shows the detail.

It appears that compiz is using the screen dimensions of screen 0 from somewhere - could this be an Xorg issue?

Notice in the attached photograph how I positioned the mouse cursor over the lower-left corner of the nvidia-settings dialog, in the black area, and it has changed the cursor image to show the resize icon. This seems to indicate that at some level it knows what is going on.

Another issue is, although compiz is supposed to only take over screen 1 it has caused the windows on screen 0 to lose their decoration and they are no longer accessible via the keyboard. Mouse clicks and drags within them work as expected, however. (See Photograph #4).

I've been doing some bisect and other testing via git.

I also took the hardy package that works correctedly with the Hardy installation - compiz (1:0.7.4-0ubuntu7) - and after making some minor changes (build dependencies) to enable it to build, built and tested it on Jaunty.

It suffers the same problem of screen 1 being clipped.

Combined with the discussions with the compiz developers, who have been very helpful, and my own reading of the compiz source it is making me wonder if the calls into Xlib are at some point returning geometry of the first screen (0) rather than the screen requested.

Note: smspillaz' comment in the IRC log is flat out wrong. Of course compiz supports two screens with different resolutions. The issue with multi-screen and compiz usually only is two different graphics cards. If you e.g. have ATI + Nvidia, you need two different libGL.so loaded in one process, which isn't possible.

It might be worthwhile to write a short test program that just opens an X connection, gets the root window for the respective screen and queries its geometry.

Also, what are your settings for the detect_outputs option on _screen 1_?

On Tue, 2009-02-24 at 08:30 +0000, Danny Baumann wrote:
> Also, what are your settings for the detect_outputs option on _screen
> 1_?

Danny, many thanks for taking the time to review this.

Your question is a good one. I've previously tried enabling and
disabling detect_outputs and observed no difference.

Prompted by your question I've just looked closer. Because I was
intrigued by where the settings are stored I opened gconf-editor and had
a peek.

At the same time I used CCSM to check and change values for screen 0 and
screen 1.

I was surprised to find the *only* screen 0 detect_outputs was changed;
no entry for detect_outputs shows up for screen 1.

grep -r detect_outputs ~/.gconf/*
/home/tj/.gconf/apps/compiz/general/screen0/options/%gconf.xml: <entry
name="detect_outputs" mtime="1235468827" type="bool" value="false"/>

Experimenting further I also found that when I edit the list of outputs
in CCSM, whether for screen 0 or 1, the resulting change is made only to
screen 0.

I left it with "detect_outputs" false and did some experiments.

Looking closer at "outputs" with gconf-editor for screen 1 it reports "!
This key has no schema" but shows (where from I don't know) "1024x768+0
+0" - this doesn't show up in CCSM editing the "outputs" for screen 1.

I tried replacing that value using gconf-editor with "128x1024+0+0" and
starting compiz on screen 1 only, but it hasn't changed the result.

I then tried changing the "outputs" for screen 0 to "1280x1024+0+0" and
starting compiz on screen 1 only (hoping it might be using the wrong
screen options) but that didn't improve matters either.

I tried adding "detect_outputs" 'true' to screen 1 options (whilst
leaving screen 0 'false'):

sed -i -e '/<gconf>/a\
\t<entry name="detect_outputs" mtime="1235468827" type="bool"
value="true"/>\
' ~/.gconf/apps/compiz/general/screen1/options/%gconf.xml

Starting compiz on screen 1 only - no change.

I set screen 1 "detect_outputs" to 'false' (screen 1 "outputs" is
listing "1280x1024+0+0") and tried again.

Hallelujah !!

Finally, screen 1 fills the full 1280x1024 of the screen.

I then tried starting compiz "normally" - managing both screens - and it
seems to behave as it used to.

So, it seems as if the issue is partly to do with CCSM?

Anything else you need checking/testing, let me know.

I tried to try the hack TJ explained above, but unfortunately I don't have any "screen1" section in /apps/compiz/general, only "screen0".

I am running NVIDIA, no Twinview, displays are :0.0 and :0.1 but I can't see this section.
I tried to run with two compiz instances with --only-current-screen but it's the same..

TJ, did you do anything special to have "screen1" show up on gconf-editor?

On Mon, 2009-04-06 at 09:56 +0000, Stéphane Travostino wrote:
> I tried to try the hack TJ explained above, but unfortunately I don't
> have any "screen1" section in /apps/compiz/general, only "screen0".
>
> I am running NVIDIA, no Twinview, displays are :0.0 and :0.1 but I can't see this section.
> I tried to run with two compiz instances with --only-current-screen but it's the same..
>
> TJ, did you do anything special to have "screen1" show up on gconf-
> editor?

I don't recall for certain now, but I *think* it was inherited from the
previously installed release (Hardy).

It is possible to manually create the screen1 keys using gconftool-2, or
creating the folder and %gconf.xml using a copy of the screen0 settings.

I dumped the settings for /apps/compiz/general/screen0 with:

gconftool-2 --dump /apps/compiz/general/screen0 > /tmp/screen1

Edited them and replaced screen0 with screen1, then reloaded it:

gconftool-2 --load /tmp/screen1

And it's working! Thank you TJ.
No more screen clipping, however I can't manage Compiz to open the windows
on the secondary monitor. They keep opening on the first one, the only way
to open them there is to force the DISPLAY variables:

DISPLAY=:0.1 gedit

Are you experiencing the same thing, TJ?

2009/4/6 TJ <email address hidden>

> On Mon, 2009-04-06 at 09:56 +0000, Stéphane Travostino wrote:
> > I tried to try the hack TJ explained above, but unfortunately I don't
> > have any "screen1" section in /apps/compiz/general, only "screen0".
> >
> > I am running NVIDIA, no Twinview, displays are :0.0 and :0.1 but I can't
> see this section.
> > I tried to run with two compiz instances with --only-current-screen but
> it's the same..
> >
> > TJ, did you do anything special to have "screen1" show up on gconf-
> > editor?
>
> I don't recall for certain now, but I *think* it was inherited from the
> previously installed release (Hardy).
>
> It is possible to manually create the screen1 keys using gconftool-2, or
> creating the folder and %gconf.xml using a copy of the screen0 settings.
>
> --
> Clipped area for multiple X screens with different dimensions
> https://bugs.launchpad.net/bugs/331918
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “compiz” source package in Ubuntu: Confirmed
> Status in “nvidia-graphics-drivers-180” source package in Ubuntu: Invalid
> Status in “xorg” source package in Ubuntu: Invalid
>
> Bug description:
> Binary package hint: xorg
>
> On a secondary X screen (:0.1) which has different (larger) dimensions than
> the primary(:0.0), the lower part of the secondary screen is ignored by the
> display manager, remaining black and not displaying windows in that area,
> although the mouse does display in that area.
>
> There appears to be a relationship between the issue and the primary screen
> in that it appears that the height of the primary screen is being used as
> the height of the secondary screen - the black area looks to be 1024-800=224
> pixels.
>
> Not entirely sure if this bug is Xorg or elsewhere. Because it relates to
> running multiple X screens it is testable only with the nvidia driver.
> However, this is a regression from Hardy/Intrepid in that the same
> configuration on those worked fine.
>
> A picture speaks a thousand words and in this case that is very true.
> Attached are two photographs that demonstrate the issue.
>
> The system has the laptop DFP (1280x800) to the left of an analogue TFT
> (1280x1024). nvidia-settings was used to position the screens relatively so
> the mouse moves between them.
>
> Photograph #1 shows the overview. The secondary screen on the right shows a
> large black band on the lower section of the display where windows cannot
> go. You can see that even the desktop background picture doesn't get
> rendered into that area.
>
> Photograph #2 focuses on the secondary screen. It shows the nvidia-settings
> dial...

I dumped the settings for /apps/compiz/general/screen0 with:

gconftool-2 --dump /apps/compiz/general/screen0 > /tmp/screen1

Edited them and replaced screen0 with screen1, then reloaded it:

gconftool-2 --load /tmp/screen1

And it's working! Thank you TJ.
No more screen clipping, however I can't manage Compiz to open the windows on the secondary monitor. They keep opening on the first one, the only way to open them there is to force the DISPLAY variables:

DISPLAY=:0.1 gedit

Are you experiencing the same thing, TJ?

On Mon, 2009-04-06 at 16:28 +0000, Stéphane Travostino wrote:

> And it's working! Thank you TJ.
> No more screen clipping, however I can't manage Compiz to open the windows on the secondary monitor. They keep opening on the first one, the only way to open them there is to force the DISPLAY variables:
>
> DISPLAY=:0.1 gedit
>
> Are you experiencing the same thing, TJ?

I originally reported that issue as bug #336721

http://launchpad.net/bugs/336721

Confirming this bug on Jaunty 64bit with a default Compiz setup.
My main display is 1024x768, the secondary is 1280x720 and was restricted to the dimension of the first.

My fix is similar to what TJ has done:
gconf-editor: apps -> compiz -> general -> screen1 -> options
create a boolean called "detect_outputs" and set to TRUE
create a list called "outputs" and make this entry: 1280x720+0+0

Restart X, both screens work as they should.

This regression could probably be fixed by having Compiz set the detect_outputs and outputs vars.

Ooops, just blundered...

Initially I set detect_outputs to TRUE, which didn't work.
Setting it to FALSE like TJ recommends does work.
Deleting the entry makes it not work again, so it's required to set it on false.