On 17 Aug 2001, Thayne Harbaugh wrote:
> I still haven't seen libbuf show up in CVS - what's the ETA for it's
> structure to be unveiled?
It needs some work to get it in sync with Christoph & my email
conversation. Maybe this weekend, depending on how fast my work
on the batchop core progresses and Christoph's available time.
> Is the structure sufficient in libovl so that someone, like myself,
> might complete libovl? What are the problems that need to be fixed with
> libovl?
LibOvl relies on LibGAlloc, what has some core work in progress and not many
targets implemented yet.
However, in the case of LibOVL you are often dealing with a hardware
feature of which there is only one (mouse cursor, YUV viewport) and
from the LibOvl extension target author's standpoint, LibGAlloc's
entire role is to give a yes-or-no answer as to whether the feature
is available and to pass information on the "snap grid" rules which
govern where the resource can be positioned. (In the case of a hw
mouse cursor then LibGAlloc would also allocate VRAM for the data and
give you a "pointer" to that VRAM relative to the start of VRAM).
It is thus particularly easy in the case of libOvl to skip the
LibGAlloc part and just assume that the feature is available and
hard code the snap grid values, in order to actually test the
hardware registers that move the feature around.
So, if you have a chipset that supports any such feature, and it works
with any existing accel driver that will let you access those hw registers,
then feel free to add a target for that chipset to LibOvl and test that.
There is even sample code in the X target for the X mouse cursor (but
don't take the LibGAlloc related parts of that code as a solid example.)
The only caveat is that since LibGAlloc has been skipped you must take
care to set a mode compatible with the feature yourself, until the LibGAlloc
support is added.
Note there may be room for improvement in the LibOVL API, especially,
we have not yet added a resolution-independent version of the positioning
function, which will allow sub-pixel accuracy for features that have higher
resolutions than the main framebuffer in doublescan or text modes.
You will need to compile/install LibGAlloc. Christoph either has or
will (I forget) put a tag in the LibGAlloc tree so folks can get a
compiling version even when we start to tear it up for the recode.
> I don't think I have great concern with layers - am I wrong? What are
> the "can't do without" features that layers provide?
You have to manage screen subregions yourself and adjust coordinates
(or use the display-sub hack). At least, I think that's what layers are for.
I think you can also put them on top of each other with alpha blending,
but I have not read the docs that deep. If you prefer to do these
types of things yourself, then they offer no advantage. I believe
the name of the GGI project's endeavor in this area is libwmh and
that Rodolphe wrote it, but it's late and my memory is fuzzy right now.
> This information being modes and video memory. Are there other
> resources that need to advertise information?
Any resource, even one that takes no VRAM like say splitline, can
potentially be incompatible with certain video modes or the use of
other features. So yes.
(P.S. JFYI, In the case of those features, usually if they are important, you
add them to the LibGAlloc reslist before you add the mode, which gives
them priority over the mode, so LibGAlloc will find a mode that works
with the resource.)
--
Brian
