[Mesa-dev] [PATCH 2/2] gbm: Use libkms to work around missing cursor support in dri drivers

[Kristian Høgsberg]

On Mon, Aug 13, 2012 at 1:00 PM, Scott Moreau <oreaus at gmail.com> wrote:
>
>
> On Mon, Aug 13, 2012 at 10:51 AM, Kristian Høgsberg <krh at bitplanet.net>
> wrote:
>>
>> On Mon, Aug 13, 2012 at 10:16 AM, Jakob Bornecrantz <jakob at vmware.com>
>> wrote:
>> > Uses libkms to work around missing dri image cursor support. One could
>> > take
>> > this patch one step futher and removing cursor surfaces entirely from
>> > the DRI
>> > interface and as a consequence also from the Gallium interface. Tho to
>> > make
>> > everybody happy with this it would probably require adding a
>> > kms_bo_write
>> > function, but that is probably wise in anyways.
>> >
>> > The only downside is that it adds a dependancy on libkms, this could how
>> > ever
>> > be replaced with the dumb_bo drm ioctl interface.
>> >
>> > Signed-off-by: Jakob Bornecrantz <jakob at vmware.com>
>>
>> That looks good, using libkms is a fine way to handle this as long as
>> it doesn't leak through the gbm API.  Using libkms or dumb_bo ioctl
>> entirely for cursor gbm bo's would be fine too.
>>
>> Reviewed-by: Kristian Høgsberg <krh at bitplanet.net>
>
>
> I briefly tested these patches on RV350 and it fixes the problem here
> https://bugs.freedesktop.org/show_bug.cgi?id=52267
> I did notice that the last frame of the last instance of weston is 'flashed'
> during the fade-in when running the next instance of weston.

Since Jakob added gbm_bo_write support now, I think you're now (for
the first time) using hw cursor instead of gl cursor.  The flicker
could be the RV350 flickering when we enable the hw cursor after the
fade finishes.  You can try adding return NULL; early in
drm_output_prepare_cursor_surface() to disable hw cursor and see if
that's the case.

Kristian