This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be 0.
- Sharing of FBs should be allowed, for heads on the same card.
- There is no way to ?change?(read as specify) the size of a FB.
- Allocating the second/... FB may be difficult,
- Have mem free as well as mem total.
- Returning hardware capabilitys(like in a termcap type way), not just
mem sizes. I.E. zbuffer type(how to know it's size).
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
>
> >--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> >
> >
> >> - 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.
> >
> >
> I didn't talk at all about memory management -- I guess I should,
> because obviously that ground's not covered.
>
> 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
>
__________________________________
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861
-------------------------------------------------------
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
