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

[Michel Dänzer]

On 29.07.2014 16:01, Jason Ekstrand wrote:
> Couple thoughs.  First, we need to also update
> drm_output_prepare_cursor_view to check against the size coming from GBM
> instead of against the hard-coded 64x64 it's currently checking
> against.  Without changing that, we are still restricted to 64x64
> regardless of the GBM checking.

You mean weston will still refuse to use the hardware cursor for images
larger than 64x64 without that change? That sounds like something that
should indeed be fixed, though it's not really critical compared to the
problem fixed by this patch, which is that the hardware cursor appears
corrupted beyond usability on hardware which only supports hardware
cursors of sizes other than 64x64.


> On Mon, Jul 28, 2014 at 2:30 PM, Alvaro Fernando García
> <alvarofernandogarcia at gmail.com <mailto:alvarofernandogarcia at gmail.com>>
> wrote:
> 
>     diff --git a/src/compositor-drm.c b/src/compositor-drm.c
>     index 7d514e4..9c83b1a 100644
>     --- a/src/compositor-drm.c
>     +++ b/src/compositor-drm.c
>     @@ -55,6 +55,18 @@
>      #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
>      #endif
> 
>     +#ifndef DRM_CAP_CURSOR_WIDTH
>     +#define DRM_CAP_CURSOR_WIDTH 0x8
>     +#endif
>     +
>     +#ifndef DRM_CAP_CURSOR_HEIGHT
>     +#define DRM_CAP_CURSOR_HEIGHT 0x9
>     +#endif
>     +
>     +#ifndef GBM_BO_USE_CURSOR
>     +#define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64
>     +#endif
> 
> 
> Is GBM_BO_USE_CURSOR a valid vallback for GBM_BO_USE_CURSOR_64x64?

It's the other way around, GBM_BO_USE_CURSOR_64x64 is the fallback for
GBM_BO_USE_CURSOR not being defined.

Note that GBM_BO_USE_CURSOR has the same value as
GBM_BO_USE_CURSOR_64x64 even in gbm.h, I just changed the name to
clarify that it's no longer restricted to 64x64.


> What happens if drmGetCap fails but GBM_BO_USE_CURSOR is defined?  Is that
> going to be ok?

The two things are not directly related, but yes, that will work,
because weston will use 64x64, which works with all versions of GBM.


>     @@ -1296,6 +1311,18 @@ init_drm(struct drm_compositor *ec, struct
>     udev_device *device)
>             else
>                     ec->clock = CLOCK_REALTIME;
> 
>     +       ret = drmGetCap(fd, DRM_CAP_CURSOR_WIDTH, &cap);
>     +       if (ret == 0)
>     +               ec->cursor_width = cap;
>     +       else
>     +               ec->cursor_width = 64;
>     +
>     +       ret = drmGetCap(fd, DRM_CAP_CURSOR_HEIGHT, &cap);
>     +       if (ret == 0)
>     +               ec->cursor_height = cap;
>     +       else
>     +               ec->cursor_height = 64;
>     +
> 
> 
> I think this was asked before, but never answered.  Do we have known
> bounds on these values?  I guess they come from GBM so we can probably
> trust that they're reasonable, but what are the guarantees?

They come from DRM, not GBM, and the values returned depend on the
individual DRM driver. If the driver doesn't set the cursor width/height
explicitly, the DRM core returns 64 for both.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer