Running Xorg inside a container

[dark-penguin]

I'm trying to figure out the secret behind running Xorg in a container. I managed to get it running, but now I'm stuck at the last step: unresponsive keyboard and mouse. I saw that you had the same problem in #7; did you have any luck with it?

I thought that's what --xorg option does, but from what I see it just runs another Xorg instance on the host, and connects the container to it. What I want is to avoid depending on the host's Xorg - for example, sometimes I want to try another version of Xorg. Ideally, I wanted to be able to run Wayland this way as well - not depending on anything on the host at all, except the kernel and the kernel graphics driver.

Or am I misunderstanding things, and --xorg actually runs the Xorg server in the container?

[dark-penguin]

Could it be possible to use #253 for keyboard and mouse passthrough?..

[dark-penguin]

I've found #221 . I wouldn't mind giving the container enough privileges to use my mouse and keyboard; I'm already giving it my whole graphics card to do acceleration, which is much more significant. The alternative is rebooting into those systems, giving them complete access to my whole system while not being able to use them at the same time.

But I really want acceleration, so Xpra is not going to help, and as far as I remember, Weston doesn't even work properly on Debian Buster (too old). The idea is to have the same experience as with running Xorg on the host, but use the container's Xorg version (for testing bugs in graphical applications, mostly).

[mviereck]

I'm trying to figure out the secret behind running Xorg in a container. I managed to get it running, but now I'm stuck at the last step: unresponsive keyboard and mouse. I saw that you had the same problem in #7; did you have any luck with it?

I remember that I had the problem and solved it. However, it#s a long time and I don't remember clearly what I did.
IIRC it was something about evdev and the Xorg evdev drivers. Maybe you just need to install libevdev2 and/or the Xorg evdev drivers in the image.

The idea is to have the same experience as with running Xorg on the host, but use the container's Xorg version (for testing bugs in graphical applications, mostly).

If it is only to test the xorg version, it will be easier to run Xorg with the dummy video driver in container and access it with xpra. But the dummy video driver does not provide hardware acceleration.

Ideally, I wanted to be able to run Wayland this way as well - not depending on anything on the host at all, except the kernel and the kernel graphics driver.

Running a nested/windowed Wayland in a container that shows up on Xorg on host is no problem. For testing purposes this should be enough. for example, this runs the KDE Wayland in container:

x11docker --gpu --init=systemd -- --cap-add SYS_RESOURCE -- x11docker/kde-plasma startplasmacompositor

[dark-penguin]

What I want is to have the same experience as with running Xorg on the host, but sometimes things don't work with the Xorg version in Debian Stable... the most recent example being the development build of Godot engine with Vulkan rendering backend. So unlike security, acceleration and video driver are not things I can sacrifice. :) I know I can always "do something else instead", but I want to try getting to the bottom of actually running Xorg (and what it would take).

Nested Wayland in X is not cool enough! :) Especially if I want to see if the new Plasma release is stable enough to run and has finally defeated tearing. And work in it. This approach only adds instability - on my system, it took a very long time to start, and then did not resize properly. (That's Plasma's fault, I guess - that's why I want to test it "close to bare metal".)

According to this:
https://stackoverflow.com/questions/33585482/keyboard-mouse-are-unresponsable-when-running-x-org-in-a-docker-container
https://stackoverflow.com/questions/50789172/libinput-in-a-docker-container
...the problem is that we have to force Xorg to use those devices, which is supposed to be managed by logind... isn't there an easier way nowadays?.. I've tried installing xserver-xorg-input-evdev, but that won't make Xorg pick up the devices. What's even worse, I'm using a USB KVM, so my keyboard and mouse are always hot-plug.

So you do remember that there is a solution, but it seemed too hacky and insecure to implement in x11docker, is that right?

[mviereck]

the problem is that we have to force Xorg to use those devices, which is supposed to be managed by logind... isn't there an easier way nowadays?.

Well, logind is the "nowadays" way, coming along with systemd.

Maybe you need an entry in xorg.conf.d/ in container. Compare the gentoo wiki: https://wiki.gentoo.org/wiki/Evdev

So you do remember that there is a solution, but it seemed too hacky and insecure to implement in x11docker, is that right?

I remember that in the final end I had a running Xorg with keyboard and mouse, but was not able to switch to other tty's.

I decided not to implement this in x11docker for two reasons:

• Xorg (and Wayland) heavily interact with the hardware. If they make false assumptions about the hardware because they see something wrong within the container, they might damage the hardware.
• Running a container with high privileges gains no security.

[jd666]

I think the requested use case here is almost more aligned to the snap packet management system. It would allow you to have multiple versions of the same package (Xorg) installed.

[mviereck]

@jd666 Thank you for your suggestion. I am not a fan of snap, but for this use case it might be the better choice, indeed.

[dark-penguin]

The idea is to have, say, the latest Ubuntu running "just like it's supposed to", like in a VM, to see how exactly is it supposed to run - without having to do things like check the Xorg version first, install it on the host in a snap package, which I'm also not a fan of...

Thank you for sharing your experience! So, after getting the devices to work, and not necessarily hotplug, there is at least one more challenge of being unable to switch VTs... I guess this is really far too complex for the benefit of "using the Xorg shipped in the container".

[mviereck]

Finally x11docker allows to run Xorg in a container.
Since x11docker version 7.1.5-beta-17 this is possible with options --xc --xorg if image x11docker/xserver is provided.
The most important missing key was to share /run/udev/data with the container to allow right hardware detection for Xorg. Other important parts are capability TTY_SYS_CONFIG and devices in /dev/input.
The setup is still experimental. I hope it will work on other machines and setups as well.

This is still not Xorg in the image you provide yourself; however, the technical issue itself is solved.