Sunshine icon indicating copy to clipboard operation
Sunshine copied to clipboard

Input doesn't work on headless wayland

Open dukzcry opened this issue 2 years ago • 9 comments

Describe the Bug

Sway run as

WLR_BACKENDS=headless WLR_LIBINPUT_NO_DEVICES=1 sway

Input (mouse, keyboard, virtual gamepad) doesn't work If I run sway in non-headless mode, input works fine

Expected Behavior

Input should work when sway is run in headless mode

Additional Context

No response

Sunshine Host Operating System and Version

Linux NixOS 21.11.333823.96b4157790f (Porcupine)

Architecture

64 bit

Sunshine Version

0.13.0

GPU Type

AMD

GPU Model

Vega 11

GPU Driver/Mesa Version

mesa 21.2.5

Capture Method (Linux Only)

No response

dukzcry avatar Apr 22 '22 09:04 dukzcry

:wave: @dukzcry, please edit your issue to complete the template with all the required info. Your issue will be automatically closed in 5 days if the template is not completed. Thanks.

github-actions[bot] avatar Apr 22 '22 15:04 github-actions[bot]

specifically: Sunshine Host Operating System and Version

ReenigneArcher avatar Apr 22 '22 15:04 ReenigneArcher

This issue was closed because the the template was not completed after 5 days.

github-actions[bot] avatar Apr 29 '22 00:04 github-actions[bot]

I can reproduce this issue as well (Fedora 36, Linux 5.17.13, AMD Radeon RX 6900XT, Sunshine 0.14.0, Sway 1.7, libinput 1.21), but I have an additional clue as to what might be happening.

While running Sway headless (and spawning Sunshine inside Sway), I had left GDM running on the primary head.

When I attached to Sunshine, I could see my Sway desktop, but my keyboard/mouse inputs were actually making it to the GDM session on the same host, but a different head (different Wayland session).

So inputs are being directed to the wrong place.

jeremyvisser avatar Jun 29 '22 11:06 jeremyvisser

Having same issue (Arch Linux 5.18.3, AMD Radeon RX 590, latest sunshine git, Sway 1.8, libinput 1.21.0). After applying patch by sergioperez and running sway in headless mode input doesn't work, in wayvnc input works at the same time.

qwert0p avatar Jul 10 '22 20:07 qwert0p

Just wanted to add some further thoughts on this. Disclaimer: I’m still fairly new to this area so I might be making bad assumptions (i.e. happy to be corrected).

Modern systems (based on systemd and logind) have the concept of a seat (seat0 is default), with associated input devices and graphics outputs. For example, look at loginctl seat-status seat0.

When Sunshine fires up uinput, it’s logically similar to plugging in a second USB mouse: the input gets attached to the default seat (seat0). This is why the Sunshine input shows up on GDM, rather than your headless Sway.

Running headless Sway from a terminal as described above (WLR_BACKENDS=headless WLR_LIBINPUT_NO_DEVICES=1 sway) doesn't create an additional seat (loginctl list-seats). libinput doesn't know which inputs it should/shouldn't use, without having done a loginctl attach seat-headless-sway /dev/uinput (or similar).

While I don't know exactly what the solution should look like, I think a headless session should ideally run as a separate "seat" (as far as logind and libinput are concerned).

This likely implies using a display manager (e.g. GDM) to launch the session.

The burden for figuring this out falls to the Sway user community, not Sunshine. If a headless session existed in a proper seat, with uinput attached appropriately, and WLR_LIBINPUT_NO_DEVICES=1 not specified, Sunshine would probably work correctly as-is.

But I suspect not all of the pieces exist, yet. For example, GDM does not seem to have any specific knowledge of headless sessions, or per-seat automatic login. Or Sway doesn't seem to know about seats. Or amdgpu has a virtual output mode, but this breaks real monitor outputs. I don't know what the answer looks like, but it's likely to involve some work.

