David Bronaugh writes:I was talking about the userspace code -only- doing mode setting. It would take the parameters passed to it via a FIFO or whatever, in whatever format, and set that mode on the specified device. Nothing more.
> 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.
It wouldn't have state (if at all possible).
One thing I'm not at all sure about is how to have bidirectional communication between kernel and userspace. The idea I had was for the userspace mode-setting program to open a block device-file (like /dev/drmctl0 (just making up names here)) and wait for input in the form of a string (there's no reason to go with the formats I've suggested here; they're just for the sake of argument). On receipt of that input, it would either set the requested mode and tell the kernel exactly what mode it set, or not set the requested mode and tell the kernel it didn't set the mode (both via the same device-file; maybe an ioctl?).
> 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.The userspace mode-setting program (what I'm talking about here), which would be doing any more tricky mode setting, would have -no- hooks into the kernel. None. Thus, even if it were GPL, it wouldn't be a problem for it to be running on a *BSD.
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).Or the requirements of the hardware, or the decisions of the driver creator -- whichever.
You mean code that could be put either into the kernel or live in userland
- depending on the requirements of the underlying OS?
Of course, the kernel portion would potentially still have license problems... it's not a total solution to that. But -- it does get as much code as you want into userspace, without enforcing policies.
> You could simply pass something like this (using an arbitrary text > format) to userspace:Right... what this says to me is that there have to be more possible parameters in this string.
> > 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.
For instance, maybe something like:
- radeon;pci:0000:01:10.1;[EMAIL PROTECTED];linear for a linear framebuffer with a refresh rate of 75hz at 1024x768 on the Radeon at pci:0000:01:10.1
- radeon;pci:0000:01:10.0;TV for TV-mode on the first function of the same Radeon
- i830;pci:0000:01:10.0;1152x864;tiled4k for 4kb tiles on an i830 (total guesswork; but iirc that's what i8xx uses)
Just ideas. Feedback entirely welcome :)
David Bronaugh
-------------------------------------------------------
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
