You still don't understand and did not answer some questions.
(like how did you want to connect several keyboards and mice to this host)

Again, switching between consoles works with and/or without X. Works also if you started more than one X server (on different consoles). X is responsible to set video for itself, but is not responsible for anything outside the running session. X must not and cannot handle the switching to another console/X or whatever.

The root inside the container is not really equivalent to the root of the host itself. Running X inside a container means you create a lot of security holes on the container to allow to do things which are not meant to do in a container.

That means you need to modify the login process to start the login shell in a docker (or another container). It is not really impossible, but still I have no idea how do you imagine it. How will be the mouse/keyboard connected?

container does not try to access anything. Containerization means the encapsulation of the environment, so when you are inside you cannot see (cannot have any idea about what is) outside. When you want to allow the app inside to use the real hardware you will just go against this encapsulation, you will need to create security holes (usually open ports) to access devices. As you see accessing the same hardware (video/audio) can be a problem, and also connecting mouse/keyboard to the containerized X can be an issue.

there won't be several keyboards and mice. just one keyboard and one mouse. it is the built-in keyboard on the laptop. the mouse is a wireless with a receiver plugged into a USB 2.0 port.

since X (probably) has the video hardware in a mode the text console cannot handle, the kernel signals X to set the mode back before the kernel completes the switch.

that's why running X in a container is an issue. inside the container is supposed to look like an isolated system. root in the container is supposed to be able to do privileged things but not affect the host or other containers. this is more difficult with X since X does need to deal with "other" consoles (see above).

this is to be decided as part of the design. i can say i won't be using docker. i may use lxc. i may just have a process that does the syscalls to build and move itself into a container.

yes, these (and more) are the issues. so i am thinking that needs to stay outside the container. X is supposed to be safe from its user exploiting its root privileges. but if X can let the user even do user things in some way, its not safe for X to be outside a container intended to (better) isolate a user in a container.

In that case how do you want to use more than one X in the same time?

No, I would rather say when you switch the console the new one will set the required config for itself (There can be a running X on the other console as well).
I don't really know if the old console should do something like "reset to default" or is there any way to "set the mode back - to what?".

No, forget it! X must not deal with other consoles, X must have no any idea if there were any other consoles available [how many, where are they] and how are they actually set. X is just an app as any other one.

Is this feasible?

i already use multiple X servers with one keyboard and one mouse. i just use one at a time. i have keyboard shortcuts that do "dm-tool switch-to-user <username>" fo about 20 user names. these users are "nopasswdlogin" group so LightDM switches without prompting me for a password. that lets me switch around quite frequently.

when i switch away, that X server understands that it is disconnected from all user interface and operates accordingly. all of them are in the same mode (1920x1080). i did some experiments with 3840x2160 which worked even though i was limited to seeing only 1920x1080 of it at one time. i had only one X server in that mode and switching to/from it worked fine.


X (not in containers) appears to be doing things different depending on how the console switching takes place, like whether the other virtual console is run by another X server or not or is just not active. in a container, that view will be different.


i don't see why not. something will need to create the container when a user logs in initially. whether X will be in the container or not, all the user processes will be (the goal of all this). LightDM doesn't do this (yet). so i need to create something that gets run first (perhaps by LightDM) and starts things up the way that is needed.

right now i have a user i switched away from playing a live radio stream on YouTube (https://www.youtube.com/watch?v=60UGcXAW0qM) while i am editing this. i have to run pulseaudio in system mode to hear it.