lkml.org 
[lkml]   [2006]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: OpenGL-based framebuffer concepts
Date
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-06-01 21:57    [W:0.346 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site