[PopOS19.10/Wayland] No protocol specified failed to open X11 display ":0.0"

[Arxcis]

Hi I am running Gnome with Wayland on PopOS 19.10. I can see that spacenavd relies heavily on the X11 display server being present.

➜  ~ tail -f /var/log/spnavd.log 
failed to open X11 display ":0.0"
No protocol specified
failed to open X11 display ":0.0"
No protocol specified
failed to open X11 display ":0.0"
No protocol specified
failed to open X11 display ":0.0"
No protocol specified
failed to open X11 display ":0.0"
found X socket yet failed to connect

I have an XWayland session running, so I should support X11 protocol.

[Arxcis]

So I read about the .Xauthority trick in FAQ #10

If there isn't an .Xauthority file in the root user's home directory (commonly /root) then you must symlink your user's .Xauthority there, to allow root connect to the X server.

This is what I tried

➜  ~ echo $XAUTHORITY 
/run/user/1000/.mutter-Xwaylandauth.3QNFI0
➜  ~ sudo -i
root@pop-os:~# cp /run/user/1000/.mutter-Xwaylandauth.3QNFI0 /root/.Xauthority
root@pop-os:~# exit
logout
➜  ~ reboot

When getting back in i check by spnavd.log

➜  ~ tail -f /var/log/spnavd.log
Invalid MIT-MAGIC-COOKIE-1 keyfailed to open X11 display ":0.0"
Invalid MIT-MAGIC-COOKIE-1 keyfailed to open X11 display ":0.0"
Invalid MIT-MAGIC-COOKIE-1 keyfailed to open X11 display ":0.0"
Invalid MIT-MAGIC-COOKIE-1 keyfailed to open X11 display ":0.0"
Invalid MIT-MAGIC-COOKIE-1 keyfailed to open X11 display ":0.0"
Invalid MIT-MAGIC-COOKIE-1 keyfailed to open X11 display ":0.0"
Invalid MIT-MAGIC-COOKIE-1 keyfailed to open X11 display ":0.0"
Invalid MIT-MAGIC-COOKIE-1 keyfailed to open X11 display ":0.0"
Invalid MIT-MAGIC-COOKIE-1 keyfailed to open X11 display ":0.0"
found X socket yet failed to connect

Update Ahhhh I see now that I copied instead of symlinking. brb!

lrwxrwxrwx  1 root root   42 Apr  4 01:08 .Xauthority -> /run/user/1000/.mutter-Xwaylandauth.3QNFI0

[Arxcis]

As I suspected the $XAUTHORITY changes on ever boot of my system.

➜  ~ echo $XAUTHORITY 
/run/user/1000/.mutter-Xwaylandauth.3QNFI0
# Reboot
➜  ~ echo $XAUTHORITY
/run/user/1000/.mutter-Xwaylandauth.HPVHI0

[jtsiomb]

So problem fixed?

Edit: oh the filename changes so you can't fix it with a symlink is what you're saying. I guess you could try to make some sort of script that runs on every boot, finds the X magic cookie and symlinks it correctly?

[jtsiomb]

This is not a bug in spacenavd. It has to do with X authority management, so I'm closing the bug report. But feel free to post here, and I will try to monitor and assist if I can.

[Arxcis]

oh the filename changes so you can't fix it with a symlink is what you're saying.

Correct.

I tried to create a wrapper-script for the spacenavd-service like this

mv /usr/local/bin/spacenavd /usr/local/bin/spacenavd-actual
vim /usr/local/bin/spacenavd

Content of /usr/local/bin/spacenavd

#!/usr/bin/env bash
XAUTHORITY=`ls /run/user/*/.mutter-Xwaylandauth.*` /usr/local/bin/spacenavd-actual

On paper, it looks like this could work, but I had no luck with this trick and got the same No protocol...-error I had originally :/

Suggestions are welcome :+1:

[jtsiomb]

This solution seems reasonable, but I'm not familiar with how wayland handles starting the X server and managing the MIT magic cookies to have any insight in the matter. The only thing I can suggest to iterate on trying out things easier, is to login through tty2 as root, and try running a simple X client like xdpyinfo with your XAUTHORITY environment variable set (and DISPLAY=:0.0), and see if it works, or what it takes to make it work.

