Hi, [EMAIL PROTECTED] escreveu: > 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.
I hope you guys are not forgetting who wants to start two (or more) instances of the Xorg server (for multiseat purposes or what ever). In this case, the daemon - in kernel or not - would be useful to handle the routing of the VGA code to the right legacy cards. An external daemon is also needed to control the "resources" provided by the vga card in the case of multiseat (which would be overlapped in a multi-head environment if the Resource Access Control (RAC) never existed on Xorg). -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ------------------------------------------------------------------------- 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
