-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

> 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.

At least mine don't do it because X has native drivers which do the 
cursor handling themselves. The SBus drivers usually implement 
respective the fbio-ioctl()s but probably not the wsdisplay variants ( 
I know I added the fbio stuff for pnozz because X accessing DAC 
registers directly was unreliable )

> 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.)

The image format hasn't been defined anywhere so I think we should use 
igsfb as example.

> 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.

Packed two bit bitmap so far.

> 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?)

Do you know any chips that use such a format? All I've ever dealt with 
use at least two bit images.

>     2) 2 color image, followed by mask, giving 2 colors + transparency
>
>     3) and/xor masks, giving 2 colors + transparency + complement

All the chips I've dealt with so far supported either mask + mono 
bitmap or 3 colours + transparency. Some did weird additional formats 
with more cursor colours though.

>     4) various alpha blended formats...

Yes, bitmap + alpha makes sense. Well, in a way bitmap+mask is a 1 bit 
bitmap and a 1 bit alpha channel ;)

> 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.)

Yes,  there should be something to ask for capabilities like supported 
colour formats, size etc.
Even the P9100 supports 64x64 cursors.
I don't think we should support too many bitmap formats - just a few 
common ones ( common as in 'no userland headache' ) - no need to have 
loads of bitmap converters in the kernel. We may need a few though, 
like packed 2bit -> separate planes and maybe the other way around. 
These are MI of course.

> 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....

Please do that.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRFJDwMpnzkX8Yg2nAQKT7Qf/VJVDEmiPfo/WOahybbiLbGe4+96yJVwx
DRZr1CyoUL/O/cqLyf+xZZUPMdoTP1Ou861Tqv8j7ye7hl5RZBPP3MCJd+yyR30H
awYft4ZXi8axorKq9Ws6azfQMoJbA/n2DpBrpAZ14cxL06u3m2OQS8u7yoEemRaY
EjIdEn7SIOwxs4VMWhsB48+tplcRMXeznBmq+xb+sOem2Ot0TpRt4p14vnHQiluc
ProqS3vJbltQcfat0G58xCpcAQndm1c9elO98VP3LiY3SsEfMs+EAaC2DESdb+EC
U2P8+xCfz1WH92jKkdRzHzeMiYZeQqfyjgpx9z1taa8Pfzdg4lmgmw==
=FmJp
-----END PGP SIGNATURE-----