Multiple X screens launch apps on screen 0

Same problem on my triple screen setup with Nvidia cards.

This is beginning to look like a deeper problem with the current Xorg. I am becoming convinced the symptoms are caused by the same issue that invokes bug #331918 "Clipped area for multiple X screens with different dimensions".

This issue affects Metacity and Compiz which suggests there is a common cause.

With one video display adapter and two X screens I've found it impossible to start many applications on :0.1 regardless of how I try. Here's a really good example - all these cause the window to open on :0.0

From gnome-terminal instance running on :0.1 (same result if it is running on :0.0)

env | grep DISPLAY
DISPLAY=:0.1

DISPLAY=:0.1 nautilus
nautilus --display=:0.1
nautilus --screen=1

Any application in the standard Gnome menu will start on :0.0. Custom additions to the gnome panel can be started on the correct screen. E.g:

evolution --display=:0.1 --component=mail
firefox %u

Notice here that Firefox is one of the few applications that correctly detects the current screen.

Combining these experiences with the issues discovered for compiz (where it seems as if compiz gets the wrong or misleading screen information from the X-server) I'm beginning to think that the X-server information functions are giving out screen 0 data.

I don't have the clipping problem, but after testing Ubuntu Jaunty Alpha 6 I can confirm that the problem is still there and the behavior is exactly as TJ described.

I launched a couple of applications from the menu and Firefox was the only one which opened on the correct screen.

There is another problem in Jaunty which wasn't there in Intrepid or Hardy, but I'm not sure if it's directly related to this one.
There are always three cursors on my triplehead setup. When I move from one screen to another the cursor of the previous screen doesn't disappear, but just stops at the edge of the monitor. I took a picture of the problem.

I'm still seeing the multiple-cursors effect. I had thought I'd posted a bug report about it previously to this one but I can't find it now. That might be because I'd put it down to an issue with the Nvidia drivers.

I've opened a new bug # 346579 "Cursor image left behind with multiple X screens"

I realised also this bug is probably assigned to the wrong package so correcting that.

We'll need your lspci -vvnn output too, TJ.

I'm getting lost in all these similar bugs... can we just put in a standing order? :)

Bryce, something that might be worth considering as part of this. The first bug report I filed regarding this issue was bug #331918 "Clipped area for multiple X screens with different dimensions" which, because I wasn't sure what the cause was I filed against nvdia-glx-180 and xorg, then later compiz. At the time you told me off for filing against xorg/multiple packages but I've got the feeling that this bug and that are related, on this basis:

There is a common thread that the problem involves the expectation that the system will do something on/related to screen X (where X is greater than 0) but in some way despite specific settings the screen actually used/reported is 0.

Since the compiz issue I've been using metacity and it is affected in the same way: screen X commands/actions end up using screen 0.

In that other bug Danny Baumann (compiz developer) suggested "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."

I'm not an X programmer and I've no felt like having the additional learning curve to figure that out, although it sounds relatively simple. However, if that is something you could knock together it'd be a quick way for us to test my suspicion that the xserver is returning incorrect information for additional X screens - you'd possibly need to make sure the calls to X are the same ones the compiz code makes to get screen info.

One thing that may be exacerbating the problem is that for video drivers other than -nvidia, Xinerama no longer works, so bugs that are particular to Xinerama setups (even if not -nvidia specific) aren't getting much upstream attention. So I could imagine bit rot having laid in, bringing regressions with it.

For your test program, see if you can do it via a call to xwininfo using the -root and -display arguments (see man xwininfo).

If you'd like to write something yourself but the C coding is too intimidating, you can likely do it with X bindings in whatever language you're comfortable with. E.g. in python the python-xlib stuff should suffice. http://python-xlib.sourceforge.net/doc/html/python-xlib_4.html#SEC3

I've not got a problem with languages - I'm on the kernel-team - so I have pretty much turn my hand to anything. I just didn't fancy having to figure out the X 'stuff' on top of everything else I'm currently doing :0

xwininfo doesn't show anything obvious. I ran it from both screens, and tried prefixing DISPLAY=:0.X in case it made a difference but each iteration reports the same results:

DISPLAY=:0.1 xwininfo -root -display :0.0

xwininfo: Window id: 0x32b (the root window) (has no name)

  Absolute upper-left X: 0
  Absolute upper-left Y: 0
  Relative upper-left X: 0
  Relative upper-left Y: 0
  Width: 1280
  Height: 800
  Depth: 24
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners: +0+0 -0+0 -0-0 +0-0
  -geometry 1280x800+0+0

DISPLAY=:0.1 xwininfo -root -display :0.1

xwininfo: Window id: 0x32d (the root window) (has no name)

  Absolute upper-left X: 0
  Absolute upper-left Y: 0
  Relative upper-left X: 0
  Relative upper-left Y: 0
  Width: 1280
  Height: 1024
  Depth: 24
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x1a3 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners: +0+0 -0+0 -0-0 +0-0
  -geometry 1280x1024+0+0

I found and built a 'simple' "Hello World" application from

http://www.paulgriffiths.net/program/c/srcs/helloxsrc.html

and adapted it to report the screen number obtained and used with:

screen_num = DefaultScreen(display);
...
XCreateSimpleWindow(display, RootWindow(display, screen_num),
...

and ran it from gnome-terminal's on both screens. It works correctly and reports the correct screen for each.

I'm wondering if the issue is in the Gnome libraries since the programs that have a problem with starting on the wrong screen all seem to be gnome/gtk/gdk specific. For example, VLC will start on the correct screen (it uses qt4).

I've done the same thing for GTK/GDK. Used the basic 'Hello GTK' source from

http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD

and amended it to get the screen number:

    gtk_init (&argc, &argv);

    /* create a new window */
    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    screen = gtk_window_get_screen(GTK_WINDOW (window));
    screen_num = gdk_screen_get_number(screen);

Again, this works correctly on both screens, reporting the correct screen number.

This is starting to narrow down the issue towards gnome-panel (I see launcher has a launcher_get_screen() function) or maybe gnome-session ?

The problem affects me too (I use an Nvidia card). I have noticed that if I create a directory on the desktop shown by the second display and I double click there, nautilus shows up in the right screen. If I try to open a videoclip with totem (by clicking on it from the nautilus window in the 2nd screen), it shows up in the 1st screen.

I think it's a gtk bug and I'll look into it. Thanks for reporting.

On Tue, 2009-03-24 at 10:18 +0000, Alberto Milone wrote:
> The problem affects me too (I use an Nvidia card). I have noticed that
> if I create a directory on the desktop shown by the second display and I
> double click there, nautilus shows up in the right screen. If I try to
> open a videoclip with totem (by clicking on it from the nautilus window
> in the 2nd screen), it shows up in the 1st screen.
>
> I think it's a gtk bug and I'll look into it. Thanks for reporting.

Alberto, great catch there!

I can confirm that creating a new folder on screen 1 then
double-clicking it starts nautilus on screen 1.

Thanks for narrowing it down TJ. Sounding like this is a peculiarity of gtk or one of its sub-libraries (or else just nautilus/gnome-panel), so reassigning it out of the xserver.

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.