* bug#15037: Display can't be opened (display newer than emacs session)
@ 2013-08-06 20:52 Sewall, Jason
2013-08-07 0:03 ` Glenn Morris
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Sewall, Jason @ 2013-08-06 20:52 UTC (permalink / raw
To: 15037
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15037: Display can't be opened (display newer than emacs session)
2013-08-06 20:52 bug#15037: Display can't be opened (display newer than emacs session) Sewall, Jason
@ 2013-08-07 0:03 ` Glenn Morris
2013-08-07 17:39 ` Sewall, Jason
2013-08-07 8:32 ` Jan Djärv
2013-08-07 14:30 ` Stefan Monnier
2 siblings, 1 reply; 8+ messages in thread
From: Glenn Morris @ 2013-08-07 0:03 UTC (permalink / raw
To: Sewall, Jason; +Cc: 15037
"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")
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15037: Display can't be opened (display newer than emacs session)
2013-08-07 0:03 ` Glenn Morris
@ 2013-08-07 17:39 ` Sewall, Jason
0 siblings, 0 replies; 8+ messages in thread
From: Sewall, Jason @ 2013-08-07 17:39 UTC (permalink / raw
To: Glenn Morris; +Cc: 15037@debbugs.gnu.org
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15037: Display can't be opened (display newer than emacs session)
2013-08-06 20:52 bug#15037: Display can't be opened (display newer than emacs session) Sewall, Jason
2013-08-07 0:03 ` Glenn Morris
@ 2013-08-07 8:32 ` Jan Djärv
2013-08-07 17:37 ` Sewall, Jason
2013-08-07 14:30 ` Stefan Monnier
2 siblings, 1 reply; 8+ messages in thread
From: Jan Djärv @ 2013-08-07 8:32 UTC (permalink / raw
To: Sewall, Jason; +Cc: 15037
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15037: Display can't be opened (display newer than emacs session)
2013-08-07 8:32 ` Jan Djärv
@ 2013-08-07 17:37 ` Sewall, Jason
0 siblings, 0 replies; 8+ messages in thread
From: Sewall, Jason @ 2013-08-07 17:37 UTC (permalink / raw
To: Jan Djärv; +Cc: 15037
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15037: Display can't be opened (display newer than emacs session)
2013-08-06 20:52 bug#15037: Display can't be opened (display newer than emacs session) Sewall, Jason
2013-08-07 0:03 ` Glenn Morris
2013-08-07 8:32 ` Jan Djärv
@ 2013-08-07 14:30 ` Stefan Monnier
2013-08-07 17:31 ` Sewall, Jason
2 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2013-08-07 14:30 UTC (permalink / raw
To: Sewall, Jason; +Cc: 15037
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15037: Display can't be opened (display newer than emacs session)
2013-08-07 14:30 ` Stefan Monnier
@ 2013-08-07 17:31 ` Sewall, Jason
2013-08-07 18:19 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Sewall, Jason @ 2013-08-07 17:31 UTC (permalink / raw
To: Stefan Monnier; +Cc: 15037
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15037: Display can't be opened (display newer than emacs session)
2013-08-07 17:31 ` Sewall, Jason
@ 2013-08-07 18:19 ` Stefan Monnier
0 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2013-08-07 18:19 UTC (permalink / raw
To: Sewall, Jason; +Cc: 15037
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-08-07 18:19 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-06 20:52 bug#15037: Display can't be opened (display newer than emacs session) Sewall, Jason
2013-08-07 0:03 ` Glenn Morris
2013-08-07 17:39 ` Sewall, Jason
2013-08-07 8:32 ` Jan Djärv
2013-08-07 17:37 ` Sewall, Jason
2013-08-07 14:30 ` Stefan Monnier
2013-08-07 17:31 ` Sewall, Jason
2013-08-07 18:19 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.