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 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.
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.
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 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.
Anyhow, just an idea. No idea if it's a good one or not, really; but I'd love to hear feedback.
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
