python-xlib icon indicating copy to clipboard operation
python-xlib copied to clipboard

X does not work on OS X EI Capitan

Open ghost opened this issue 8 years ago • 17 comments

I tried a project which used python-xlib on OS X EI Capitan. And the bottom is backtraces. And I have found some issue on stackexchange. It's seems not a bug related to python-xlib, but the X11 on Mac os has changed the socket path from /tmp to /private/tmp. I tried to change host.startswith('/tmp/'): to host.startswith('/private/tmp/'):, and then the backtraces go away. I also saw a similar ticket http://sourceforge.net/p/python-xlib/bugs/27/ which claimed fixed. I am not sure its the same issue. I am just adding an issue here in case others come across the same problem. Hope not to bother you.

File "/Users/declanqian/Dev/site-lisp/webkit/xutils.py", line 31, in get_xlib_display
    xlib_display =  display.Display()
  File "/usr/local/lib/python2.7/site-packages/Xlib/display.py", line 83, in __init__
    self.display = _BaseDisplay(display)
  File "/usr/local/lib/python2.7/site-packages/Xlib/display.py", line 65, in __init__
    apply(protocol.display.Display.__init__, (self, ) + args, keys)
  File "/usr/local/lib/python2.7/site-packages/Xlib/protocol/display.py", line 49, in __init__
    self.socket = connect.get_socket(name, host, displayno)
  File "/usr/local/lib/python2.7/site-packages/Xlib/support/connect.py", line 79, in get_socket
    return mod.get_socket(dname, host, dno)
  File "/usr/local/lib/python2.7/site-packages/Xlib/support/unix_connect.py", line 90, in get_socket
    raise error.DisplayConnectionError(dname, str(val))
Xlib.error.DisplayConnectionError: Can't connect to display 
"/private/tmp/com.apple.launchd.userNDyhts/org.macosforge.xquartz:0": 
[Errno 8] nodename nor servname provided, or not known

ghost avatar Dec 28 '15 00:12 ghost

Hi @declanqian, thank you for the issue investigation. Sorry for the delayed reply, I went back from vacation just yesterday. I had no chance to test the fix on at least 2 OS X versions yet. If you were confirmed it's OK on earlier OS X, I would merge the pull request. Peter is not active enough so I'm trying to migrate the project to GitHub and there are still plenty of work. Any help would be great.

vasily-v-ryabov avatar Jan 12 '16 12:01 vasily-v-ryabov

Maybe we can wait util the transition to GitHub is finished. I am not a python expert. You should test it before you merge. :)

ghost avatar Jan 12 '16 13:01 ghost

I just ran into this problem with my Python application. I am currently running from https://github.com/declanqian/python-xlib/tree/66b67e7725346b0924fe1f57992a5e30f630fac6 and I am no longer getting this error.

ezfe avatar Mar 13 '16 14:03 ezfe

Hi @ezfe , which OS X version do you use?

vasily-v-ryabov avatar Mar 13 '16 20:03 vasily-v-ryabov

@vasily-v-ryabov I'm using El Capitan

ezfe avatar Mar 13 '16 23:03 ezfe

Now I can check the tests on OS X El Capitan. The fix is working. But we have 1 test failure though:

======================================================================
FAIL: test_keysym_to_keycode_for_valid_symbol (test.test_xlib_display.TestXlibDisplay)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/test/python-xlib_related/python-xlib/test/test_xlib_display.py", line 100, in test_keysym_to_keycode_for_valid_symbol
    self.assertEqual(self.display.keysym_to_keycode(self.keysym), 119)
AssertionError: 125 != 119

I'm going to merge #2 but will keep the issue open until all the tests are fixed. Will check on other OS X version later.

vasily-v-ryabov avatar Jul 01 '16 09:07 vasily-v-ryabov

Isn't the Delete key non-standard on some Apple keyboards? What do you get with xmodmap -pk | grep Delete?

Maybe testing something else, like Escape is more robust:

diff --git i/test/test_xlib_display.py w/test/test_xlib_display.py
index fb617a3..8ee7e21 100644
--- i/test/test_xlib_display.py
+++ w/test/test_xlib_display.py
@@ -21,7 +21,7 @@ class TestXlibDisplay(unittest.TestCase):
         self.display_num = os.getenv("DISPLAY")
         self.display = Xlib.display.Display(self.display_num)
         self.dummy_str = "qqq"
