On Mon, 22 Oct 2001, Peter Surda wrote: > On Mon, Oct 22, 2001 at 05:48:56AM +0100, MichaelM wrote: > > Would you consider it a good idea to make DRI part of the source of a > > kernel? Direct 3d graphics supported from the boot sequence. > Hmm I thought DRI is part of the kernel? Perhaps you meant the DRM part of it. > > > I'm really concerned about your answer. There was a whole thread on > > the linux-kernel mailing list about the hypothesis of the release of > > an X-Kernel, a kernel which would include built-in desktop support. > I think it is a great idea to have a kernel implementation of Xserver. But it > would have to be more modular than current XF86, and also have a highly > flexible structure, so that adding new types of devices and functionality > wouldn't pose problems. I think this is currently the biggest XF86's drawback.
XFree86 can run on top of the framebuffer (fdbev I think, but maybe vesafb or something else - I haven't been keeping up). Last time I looked there was a specific accelerated framebuffer interface for MGA cards, so there may be a problem making the interface sufficiently general for acceleration on all cards. Provided that this can be done, it seems to me that fbdev + DRI could be the basis for a kernel level graphics driver, with a user level X server on top. I believe I read that SGI Irix works like this (or did once), and I believe it is also the model that GGI is aiming for. However, moving all the hardware drivers from the Xserver to the kernel will be a big job (it took 3-4 years to move them all from XFree86 3.3 to 4.x). Even if this kernel graphics system works on Linux and the *BDS OSes, XFree86 runs on another dozen unixes, not to mention OS/2 and Win32, and possibly other non-unix platforms. I think that most active developers would find that they had to concentrate on either this kernel based graphics, or the platform neutral user level XFree86. Dividing development like this would be bad for both projects. > Oh and one more thing: the driver should autodetect if it is running on > the same videocard as the virtual terminal stuff, so that the first card > will simply open a new VT but secondary card will run independently of > this VT stuff. This would finally allow a decent way to concurrently run > 2 separate X sessions on the same machine using local hardware. I'm convinced that the solution to that is for the kernel VT support to support multiple sessions. Then the user-level X server can just take over a single VT session (possibly via fbdev). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
