Mike Mestnik wrote:
--- 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.
Why not just be able to query how much physical video RAM is -not-
allocated?
It sounds to me like this would solve the problem.
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
