On Mon, Aug 13, 2012 at 1:00 PM, Scott Moreau <ore...@gmail.com> wrote: > > > On Mon, Aug 13, 2012 at 10:51 AM, Kristian Høgsberg <k...@bitplanet.net> > wrote: >> >> On Mon, Aug 13, 2012 at 10:16 AM, Jakob Bornecrantz <ja...@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 <ja...@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 <k...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
