David Bronaugh writes:My only argument for having any of the mode setting kernel-side, really, was for bootstrap/initial mode setting. Other than that, I don't care.
> Egbert Eich wrote:
> >
> >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.
> > > >
> 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.
> > 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?).
That is pretty much like power management is handled today.
A user daemon sits there and waits for events. It will act accordingly and return a status to the kernel.
But why do you want to do mode setting from inside the kernel
anyhow? If we can make the kernel do its output on whatever video
mode it gets we should be fine. This way the user app sets the
video mode and the kernel can still print emergency messages
(well, in theory - as writing to the fb will definitely collide with
active accellerator hardware).
And the initial mode setting for boot messages needs to happen way earlier - possibly in a bootstrap manager.If this proposal were to follow your idea, and encompass all mode setting code, then the only code needed -should- be trivial. In fact (interesting idea) there's no reason a userspace application couldn't feed a mode change request to the daemon via a FIFO, and the mode setter merely inform the kernel (sounds a bit more sane, even).
> > > > 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.
> > > >
> 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.
> > > > 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?
> > > >
> Or the requirements of the hardware, or the decisions of the driver > creator -- whichever.
> > 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.
>
Right.
That would almost totally decouple mode setting from the kernel -- which, by the sounds of it, would be a good thing. If an OS wants to do things differently, it shouldn't be a big deal.
> >Absolutely.
> >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.
> > > >
> Right... what this says to me is that there have to be more possible > parameters in this string.
>
And some may even be driver dependent.
Anyhow... to recap the ideas thus far:
- Userspace application (mode setter) which holds all mode setting code which waits on a FIFO for input
- Informs kernel of mode changes via ioctl
- Small userspace library to format mode requests to be sent to the mode setter via FIFO
- Kernel video device manager (for lack of a better term) handles ioctl informing kernel of mode changes
Does this sound good? Also, should I be forwarding this onto other lists, etc?
David Bronaugh
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
