Michael wrote:
> 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.

Nothing modern.  But it seems like it would be a reasonable thing on a
low-end monochrome LCD, where you don't really have color anyway.

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

Yeah.  Radeon can do better, but I'm not implementing right now...

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

Yes.

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

Soon.  Next week, probably.

    -- Garrett
>
> have fun
> Michael
>
> -- 
> 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
>