On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote: > Hi, > > On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: > > There should be master (possibly one for each card) which be the only > > one being able to do this call: > > DRM_IOCTL_MODE_SETCRTC - set CRTC parameters > > [...] > > > master (big boss) > > - X server (got its framebuffer) > > - X application > > - sub GL window of this application (might want to have its > > framebuffer) > > - GL application (dri) client running X application (got its > > framebuffer which > > can used as a texture by the compositor, hello redirected direct > > rendering :)) > > - EGL program (got its framebuffer) > > - Console (got its framebuffer) > > - GL app offscreen rendering (no framebuffer for scanout) > > 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. > 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. Of course, most of this has yet to be prototyped, though most of the code is already written (in some cases several times over), lying around in various projects... 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
