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.). > 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. > As I pointed out in my FOSDEM talk, the kernel does *not* strictly need > to know how to determine what modes are available, or how to set up a > mode with desired properties -- this can be handled by the client. > However, the kernel *does* need to know enough about the hardware, to be > able to safely switch between arbitrary client-supplied modes. (Or back > to a default mode, if a client dies.) Yep, no disagreement here. Generally the kernel can grab the currently programmed mode at boot time, and assume its fairly safe should something catastrophic happen. 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
