Fix Steam input in unprivileged containers

[ABeltramo]

Steam input works by creating virtual devices using uinput (similar to how we do it in inputtino). So the first step is obviously to allow the Steam container to access it:

devices = ["/dev/uinput:/dev/uinput"]
env = [
  "PROTON_LOG=1",
  "RUN_GAMESCOPE=true",
  "GOW_REQUIRED_DEVICES=/dev/uinput /dev/input/* /dev/dri/* /dev/nvidia*"
]

When you start a game with steam input enabled the following uevents will be generated:

➜ docker exec -it -u retro WolfSteam_4135727842959053255 udevadm monitor -p
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[13943.544155] add      /devices/virtual/input/input165 (input)
ACTION=add
DEVPATH=/devices/virtual/input/input165
SUBSYSTEM=input
PRODUCT=3/28de/11ff/1
NAME="Microsoft X-Box 360 pad 0"
PROP=0
EV=20000b
KEY=7cdb0000 0 0 0 0 0 0 0 0 0
ABS=3003f
FF=10000 0 0
MODALIAS=input:b0003v28DEp11FFe0001-e0,1,3,15,k130,131,133,134,136,137,13A,13B,13C,13D,13E,ra0,1,2,3,4,5,10,11,mlsf50,w
SEQNUM=23561

KERNEL[13943.544214] add      /devices/virtual/input/input165/event26 (input)
ACTION=add
DEVPATH=/devices/virtual/input/input165/event26
SUBSYSTEM=input
DEVNAME=/dev/input/event26
SEQNUM=23562
MAJOR=13
MINOR=90

KERNEL[13943.544244] add      /devices/virtual/input/input165/js3 (input)
ACTION=add
DEVPATH=/devices/virtual/input/input165/js3
SUBSYSTEM=input
DEVNAME=/dev/input/js3
SEQNUM=23563
MAJOR=13
MINOR=3

As you can see it's missing the corresponding udev events (network isolation for the win); we'll have to pick those kernel events up, mknod the devices and relay the correspondent udev event using fake-udev.

The only bit that I'm not sure is how to avoid mounting other containers devices. Unfortunately kernel events aren't isolated, for example I can see the event for when a device is plugged in the host.. How can we mknod only the devices that are actually generated by this steam instance? Intercept /dev/uinput ioctl calls?

Quick fix

This will break isolation, but for a single user this should work:

[[apps]]
title = "Steam"
start_virtual_compositor = true

[apps.runner]
type = "docker"
name = "WolfSteam"
image = "ghcr.io/games-on-whales/steam:edge"
mounts = ["/dev/input:/dev/input:rw", "/run/udev:/run/udev:ro"]
env = [
  "PROTON_LOG=1",
  "RUN_GAMESCOPE=true",
  "GOW_REQUIRED_DEVICES=/dev/uinput /dev/input/* /dev/dri/* /dev/nvidia*",
]
devices = ["/dev/uinput:/dev/uinput"]
ports = []
base_create_json = """
{
  "HostConfig": {
    "NetworkMode": "host",
    "IpcMode": "host",
    "CapAdd": ["SYS_ADMIN", "SYS_NICE", "SYS_PTRACE", "NET_RAW", "MKNOD", "NET_ADMIN"],
    "SecurityOpt": ["seccomp=unconfined", "apparmor=unconfined"],
    "Ulimits": [{"Name":"nofile", "Hard":10240, "Soft":10240}],
    "Privileged": false,
    "DeviceCgroupRules": ["c 13:* rmw", "c 244:* rmw"]
  }
}
\
"""

And set the env variable WOLF_DOCKER_FAKE_UDEV_PATH="" to disable our fake_udev implementation.

[Drakulix]

Intercept /dev/uinput ioctl calls?

Yes. A valve engineer confirm to me, that LD_PRELOAD-ing steam to do this should give us all the infos we need.

Basically we should intercept UI_DEV_CREATE and then internally call UI_GET_SYSNAME, matching the name to our container and returning from the intercepted ioctl.

Everything that is not UI_DEV_CREATE we can just passthrough and ignore.

[ABeltramo]

Thank you so much for confirming it! It should be fairly straightforward then, just need to plug together fake-udev and mknod in a simple library that I'll preload.
Damn I wish I could bother a Valve engineer too 😅

[pahaze]

Nice, unfortunately that's just a workaround.. Hopefully I'll get around to properly support Steam input in Wolf!

If possible, I might try to look into it some myself too. I'm not too experienced with Docker, or Linux to that level, and I'd like to start learning! I've not been doing much programming as is, too :). But, just an idea, and please tell me if this isn't possible or I'm wrong, but is it possible to set up seats between the Wayland sessions to know which Steam Input device is being used for each Wolf session, rather than having to rely on kernel events and potentially accessing other containers?

[ABeltramo]

Unfortunately no, historically compositors just ignored joypads and apps had to direcly access them so everything relies on accessing stuff directly under /dev/input.

If you want to take a look into this I suggest reading how we achieved hotplug in Docker and the rationale behind this issue and the status of the corresponding stale PR.

Feel free to jump in our Discord server if you want to ask anything in more detail!

[pahaze]

I see.. I'll definitely try to look into it some if I can, at the very least to try to get a better understanding. I did change my config, and I got this at first:

Which, scared me, until I went past the screen and saw it was actually working as an Xbox controller (hello from work!) 😆

Thanks again for the help and all info!