Missing some input devices in wayland session

[schauveau]

I am using sway compiled from git master on Debian and I noticed that my Fn+Brightness keys were not reporting any events when Sway is started by LightDM (via a custom desktop file in /usr/share/wayland-sessions/ ). Everything works fine when I manually start Sway from a VT.

I eventually figured out that Sway started via LigthDM is only showing 5 of the 8 input devices that my laptop is normally providing. However, those missing input devices exist in the system and can be tested using evtest or libinput. I also noticed that the missing input devices (and the brightness key events) become visible after switching back and forth to another VT.

The issue is not limited to Sway. I also tested Weston. It does not provide a list of its input devices but I noticed that weston-eventdemo is not reporting any event for the Fn+Brightness keys until I switch VT manually.

So I suspect a race condition between LightDM and the Wayland compositor using libinput (because of ibus? systemd? VT switch?).

For me, a temporary workaround was to add a sleep 1 command before starting sway.

System information:

• debian buster
• ligthdm 1.26.0-3
• weston 5.0.0-1
• libinput 1.12.6-1
• sway version 1.0-rc1-145-g19df2e59 (Mar 6 2019, branch 'master')

[schauveau]

I now think that the problem is caused by VT switching. I replaced the sleep command by the following code in my bash startup script and I observe that the VT switch takes about 200ms.

if [ -n "$XDG_VTNR" ] ; then
    echo "Waiting for VT $XDG_VTNR:"
    for ((i=0;i<100;i++)) ; do
      CURRENT="$(</sys/devices/virtual/tty/tty0/active)" 
      echo  "  $(date +%s.%N) using $CURRENT"
      if [[ "$CURRENT" = "tty$XDG_VTNR" ]]; then
          break
      fi
      sleep 0.01
    done 
fi

Sample output is

Waiting for VT 8:
  1552154764.152520398 using tty7
  1552154764.164865259 using tty7
  1552154764.177245339 using tty7
  1552154764.190049547 using tty7
  1552154764.203371044 using tty7
  1552154764.218131704 using tty7
  1552154764.233349038 using tty7
  1552154764.248466143 using tty7
  1552154764.263763813 using tty7
  1552154764.279163875 using tty7
  1552154764.294596960 using tty7
  1552154764.309962151 using tty7
  1552154764.325172099 using tty7
  1552154764.340315917 using tty7
  1552154764.355977478 using tty7
  1552154764.371343461 using tty8

[trwnh]

@schauveau where did you add the sleep 1 command?

[schauveau]

As of today, Debian does not provide any user-defined Wayland session so I created my own using the following 3 files:

A custom Wayland session file /usr/share/wayland-sessions/wayland-user-session.desktop

[Desktop Entry] 
Name=Wayland User Session
DesktopNames=Wayland
Exec=/usr/local/bin/wayland-user-session
Type=Application
X-LightDM-Session-Type=wayland

Then an executable script /usr/local/bin/wayland-user-session

#!/bin/sh
exec $HOME/.wayland-session

And finally a ~/.wayland-session script where I customize my Wayland environment before starting sway.

#!/bin/bash
source /opt/sway/env.sh 
export PATH="$HOME/bin:$PATH"
... 
exec /opt/sway/bin/sway

The sleep command (see my previous comment) is done just before the final exec in that script.

Remark: If I remember well, Lightdm on Debian starts its Wayland sessions exactly like regular X11 sessions by calling the script /etc/Xsession which itself executes everything in /etc/Xsession.d/* and eventually calls the program specified in the session file. In practice, that means that I do not need to care about services such as dbus and ssh-agent in my ~/.wayland-session script. However, be aware that every Xsession script that relies on X11 will fail (hopefully in a non fatal way) since XWayland is not yet started at that time. That also means that an alternative location for the sleep command could be a custom script in /etc/Xsession.d/* . That script could identify Wayland sessions by testing $XDG_SESSION_TYPE=="wayland"

Have fun.

[andyrtr]

Using Arch linux with sway package + lightdm gives a similar issue: usb mouse connector isn't recognised until you pull and plug it in again. It's probably the same race condition.

see also last comment here: swaywm/sway#3192

[schauveau]

Yes, this is likely the same issue. Sway developers are very explicit about the fact that they do not care about bugs that involve a login manager. Also the fact that this ticket did not receive any answer tells me that the lightdm devs probably do not care either about bugs in an obscure compositor like sway. Filling a bug in Arch linux could help.
In the meantime, waiting for the VT switch completion before starting Sway (see my previous comments) is probably the best solution.

[YorozuyaDev]

I tried with sleep 1 before and it doesn't fixed, but using linux kernel 5.1.16 bright keys work fine, except if I close session and start a new one. (using swaywm in arch linux)

[trwnh]

I'm having issues with XFCE brightness control under LightDM as well, in addition to Sway under LightDM. This bug makes me just want to disable LightDM and type in "sway" or "startxfce4" manually after boot+login.

[Iey4iej3]

Does you LightDM greeter run under wayland? See https://lists.freedesktop.org/archives/lightdm/2019-June/001172.html

[schauveau]

@Iey4iej3 Interesting but running LigthDM under X11 or Wayland probably does not matter here because LightDM terminates its own session before starting Sway in a different VT. The issue is that Sway (or more precisely libinput) fails to grab some devices when it is started while the VT switch is still not complete. I do not see how running LightDM under Wayland could help.

[Strum355]

1s sleep fixed the issue for me, not just for brightness controls but also touchscreen, on Dell XPS 15 9500 (i9 4k touchscreen version) running Arch with kernel 5.9.0-rc5-ath11k and latest sway/wayland available through pacman/AUR at the time of writing.

I noticed that touchscreen events and brightness events weren't showing in wev/xev but did under evtest, and neither were showing in swaymsg -t get_inputs, but were showing under libinput list-devices.