On Wednesday, July 19th, 2023 at 03:42, Zack Rusin <z...@kde.org> wrote:
> From: Zack Rusin <za...@vmware.com>
>
> Cursor planes on virtualized drivers have special meaning and require
> that the clients handle them in specific ways, e.g. the cursor plane
> should react to the mouse movement the way a mouse cursor would be
> expected to and the client is required to set hotspot properties on it
> in order for the mouse events to be routed correctly.
>
> This breaks the contract as specified by the "universal planes". Fix it
> by disabling the cursor planes on virtualized drivers while adding
> a foundation on top of which it's possible to special case mouse cursor
> planes for clients that want it.
>
> Disabling the cursor planes makes some kms compositors which were broken,
> e.g. Weston, fallback to software cursor which works fine or at least
> better than currently while having no effect on others, e.g. gnome-shell
> or kwin, which put virtualized drivers on a deny-list when running in
> atomic context to make them fallback to legacy kms and avoid this issue.
>
> Signed-off-by: Zack Rusin <za...@vmware.com>
> Fixes: 681e7ec73044 ("drm: Allow userspace to ask for universal plane list
> (v2)")
> Cc: <sta...@vger.kernel.org> # v5.4+
> Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> Cc: Maxime Ripard <mrip...@kernel.org>
> Cc: Thomas Zimmermann <tzimmerm...@suse.de>
> Cc: David Airlie <airl...@linux.ie>
> Cc: Daniel Vetter <dan...@ffwll.ch>
> Cc: Dave Airlie <airl...@redhat.com>
> Cc: Gerd Hoffmann <kra...@redhat.com>
> Cc: Hans de Goede <hdego...@redhat.com>
> Cc: Gurchetan Singh <gurchetansi...@chromium.org>
> Cc: Chia-I Wu <olva...@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> Acked-by: Pekka Paalanen <pekka.paala...@collabora.com>
> Reviewed-by: Javier Martinez Canillas <javi...@redhat.com>
Nit: I think it would be better to reflect the name of the DRM client cap in
the supports_virtualized_cursor_plane field.
Regardless:
Reviewed-by: Simon Ser <cont...@emersion.fr>
