Incus container support

[Danukeru]

Host: Ubuntu 24.04
Running Incus 6.33

(mouse and kb input was temporarily achieved by passing in devices explicitly to get these images)

Under the container config this properly maps, and I see creation host side of devices when sunshine boots up in the container which has a V100 passthrough under Xorg. I can run ie. Death Stranding 2 without issue under WINE.

However within the container I do not see creation or mappings under /dev/input and have the following errors host side for vuinputd once sunshine starts. vuinputd does not run within the container.
/dev/input is create using a systemd unit /etc/systemd/system/dev-input.mount using tmpfs upon container start

Mar 26 02:09:17 KONPEKO systemd[1]: Started vuinputd.service - uinput proxy.
Mar 26 02:09:17 KONPEKO vuinputd[1272563]: [2026-03-26T02:09:17Z WARN  vuinputd::vt_tools] tty1 keyboard mode is active (mode=3) — VT may consume input
Mar 26 02:10:35 KONPEKO systemd[1]: Stopping vuinputd.service - uinput proxy...
Mar 26 02:10:35 KONPEKO systemd[1]: vuinputd.service: Deactivated successfully.
Mar 26 02:10:35 KONPEKO systemd[1]: Stopped vuinputd.service - uinput proxy.
Mar 26 02:10:35 KONPEKO systemd[1]: Started vuinputd.service - uinput proxy.
Mar 26 02:10:35 KONPEKO vuinputd[1273647]: [2026-03-26T02:10:35Z WARN  vuinputd::vt_tools] tty1 keyboard mode is active (mode=3) — VT may consume input
Mar 26 02:32:49 KONPEKO vuinputd[1284258]: Create /dev/input
Mar 26 02:32:49 KONPEKO vuinputd[1284258]: thread 'main' (1284258) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:32:49 KONPEKO vuinputd[1284258]: Error handling action: Value too large for defined data type (os error 75)
Mar 26 02:32:49 KONPEKO vuinputd[1284258]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:32:50 KONPEKO vuinputd[1284264]: thread 'main' (1284264) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:32:50 KONPEKO vuinputd[1284264]: Error handling action: Value too large for defined data type (os error 75)
Mar 26 02:32:50 KONPEKO vuinputd[1284264]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:32:50 KONPEKO vuinputd[1284266]: Create /dev/input
Mar 26 02:32:50 KONPEKO vuinputd[1284266]: thread 'main' (1284266) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:32:50 KONPEKO vuinputd[1284266]: Error handling action: Value too large for defined data type (os error 75)
Mar 26 02:32:50 KONPEKO vuinputd[1284266]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:32:50 KONPEKO vuinputd[1284281]: thread 'main' (1284281) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:32:50 KONPEKO vuinputd[1284281]: Error handling action: Value too large for defined data type (os error 75)
Mar 26 02:32:50 KONPEKO vuinputd[1284281]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:32:55 KONPEKO vuinputd[1284309]: thread 'main' (1284309) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:32:55 KONPEKO vuinputd[1284309]: Error handling action: No such file or directory (os error 2)
Mar 26 02:32:55 KONPEKO vuinputd[1284309]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:32:55 KONPEKO vuinputd[1284308]: thread 'main' (1284308) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:32:55 KONPEKO vuinputd[1284308]: Error handling action: Device does not exist
Mar 26 02:32:55 KONPEKO vuinputd[1284308]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:32:55 KONPEKO vuinputd[1284312]: thread 'main' (1284312) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:32:55 KONPEKO vuinputd[1284312]: Error handling action: Device does not exist
Mar 26 02:32:55 KONPEKO vuinputd[1284312]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:32:55 KONPEKO vuinputd[1284313]: thread 'main' (1284313) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:32:55 KONPEKO vuinputd[1284313]: Error handling action: No such file or directory (os error 2)
Mar 26 02:32:55 KONPEKO vuinputd[1284313]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:33:43 KONPEKO vuinputd[1284512]: Create /dev/input
Mar 26 02:33:43 KONPEKO vuinputd[1284512]: thread 'main' (1284512) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:33:43 KONPEKO vuinputd[1284512]: Error handling action: Value too large for defined data type (os error 75)
Mar 26 02:33:43 KONPEKO vuinputd[1284512]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:33:43 KONPEKO vuinputd[1284518]: thread 'main' (1284518) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:33:43 KONPEKO vuinputd[1284518]: Error handling action: Value too large for defined data type (os error 75)
Mar 26 02:33:43 KONPEKO vuinputd[1284518]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:33:44 KONPEKO vuinputd[1284520]: Create /dev/input
Mar 26 02:33:44 KONPEKO vuinputd[1284520]: thread 'main' (1284520) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:33:44 KONPEKO vuinputd[1284520]: Error handling action: Value too large for defined data type (os error 75)
Mar 26 02:33:44 KONPEKO vuinputd[1284520]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:33:44 KONPEKO vuinputd[1284535]: thread 'main' (1284535) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:33:44 KONPEKO vuinputd[1284535]: Error handling action: Value too large for defined data type (os error 75)
Mar 26 02:33:44 KONPEKO vuinputd[1284535]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Mar 26 02:33:53 KONPEKO vuinputd[1284641]: thread 'main' (1284641) panicked at vuinputd/src/actions/handle_action.rs:13:9:
Mar 26 02:33:53 KONPEKO vuinputd[1284641]: Error handling action: Device does not exist
Mar 26 02:33:53 KONPEKO vuinputd[1284641]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Note: I am not making use of steam to run the games. Only heroic launcher and games patched to run standalone that I know work on another machine under heroic, not in a container env.

