RE: [Linux-fbdev-devel] API prototype doc

[Sottek, M. J <mat...@in...>]

>That's why for 2.5.x we wanted to disable VT switching for a VT
>that has its /dev/fb* opened by some application.

Geert,
  I agree that just disabling VT switching makes things very easy,
but you are eliminating behavior that I would say is very
required. It just isn't a good trade.
  Lots of people run an X server on one virtual terminal and 
leave the other terminals as consoles, or run two X servers at
different depths. You can't do this if you can't VT switch
while an application is running.
And what happens when an app locks up with the device open? Forget
VT switching.
And a fb based installer that needs kernel messages on another
terminal plus a console just in case.
And an embedded controller that runs a diagnostic app on a different
VT from the main display without shutting down the main display.

I can not see how this is a good idea.

>> I am unsure of how XFree handles this. Does the X server trap the
>> vt switch sequence, call leave_vt() then switch the vt?

>The X server indeed installs a VT switch handler, and releases
>access to the hardware and does the VT switch.

That's what I thought, but that doesn't work for our needs because
VT switch handlers are for trusted apps. The X server runs as root,
so do the old svgalib apps. The point is, that something with direct
hardware access needs to be trusted to leave the hardware in a known
safe state when leaving. That isn't what we have here. We are
eliminating the need for direct hardware access. We are virtualizing
the graphics device and providing safe interfaces for user applications
that are not trusted. If you want to trust user apps then just run
them as root and forget the kernel.

The best alternative I see at this time is to, on a VT switch, remove
any mappings that clients may have and install a zero page fault
handler that blocks applications that attempt to write until the
VT is switched back. This only impacts mmaped clients as the other
interfaces are easy to block. We could also have the client request
to be signaled so they can do something other than block, and are
notified on return so they can refresh... but the signal handling
has to be optional.

 -Matt