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. > > However, I do not see why some central daemon should be involved > > when an X server or framebuffer application or console driver or > > whatever wants to set up a mode on its VT; or if the system is > > suspended/resumed. > > 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. 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 :-) -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
