Hi, On Sun, Aug 12, 2007 at 09:36:32PM -0700, Jesse Barnes wrote: > On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote:
> > I fail to understand why you want to put the manager in a daemon, > > instead of just letting the kernel do the management, like it does > > for all other hardware. Why is graphics hardware supposed to be > > different in this regard? > > Graphics hardware is somewhat different in this regard due to the > large userland component to the driver. The userland component, translating abstract requests into low-level hardware-specific commands, is is large; and this is fine. My point was that *management* -- which is *not* large -- belongs into the kernel. > > It just doesn't make sense to have console setup and console > > switching -- which, on a monolithic system, is part of the kernel -- > > depend on a userspace daemon. This would be almost as bad as the > > current situation, where a userspace daemon called "X server" is > > doing all the management... > > Well, I'm not sure it's quite as bad as you make out. The kernel must > still come up with *some* initial mode, though this may typically be > whatever the bootloader gave us at handoff time. Once the kernel has > started init, however, a userspace program (call it 'gfxmgr') can do > full output probing (i.e. monitor & mode detection, output->crtc > mapping, and initial mode picking) taking better advantage of the > hardware. The 'gfxmgr' program should be *much* smaller than the X > server, since it will be doing far less--just output probing and > access control, not full mode setting (the kernel will do this), > protocol management, and client scheduling. Well, obviously it's an improvement to move this functionality out of the big server; yet the fundamental problems remain the same. 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...) 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. 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.) Any scheme that tries to delegate this knowledge to some external daemon, is inherently complicated and fragile, and will end up with the very same problems we have today. -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
