ERROR - root - Error starting interface: Can't connect to display ":0": b'No protocol specified\n'

[roseswe]

Version used: latest (commit: 24ef38e) openSUSE Leap 15.0 LANG=en_US.UTF-8 /usr/bin/autokey-gtk -l

::

2018-08-14 15:07:22,691 INFO - service - Starting service 2018-08-14 15:07:22,702 ERROR - root - Error starting interface: Can't connect to display ":0": b'No protocol specified\n' Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/autokey/gtkapp.py", line 149, in initialise self.service.start() File "/usr/lib/python3.6/site-packages/autokey/service.py", line 81, in start self.mediator = IoMediator(self) File "/usr/lib/python3.6/site-packages/autokey/iomediator/_iomediator.py", line 50, in init self.interface = XRecordInterface(self, service.app) File "/usr/lib/python3.6/site-packages/autokey/interface.py", line 201, in init self.__initMappings() File "/usr/lib/python3.6/site-packages/autokey/interface.py", line 254, in __initMappings self.localDisplay = display.Display() File "/usr/lib/python3.6/site-packages/Xlib/display.py", line 89, in init self.display = _BaseDisplay(display) File "/usr/lib/python3.6/site-packages/Xlib/display.py", line 71, in init protocol_display.Display.init(self, *args, **keys) File "/usr/lib/python3.6/site-packages/Xlib/protocol/display.py", line 160, in init raise error.DisplayConnectionError(self.display_name, r.reason) Xlib.error.DisplayConnectionError: Can't connect to display ":0": b'No protocol specified\n'

[luziferius]

This error message indicates that autokey cannot connect to the X server. This may or may not be a permission problem.

• Is there an X server running?
• Is autokey-gtk run from within the GUI session or from a tty?
• Is it run as root? Autokey does not need root privileges and should not be run from a root shell.
• is $DISPLAY correctly set (most probably, on a default system, it should be :0)
• Is your $XAUTHORITY correct? See https://unix.stackexchange.com/a/118826.
• Is AppArmor interfering? Run dmesg -T | grep "apparmor=" to see if something related to AppArmor and autokey is in the system log.

[luziferius]

@roseswe Is this still an issue?

[roseswe]

Yes also with 0.95.3 Also gives me a "(autokey-gtk:9885): Gdk-CRITICAL **: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed"

BTW: autokey-gtk -V or --version could be useful!

[roseswe]

~ > echo $XAUTHORITY /run/user/1000/gdm/Xauthority ~ > echo $DISPLAY :0

Run as user, either a from terminal or GNOME failed with the same message OS = openSUSE Leap 15.0

~ > export XAUTHORITY=~/.Xauthority ~ > autokey-gtk No protocol specified No protocol specified Unable to init server: Could not connect: Connection refused No protocol specified No protocol specified Unable to init server: Could not connect: Connection refused

(autokey-gtk:10560): Gtk-CRITICAL **: gtk_clipboard_get_for_display: assertion 'display != NULL' failed

(autokey-gtk:10560): Gtk-CRITICAL **: gtk_clipboard_get_for_display: assertion 'display != NULL' failed Fatal Python error: Segmentation fault

Current thread 0x00007fa147582540 (most recent call first): File "/usr/lib64/python3.6/site-packages/gi/overrides/init.py", line 326 in new_init File "/usr/lib64/python3.6/site-packages/gi/overrides/init.py", line 326 in new_init File "/usr/lib64/python3.6/site-packages/gi/overrides/Gtk.py", line 541 in init File "/usr/lib64/python3.6/site-packages/gi/overrides/init.py", line 326 in new_init File "/usr/lib/python3.6/site-packages/autokey/gtkapp.py", line 281 in show_error_dialog File "/usr/lib/python3.6/site-packages/autokey/gtkapp.py", line 154 in initialise File "/usr/lib/python3.6/site-packages/autokey/gtkapp.py", line 98 in init File "/usr/lib/python3.6/site-packages/autokey/gtkui/main.py", line 8 in main File "/usr/bin/autokey-gtk", line 11 in Segmentation fault (core dumped)

[luziferius]

BTW: autokey-gtk -V or --version could be useful!

Now on the TODO list for the next version :) https://github.com/autokey/autokey/issues/190

 export XAUTHORITY=~/.Xauthority

Don’t mess with it like that. The X authority path is set by your system and should be right. After exporting, it points to a non-existing file (if openSuse uses /run/user/1000/gdm/Xauthority instead of ~/.Xauthority), causing those Connection refused errors.