Please advise if this is a limitation to the current supported containers.

[joleuger]

Hi, actually, I don't know. Can you run strace with vuinputd?

https://github.com/joleuger/vuinputd/blob/main/docs/DEBUG.md

Maybe the option "--placement on-host" might help you

https://github.com/joleuger/vuinputd/blob/main/docs/USAGE.md

Incus container really sound interesting. I'll give them a try!

[Danukeru]

Thanks for the consideration.

This is the cleanest log I could generate under strace.
https://gist.github.com/Danukeru/56213c88ec853186e0450e6b6f38ec39

It should be a trace of service startup, then starting the container, sunshine starts and creates devices, and I open a sunshine session and I have the desktop.

It is the default service file aside from adding strace.
udev rules were installed on the host as per BUILD.md
/dev/input is created with a tmpfs service by container on start, and the necessary files were already under /run/udev

This is the container config if it can be of any help

architecture: x86_64
config:
  image.architecture: amd64
  image.description: Ubuntu noble amd64 (20260306_07:42)
  image.os: Ubuntu
  image.release: noble
  image.requirements.cgroup: v2
  image.serial: "20260306_07:42"
  image.type: squashfs
  image.variant: default
  raw.idmap: |
    uid 0 0
    gid 996 995
  security.nesting: "true"
  security.privileged: "false"
  security.syscalls.intercept.bpf: "true"
  security.syscalls.intercept.mknod: "true"
  security.syscalls.intercept.mount.fuse: "true"
  security.syscalls.intercept.sched_setscheduler: "true"
  security.syscalls.intercept.setxattr: "true"
  volatile.base_image: 844cdf68d5f46fbef59e4926f00e34d41e76f2582f56720af7ffbae4f42d64ca
  volatile.cloud-init.instance-id: 3310fd03-debf-4fd6-9f20-69e3f131d516
  volatile.eth0.host_name: veth0a5e5b47
  volatile.eth0.hwaddr: 10:66:6a:36:d1:77
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":0,"Nsid":0,"Maprange":1},{"Isuid":true,"Isgid":false,"Hostid":1000001,"Nsid":1,"Maprange":999999999},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":995},{"Isuid":false,"Isgid":true,"Hostid":996,"Nsid":995,"Maprange":1},{"Isuid":false,"Isgid":true,"Hostid":1000996,"Nsid":996,"Maprange":999999004}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":0,"Nsid":0,"Maprange":1},{"Isuid":true,"Isgid":false,"Hostid":1000001,"Nsid":1,"Maprange":999999999},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":995},{"Isuid":false,"Isgid":true,"Hostid":996,"Nsid":995,"Maprange":1},{"Isuid":false,"Isgid":true,"Hostid":1000996,"Nsid":996,"Maprange":999999004}]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.last_state.ready: "false"
  volatile.uuid: aaa98625-6645-437a-9cb2-5b9155dbda4a
  volatile.uuid.generation: aaa98625-6645-437a-9cb2-5b9155dbda4a
