On Fri Dec 8 08:28:22 2023 +0000, Vlad Zahorodnii wrote:
I have also seen this with KDE, and my current inclination is to say
that this is a compositor problem. Looking at the logs it seems the driver is issuing the proper requests, but the cursor remains visible. Yeah, the wayland log looks okay.
[ 858989.759] -> wl_pointer@15.set_cursor(172832, nil, 0, 0) [ 858989.762] -> zwp_relative_pointer_manager_v1@10.get_relative_pointer(new id zwp_relative_pointer_v1@59, wl_pointer@15) [ 858990.080] -> wl_compositor@4.create_region(new id wl_region@57) [ 858990.083] -> wl_region@57.add(1280, 720, 0, 0) [ 858990.086] -> zwp_pointer_constraints_v1@9.confine_pointer(new id zwp_confined_pointer_v1@49, wl_surface@3, wl_pointer@15, wl_region@57, 2)this should work, there's only one pointer enter event and no leave event before. Will check why kwin refuses to hide the cursor.
@afrantzis I figured out why the cursor is not hidden in plasma. https://invent.kde.org/plasma/kwin/-/merge_requests/5158 should fix it in plasma 6. However, it would be nicer if wine calls wl_pointer.set_cursor first, then destroys the cursor surface. What the compositor should do when the cursor surface is destroyed is not covered explicitly by the spec, and doing things in the opposite (wl_pointer.set_cursor; wl_surface.destroy) is going to have fewer chances of hitting compositor bugs. :)
-
Vlad Zahorodnii (＠zzag)