I've been hacking on my radeonfb adding hardware cursor support via the
WSDISPLAY_SCURSOR support.

I've noticed a few things.

Almost none of the framebuffers implement this.  While this is fine for
a text console, it limits the ability to write graphics programs that
use a generic wsdisplay rather than having chip-specific drivers (which
is what X does.)  Think Xwsfb.

Right now the only counter-examples I know of are igsfb and
arm/vidcvideo.c.  (And I'm not so sure about vidcvideo.c.  Some code is
there, but it doesn't look complete to me, but I don't have one to test
with.)

Further, there is no agreement about what the image and mask data passed
into these ioctls are -- i.e. it is treated as "device specific" data. 
That makes it pretty hard to write portable programs.

I think it would be nice to have some additional fields in
wsdisplay_cursor that provide information about the format of data. 
Legal formats I can imagine are:

    1) simple 1-color bit mask (maybe image is ignored, and only mask is
used?)

    2) 2 color image, followed by mask, giving 2 colors + transparency

    3) and/xor masks, giving 2 colors + transparency + complement

    4) various alpha blended formats...

Also, we need data like max cursor dimensions that the hardware
supports.  (This may be a factor of the format selected.  E.g. with some
of the alpha formats you can only have 32-pixel wide cursors on radeon.)

If folks are interested, I'll post a detailed proposal, or even diffs,
as I have time.  For now I'm writing my programs to assume 2bpp color +
transparency....

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191