On Tue, Jul 29, 2014 at 12:17 AM, Michel Dänzer <mic...@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 > > <alvarofernandogar...@gmail.com <mailto:alvarofernandogar...@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 >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel