[PATCH V3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

[Alex Deucher]

On Tue, Jul 29, 2014 at 3:03 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Tue, 29 Jul 2014 13:19:10 +0200
> Daniel Vetter <daniel at ffwll.ch> wrote:
>
>> On Tue, Jul 29, 2014 at 12:55:24AM -0700, Jason Ekstrand wrote:
>> > I pushed this one.  Let's get a follow-up that lets weston actually use the
>> > bigger cursors.  It would also be good to hack together a little client
>> > that attaches a big cursor so we can verify that it's working.  I don't
>> > think we need to put it in the repo, I'd just like proof that we're
>> > actually taking advantage of our new-found big cursors.
>>
>> Just an aside: With recent kernels intel hw supporst 64x64, 128x128 and
>> 256x256. On all generations (down to gen2).
>
> Ok, so which one of those will we get through drmGetCap()?
>
> I think it would not be nice, if we receive the values 256x256,
> because then Weston will pad *all* cursor images to 256x256,
> even if 64x64 would suffice. So possibly quite a waste there, first
> memcpy and then full-sized gbm_bo_write for every cursor change.
>
> If drmGetCap returns 64, 128, or 256, how would we infer all the
> valid sizes? All powers-of-two larger than 64x64, included? Is
> e.g. 64x256 valid?

I added the drmGetCap cursor support for radeon as our hw only
supports fixed size hw cursors and there is other hardware out there
with similar limitations.  I'm not sure what the best way to handle
this would be for hw that supports multiple cursor sizes.  I think
perhaps the recent KMS overlay/plane changes cover this by exposing
cursors as planes.

Alex