2 ms·
First of all you have systemd-logind that tracks "sessions" (using a different definition to the one found inside the kernel, natch) and "seats", that then polk
by digi_owl 10y ago
First of all you have systemd-logind that tracks "sessions" (using a different definition to the one found inside the kernel, natch) and "seats", that then polkit talks to via dbus (yay...), and then the DE talks to polkit (again via dbus).
These then try to tie a video output, and at least one input device (mouse, keyboard, whatsnot) to a specific seat (as defined by systemd-logind) so that only associated (systemd-logind defined) sessions can interact with them.
Note that all this happens above the kernel, that (as best i can tell) do not have a concept of a seat, and sessions are tracked on a tty basis.
And ttys used to be physical devices connected to the computer via a serial connection (and still can be even on Linux, nice for getting those early kernel errors onto something that do not go poof the moment the GPU driver code do a belly flop).
Never mind that X was designed to work as a graphical tty of sorts. Thus rather than try to stuff raw bitmaps down the wire, the client code running on the computer would send draw command primitives (line from X,X to Y,Y, square with top left corner at A,A and bottom right at B,B, that sort of stuff) that the X server sitting on a desk somewhere would turn into a GUI.
I think Xscreensaver still use that for drawing the "screen lock" password prompt and launch popup.