> Ok, I understand if that is the current goal, but I think the Right > Thing should (1) behave in a sane way if the X server is kill -9:ed > (i.e. cleanup bound to a no-senders notification somewhere), and (2) > support arbitrary frame buffer applications in a simple and robust > way.
I think X can be considered an arbitrary frame buffer application, and there should just be a single simple and robust way to make sure this is right. For friendly switches, the VT synchronization interfaces designed for X suffice. Forcible switches are always a last resort that may permanently screw the state of the program that you switched away from. Doing that on the last close of a VT seems fine. > I.e. the responsibility for sane gfx state should be in some > privileged process. A non-privileged user should not be able to shoot > it down (but he should still be able to kill his own X server, and > certainly his fb applications, and perhaps even his own console). A more complex idea that just occurred to me to truly improve robustness would be to enforce io access only for the properly switched-to vt. That would be a reason to have a hairier io port access interface. It would be ideal if a Hurd interface through the particular vt gave you an individual port that you could pass to the kernel to enable io access. Then a master control interface would dynamically disable the access imputed by a particular port, so that in vt switching the console server made only the port gotten from the active vt able to do video io. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