The interesting bit is if xauth list returns valid data. I don’t really know the details, so the only thing I can say is: If xauth list gives some error message, something is wrong.

The error message Xlib.error.DisplayConnectionError: Can't connect to display ":0": b'No protocol specified\n' directly comes from the used Xlib library, thus is not directly an autokey error. There are several other programs affected because of various reasons https://www.google.com/search?q=Can%27t+connect+to+display+%22%3A0%22%3A+b%27No+protocol+specified\n%27&ie=utf-8&oe=utf-8

Try creating a simple script containing

#!/bin/bash
echo $DISPLAY

Mark it as executable and run it from a fresh shell. It should output a valid value (like :0)

Try running xhost +localhost in the shell before starting autokey. This allows all applications on the local machine to run on your X server, regardless of any permissions. If autokey starts afterwards, it is definitely some issue with your GUI session.

[ghost]

I'm on openSUSE Leap 15.0 and I got exactly the same problem. After some try, I solved the issue by granting all permission to the X access with command xhost +. It just a workaround, I didn't have time to investigate which permission name it is.

I think maybe Leap 15 have a more restrict default permission to X. I recalled when I run a GUI application inside docker container, I encountered similar issue.

[luziferius]

@wnereiz try xhost +localhost instead. It does the same for local processes, but doesn’t open up all doors for unrestricted network access.

Thank you for confirming that this is a permission issue on openSUSE.

[beroal]

I have a similar issue with autokey-gtk on ArchLinux, though the error message is different. It is

Error starting interface. Keyboard monitoring will be disabled. Check your system/configuration. Can't connect to display ":2.0": b'Invalid MIT-MAGIC-COOKIE-1 key'

I am using LightDM, so I do not set up Xorg server authorization myself. I start autokey-gtk from layout-b450-main seat0. The result is the same independently of whether I start autokey-gtk from a virtual terminal or from the XFCE program menu.

/etc/lightdm/lightdm.conf:

[LightDM]
minimum-vt=6
minimum-display-number=1
run-directory=/run/lightdm

[Seat:*]
xserver-share=true
greeter-session=lightdm-kde-greeter
session-wrapper=/etc/lightdm/Xsession
user-session=xfce
allow-guest=false
autologin-guest=false

[Seat:seat0]
xserver-layout=layout-b450-main
exit-on-failure=false

[Seat:seat-guest]
xserver-layout=layout-hd6670-guest
exit-on-failure=false

[Seat:seat-root]
exit-on-failure=false

At the time of the error: ps -e | grep Xorg

    510 /usr/lib/Xorg :2 -layout la S tty6     00:06:38 /usr/lib/Xorg :2 -layout layout-b450-main -seat seat0 -auth /run/lightdm/root/:2 -nolisten tcp vt6 -novtswitch
  29652 /usr/lib/Xorg :1 -layout la S ?        00:00:00 /usr/lib/Xorg :1 -layout layout-hd6670-guest -seat seat-guest -auth /run/lightdm/root/:1 -nolisten tcp

[DaAwesomeP]

I'm seeing this in openSUSE Leap 15.4.

Here are some related issues in other applications. I think this is possibly the same issue:

• Basically the same issue: https://github.com/flatpak/flatpak/issues/4043#issuecomment-770964461
• Another in-depth explanation: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/issues/53
• xhost +si:localuser:$(id -nu) workaround that shouldn't be necessary: https://github.com/flatpak/flatpak/issues/1821#issuecomment-577859329
• openSUSE bug: https://bugzilla.opensuse.org/show_bug.cgi?id=262309
• Example fix: https://github.com/flatpak/flatpak/pull/4130

openSUSE's hostname changes, causing the hostname associated with the MIT-MAGIC-COOKIE to no longer match. The solution is to fall back to $XAUTHLOCALHOSTNAME when the cookie fails with the current hostname (see that last pull request link for an example).

[josephj11]

@DaAwesomeP Thanks for the information. I don't understand this issue.

Is this a problem within openSUSE that they have to fix and/or is there something we have to fix in AutoKey?

I haven't explored the links you provided yet, but they look like they are noit drectly related to AutoKey.

If you know of a workaround such as other posts above on this issue suggest, we could add something about it to our wiki.

[DaAwesomeP]

I think this is something to fix in autokey; I will look into it this week and possibly turn it into a pull. It has to do with how autokey presents the correct hostname to xauth.

[josephj11]

@DaAwesomeP TY! We currently have very limited developer resources and need all the help we can get.

[Elliria]

Yes, please do, @DaAwesomeP. We would love the help. You might also find the Contributing Code page useful.