Hi, On Tue, Sep 04, 2007 at 10:52:41AM -0700, Jesse Barnes wrote: > On Sunday, September 2, 2007 6:21 pm [EMAIL PROTECTED] wrote:
> > As for EDID, I totally agree that this can be done in user space > > just fine. What I'm saying is that no central daemon is required for > > that. Handling this data should be totally uncritical -- it can be > > done by a library linked to the actual client processes. (X server, > > console etc.) Ideally, using a DRM backend to a generic library like > > libggi, which adds a lot of additional flexibility :-) > > Right, there's no reason most of this code can't be in a set of > libraries. Nor is there any reason to *require* the use of a gfx > daemon in many cases. It's just that for some of the cases we have in > mind (multiple users, each with multiple clients, possibly doing > direct rendering), a gfx daemon to arbitrate things may be a good > approach. Yeah, I guess some kind of daemon is necessary to manage access policy in more complex cases, like multiple physical users. However, the design should not *depend* on such a daemon. Also, I don't think this daemon really needs to do an awful lot: Basically, it only has to assign the available devices to the various users. Once the devices are assigned, there is no further need for any third party: Probing hardware capabilities, determining available modes, setting a desired mode -- this can all be done by the user process with the help of the kernel; there are no further policy decisions involved with that. Also, I don't think that assigning the devices requires any special mechanism. Seems to me that it boils down to setting ordinary file access permissions on the graphics device files. As for multiple clients: This is actually only interesting when having multiple clients *on one VT*, i.e. when using an X server, or maybe some other windowing environment. However, this manager only needs to manage the clients on *one* VT -- this doesn't require special privileges, and can be done by the X server itself. If there is another server on a different VT, it can do it's own management for that VT. Again, no need for a system-wide daemon. -antrik- ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
