On Sul, 2004-03-14 at 20:00, Jon Smirl wrote: > However, I am saying that we need a blend between framebuffer and DRM. Not DRM > bolted on top of framebuffer.
You keep imposing policy in the mid layer. How do you know whether you need a blend or not - its card specific. Some cards have 2D/3D seperate, others have them closely intertwined so that the fb acceleration for text does want to use the DRM layer. > 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. Thats hardware specific. The voodoo for example can't do this, the frame buffer layout is hardware fixed. A large number of very low end PDA like graphics controllers are similar. There is one frame buffer image, it starts at the beginning and you can't alter it. > 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. File a bug. It works for me I do it all the time, and it should work for you. > Modprobe in the framebuffer driver for your video card from > an xterm window, you're going to reboot to fix it. Root is allowed to do stupid things, news at 11. > 1) There should be a single device drivers controlling access to the video > hardware You need this to handle hot plug as well. I don't think anyone disagrees > 2) There should a single device driver presenting virtual hardware. Other > apps/devices can then use this virtual device however they see fit. Why ? > 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. Thats a matter for locking. > 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. That is an argument for #1, and maybe an argument that the device driver has some responsibility for context management. ------------------------------------------------------- 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
