Re: [Dri-devel] Three concepts for changing the way video works in Linux

[Alan C. <al...@lx...>]

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.