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.
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
