On Thu, 1 Feb 2001, Stefan Seefeld wrote:
> I'm totally confused. Of course, I don't know *anything* about h/w cursor
> implementations, but I would assume that the cursor's pixel layout is the
> same as that of the corresponding visual.
Heh. Guess again. Most of the SVGA family have a 2-bit or 4-bit depth,
and it is an index of a register which contains a value which can be anything
from entirely independent from the main visual, to an index into the
main visual's palette, to a raster op (transparant, inverse video, etc.)
And a lot of the chips have different registers you can poke around with
to change the maening of the values of the cursor color registers.
Getting this into an API that anyone is going to want to use is a worthy
program design challenge :-)
> Having a palette for the cursor
> which needs to be translated into the visual (palette or truecolor) seems not
> to make much sense. And why 4 bit ??
<cynical>
In order to make it difficult for us to get the cursor to work in the
first place. In fact, there are even highly advanced ways of making
it difficult for us to get the cursor to work, like not allowing the
data for the curcor to reside in certain areas of the framebuffer memory.
</cynical>
(which is why we need a "feature negotiation API" before anything like
the cursor or sprite libraries see hardware acceleration.)
--
Brian
