On Thu, 2005-06-16 at 22:01 -0400, Adam Jackson wrote: > On Thursday 16 June 2005 20:06, Jon Smirl wrote: > > On 6/16/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > In fact, the framebuffer support/mode setting doesn't have to be in the > > > kernel stricto-sensus. > > > > In the model I'm working with, things like mode setting always have to > > go through a kernel call gate to provide the user to root privilege > > escalation. Once you are in the driver, the driver is free to set the > > mode in the kernel or do something like call_userhelper() for a user > > space implementation. call_userhelper() runs the helper as root so it > > can get to the registers. > > I would strongly suggest that we use usermode helpers as much as possible > even > on linux, since we have the code already written in X and it'll increase the > similarity with other platforms. Write it once. Other platforms without an > fbdev layer will run the server as root and just fork the modesetter. > > This would be nice to do even for the classic server if possible.
I think the best would be to have the mode setting in a daemon. It use very simple kernel interface to mmap the various bits & pieces it needs, wether it uses fbdev or not is a matter of what "backend" plugin that daemon uses for a given platform/board. By doing so, the whole privilege issue than Jon is concerned about is gone. The daemon can run with appropriate permissions to access the HW and deal with rights on it's own. It's also easier then for that daemon to be the sole "listener" of various hotplug events concerning the HW, and then do the appropriate messaging (using dbus maybe ?) with various clients etc... It also provices a nice separate process context for the mode setting drivers separate from client applications (thus with a well known environment vs. signals etc...) A "backend" for this daemon could be to re-use existing X DDX's (at least the mode setting part of them) as a way to quickly get up & running though that wouldn't have full functionality of screen hotplug etc... I still think however that this should remain an implementation detail. Whatever mode setting API we ultimately come up with should be a library. If that library just wraps dbus-like messaging to a daemon, then good, but that may not be necessary. That way, we could even imagine a very slim implementation that layers directly on top of fbdev for small embedded devices with no hotplug capabilities or other variations... Ben. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