-        self.keysym = 65535
+        self.keysym = 0xff1b # Escape

     def test_display_instance(self):
         self.assertTrue(isinstance(self.display, Xlib.display.Display))
@@ -97,7 +97,7 @@ class TestXlibDisplay(unittest.TestCase):
         self.assertEqual(self.display.keysym_to_keycode(Xlib.X.NoSymbol), 0)

     def test_keysym_to_keycode_for_valid_symbol(self):
-        self.assertEqual(self.display.keysym_to_keycode(self.keysym), 119)
+        self.assertEqual(self.display.keysym_to_keycode(self.keysym), 9)

     def test_keysym_to_keycodes_for_nosymbol(self):
         self.assertEqual(self.display.keysym_to_keycodes(Xlib.X.NoSymbol), [])

benoit-pierre avatar Jul 01 '16 10:07 benoit-pierre

xmodmap -pk | grep Delete prints code 125. With your suggestion it fails with 61 != 9.

I'm running it on VirtualBox image (host system is Win8.1, guest one is El Capitan). So it's not an Apple keyboard. Are you able to run it on Mac?

BTW pyautogui library uses its own key mapping for OS X.

vasily-v-ryabov avatar Jul 01 '16 11:07 vasily-v-ryabov

Nope, I don't have access to a OS X machine. The problem with this test is it's highly dependent on the keymap being used, so maybe we should just drop it.

benoit-pierre avatar Jul 01 '16 11:07 benoit-pierre

Does it work when run under Xvfb?

xvfb-run nosetests test/test_xlib_display.py

benoit-pierre avatar Jul 01 '16 13:07 benoit-pierre

I don't have such a command on OS X. Help for xvfb also doesn't list words like run.

vasily-v-ryabov avatar Jul 01 '16 13:07 vasily-v-ryabov

It's an helper script provided by the package on Arch Linux / Ubuntu. And running manually with (export DISPLAY=:99; Xvfb -ac :99 & xvfb_pid=$!; sleep 3; nosetests test/test_xlib_display.py; kill $xvfb_pid; wait $xvfb_pid)?

benoit-pierre avatar Jul 01 '16 13:07 benoit-pierre

It prints -bash: !: event not found

vasily-v-ryabov avatar Jul 01 '16 13:07 vasily-v-ryabov

Damn! (I use ZSH). With (export DISPLAY=:99; Xvfb -ac :99 & sleep 3; nosetests test/test_xlib_display.py; pkill Xvfb) then.

benoit-pierre avatar Jul 01 '16 13:07 benoit-pierre

Now the failure is different:

======================================================================
FAIL: test_keysym_to_keycode_for_valid_symbol (test.test_xlib_display.TestXlibDisplay)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/test/python-xlib_related/python-xlib/test/test_xlib_display.py", line 100, in test_keysym_to_keycode_for_valid_symbol
    self.assertEqual(self.display.keysym_to_keycode(self.keysym), 119)
AssertionError: 107 != 119

BTW I will have a chance to test it on Macbook next week.

vasily-v-ryabov avatar Jul 01 '16 14:07 vasily-v-ryabov

I just tested git master on a native El Capitan, and get this error:

FAIL: test_keysym_to_keycode_for_valid_symbol (__main__.TestXlibDisplay)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test/test_xlib_display.py", line 100, in test_keysym_to_keycode_for_valid_symbol
    self.assertEqual(self.display.keysym_to_keycode(self.keysym), 119)
AssertionError: 125 != 119

Running against the native X display, not Xvfb since I didn't get that running immediately.

My hunch is that these tests are about the keycode/keysym cache. Perhaps they can be reformulated to not be device-dependent.

petli avatar Jul 01 '16 22:07 petli

Seeing this when running on with the Xdummy driver on Fedora:

FAIL: test_keysym_to_keycode_for_valid_symbol (test.test_xlib_display.TestXlibDisplay)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/python-xlib-0.20/test/test_xlib_display.py", line 100, in test_keysym_to_keycode_for_valid_symbol
    self.assertEqual(self.display.keysym_to_keycode(self.keysym), 119)
AssertionError: 107 != 119

opoplawski avatar Apr 14 '18 01:04 opoplawski