On Mon, Sep 15, 2008 at 01:15:37PM -0400, Adam Jackson wrote:
- command to say "activate this VT or die trying". I'm
not sure how to
have this without breaking the idea of "process mode" altogether.
Not trivial. Currently activation is an asynchronous request and anybody
else involved in the process (eg another X server) can get in the way. A
VT_ACTIVATE is treated very much as a request and one other tasks also wanting
the VT, as well as the user, can override.
Where switching is currently allowed it looks possible to do a 'VT switch,
activate and return' deferring any parallel requests and user console triggers
until the activation is done.
- file descriptor that selects readable when a vt change happens,
ConsoleKit and friends.
That one ought to be quite easy to add on, we have a wait queue for it, we
have the current state we just don't have a device to hang it off.
We also (need, want) a kernel concept of a seat that binds together
displays and input devices. Right now, multiseat requires that you
Not sure I understand how the kernel can help here when in some cases
X is using libusb and network connected devices as inputs or displays.
abandon vt switching as a feature; if you're not careful about
setup right now, c-a-f1 on one person's seat will stop X on the other
seats. It's fine if "seat zero" is the legacy seat and some system
policy service handles setting up /dev/seat1/vt*.
Right so what you actually need is a way to tie together not seats but
vt groups of some sort into displays ?
Then we need some way of very early in life switching to the new
model and never letting go.
Ideally we can have one sane model that works from the beginning providing
we can understand what is needed (eg starting with all vts belonging to
'display 0' until reassigned and old ioctls applying to display 0 ).