bug#15037: Display can't be opened (display newer than emacs session)

bug#15037: Display can't be opened (display newer than emacs session)

[Sewall, Jason]

I have a long-running emacs session with a server running on it (24.2.1, on Fedora 18). I have started up a new VNC session on the host, creating DISPLAY :1.0, but emacs refuses to let me create a frame on it: 

M-x make-frame-on-display <RET> :1.0 <RET>
Display :1.0 can't be opened

If I start a new emacs session with emacs (with -Q or not) and run the above, the frame is created.

I am not an expert in emacs frame handling nor in X, but it seems like emacs is reading the available displays when it starts up and refuses to connect to anything that started up after it. I'm happy to provide more info as needed. 

Cheers,
Jason

bug#15037: Display can't be opened (display newer than emacs session)

[Glenn Morris]

"Sewall, Jason" wrote:

> I have a long-running emacs session with a server running on it
> (24.2.1, on Fedora 18). I have started up a new VNC session on the
> host, creating DISPLAY :1.0, but emacs refuses to let me create a
> frame on it:
>
> M-x make-frame-on-display <RET> :1.0 <RET>
> Display :1.0 can't be opened
>
> If I start a new emacs session with emacs (with -Q or not) and run the
> above, the frame is created.
>
> I am not an expert in emacs frame handling nor in X, but it seems like
> emacs is reading the available displays when it starts up and refuses
> to connect to anything that started up after it.

With Emacs 24.2, the following works fine for me:

## Without X running
emacs -Q --daemon
startx &
## Back in the tty
emacsclient -t
## In Emacs
(make-frame-on-display ":0.0")

bug#15037: Display can't be opened (display newer than emacs session)

[Jan Djärv]

Hello.

6 aug 2013 kl. 22:52 skrev "Sewall, Jason" <jason.sewall@intel.com>:

> I have a long-running emacs session with a server running on it (24.2.1, on Fedora 18). I have started up a new VNC session on the host, creating DISPLAY :1.0, but emacs refuses to let me create a frame on it: 
> 
> M-x make-frame-on-display <RET> :1.0 <RET>
> Display :1.0 can't be opened
> 
> If I start a new emacs session with emacs (with -Q or not) and run the above, the frame is created.
> 
> I am not an expert in emacs frame handling nor in X, but it seems like emacs is reading the available displays when it starts up and refuses to connect to anything that started up after it. I'm happy to provide more info as needed. 

That is not what Emacs does.  "Reading available displays" is not possible.  Emacs just tries to connect when you do open display.
Did you kill the old server and start a new server in the same shell as you started the first?  My guess is that you did not, and so the second server either gets the correct authentication and thus can connect.

To really see what is going on you would need to debug Emacs with gdb when the make-frame-on-display fails.

	Jan D.

bug#15037: Display can't be opened (display newer than emacs session)

[Stefan Monnier]

> M-x make-frame-on-display <RET> :1.0 <RET>
> Display :1.0 can't be opened

> If I start a new emacs session with emacs (with -Q or not) and run the
> above, the frame is created.

What does M-: (getenv "XAUTHORITY") RET say in those two Emacs sessions?


        Stefan

bug#15037: Display can't be opened (display newer than emacs session)

[Sewall, Jason]

> From: Stefan Monnier [mailto:monnier@iro.umontreal.ca]
> Sent: Wednesday, August 7, 2013 7:30 AM

> What does M-: (getenv "XAUTHORITY") RET say in those two Emacs sessions?

For the older session (in the original frame): "/var/run/gdm/auth-for-jsewall-jWCxJH/database"

For a new session started from display :1.0, 'nil'. 

Cheers,
Jason

bug#15037: Display can't be opened (display newer than emacs session)

[Sewall, Jason]

> From: Jan Djärv [mailto:jan.h.d@swipnet.se]
> Sent: Wednesday, August 7, 2013 1:33 AM

> That is not what Emacs does.  "Reading available displays" is not possible.
> Emacs just tries to connect when you do open display.

Makes sense. 

> Did you kill the old server and start a new server in the same shell as you
> started the first?  My guess is that you did not, and so the second server
> either gets the correct authentication and thus can connect.

If you mean kill emacs and restart it, I could certainly do that (it will work, from past experience) but it defeats the purpose from my point of view. I'd like emacs to be able to create a frame on any display I ask it to, no matter the relative age of the emacs session and the remote display. If you mean (server-start), that is easy to do, but my understanding is that it has nothing to do with remote displays. Indeed, if I do emacs -Q (i.e., starting no servers) I am able to do that make-frame-on-display without trouble (for an emacs newer than the display)

> To really see what is going on you would need to debug Emacs with gdb
> when the make-frame-on-display fails.

While that is fine, as a somewhat experienced programmer and noob with Emacs internals, I am very surprised there isn't a higher-level way to debug this sort of problem in emacs-lisp. It isn't something I have the time to figure up right now at any rate.

Cheers,
Jason

bug#15037: Display can't be opened (display newer than emacs session)

[Sewall, Jason]

> From: Glenn Morris [mailto:rgm@gnu.org]
> Sent: Tuesday, August 6, 2013 5:03 PM
> With Emacs 24.2, the following works fine for me:
> 
> ## Without X running
> emacs -Q --daemon
> startx &
> ## Back in the tty
> emacsclient -t
> ## In Emacs
> (make-frame-on-display ":0.0")

That's good, but I suspect those conditions are different than the ones I am in. In particular, I am using GDM (and I haven't had to do startx manually for 10 years, I'd guess).

Cheers,
Jason

bug#15037: Display can't be opened (display newer than emacs session)

[Stefan Monnier]

>> What does M-: (getenv "XAUTHORITY") RET say in those two Emacs sessions?

> For the older session (in the original frame): "/var/run/gdm/auth-for-jsewall-jWCxJH/database"

> For a new session started from display :1.0, 'nil'. 

There's your problem.  You're using GDM3 which has the obnoxious habit
of putting your authorization keys in a separate file and setting
XAUTHORITY to point to it.  So your session doesn't have access to the
keys you have in your ~/.Xauthority and your other sessions don't have access
to this display.

See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586685
https://bugzilla.gnome.org/show_bug.cgi?id=651431

Note that it's not just Emacs that suffers this way:
If M-x make-frame-on-display <RET> :1.0 <RET> fails for you, then try
(in that very same Emacs) to do M-x shell RET xterm --display :1.0 RET
it should fail in the same way.


        Stefan