Re: Mode manager / Framebuffer management

[David Bronaugh]

Mike Mestnik wrote:
--- 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.
 

I don't think what I was proposing coupled or brought together the two. 
As I see it, the mode programming code (both DAC and CRTC are rather 
outmoded terms; think LCD with digital link) is totally separate from 
the framebuffer management code. The only reason there's even any 
calling between them is that a side effect of setting a mode is 
allocating a fresh framebuffer, and wiping out the old one. That, as far 
as I can see, is the only way they are coupled.

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.
 

I don't think we're on the same page here. What I'm proposing -is- a 
pretty static way of doing things -- but my argument about why this is 
the case is, just how many ways -can- you initialize a mode? Not all 
that many. Maybe 3 or 4 different ways.

Once you've initialized the mode, lots of complications can happen 
(double buffering, triple buffering, Z buffers, etc) but these can be 
set up after the mode's set. They don't have to be set up at mode switch 
time.

- 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.
 

I was thinking that if the mode set failed, the ioctl would return an 
error. Does this sound sane?

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