> From: Sottek, Matthew J [mailto:[EMAIL PROTECTED]] [...] > #1 A kernel API for mode setting, mmaping of the framebuffer and > video memory management.
Truely needed. Something like the Linux version of the VESA interface. I think the Linux framebuffer project took this thing as their basic idea. > #2 A kernel api for only the most basic drawing. i.e. Blit and > data copy. I personally dont think these specific tasks neccessarily need to be implemented into the kernel itself. In normal operation most of the rendering will be initiated from userland. So i rather see the need to move grafics adapter programming out of the kernel space. This will speedup anything because fewer kernel calls will be needed for just the same. Userland library level would fit here much better. For those that do need grafics at boot time the option of having some sort of initial ram disk should serve them much better. As i have read there will be further improvements to the concept of the initial ramdisk when kernel 2.5.x branch is launched. Okay, dri/drm is already making use of several kernel modules, but here rather thought about userland modules. So its just a question which kernel service (i.e. syslogging or oopses) is so important that it really needs direct access to routines that i.e. can blit a sequence of character bitmaps from main memory to framebuffer. Maybe it sounds odd, but i could imagine some sort of library that is "mirrored" between kernel and user land. (Compare: Atari TOS had only one sprintf coding for any protection ring in the whole system.) > #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) Again this souds to me much more like a userland library. Hmm, the Mach system (microkernel architecture) sounded to me pretty reasonable because of the strict concept of resource servers that do provide anything to anyone with sufficient access privileges. Such a server is just the keymaster to the resources - and that is the thing that i suppose to be the best way to evolve. So the backend of the X11 support of any device would be built with just a specification that describes the hardware and the resources that the sever should deliver. If the concept is reasonable, then things like the VT system should attach to this lock as well and register there with a callback that lets the VT component "shut down" usage of the textmode framebuffer in favorite of some memory based character buffer. (I think this sheme could even work for hotplugging.) Anybody that has ever tried to run X11 dualheaded or with multiple useser might have found out that its not really that pleasant as soon as third party components like the adapter(s)'s or the mainboard's BIOS do come into effect in special moments like mode switching. Maybe a single resource server might help to fixup such critical phases a bit better by providing an optional locking sheme between those multiple adapters if found to be critical. > 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. OpenGL is a good standard for a big bunch of targest but there was already the question if the "ever moving target" DirectX already has outdone this concept just because it has implemented several more or less important features of current boards. (Okay, only OpenGL does have extensions, but is that idea a good one?) There was the idea of "Fahrenheit" but i assume its dead before it ran. With the Video4Linux folks we are facing another halfways sane idea of bringing interesting stuff into the Linux world. And as a counterpart again there is the DirectX implementation. Of course i think its nice to have an API that anybody interested in is allowed to play with, but in the view of the application programmer, its much more important to have a reliable, simple and flexible interface that stays as it is. (GDI is such a thing, of course for the Windows world.) The current question is not that much to change the interfaces, simply merging them into a single API would be enough if this is at all seen to be required. But the supposed works here have to go on under the hood. Since the device is claimed and the application has ist handle, we just need ways to let an OpenGL context coexist with an X11 window and any sort of video that the device can do. I would base the whole system on memory management - if an application does open a specific interface that refers to the hardware, it can only operate on the hardware if it got the respective resources, either as shared access or exclusive (i.e. a pice of framebuffer memory). > 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. So i consider it lacks in the design of the Linux kernel and the X11/dri programmers cannot be blamed for finding ways to work around that lack at first. In the long term someone has to startup and find ways to solve this lack smoothly on the level that serves the purpose best. > 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. I dont care for this question now, at least as it concerns the proposed winner of this contest. If we can find an alternative approach that fits the needs much better plus throwing some other historic loads overboard, we then can give it a different name. At this point i have to state that i am not really that satisfied the way current XFree86/drm is searching for devices and matching those devices with device nodes. Not that it does not work in the end, but i am sure that there can be nicer and more generic ways of doing device management. If this will finally cancel the need for a single and big XF86Config file by splitting it up then this could be another advantage. Regards AlexS. PS: dont flame me about Outlook, i know how to manually line wrap. --- these are all just personal thoughts in a public discussion --- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
