Re: radeon-pre-2

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> What about if you want to use fb when in text mode (Because you get 
> 200x75 on a 1600x1200 screen) AND run DRI because the rest of the time 
> you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7 
> back & forth between X & fb... (i.e. how I currently use it but with 
> unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely).

Thats actually the easy case. We don't care if it takes another 30th of
a second to flip console. The hard one Jon was trying to point out is
a dual head card. Head 0 has someone running bzflag, head 1 has someone
editing an open office document. You have one accelerator set for both
heads. At that point you do care about the switch over, but the drivers
can co-operate for it. So it would always work, but it would work better
with friendly drivers when there is a need to do so.

> Currently this fails to work... Presumably because the fb & DRI code 
> (fglrx here BTW) don't talk to each other & so the display gets garbled 
> if you're lucky... Lockup if you're not.

fglrx stomps blindly on everything including your AGP. Not much we can
do about it.

> although Alan's probably works for DRI & fb on separate heads, how does 
> it guarantee that the chipset is all setup the same way for each process 
> on different heads... (When they have to share some of the hardware). Or 
> is that necessary?

You assume someone else crapped on the hardware. That is how DRI works
for example. You have multiple rendering clients each of which when it
takes the lock finds out if it was the last user (thats one thing Linus
sketch lacked but is easy to add).

My code ends up looking like

	lock
	if(someone_else_used_it)
		restore_my_state()
	blah 
	unlock