To address another question: why does wayvnc work properly? What does it do differently than Sunshine? Well, wayvnc creates virtual input devices specific to the current Wayland session, but rather than uinput, it uses the virtual_keyboard_unstable_v1 protocol. GNOME explicitly does not support this protocol, and wayvnc is explicitly incompatible with GNOME or KDE. Meanwhile, GNOME prefers a solution that uses libei, but either way efforts have stalled. There are a few potential approaches, but generally result in a solution that only works for a small subset of users.

jeremyvisser avatar Jul 11 '22 04:07 jeremyvisser

Oh, i fixed my issue by simply setting WLR_BACKENDS=headless,libinput and removing WLR_LIBINPUT_NO_DEVICES=1.

qwert0p avatar Jul 12 '22 14:07 qwert0p

@jeremyvisser I agree that this may not be something that can (or should) be fixed on the Sunshine end of things, but find the discussion very interesting! My own "solution" was to setup sway accordng to their Wiki and start the headless session without a login manager via bash profile login on another tty with the following startup options:

#!/bin/bash

export DESKTOP_SESSION="sway"
export XDG_CURRENT_DESKTOP="sway"
export XDG_SESSION_DESKTOP="sway"
export XDG_SESSION_TYPE="wayland"
export WLR_BACKENDS="headless,libinput"

exec /usr/bin/sway -c /home/play/.config/sway/head

Input works as long as the session is focused and game controllers (not controlled via sway-input) stay focused on the sway session even after switching the focus back to another tty (X11 session). It's not a solution for everybody, but pretty much does what I'm asking for - using the main session while someone else can stream a game to the TV.

As for the seatx configuration, are you sure that sway does not support this? the sway-input manual explicitly mentions assigning devices to seats, so maybe something could be done with that. Edit: Scratch that. As Jeremy writes, sway headless (even with libinput) does not create a seat, so there's nothing there to attach to.

falk4243 avatar Jul 12 '22 16:07 falk4243

To address another question: why does wayvnc work properly? What does it do differently than Sunshine? Well, wayvnc creates virtual input devices specific to the current Wayland session, but rather than uinput, it uses the virtual_keyboard_unstable_v1 protocol. GNOME explicitly does not support this protocol, and wayvnc is explicitly incompatible with GNOME or KDE.

I've just had a quick chat with one of the sway devs and he suggested that implementing "wlr-virtual-{pointer,keyboard}" instead of going through evdev would solve the issue (at least as far as sway is concerned). I'm not a developer myself, but maybe the suggestion isn't completely outlandish and somebody working on Sunshine could pick this up?

Edit: Since this is a bug report and not a feature request and the discussion is all over the place, I have opened a feature request for better visibility as this could be quite intersting to people looking for a simple way to integrate headless game streaming.

falk4243 avatar Aug 12 '22 15:08 falk4243

This issue is stale because it has been open for 90 days with no activity. Comment or remove the stale label, otherwise this will be closed in 10 days.

LizardByte-bot avatar Nov 12 '22 00:11 LizardByte-bot

This issue was closed because it has been stalled for 10 days with no activity.

LizardByte-bot avatar Nov 23 '22 00:11 LizardByte-bot

@falk4243 This worked for a problem i had with Sunshine not accepting any kind of input.

Many thanks kind stranger! Your solution helped me greatly!

rathmerdominik avatar May 27 '23 21:05 rathmerdominik

@falk4243 This worked for a problem i had with Sunshine not accepting any kind of input.

Many thanks kind stranger! Your solution helped me greatly!

All you did was add those environment variables and run sway then sunshine? I still don't get any inputs and was wondering if there was more to the solution.

EDIT: Nevermind I got it working by going into the tty first with sunshine and running it then going in again with WAYLAND_DISPLAY=wayland-1 sunshine to access sway. There probably is a better way to run this that I'm missing.

NickSica avatar Aug 25 '23 20:08 NickSica