>> #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. The basic idea in the framebuffer is fine, but the implementation isn't very good. It is more grown out of console functions rather than starting from a graphics driver perspective. >> #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. I don't see how a user library alone would be useful. Having user libraries touching hardware is the _problem_ not the solution. You can not properly virtualize a device from userland, you can only virtualize it for people wanting to use your API. Note that all complex drawing tasks would be broken down into the format most useful for the hardware in userland by a library, but the device touching would happen at the kernel level. This is pretty much how the drm works now. I'm not suggesting putting any complex data manipulation in the kernel. Here are the functions I see in a graphics architecture and arguments for if they should be kernelized. #1 Device bootstrap: If anything useful is to be displayed this has to happen early in the boot process, well before userland. So that makes it kernel. Currently you use either a fb driver or VGA to do the same in kernel space, but then it all happens again in X. #2 Mode setting: Since you need at least one mode for booting you have to have this kernel side. Plus after booting there is no guarantee of any higher level API being in use so a simple kernel interface for mode changes is necessary. This currently happens in an fb driver or via VGA then is redone in X. #3 Resource allocation: Video Memory, AGP resources, Locks. Locks need kernel access. Video memory can not be mmaped without a root client or kernel access (This isn't always needed but direct draw facilities are lacking as is). Video Memory needs to be allocated to higher level libraries in some manner and unless they all agree on an algorithm you'll need a gatekeeper. Currently this is minimally done in a fb driver or VGA, then done in X with some resources given to the drm who then allocates those further. Applications must all agree on who owns what since there is no gatekeeper. #4 2d: This is a complicated problem. It should be solved in user land with only very low level drawing "commands" being sent to the kernel driver. The most basic of those commands could have a standard interface just so some low-overhead (maybe a console driver) programs could use them. Most of this would be hardware specific and only usable via a high level (Xlib or Mesa) library. Currently you have either an fb driver or VGA doing low level console drawing, then X takes over or possibly some other 2d API. #5 3d: Even harder, do it just like Mesa + drm does it now. Break the problem down to as close to the hardware as you can securely get and then send it to the kernel. This one pretty much is already done this way. Anyway, this is just one way of doing things, and a pipe-dream at that. Certainly someday everyone will have to step back an rework the whole design from console to 3d such that it is consistent secure and provides a strong foundation to expand. -Matt _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
