Anyhow... to recap the ideas thus far:
I'm going to elaborate considerably at this point, probably dragging in lots of stuff no one wants to see in here, etc -- all to try and figure out what's wanted/needed. The following is about the mode setter itself.
One weird thought I had was that in the end, this "mode setting" system would probably have to handle monitor hotplug events. I don't know how useful this feature is, etc. I'm not sure exactly how this would work, or -if- it works, or if it belongs in this. But -- there are some interesting consequences of it:
- Monitors could be unplugged at any time, and swapped -- and things like refresh rates could be changed if needed (an interesting possibility). I'm not sure, but I -think- this might be good support infrastructure for various power management suspend options.
- This would allow for monitor swaps during operating system operation to be rather painless, which I can state for certain is not true on some other platforms *cough* Winders *cough*
Putting monitor parameter read code (DDC or whatever it ends up being) into this -does- make sense in my opinion (hotplug or none). Feedback on why this is a good/bad thing to do would be nice, since I really don't know.
Another weird idea I had involved Linux's hotplug system -- there are some interesting possibilities there. I'm not sure where it'd go though. But -- the end result of it is that there should be more than one way to get output out of this code when a mode change is requested, or other events happen (like monitors being plugged in). Possibly have a message bus to throw stuff like this onto (D-Bus anyone?).
This might be useful for a future X server, for example, to be able to change configuration on the fly as the hardware configuration changes.
Random question: How close a correspondence is there currently between userspace (X server) and kernelspace (fbdev) drivers?
- Userspace application (mode setter) which holds all mode setting code which waits on a FIFO for input
- Informs kernel of mode changes (and other things? what else?) via ioctl
- Informs other listening applications of mode changes, monitor connect events, etc. (D-Bus?)
- (What about hotplug video?)
- How should the kernel inform this of a video card addition? Is this meaningful/relevant?
- Should call ioctl to get list of available "Extended DRM" devices and associated drivers (don't want to duplicate code)
- It seems like there would be exact pairing between kernel-side "Extended DRM" devs and mode setting drivers
- This sounds to me like a very useful thing for the "Extended DRM" being proposed (could be used in X servers, maybe; see random question above)
- Small userspace library to format mode requests to be sent to the mode setter via FIFO
- Don't reinvent the wheel
- Format of messages might be something like device identifier, resx, resy, colour depth, refresh (optional), extra_params (optional)
- Kernel "Extended DRM" driver (for lack of a better term) handles ioctl informing kernel of mode changes
Anyhow, there's the weird-thoughts-and-fleshing-out for the day.
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
