python-xlib / python-xlib

XLib in pure Python (Py2/Py3 compatible)
GNU Lesser General Public License v2.1
426 stars 109 forks source link

X does not work on OS X EI Capitan #1

Open ghost opened 8 years ago

ghost commented 8 years ago

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
vasily-v-ryabov commented 8 years ago

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.

ghost commented 8 years ago

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

ezfe commented 8 years ago

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.

vasily-v-ryabov commented 8 years ago

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

ezfe commented 8 years ago

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

vasily-v-ryabov commented 8 years ago

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.

benoit-pierre commented 8 years ago

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), [])
vasily-v-ryabov commented 8 years ago

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.

benoit-pierre commented 8 years ago

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 commented 8 years ago

Does it work when run under Xvfb?

xvfb-run nosetests test/test_xlib_display.py
vasily-v-ryabov commented 8 years ago

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

benoit-pierre commented 8 years ago

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)?

vasily-v-ryabov commented 8 years ago

It prints -bash: !: event not found

benoit-pierre commented 8 years ago

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

vasily-v-ryabov commented 8 years ago

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.

petli commented 8 years ago

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.

opoplawski commented 6 years ago

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