After upgrading xorg, including libX11-1.4.0, I am unable to launch any application on secondary screens. Xorg is configured to use separate screens (no twin-view, xinerama or similar) and I use fluxbox as window manager. In the console the following is printed: xterm Xt error: Can't open display: :1 However, using a terminal on :0.0 I am able to launch applications by setting DISPLAY=":0.1". Correct me if I'm wrong but I've believed the display names to be :0.n when using multiple screens running on the same server. So there seems to be a mismatch with the name. Downgrading libX11 confirms that those names were used and the issue goes away. I digged into the source and and found the offending commit is f92e754297ec5fdb81068b56a4435026666224fa [1]. Just to try it out I reverse-applied the patch on vanilla libX11-1.4.0 and installed, and it fixes my issue. [1] http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=f92e754297ec5fdb81068b56a4435026666224fa
That's awfully weird. The man page is very clear that XDisplayString should return exactly the same string as was passed into XOpenDisplay, so the fact that it was taking ".0" on the end was definitely a bug. However, :1 should be a valid display name, so your problem points to a bug somewhere else that was exposed by my change. I'll try to reproduce your problem as soon as I get a chance. Does it work if you set DISPLAY=:1.0 instead of DISPLAY=:1?
Okay, I can't reproduce this problem. Using vncserver to start an X server on :1, both DISPLAY=:1 and DISPLAY=:1.0 work fine for me. :1 is not a valid way of naming the second screen on a single display, so if that worked for you before, it was a bug. Can you please attach /var/log/Xorg.*.log and a list of the exact commands you entered to reproduce this problem?
Before libX11-1.4 I had :0.0 and :0.1 (according to `env | grep DISPLAY`) After libX11-1.0 I get :0 on the one previously called :0.0, and trying to do anything with the other yields "Can't open display :1", however on :0 I am able to start an application by setting "DISPLAY=:0.1". I don't run two display servers, just a single one, with two screens without using xinerama or similar. I will post /var/log/Xorg.*.log and xorg.conf in a moment.
On Mon, Dec 13, 2010 at 10:26:16AM -0800, aaronp wrote: > Okay, I can't reproduce this problem. Using vncserver to start an X server on > :1, both DISPLAY=:1 and DISPLAY=:1.0 work fine for me. :1 is not a valid way > of naming the second screen on a single display, so if that worked for you > before, it was a bug. Can you please attach /var/log/Xorg.*.log and a list of > the exact commands you entered to reproduce this problem? My interpretation of it was that he only had one server running, and the problem came from :0 vs. :0.0 vs. :0.1, I guess.
Created attachment 41076 [details] this is printed in the console
Created attachment 41077 [details] Xorg.0.log
Created attachment 41078 [details] xorg.conf
Also, this is reproducable using both ati-drivers and nvidia-drivers (I'm having this issue with all machines having this setup, no matter what hardware it have) (In reply to comment #3) > After libX11-1.0 I mean libX11-1.4.0 ofcourse.
David, which desktop environment are you using, and how are you trying to launch the xterm that fails? It sounds like whatever is responsible for setting DISPLAY is getting confused by having the correct display string, and is translating :0.1 into :1 somehow. It would be interesting to know what's being passed into XOpenDisplay, because if it was ":0.1" then it should be getting exactly that back both before and after my change.
(In reply to comment #9) > David, which desktop environment are you using, and how are you trying to > launch the xterm that fails? It sounds like whatever is responsible for > setting DISPLAY is getting confused by having the correct display string, and > is translating :0.1 into :1 somehow. It would be interesting to know what's > being passed into XOpenDisplay, because if it was ":0.1" then it should be > getting exactly that back both before and after my change. just fluxbox (runs from .xinitrc), but I could try something else.
Thanks, David. I'll give Fluxbox a try as soon as I finish recovering my development system and I figure out how to make Ubuntu stop breaking GRUB after a fresh install.
(In reply to comment #11) > Thanks, David. I'll give Fluxbox a try as soon as I finish recovering my > development system and I figure out how to make Ubuntu stop breaking GRUB after > a fresh install. The wm "awesome" seems to work, so maybe this is just a problem with fluxbox.
This is a bug in Fluxbox. It constructs the DISPLAY environment variable from DisplayString by deleting the last character and then tacking on the screen number, regardless of whether it had a display number already or not. Previously, when libX11 was erroneously returning :0.0 when DISPLAY was set to :0, it would translate that to :0.1. Now that it correctly returns :0, it transforms that to :1 instead. I'm not sure what the right thing to do is. On the one hand, the documentation for DisplayString is very clear, but on the other hand, who knows how many applications have this bug? I'm going to resolve this as NOTOURBUG, but if lots of other applications turn out to have this problem, then maybe we need to waive this part of the X test suite and just declare libX11 unfixable. GNOME doesn't seem to have this problem, and KDE 4 doesn't support multiple X screens in the first place (which is a huge bug on their part), unless they fixed it recently.
I've tried a few more wm's and of those that supports multiple screens, only fluxbox was affected so far. Good to know this is a bug in fluxbox. I will take this bug to them. Thanks for your time!
our bug for sure, fixed that.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.