--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
>
> >--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Mike Mestnik wrote:
> >>
> >>
> >>>--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> >>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.
>
Ohh, "Yes" as in 'slang' for I agree and not 'english' for "I disagree".
It's not a problem at all for the mode setting code to zero out or set the
FB and view port pos to NULL. There is a race condition here, but I think
it can be dealt with.
> 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.
>
There may be only a fue, however there may be 2 or more apps that will
have input to consider. I agree this will be a first come first serve. I
also would like the freedome to do all sorts of wiered things, this would
need an API any way. I.E. moving a screen to/from a cloned mode, ect. As
far as being able todo things later there may no be enuff memory, so the
'mode' will have to be able to not have a FB.
I guess it's all a mute point that can be turned up later.
> >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?
>
lol, It dose sound sane :)
However id like to avoid apps switching modes untill they find one where
thay can do zbuffer(or whatever they need) by being able todo that b4 they
switch mode. I guess I was thinking that they would have todo that after
the mode was set. It seams sane to me that the FB and what not should be
allocated then the mode set. During this time the mode has no FB, it(the
FB that we should not have) would use ram.
> 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
