Messages in this thread | | | From | "D. Hazelton" <> | Subject | Re: OpenGL-based framebuffer concepts | Date | Thu, 1 Jun 2006 15:54:43 +0000 |
| |
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/
| |