Python X Library

Bugs item #3023796, was opened at 2010-07-01 15:10
Message generated for change (Comment added) made by gberh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110350&aid=3023796&group_id=10350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido Berhoerster (gberh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot connect to display

Initial Comment:
I seem to encounter a problem very similar to that in bug #1623900, that is instantiating Xlib.display.Display results in the following traceback every time:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/site-packages/Xlib/display.py", line 85, in __init__
    self.display = _BaseDisplay(display)
  File "/usr/lib/python2.6/site-packages/Xlib/display.py", line 67, in __init__
    apply(protocol.display.Display.__init__, (self, ) + args, keys)
  File "/usr/lib/python2.6/site-packages/Xlib/protocol/display.py", line 121, in __init__
    raise error.DisplayConnectionError(self.display_name, r.reason)
Xlib.error.DisplayConnectionError: Can't connect to display ":0.0": No protocol specified

However, this is with Python 2.6.5 and python-xlib 0.14 which contains the fix for bug #1623900.

----------------------------------------------------------------------

>Comment By: Guido Berhoerster (gberh)
Date: 2010-08-17 00:33

Message:
> It would be interesting to know how the X server got one hostname but
> python is getting another - perhaps the hostname is set when you connect
to
> your network, after X has started up?

This is on Linux, GDM seems to set it to "localhost".

> Perhaps one way would be to convert domain names in the .Xauthority
file
> back to IPs and compare those? This also sounds a bit unsafe.

In any case you would need to determine all IP addresses of the local
host, then you can also easily get all hostnames and aliases. Porbably
non-trivial to implement in a cross-platform manner in Python.

> Another thought is that this will presumably only occur for unix sockets
-
> perhaps we could ignore the hostname field in this case as it's not
> meaningful and just use family (unix) and display number. This assumes
> there's only one cookie per display for unix sockets.

That also came to my mind, are the display number and a local socket
sufficient? If there are several cookies for the current display number and
a local socket, should we simply try them until one works? Not exactly
clean either...

----------------------------------------------------------------------

Comment By: Mike Grant (mggrant)
Date: 2010-08-16 22:56

Message:
So, if I understand you correctly, there is no host specified (e.g.
$DISPLAY = :0.0) so the code looks up the local hostname of the machine and
gets "your.machine.domain".  However, the X cookie is stored under another
hostname (in your case "localhost").

It would be interesting to know how the X server got one hostname but
python is getting another - perhaps the hostname is set when you connect to
your network, after X has started up?

I'm also unsure of the best way around this - one obvious option is to
ensure the hostname doesn't change (seems to have caused problems in other
contexts, e.g.
http://www.macosxhints.com/article.php?story=20040426134835245), but that's
not necessarily going to work in the real world ;)

Perhaps one way would be to convert domain names in the .Xauthority file
back to IPs and compare those?  This also sounds a bit unsafe.

Another thought is that this will presumably only occur for unix sockets -
perhaps we could ignore the hostname field in this case as it's not
meaningful and just use family (unix) and display number.  This assumes
there's only one cookie per display for unix sockets.

----------------------------------------------------------------------

Comment By: Guido Berhoerster (gberh)
Date: 2010-08-16 20:23

Message:
I've looked into this issue, the problem here is that the xauthority file
parsing code assumes that there is an entry for the hostname returned by
gethostname(). If the entries' address is different, e.g. "localhost" in
my
case, it wont find the cookie and will subsequently fail to connect.

Fixing this in case of "localhost" would be easy, it could be added as a
fallback if we have a Unix socket. However, this is not sufficient as
entriescould be set to something else such as an alias hostname.
What would be the best way to handle this more generically?

There is also the old_get_auth function which parses the "xauth list"
ouput. However it is hardcoded to always take the cookie from the first
line of output, is that guaranteed to be the right one?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110350&aid=3023796&group_id=10350

2006	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (4)	Sep (4)	Oct (1)	Nov (5)	Dec (1)
2007	Jan	Feb (7)	Mar (2)	Apr	May	Jun (2)	Jul	Aug (2)	Sep	Oct (4)	Nov	Dec (2)
2008	Jan	Feb	Mar (5)	Apr	May (2)	Jun (7)	Jul (9)	Aug (2)	Sep	Oct	Nov (1)	Dec
2009	Jan (2)	Feb	Mar (1)	Apr (5)	May (2)	Jun (4)	Jul (2)	Aug	Sep (1)	Oct	Nov (2)	Dec
2010	Jan	Feb	Mar	Apr	May	Jun (4)	Jul (2)	Aug (4)	Sep (4)	Oct	Nov	Dec
2011	Jan	Feb (2)	Mar (2)	Apr	May	Jun	Jul (9)	Aug (1)	Sep (1)	Oct (2)	Nov	Dec
2012	Jan	Feb	Mar	Apr	May	Jun	Jul (4)	Aug (2)	Sep	Oct	Nov (1)	Dec (4)
2013	Jan	Feb (1)	Mar (1)	Apr (4)	May	Jun (2)	Jul (5)	Aug	Sep	Oct (1)	Nov	Dec

Thanks for helping keep SourceForge clean.

Python X Library

Status: Beta

Brought to you by: calroc99, funkiedamouse, mggrant, petli, zampire

python-xlib-notifications — Automatic notifications list (bug, patch, etc trackers)

S	M	T	W	T	F	S
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16 (3)	17	18	19 (1)	20	21
22	23	24	25	26	27	28
29	30	31