Let me start of by saying I think you are on the right track and all of
your ideas look good.
--- 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.
> Alternatively to this, maybe the best way to do this would be to specify
>
> a double-width mode (eg 2048x768) and an extra "feature" parameter of
> MERGEDFB or some such -- that might work. However, I can't claim to
> understand mergedfb (as in, how it's implemented) yet, so this is
> probably a naive solution.
>
I see it more as just a way of pointing a viewport to a framebuffer, like
a screen(FB) swap. What I see is that a FB gets allocated and then modes
get set, with it's viewport looking into this FB. This can all be part of
the modesetting code, then the FB and the viewport should be returned.
That way the FB can be deallocated, after a succsesfull FB change. There
will be rare cases where the card can't handel both FBs then the FB
allocate code might need to handel this NEEDED deallocate/change inorder
to allocate the new/replacing FB.
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.
> > - Sharing of FBs should be allowed, for heads on the same card.
> >
> >
> Same deal, except instead of a "feature" of MERGEDFB, the "feature"
> should be CLONE
>
I don't like the idea of having things so static. Attaching and
deattaching modes(viewports) from FBs should be done via a full API. If
this is at all possible?
> > - There is no way to ?change?(read as specify) the size of a FB.
> >
> >
> If you can specify the resolution, you can specify the size of the
> framebuffer. What else did you have in mind?
>
Size of viewport != FB size, thought I think you got that by the end of my
msg.
> > - Allocating the second/... FB may be difficult,
My comments above and below, as two diffrent cases.
> > - 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.
>
> This is sorta what I had in mind for modes. The first part is a blatant
> rip of linux/fb.h:
>
> struct mode {
> __u32 xres; /* Actual FB width */
> __u32 yres; /* Actual FB height */
> __u32 xres_virtual; /* Virtual fb width */
> __u32 yres_virtual;/* Virtual fb height */
> __u32 xoffset; /* Offset of actual from top-left corner of virtual
> */
> __u32 yoffset;
>
> __u32 bpp; /* Bits per pixel */
>
> __u32 refresh; /* Preferred refresh rate (0 for no preference) */
>
> __u32 fb_mode; /* Example: various tiled modes versus linear;
> defined as integers (LINEAR, TILED4K, etc) */
> __u32 feature; /* Numeric feature code (eg MERGEDFB, CLONE) */
> };
>
Virtual fb vs Actual FB. IMHO Actual FB is the monitors mode and not the
allocated size of the FB(Virtual fb).
> This is what the mode manager receives:
>
> struct ms_mode {
> __u32 xres;
> __u32 yres;
> __u32 bpp;
> __u32 refresh;
> };
>
No FB? This may be positive.
__________________________________
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
