[ I'm changing CC to [EMAIL PROTECTED], so it gets archived too ] Hi Gael,
On Fri, Jul 18, 2003 at 11:41:10AM +0200, Gaël Le Mignot wrote: > Hello Robert! > > Just to remind you that it's not the console _server_ which conflicts > with X, but the console _client_ using vga or a keyboard driver. Your > mail wasn't clear at all about that. ouch.. well, whatever it's called, I was referring to the program that uses hardware resources :) > I don't think the correct solution would be for X and the console to > directly speak to each other like X saying to the console client "stop > please", but rather a per-ressource (VGA, keyboard, mouse) way to say > "I want exclusive access to this ressource". The console client itself > would just agree to give to the access to X, or something like that. Ah, ok. IIRC last time we discussed this I proposed something like having the userspace drivers as translators that either block a second process from accessing them, or queue the requests somehow. My idea was to implement the driver in userspace and force X to use it. Following this dessign, we could end up seeing X running as non-root. What we could do is writing the keyboard, vga etc translators, but don't implement the actual hardware I/O on them yet. Instead, just use them for resource management. > It would be nice too if we could "switch" at run-time from X to > console and vice-versa like we can do on GNU/Linux. That feature is (on monolithic kernels) VT_ACTIVATE. X tells the (monolithic) kernel to bring up the console with the ioctl VT_ACTIVATE on /dev/console or another arbitrary device. (see my patch to disable this feature for systems without VT_ACTIVATE in xfree86's debian/patches dir) Once we come up with our own interface, adding a replacement for VT_ACTIVATE shouldn't be too hard. -- Robert Millan _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
