Under a guest VM running Gnome 3.26.2 Wayland, the mouse cursor becomes laggy, and a double cursor (both host and guest I presume) when Mesa 17.3.x is installed including the latest, 17.3.3. Reverting back to 17.2.8 and the problem goes away. In the system logs the following can be found: Feb 03 22:03:19 lfs13 org.gnome.Shell.desktop[651]: Window manager warning: HW cursor for format 875713089 not supported I've done a git bisect: e14fe41e0bf5d82c0b22eda2f8dcea058ac6e610 is the first bad commit Tracking it even further, it seems to be related to __DRI_IMAGE being changed from 15 to 17 in src/gallium/state_trackers/dri/dri2.c . More info: GL_RENDERER: llvmpipe (LLVM 5.0, 256 bits) kms_swrast_dri.so I wrote a simple test program, and the following function returns false under 17.3.3, and returns true under 17.2.8. gbm_device_is_format_supported (gbm, gbm_format, GBM_BO_USE_CURSOR | GBM_BO_USE_WRITE)
Same problem here with Gnome 3.2.6 under Virtualbox and Mesa 17.3.6.
Problem is still present with Mesa 18.0-rc4
I was able to reproduce the `gbm_device_is_format_supported` failure. The call sequence is following: * gbm_device_is_format_supported * gbm_dri_is_format_supported (gbm->is_format_supported) - `dri->image->base.version` is now 17 (this changed in the bisected commit e14fe41e0!) and `dri->image->queryDmaBufModifiers` is set, so it will be called. * dri2_query_dma_buf_modifiers (dri->image->queryDmaBufModifiers) - oh no, `pscreen->query_dmabuf_modifiers` is 0, so return false... The situation depends on whether the screen was initialized with `dri2_init_screen` or with `dri_kms_init_screen`. In case of `dri2_init_screen` the `dri->image->queryDmaBufModifiers` is not set if `pscreen->query_dmabuf_modifiers` is null. In case of `dri_kms_init_screen` it is set unconditionally. The condition was added to `dri2_init_screen` in commit a65db0ad1c3. I think that equivalent condition is needed in `dri_kms_init_screen`. Will send patch...
https://lists.freedesktop.org/archives/mesa-dev/2018-March/189030.html
The above patch has fixed the issue for me. Thanks!
Hmm. Fix is not yet in git master. :-(
I'm seeing exactly these same message floods running Fedora 29 images in VMs, and indeed the fix seems to have got lost - there was one reply to the message, then crickets after that, and it's still broken in git master. :(
Confirmed the patch fixes the error message flood, makes my VM cursor move much more smoothly, and somehow seems to fix paste from the host system into the VM too. Maybe I should see if it can pick my lotto numbers for me as well...
commit 194bf0a2e01769f4b29df06febf27ce340c1cd68 (HEAD -> master, origin/master, origin/HEAD) Author: Michal Srb <msrb@suse.com> Date: Thu Mar 15 17:27:57 2018 +0100 st/dri: don't set queryDmaBufFormats/queryDmaBufModifiers if the driver does not implement it This is equivalent to commit a65db0ad1c3, but for dri_kms_init_screen. Without this gbm_dri_is_format_supported always returns false. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104926 Fixes: e14fe41e0bf ("st/dri: implement createImageFromRenderbuffer(2)") Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Tested-by: Adam Williamson <adamwill@fedoraproject.org>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.