Re: OpenGL-based framebuffer concepts

["D. Hazelton" <dhazelton@enter.net>]

On Thursday 01 June 2006 11:51, Marko M wrote:
> Sure it is. I mean, it uses only VESA (extended VGA) registers and
> doesn't know anything about present bliters, backend scalers or
> similar hw features, AFAIK.
>
> I think DirectFB guy have right approach, only they do it from user
> space. fbdev should be capable of detecting present chip(s) and load
> appropriate (acceleration) module, which describes hardware more
> precisely.
>
> If there is no specific (fbdev) driver module for your gfx then
> everything should work with generic (VESA) one, though it would be
> somewhat slower.

(Ewww, top-posting!)

Anyway, this method is what drmcon is going to do. For fbdev the plan is to 
make it a very minimal driver under most circumstances, and capable of being 
told to shut down so that the drmcon that I am working on can take over.

Jon makes a good point about daemons being able to get killed by the OOM 
killer. However, because drmcon is going to provide the full DRI capacity to 
userspace, having tons of helpers that need to be launched for various tasks 
isn't a good choice. Sure X could retain it's own DRI system and not require 
the helpers or whatever, but what of an app written using Qt or GTK that runs 
on the console rather than under X?

Such an application would continuously be using the 2D acceleration features 
(which will all be merged into DRM) - having to start the helpers for every 
acceleration call would be stupid. By providing a daemon to do the work we 
simplify things immensely.

And in the case that the daemon is killed (for any reason) the console itself 
should survive, since it doesn't need the daemon to run. What will die is the 
application that depends on it... Yes, that isn't good, but it's better than 
the whole system coming down. And since the OOM killer does provide an error 
message that nominally hits the console, the user will know what occurred.

DRH