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

[Jason Ekstrand]

On Tue, Jul 29, 2014 at 12:17 AM, Michel Dänzer <michel at daenzer.net> wrote:

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

Yup.  That is exactly what it means.  It should be a fairly easy fix.  If
you'd rather I push this and fix in a follow-up patch, that's probably ok,
but let's make sure one is coming.
--Jason Ekstrand


>
>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140729/5c18f80c/attachment.html>