In previous discussions I never said OpenGL in the kernel, I only said DRM in the kernel. Item four was a very brief recap that left out a lot of detail. The kernel console uses a direct entry point into the DRM driver. This direct entry point has enough state to display no matter what is happening in user space. That is why I separated user console from kernel console. I am definitely against 2MB OpenGL device drivers.
However, I am saying that we need a blend between framebuffer and DRM. Not DRM bolted on top of framebuffer. For example the kernel console entry point may be implemented quite differently for different hardware. One implementation might just store the strings and compute the display on SysReq. Another might immediately put the strings into a background framebuffer and display it on SysReq. Another might encode them as a queue of hardware commands and execute the queue on the main framebuffer. Virtual terminals may be implemented differently too. Why can't each virtual terminal have a screen buffer allocated in VRAM? Then on VT switch the video base pointer is simply moved around. Now run xserver with compositing. Since you have all of the VTs in video RAM they can be composited along with all of the other X windows. Linux's current design has lots of holes in it. Start two X servers on two different VTs (not just two sessions to the same X server) you're going to reboot your machine. Modprobe in the framebuffer driver for your video card from an xterm window, you're going to reboot to fix it. These are examples of mutlple systems trying to control the video hardware in an uncontrolled way. The only reason anything works today is because there are some gentleman's agreements between various systems not to stomp on each other. In order to achive safety on graphics hardware you have to reach one of these four conclusions: 1) There should be a single device drivers controlling access to the video hardware 2) There should a single device driver presenting virtual hardware. Other apps/devices can then use this virtual device however they see fit. 3) Every app and device driver has to completely cooperate with each other and never take an action that will interfere with another's user of the video hardware. 4) Each VT session can do what it wants to the video hardware. At VT swap the entire state of all registers, VRAM, AGP memory, outstanding DMA, interrupt handlers, etc is saved and the state of the next VT is loaded. Right now Linux is taking choice number three. ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
