i need to feed some keyboard input into the X based desktop as part of a broad setup script that is run after my laptop boots into Xubuntu 20.04 LTS. i have tried "xdotool" for this purpose but it is not suitable.

i am running with "LightDM" as the display manager with multiple userids set to not prompt for password at the desktop. the allows "LightDM" to rapidly switch between users. each user is run under a separate instance of "Xorg". only one instance of "Xorg" is connected to the display, keyboard, and mouse at a time. "Xorg" is programmed to deal with being connected and disconnect when it is signaled to do so. this signalling is done by the kernel when a console change key is pressed. alternatively "LightDM" can make these switches. i don't know the API involved, but i suspect "LightDM" uses a kernel interface to have the kernel do it.

this console switching appears to be the cause of the problems i am having with "xdotool". when i use "xdotool" to virtually type in a command, it fails to type in anything, unless the instance of "Xorg" it is running under is connected. so this feature involves more than just "xdotool" interfacing with a particular instance of "Xorg". it appears to not be a case of sending to the wrong instance of "Xorg" as i have no cases of displaced commands.

my needs include some virtual typing input (done by components of the setup script) to the desktop independently for each user at times that user is disconnected from the desktop. the only real way to do this is for a typed input tool to communicate with "Xorg" directly, at least when it is disconnected from the desktop.

an alternate typed input tool is what i am looking for to replace "xdotool". this will allow my setup script to complete much faster by allowing the user setup part to run in parallel while disconnected, instead of waiting for each user's setup to be carried out while connected to the display. the user setup parts vary by user but typically take around 30 seconds each. with 18 users involved this can be 9 minutes of time. time i want to shorten.

has anyone who understands this issue heard of, know of, or written an alternative tool that can work with "Xorg" even while it is in a disconnected state (it is still running in this state as many other X-related setups do work)?

How about this:
https://github.com/ReimuNotMoe/ydotool

I haven't used it.

if you want to run a setup script just connect it to a pipe or similar and you can send any command to it using that pipe and without Xorg.

i haven't used it, either. to test if it can send input to the selected instance of X or the X it is running in (how to detect this?) among many instances or X that are disconnected from the physical console. can the /dev/uinput system determine this? maybe an X server is suppose it "unhook" from whatever input it is using so another (or virtual console) can "hook" to it. i need to read up on /dev/uinput to see what it handles. the need for root can be worked around in my case.

some of the input goes to apps that have a window open on X. the setup involves how things are arranged in the GUI environment of most users.

suppose with 3 users, 2 are disconnected from the console and "admin" is connected (it has sudo powers). both of the disconnected users have their pointer inside a window. now feed up/down key actions to the 2nd user sending "foobar\r". can the 2nd user be identified? this is the kind of thing i am worried about.

i was hoping X had a secret port to listen for input. maybe this is what /dev/uinput does (it could register its identity). then there a security issues and maybe even denial of service issues in all of this.

i might have to run X via VNC and intercept that protocol to inject input. i would have to leave each X connected and have the interception fake the connect/disconnect activity.

X has its own console. (or terminal). X does not handle itself the keyboard events, but the console (where it is attached to) (You can see it for example with ps). Inside X you can create [almost] any number of pseudo terminals, which will connected to terminal emulators or apps running inside, but actually the events of the original console will be redirected to those ptys (depending on the focus). When you switch X, the server will not be detached from that terminal, just it will not be displayed any more (and also that terminal will not get any input, because those events will be sent to another one).
What I suggested is: use IPC (inter-process communication) (or something similar) which is the common way to send data between apps. For example you can use
to send text to that pseudo terminal. Obviously it does not work with mouse events. But in general you don't need to identify the user, but the process.
by the way xdotool needs the DISPLAY variable, so it can always send the event to the named X, if it is allowed (to access that display). It does not depend on the screen.