[Arxcis]

The only thing I can suggest to iterate on trying out things easier, is to login through tty2 as root, and try running a simple X client like xdpyinfo with your XAUTHORITY environment variable set (and DISPLAY=:0.0), and see if it works, or what it takes to make it work.

Ooo that is a good tip :+1: Thank you very much. I tried it out real quick on my local user, just to see what it takes to make xdpyinfo fail.

Test 1: Run xdpyinfo without XAUTHORITY

xdpyinfo does not seem to care about XAUTHORITY, because it works without it.

$ DISPLAY=:0 XAUTHORITY="" xdpyinfo
name of display:    :0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    12005000
X.Org version: 1.20.5
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  None
number of extensions:    25
    BIG-REQUESTS
....

Test 2: Run xdpyinfo without DISPLAY

Setting DISPLAY="" on the other hand makes it fail

$ DISPLAY="" XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.363BI0 xdpyinfo 
xdpyinfo:  unable to open display "".

DISPLAY=""  XAUTHORITY="" xdpyinfo
xdpyinfo:  unable to open display "".

Test 3: Compile spacenavd without x11 support

I also tried to compile spacenavd without the x11 support using ./configure --disable-x11. Now my daemon is running without errors :+1:

➜  spacenavd git:(master) ./configure --disable-x11
configuring spacenavd - v0.7.1-5-g11a43b8
  prefix: /usr/local
  optimize for speed: yes
  include debugging symbols: yes
  x11 communication method: no
  use hotplug: yes

WARNING: you have disabled the X11 interface, the resulting daemon won't be compatible with applications written for the proprietary 3Dconnexion daemon (3dxserv)!

creating Makefile ...
creating config.h

Done. You can now type make (or gmake) to compile spacenavd.

➜  spacenavd git:(master) make
...
➜  spacenavd git:(master) reboot
...
➜  spacenavd git:(master) tail -f /var/log/spnavd.log
Spacenav daemon v0.7.1-5-g11a43b8
reading config file: /etc/spnavrc
failed to open config file /etc/spnavrc: No such file or directory. using defaults.
adding device.
device name: 3Dconnexion SpaceNavigator
using device: 3Dconnexion SpaceNavigator (/dev/input/event17)

@jtsiomb Are there any overview of which apps work without x11? I see that Blender is mentioned in the README.md, but do you know of other apps?

But I don't see any output comming from the /dev/input/event17 mentioned by the spacenavd.log.

➜  spacenavd git:(master) sudo cat /dev/input/event17
....no output here when moving the spacemouse

Is this to be expected?

Test 4: Compile spacenavd with x11 support, and run directly

Running spacenavd directly gives me no output, and it quits immediately.

➜  spacenavd git:(master) ./configure 
configuring spacenavd - v0.7.1-5-g11a43b8
  prefix: /usr/local
  optimize for speed: yes
  include debugging symbols: yes
  x11 communication method: yes
  use hotplug: yes

creating Makefile ...
creating config.h

Done. You can now type make (or gmake) to compile spacenavd.

➜  spacenavd git:(master) make 
...
➜  spacenavd git:(master) echo $XAUTHORITY 
/run/user/1000/.mutter-Xwaylandauth.363BI0
➜  spacenavd git:(master) echo $DISPLAY      
:0
➜  spacenavd git:(master) spacenavd
...nothing
➜  spacenavd git:(master) DISPLAY="" spacenavd
...silence
➜  spacenavd git:(master) XAUTHORITY="" spacenavd
...emptyness

Is this to be expected?

[Arxcis]

Back to running without x11 now. spnavcfg is awesome.

[jtsiomb]

spacenavd is a daemon. It doesn't print anything in the console because it doesn't have a controlling terminal, it logs any messages to /var/log/spnavd.log. If you want to prevent spacenavd from daemonizing, and have it write its messages to the console instead, pass the -d option.

