--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
> >--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Mike Mestnik wrote:
> >>
> >>
> >>
> >>>This is vary good.
> >>> - To accomidate mergedfb the number of FBs should be allowed to be
> 0.
> >>>
> >>>
> >>>
> >>>
> >>How does mergedfb work internally? I don't know.
> >>
> >>
> >However we need it to? I think if we cripple X the current mergedfb
> will
> >also have to be crippled.
> >
> >
> I think this design allows for mergedfb to work "however we need it to"
> by encapsulating all that (setup) logic within the "Extended DRM"
> module.
>
> Do you disagree?
>
Yes, I think the mode/dac programing code should be seperat from the
frambuffer allocation/mngmnt code. Wather it should live in the DRM is
another story, thought It should live kernel side as it workes closely
with the hardware.
A fue other questions, directed at the memory mngmt ppl. What about 2d
only page fliping, ModeX and the like? Where these ever supported outside
of libsvga? Are thay rellecs from the past that can die?
> >Hopefully modes can be set withought FBs this cuts down on the FB
> >{a,de}lloc code. However inorder to cutdown on card specific code, it
> may
> >be best for all cards the deal with worst-case FB alloc, if this is to
> be
> >a feature.
> >
> >
> All allocation of framebuffers will happen within the kernel. None will
> be requested by the mode manager.
>
I think this is the best desing, as it gives the app programer lots of
freedom.
> >>> - Have mem free as well as mem total.
> >>>
> >>>
> >This helps with multi-tasking, I.E. Two apps sharing the same
> VT(context).
> > For multi-headed cards thay will have to share FB resources.
> >
> >
> >
> >>> - Returning hardware capabilitys(like in a termcap type way), not
> >>just
> >>>mem sizes. I.E. zbuffer type(how to know it's size).
> >Allocating a FB on some cards may not be a simple as L*H*D. As I'm not
> an
> >expert on hardware I don't know what snags you might hit on, that are
> not
> >version but card dependant.
> >
> >>Hmm... I'd love for you to elaborate here, though I -think- I know
> what
> >>you're getting at.
> >I wish I could but I realy don't know, it's just something I think the
> >desing might need. I used the source and saw into the future.
> OK; elaborate?
>
Allocating a frame buffer may need a FB description header filled out in
video memory, taking up some space. The hardware cursor may need to be at
a perticular offset, thus making it immposible for a FB to span that
offset. I guess that since there are an infinet number of reasons a FB
might not be allicatable that it's better of the call to just fail rather
then the lib/app trying to guess that it will. So no communication from
the driver to the app is needed.
>
> David Bronaugh
>
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/
-------------------------------------------------------
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
