[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bug#185450: Xfree86 and console server (and VT_ACTIVATE, etc)

From: Robert Millan
Subject: Bug#185450: Xfree86 and console server (and VT_ACTIVATE, etc)
Date: Fri, 18 Jul 2003 14:58:06 +0000
User-agent: Mutt/1.5.4i

[ I'm changing CC to 185450@bugs.debian.org, 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]