devices:
  dev-uinput:
    mode: "666"
    path: /dev/uinput
    source: /dev/vuinput
    type: unix-char
  dir-SLAB02:
    path: /mnt/SLAB02
    shift: "true"
    source: /mnt/SLAB02
    type: disk
  root:
    path: /
    pool: ssd01
    type: disk
ephemeral: false
profiles:
- default
- gpu0
stateful: false
description: ""
created_at: 2026-03-23T07:53:00.476338832Z
name: studio00
status: Running
status_code: 103
last_used_at: 2026-03-27T00:32:40.559898766Z
location: none
type: container
project: SPELPLAN

I attempted --placement on-host and mapping the generated dir to /dev/input instead of the tmpfs, but no luck there either.

I managed to get the mentioned mouse and keyboard for earlier test by passing in the system with the following in the container config, however I can't pass in the virtual joypad from sunshine in this way before its creation.
I mention it for context

[joleuger]

Okay, I can reproduce it:

incus launch images:ubuntu/noble first

incus start first -v

incus config show first

incus config device add first vuinput unix-char path=/dev/uinput source=/dev/vuinput mode="666"

incus file push target/debug/test-scenarios first/root/test-scenarios

#incus console first
incus exec first -- bash

[joleuger]

Okay, I see. It actually fails here:

