On Sunday, September 2, 2007 6:21 pm [EMAIL PROTECTED] wrote: > Hi, > > On Fri, Aug 24, 2007 at 08:31:10AM -0700, Jesse Barnes wrote: > > On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote: > > > I am *not* opposed to a scheme where userspace has to provide > > > information how to set up a desired mode. (Although I'm not > > > conviced it's really necessary -- both Keith Packard and Dave > > > Airlie argued that mode setting is simple enough to be done in > > > the kernel completely...) > > > > I'm not sure what you mean here--the kernel does fully set the mode > > in this scheme, all userspace does is provide the mode info > > (timings, etc.). > > Well, some people argue that even the timings etc. could be > calculated directly in the kernel -- unless I totally misunderstood > their remarks. > > Anyways, my point was that I'm fine with both variants.
Yeah, that could be done either way; in fact the kernel already has some timing formulas builtin. We could add a GTF version if needed. > > At a minimum, there must be a program to determine which outputs > > have monitors attached, and what modes are available on those > > monitors. It's possible this could be hardcoded in simple or > > embedded cases, but for a dynamic system it should probably be done > > in userspace, since EDID overrides will be fairly common, and > > various platform specific quirks will probably be necessary. > > I'm pretty sure detecting the outputs is something that can be done > in the kernel without problems. And it *should* be done there, so the > kernel can actually manage the available hardware. Yeah, I think output enumeration should be done in the kernel. But figuring out what's attached to a given output and what it supports is a little more burdensome (e.g. EDID as you mention below): not only are there a huge number of devices and combinations (think of just monitors and KVMs as an example) but myriad broken or simple devices that provide incorrect information or no information at all. > 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. Jesse ------------------------------------------------------------------------- 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
