On Mon, 2008-09-15 at 11:56 -0400, Alan Cox wrote: > Now as the API - it has interesting design features that go back ten years to > a different model of usage. Right now that code is all getting revamped, fine > grain locked and tidied so now is a very good time for the distro folks to > produce and send out a "What we hate about the console and how we think it > could be addressed" email... You fundamentally can not do VT switch reliably with the current VT_ACTIVATE / VT_WAITACTIVE pair. If someone sneaks in with an ACTIVATE between your two ioctls, you'll hang forever. You can't even fix all the userspace callers to do "something reliable" to work around it. I don't see how we can have a reliable vt subsystem while still claiming those ioctls work. But Linus isn't about to let us break them, so, sort of an impasse here. I think what we want is: - 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. - file descriptor that selects readable when a vt change happens, for ConsoleKit and friends. Initially I also thought we'd want a third feature here for "let me finalize switches", but I think this is unnecessary, userspace synchronization will work fine. We also (need, want) a kernel concept of a seat that binds together displays and input devices. Right now, multiseat requires that you abandon vt switching as a feature; if you're not careful about seat 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*. Then we need some way of very early in life switching to the new sane model and never letting go. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
