--- David Bronaugh <[EMAIL PROTECTED]> wrote:I didn't talk at all about memory management -- I guess I should, because obviously that ground's not covered.
- Format of messages might be something like device identifier, resx, resy, colour depth, refresh (optional), extra_params (optional)Did you talk at all about memory mngmt? For instance when setting a mode
is it needed to have a frame buffer or at least enuff memory for that
mode. The reason I ask is in the VGA days one could have 6 FBs. I know
for most things 2 will be sufficent but 3 is also good, thought it's true
you probly rarely need a full-screen FB.
First, you'd have to add a parameter specifying how many framebuffers you wanted at that res -- add that after 'depth'.
Next, you'd use a kernel-side ioctl to query whether there is enough memory to set a mode -- almost identical to the ioctl to actually set the mode. So the sequence would go:
- Userspace program requets mode by feeding string into FIFO of mode setter (generated using library)
- Mode setter makes sure that the mode is possible given the current monitor setup and CRTC
- Mode setter locks device (so that nothing funny can happen)
- Mode setter asks kernel if mode is possible
- If mode is not possible, mode setter releases lock and feeds "couldn't do this" type response to program requesting mode
- If mode is possible, continue
- Mode setter tries to set mode
- If somehow this fails, mode setter releases lock and feeds "couldn't do this" type response to program requesting mode
- I don't know how this would ever happen; if it can't this code can be simplified.
- If this succeeds, continue
- Mode setter informs kernel of mode change, new parameters
- Mode setter releases lock
If the actual act of setting a mode can never fail, then this can be simplified -- we don't need an ioctl to ask if a mode is possible (from the kernel's perspective; aka, is there enough memory), we simply need a way to find out if setting that mode in kernel was successful.
Essentially, this would be the set of events then:
- Userspace program requets mode by feeding string into FIFO of mode setter (generated using library)
- Mode setter makes sure that the mode is possible given the current monitor setup and CRTC
- Mode setter locks device (so that nothing funny can happen)
- Mode setter informs kernel of mode change, new parameters
- If mode is not possible, mode setter releases lock and feeds "couldn't do this" type response to program requesting mode
- If mode is possible, continue
- Mode setter sets mode
- Mode setter releases lock
When the mode setter informs the kernel of a mode change, it can do whatever it wants, but the logical action is for it to allocate framebuffer memory.
This is one possible route, where the kernel is minimally involved. I don't like it all that much, for the following reasons:
- It's illogical to open a FIFO which ends in some userspace program to set modes (shouldn't you call an ioctl to the driver to do this?)
The alternative is to have the kernel somehow call this code (can it feed a FIFO?). I don't know if this is a better approach -- Egbert Eich doesn't seem to think so.
Feedback more than weclome.
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
