<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 29, 2014 at 12:17 AM, Michel Dänzer <span dir="ltr"><<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 29.07.2014 16:01, Jason Ekstrand wrote:<br>
> Couple thoughs.  First, we need to also update<br>
> drm_output_prepare_cursor_view to check against the size coming from GBM<br>
> instead of against the hard-coded 64x64 it's currently checking<br>
> against.  Without changing that, we are still restricted to 64x64<br>
> regardless of the GBM checking.<br>
<br>
</div>You mean weston will still refuse to use the hardware cursor for images<br>
larger than 64x64 without that change? That sounds like something that<br>
should indeed be fixed, though it's not really critical compared to the<br>
problem fixed by this patch, which is that the hardware cursor appears<br>
corrupted beyond usability on hardware which only supports hardware<br>
cursors of sizes other than 64x64.<br></blockquote><div><br></div><div>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.<br>
</div><div>--Jason Ekstrand<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
<br>
> On Mon, Jul 28, 2014 at 2:30 PM, Alvaro Fernando García<br>
</div>> <<a href="mailto:alvarofernandogarcia@gmail.com">alvarofernandogarcia@gmail.com</a> <mailto:<a href="mailto:alvarofernandogarcia@gmail.com">alvarofernandogarcia@gmail.com</a>>><br>
<div class="">> wrote:<br>
><br>
>     diff --git a/src/compositor-drm.c b/src/compositor-drm.c<br>
>     index 7d514e4..9c83b1a 100644<br>
>     --- a/src/compositor-drm.c<br>
>     +++ b/src/compositor-drm.c<br>
>     @@ -55,6 +55,18 @@<br>
>      #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6<br>
>      #endif<br>
><br>
>     +#ifndef DRM_CAP_CURSOR_WIDTH<br>
>     +#define DRM_CAP_CURSOR_WIDTH 0x8<br>
>     +#endif<br>
>     +<br>
>     +#ifndef DRM_CAP_CURSOR_HEIGHT<br>
>     +#define DRM_CAP_CURSOR_HEIGHT 0x9<br>
>     +#endif<br>
>     +<br>
>     +#ifndef GBM_BO_USE_CURSOR<br>
>     +#define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64<br>
>     +#endif<br>
><br>
><br>
> Is GBM_BO_USE_CURSOR a valid vallback for GBM_BO_USE_CURSOR_64x64?<br>
<br>
</div>It's the other way around, GBM_BO_USE_CURSOR_64x64 is the fallback for<br>
GBM_BO_USE_CURSOR not being defined.<br>
<br>
Note that GBM_BO_USE_CURSOR has the same value as<br>
GBM_BO_USE_CURSOR_64x64 even in gbm.h, I just changed the name to<br>
clarify that it's no longer restricted to 64x64.<br>
<div class=""><br>
<br>
> What happens if drmGetCap fails but GBM_BO_USE_CURSOR is defined?  Is that<br>
> going to be ok?<br>
<br>
</div>The two things are not directly related, but yes, that will work,<br>
because weston will use 64x64, which works with all versions of GBM.<br>
<div class=""><br>
<br>
>     @@ -1296,6 +1311,18 @@ init_drm(struct drm_compositor *ec, struct<br>
>     udev_device *device)<br>
>             else<br>
>                     ec->clock = CLOCK_REALTIME;<br>
><br>
>     +       ret = drmGetCap(fd, DRM_CAP_CURSOR_WIDTH, &cap);<br>
>     +       if (ret == 0)<br>
>     +               ec->cursor_width = cap;<br>
>     +       else<br>
>     +               ec->cursor_width = 64;<br>
>     +<br>
>     +       ret = drmGetCap(fd, DRM_CAP_CURSOR_HEIGHT, &cap);<br>
>     +       if (ret == 0)<br>
>     +               ec->cursor_height = cap;<br>
>     +       else<br>
>     +               ec->cursor_height = 64;<br>
>     +<br>
><br>
><br>
> I think this was asked before, but never answered.  Do we have known<br>
> bounds on these values?  I guess they come from GBM so we can probably<br>
> trust that they're reasonable, but what are the guarantees?<br>
<br>
</div>They come from DRM, not GBM, and the values returned depend on the<br>
individual DRM driver. If the driver doesn't set the cursor width/height<br>
explicitly, the DRM core returns 64 for both.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Earthling Michel Dänzer            |                  <a href="http://www.amd.com" target="_blank">http://www.amd.com</a><br>
Libre software enthusiast          |                Mesa and X developer<br>
</font></span></blockquote></div><br></div></div>