When building spacenavd with X11 support, even if the connection to the X server fails to be established, the non-X11 protocol still works fine. You don't need to build without X11 to make it work. That option is there just for people who don't want the X dependency, or running headless systems and don't even have X libraries installed.

Unless your X server has authentication disabled (xhost +), no X client can connect without a valid MIT-MAGIC-COOKIE:

$ XAUTHORITY='' xdpyinfo
No protocol specified
xdpyinfo:  unable to open display ":0".

[Arxcis]

Unless your X server has authentication disabled (xhost +), no X client can connect without a valid MIT-MAGIC-COOKIE:

You are of course right. There is probably some kind of caching of XAUTHORITY's magic cookie, once you are logged in. Hmm..

[Arxcis]

Update I have a setup that works for me now, although it is not a generic solution. I have two symlinks. One in /root and one in /home/jonas

root root   .Xauthority -> /home/jonas/.Xauthority
jonas jonas .Xauthority -> /run/user/1000/.mutter-Xwaylandauth.OS8MI0

Roots symlink points to my symlink which points to the actual dynamic xauthority file.

In my .zshrc I have a script which generates a new .Xauthority on every login, as long as $XAUTHORITY exists.

#
# Update ~/.Xauthority
#
if [ -n "$XAUTHORITY" ]; then
    rm -f "$HOME/.Xauthority";     
    ln -s $XAUTHORITY "$HOME/.Xauthority";
fi

[jtsiomb]

nice, glad you sorted it out

[Arxcis]

nice, glad you sorted it out

Thank you for sticking with me :+1:

[aweibell]

I did not succeed with this I'm running Sway Window manager on Fedora 32 with Wayland. Also running XWayland, but I have no $XAUTHORITY set, and no .Xauthority file that I can see. In spnavcfg I'm told that "spacenavd driver is running fine", and systemctl reports the service to be running. The log in /var/log/spnavd.log, however, says

no protocol specified failed to open X11 display ":0.0"

The device (3Dconnexion Space Mouse) was recognized, though.

It would be nice if the FAQ could include some information on how to run this with Wayland.

Side note: According to the vendor page it should also be possible to use for OnShape within the browser – is that expected to work in linux with spacenavd as well? https://www.3dconnexion.eu/index.php?id=425

[jtsiomb]

I'm sorry but I have no interest whatsoever in wayland, and therefore I don't know anything about it. If you wish to write a guide for setting everything up with wayland, I'll be glad to include a link to the guide in the FAQ though.

I take it "OnShape" is a web app. I don't know what mechanism it uses to receive 6dof input from within the browser. You better ask the OnShape developers about this.

[aweibell]

I'm sorry but I have no interest whatsoever in wayland, and therefore I don't know anything about it. If you wish to write a guide for setting everything up with wayland, I'll be glad to include a link to the guide in the FAQ though.

Oh... that was surprising! I thought Wayland was expected to more and more replace Xorg, so I would expect that to be relevant for SpaceNav.

I take it "OnShape" is a web app. I don't know what mechanism it uses to receive 6dof input from within the browser. You better ask the OnShape developers about this.

– I asked you because the 3dconnexion page mentioned it, and as I understand FreeSpaceNav aims to be compatible with the original driver.

[jtsiomb]

OnShape is a javascript web-app, so necessarilly it can't possibly use the 3dconnexion API directly. It has to go through unknown layers of javascript and browser abstractions, and I don't know through what mechanism it ends up receiving 6dof input. If it turns out that below all these layers the browser uses the 3dconnexion API to feed events to javascript apps, then it should work with spacenavd too, but I doubt that's what happens. In any case as I said, this is a question the OnShape developers are in a position to answer, so I suggest you just ask them, instead of guessing.

I thought Wayland was expected to more and more replace Xorg, so I would expect that to be relevant for SpaceNav.

I don't think so. I'd be extremely surprised if wayland ever manages to replace X11 as the defacto standard window system for UNIX systems. But even if that happened that's not really relevant to this project. The X11 part of spacenavd is there just to provide compatibility with the original 3dconnexion driver and its X-based event delivery protocol. If X somehow went away, it's not like there would be any reason to deal with wayland at all.