Re: OpenGL-based framebuffer concepts

[Helge Hafting <helge.hafting@aitel.hist.no>]

Kyle Moffett wrote:
>
> The one really significant potential problem with the exo-kernel model 
> for graphics is that the kernel *must* have a stable way to display 
> kernel panics regardless of current video mode, framebuffer settings, 
> 3D rendering, etc.  The kernel driver should be able to provide some 
> fundamental operations for compositing text on top of the framebuffer 
> at the primary viewport regardless of whatever changes userspace makes 
> to the GPU configuration.  We don't have this now, but I see it as an 
> absolute requirement for any replacement graphics system.  This means 
> that the kernel driver should be able to understand and modify the 
> entire GPU state to the extent necessary for such a text console.
I am not so sure I want this at all.
In the early 90's, I used unix machines wich did exactly this - spamming the
framebuffer console with occational messages while X was running.
Yuck yuck yuck yuck yuck .  .  .

Now, a panic/oops message is sure better than a silent hang, but that's 
it, really.
Anything less than that should just go in a logfile where the admin can look
it up later.  The very ability to write on the console will alway be abused
by some application programmer or kernel driver module vendor. 

Blindly writing on the console won't be very useful either, the user might
be running a game or video which overwrites the message within 1/30s anyway.
Well, perhaps it can be done better than that, with some thought. I.e. :

* block all further access to /dev/fb0, processes will wait.
* Mark graphichs memory "not present" for any process that have it mapped,
   so as to pagefault anyone using it directly.  (read-only is not enough,
  processes should see the graphichs memory they expect, not
  the kernel message)
* Try to allocate memory for saving the screen image (assuming the
   machine won't hang completely, it will often keep running after an oops)
* Annoy the user by showing the message
* Provide some way of letting the user decide when to proceed, such
   as pressing a key
* Restore the saved screen memory (if that allocation was successful)
* Mark framebuffer memory present, releasing pagefaulted processes
* Unblock /dev/fb0

So, kernel messages can be done.  But if the plan just is to blindly
write messages to the framebuffer, then please drop it.  I really hate
stupid messages on top of my windows, especially when the X display
is _scrolled_ without invalidating the windows. :-(

Helge Hafting