setns(4, CLONE_NEWNS) = 0   // You entered the container's mount namespace
...
openat(AT_FDCWD, "/run/udev/data/c13:68", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EOVERFLOW

[joleuger]

Sorry for the late reply.

Okay, it is pretty similar to #1 and #6

Reason is that I really need to implement this proposed change:
#6 (comment)

The effect will be that the created devices will all have the id 1 inside the container and not the id 1 of the host, which does not exist and therefore the request fails with EOVERFLOW.

I will try to fix it soon. Thanks for pointing out your setup with incus; I was not aware of the project and it really will make testing on different distributions a lot easier in the future.

[joleuger]

Ok, now I have actually implemented it and I get a

mknodat(AT_FDCWD, "/dev/input/event4", S_IFCHR|0666, makedev(0xd, 0x44)) = -1 EPERM (Operation not permitted)

I guess I will change my mknod strategy: for incus I must use the available cli-tool.

What was the problem with "I attempted --placement on-host and mapping the generated dir to /dev/input"? Have you created a tmpfs that has dev-permissions?

[Danukeru]

I had the setup done with a service that created the custom paths under /run/udev and then properly mapped the /dev/input path and /dev/uinput in to the container.
I saw the appearance of devices under /dev/input and sunshine did not complain about input creation but had no input on the desktop.
I also attempted to map in the /run/udev/control and data, but those seem to get overriden upon incus startup, and have not been able to look into if it's incus itself, or a systemd udev task.

[joleuger]

Hmmm, interesting. Having the devices in the container is a first good sign. Have you tried out libinput debug-events ( see section 7 in https://github.com/joleuger/vuinputd/blob/main/docs/USAGE.md )

Might be an issue with the netlink message or with a misconfiguration of the compositor as well. Please ensure that the /run/udev/control file exists before the compositor starts. But missing files in /run/udev/data might be the source of the problems. With my wayland compositor I had to set the following environment parameters:

WLR_BACKENDS=headless,libinput
WLR_LIBINPUT_NO_DEVICES=1
LIBSEAT_BACKEND=noop

What I am currently implementing is a native way for incus containers in vuinputd. I am also rewriting parts of the tool to facilitate the setup of the other container engines as well. If everything works fine, you can expect a release soon.

[joleuger]

The implementation now has a simple incus-mode

vuinputd --container-runtime incus --target-container container_name --device-owner container-dev-folder

The current state is that it is undocumented, there are no hints how to use it, it freezes when either --target-container or --device-owner is missing... BUT it should work

[Danukeru]

Current status as of commit 919b420

The following 2 images show these order of events with the new command running as a service host side. Tops being host, and the container being sandbox00

• Container start
• Sunshine start (same result with preview and stable versions)
• With moonlight connected

logs host side shows following post moonlight connection

The container's config shows the applied passthrough rules up to /dev/input/event6 and I see the correct permissions mapped.

Sadly the end result is that I don't have input working in sunshine, and sunshine logs show no errors wrt to device creation (since obviously the /dev/vinput is working in that respect)

Side note: I had tested the libinput debug-events in previous iterations and I saw mouse events coming through. Sunshine server log in debug still shows mouse and kb input coming through. No errors relating to device, libinput etc.

The environment is minimal cinnamon desktop with autologin on top of Xorg (I have not managed to get sway to have an accelerated instance that works with sunshine on wayland with the Tesla V100 on 580 driver)

[joleuger]

I think I have fixed the "Error: The device already exists" error. Now devices get deleted when unplugged with incus.

For the other error, the problem seems that the netlink message does not arrive despite being sent. I could reproduce it with udevadm monitor -p. Thus, libinput (and X11 and similar libinput-users) does not recognize that a device has been plugged in. The libinput cli has no problems, because it reads the /run/udev/data folder at startup and listens only afterwards on netlink.

Instead of sending the message via vuinputd, I could copy a tool into the container that is called via "incus exec" to emit the message.

Sorry for the inconvenience. I think we are close...

[joleuger]

I found another solution: I need to enter the user namespace as well

    let user = File::open(nspath.to_string() + "/user")?;
...

    unsafe {
        // enter namespaces
        libc::setns(user.as_raw_fd(), libc::CLONE_NEWUSER);
        libc::setresgid(0, 0, 0);
        libc::setresuid(0, 0, 0);

[joleuger]

Now it should work

I don't know how X11 makes session management, it might be necessary, that I "fake" a seat so the mouse gets recognized. But first lets try without.

[Danukeru]

I have some good news. :)
https://github.com/user-attachments/assets/cac5dc48-efd0-4f9b-b2b5-a84b3fa33925

Currently it properly allows mouse and kb input and removes and reattaches between moonlight disconnect then reconnect.
The gamepad devices seem to be suffering from the same error as before.
This does not impede mouse or kb function.

A minor thing is that the passthru devices staying in the container config, causes the container to fail restarting since they no longer exist on container start.
So a todo might be to also delete them from the config as they're removed from /dev/input, but I can manage with a cleanup script for now.

Also note on session, I'm using gdm3 for autologin so it works same as with loginctl etc.

[joleuger]

Glad to hear that and see working evidence :-)

Hmmm, gamepads are somehow special, because they don't only provide data, but you can also send them data (the rumble stuff). Maybe that is a reason that the disconnection does not work properly. Do you mind if I ask you to provide the cleanup script? I wonder if I should integrate something like that during the startup for incus especially (given a container-name, list all event devices and remove all). (But for now, I think I need a week break from vuinputd ;) )

This issue lead to a great improvement of vuinputd, now not only generic device injection is supported (which doesn't work all the time), but the injection can be made specific for each supported container engine. The downside is that a lot of cleanup work and testing is necessary, before I can make a release. Do you mind to provide me some update in a few weeks if you are facing issues or also if everything else works okay? That would enhance my trust in the upcoming release.

Anyway thanks for reporting the issue! My feeling is that for everyone reporting an issue there are ten others that face the same issue and just give up.