>>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. Most people answered, no, this would be >>ridiculous, other said, yes, but hardware manufacturers are >>too unhelpful therefore this would be totally a totally unstable >>release. Others said.. other various things. >> >> So, what do you think?
Linux is badly in need of some sort of sane kernel graphics architecture, but certainly the answer is not a kernel version of X. In order to do a good driver model you need both a kernel api and a client api. The client api is implemented via a library that is flexible enough to handle differing kernel api's. (This is how libGL works) The client API, opengl, is the same for everyone. But, the kernel->library api can be hardware dependent. As Daryll said the kernel driver should provide the leanest possible interface to the hardware, the library should then smooth out the hardware differences into a common API. So putting the X api in the kernel isn't a good idea. Just as putting the opengl API in the kernel isn't a good idea. Daryll said as much here: >No, I don't think it is a good idea. Kernel's should provide >the minimum layer needed to securly and efficiently implement >solutions in user space. The DRI has a kernel component to >access the graphics hardware. The rest of OpenGL is in user >space. I do want to argue that the kernel has another, just as important, role as security. That is resource allocation. The video resource allocation is handled via the DRM with locking, but there is no kernel level resource allocation for video memory, modes etc. I really think that the concept of framebuffer (The concept, not the implementation) and the concept of the drm need to be combined such that we have the following: #1 A kernel API for mode setting, mmaping of the framebuffer and video memory management. #2 A kernel api for only the most basic drawing. i.e. Blit and data copy. #3 A framework do allow the implementation of the other hardware specific functions.. basically the drm. So that higher level interfaces can use them. (Mesa and X) Daryll wrote: >1) The kernel remains small. No wasted memory. Less security > problems. >2) You can layer different graphics systems on top of the same > kernel interface. (For example the Xv guys wanting to use it) >3) It easier to change, debug, etc. Allowing resource management (via a common api) and drawing (via a device specific api) makes all 3 of these things better than they are today. 1) The kernel remains small. Only a little added code since a lot of people have drm and framebuffer already. The added size is as small as possible. Security is much improved. Having a huge setuid root binary that accepts remote connections is not a good security model. XFree is pretty good about having tight security, but the model is broken from the beginning. 2) You can not layer anything on top of what we have today. You have to totally reimplement a 2d driver with complete mode setting, drawing and memory management. Only then can you play nice with the 3d interfaces in the drm. If hardware specific drawing api's were in the kernel then everyone could layer on top of them. X, Mesa, and any new graphics library. All without reimplementing the basics. 3) It is easier for everyone writing graphics applications if they don't have to debug drivers. Having drivers in 3 places already (framebuffer, drm, XFree) plus any other upcoming api's isn't helping. >There's essentially no advantage to having X or OpenGL in the >kernel. Do you really need 3D during boot? I'd say no. It can >wait until you mount a file system. If you want to get graphics >running earlier in the boot sequence, go right ahead and work >on that. Most of the replies have been addressing why putting X in the kernel is a bad idea without addressing the real (unstated) problem. Linux doesn't have a graphics architecture that handles the basic needs that should be provided by a kernel. As a result the basics get reimplemented in incompatible ways every time someone tries something new. In my opinion the drm should become _the_ interface for graphics on Linux (and other kernels). The kernel should use drm interfaces for console drawing, and user libraries should only access the device through the drm. -Matt _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
