[GH-ISSUE #11 ] Incus container support #11

Author

Owner

@joleuger commented on GitHub (Apr 8, 2026):

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 commented on GitHub (Apr 8, 2026): 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 ```

bsakaguchi commented

Author

Owner

@joleuger commented on GitHub (Apr 8, 2026):

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:
https://github.com/joleuger/vuinputd/issues/6#issuecomment-3925407112

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 commented on GitHub (Apr 8, 2026): 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: https://github.com/joleuger/vuinputd/issues/6#issuecomment-3925407112 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.

bsakaguchi commented

Author

Owner

@joleuger commented on GitHub (Apr 9, 2026):

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?

@joleuger commented on GitHub (Apr 9, 2026): 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?

bsakaguchi commented

Author

Owner

@Danukeru commented on GitHub (Apr 13, 2026):

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.

@Danukeru commented on GitHub (Apr 13, 2026): 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.

bsakaguchi commented

Author

Owner

@joleuger commented on GitHub (Apr 13, 2026):

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 commented on GitHub (Apr 13, 2026): 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](https://github.com/joleuger/containerized-headless-sunshine-howto/blob/main/README.md) 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.

bsakaguchi commented

Author

Owner

@joleuger commented on GitHub (Apr 14, 2026):

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

@joleuger commented on GitHub (Apr 14, 2026): 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

bsakaguchi commented

Author

Owner

@Danukeru commented on GitHub (Apr 16, 2026):

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)

@Danukeru commented on GitHub (Apr 16, 2026): 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 <img width="1354" height="203" alt="Image" src="https://github.com/user-attachments/assets/69a411d8-eecb-404a-8a4d-939f2ad8dce7" /> <img width="1354" height="203" alt="Image" src="https://github.com/user-attachments/assets/d4db26ab-364d-423a-aeca-69974e0c608a" /> logs host side shows following post moonlight connection <img width="1009" height="249" alt="Image" src="https://github.com/user-attachments/assets/a738a152-9ce5-4b19-a752-9f90895cfe85" /> 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)

bsakaguchi commented

Author

Owner

@joleuger commented on GitHub (Apr 16, 2026):

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 commented on GitHub (Apr 16, 2026): 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...

bsakaguchi commented

Author

Owner

@joleuger commented on GitHub (Apr 16, 2026):

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 commented on GitHub (Apr 16, 2026): 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); ```

bsakaguchi commented

Author

Owner

@joleuger commented on GitHub (Apr 16, 2026):

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.

@joleuger commented on GitHub (Apr 16, 2026): 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.

bsakaguchi commented

Author

Owner

@Danukeru commented on GitHub (Apr 16, 2026):

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.

@Danukeru commented on GitHub (Apr 16, 2026): 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. <img width="1033" height="325" alt="Image" src="https://github.com/user-attachments/assets/df62e24d-fbd7-488e-ab7a-edc6ee804df8" /> 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.

bsakaguchi commented

Author

Owner

@joleuger commented on GitHub (Apr 17, 2026):

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.

@joleuger commented on GitHub (Apr 17, 2026): 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.

bsakaguchi commented