Re: [Dri-devel] Memory management of AGP and VRAM

[Egbert E. <ei...@pd...>]

David Bronaugh writes:
 > Egbert Eich wrote:
 > 
 > >I don't only want to see mode selection in user land but also mode
 > >programming.
 > >I keep reiterating the reasons:
 > >
 > >1. Mode programming for a number of chips needs to be done thru the BIOS.
 > >   Unless one wants to stick a complete x86 emulator into the kernel
 > >   this needs to be done from user land.
 > >2. HW programming (especially programming around hw quirks) is a hard job,
 > >   and you need the hardware - if possible every flavor if it.
 > >   No need to duplicate this for different OSes - not speaking of the support
 > >   nightmare that is involved.
 > >  
 > >
 > I don't know if someone else has suggested this (if so, I apologize for 
 > stealing your idea, random person), but is there any reason you can't 
 > have the more complicated mode programming code (the non-bootstrap 
 > variety) as a userspace program which the kernel somehow "calls" 
 > (however it ends up; via FIFO communication, whatever; I'm not a kernel 
 > guru), and which does all the mode setting work?

I don't think you want to call user mode code from inside the kernel.
The kernel could take a passive role and use the mode that a userland
program tells it is set. If all the kernel needs is a linear freambuffer
of size x * y and depth d there is no problem. 
Things get a little more complicated if the kernel wants to set the fb 
start address for scrolling, use acceleration for faster drawing or the 
framebuffer is not really fully linear.

 > 
 > As I see it, this'd basically get around all the license problems with 
 > the mode setting code (it could still be GPL, yet since it isn't in a 
 > position to taint, that's OK) and it would result in -one- location, 
 > guaranteed, for mode setting code. I don't know whether the one location 
 > thing'd be a good idea, but it sounds like one to me.

Here my point is that the world is not Linux only (although I use Linux
myself) and it would make sense to make this code portable across OSes.
In this case GPL may be a problem - especially if the code needs to
go into the kernel.

 > 
 > It'd ensure that the mode setting code was -entirely- separate from the 
 > X server, any other libraries, etc. It'd also allow the driver writer, 
 > at their discretion, to put the code in the kernel (in which case the 
 > userspace code would never be used) or in userspace (in which case the 
 > kernel would simply request that the userspace code do its bidding).

You mean code that could be put either into the kernel or live in userland
- depending on the requirements of the underlying OS?

 > 
 > You could simply pass something like this (using an arbitrary text 
 > format) to userspace:
 > 
 > radeon:1024x768
 > 
 > and have it set the best-match mode. The 'radeon' part, of course, would 
 > make sure that the wrong code wasn't used. Likewise, the  userspace 
 > program could be fed any data it needed this way.
 > 

Right, however there are people who like to have a more fine grained 
control over things than just accepting what the driver considers the 
best-match.

Cheers,
	Egbert.