STEPS TO REPRODUCE 1. start Wayland session 2. install Kodi 18 RC2 via flatpak/flathub 3. open Kodi and move the cursor OBSERVED RESULT two cursors are visible EXPECTED RESULT only one cursor should be visible SOFTWARE/OS VERSIONS KDE Plasma Version: 5.14.4 KDE Frameworks Version: 5.52 Qt Version: 5.12 ADDITIONAL INFORMATION already reported to Kodi devs. https://github.com/xbmc/xbmc/issues/15002 "The two pointer objects are not the problem, I tested by disabling one of them. Wayland debug logs show that the cursor image is set to null, which according to the specification means that the cursor has to be hidden. KWin does not do this for whatever reason - it works on GNOME and Weston. I recommend you to retry with the latest possible version of KWin (preferably built from Git master) and if your problem persists report it to the KDE people."
Please attach the output of WAYLAND_DEBUG. KWin in general does support the hiding of the cursor, so something might be wrong in the event sequence.
Created attachment 116802 [details] wayland_debug
The log is incomplete. You need to redirect everything to a file.
Created attachment 116811 [details] complete output of wayland_debug
After analyzing the debug output it looks like kodi is doing some things wrong. It creates two wl_pointer objects as described in the github issue. On one of them it sets a null cursor. On the other one it doesn't set a cursor at all. Given that we should have no cursor - neither from Kodi nor from KWin. This means that Kodi is also drawing it's own cursor. But Kodi is not using the Wayland protocols for such an interaction. It should use the pointer constraints interface and lock the cursor and use the relative pointer interface for motion when the cursor is locked. I'm setting this bug report to not a bug on our side.
(In reply to Martin Flöser from comment #5) > After analyzing the debug output it looks like kodi is doing some things > wrong. There is nothing in the specification that forbids creating two wl_pointer objects. It is also not connected to the bug. As described in the GH issue, using only one wl_pointer does not change anything. > It creates two wl_pointer objects as described in the github issue. > On one of them it sets a null cursor. On the other one it doesn't set a > cursor at all. Given that we should have no cursor - neither from Kodi nor > from KWin. This means that Kodi is also drawing it's own cursor. Yes. > But Kodi is not using the Wayland protocols for such an interaction. It should use the > pointer constraints interface and lock the cursor and use the relative > pointer interface for motion when the cursor is locked. In Kodi, the cursor is part of the skin and cannot easily be put in its own surface. Anyway, both pointer-constraints and relative-pointer are not directly related to showing or not showing the cursor image. That is, using them would not solve the problem at hand, and I don't really see how they would benefit our use-case in the first place. > I'm setting this bug report to not a bug on our side. I don't see how you come to this conclusion. You said yourself: "Given that we should have no cursor - neither from Kodi nor from KWin" - so KWin should not draw a cursor in this case. Yet, it does, violating the Wayland protocol. I actually made a MWE, but it's even simpler. Try weston-confine. The cursor should disappear over the window, and it does so on GNOME and Weston. It stays visible on KWin.
Please do things as intended by the Wayland protocols: * Set a null surface on all pointer objects * Use pointer locking and relative pointer Drawing your own cursor without locking won't work - nowhere. The cursor might get warped or similar and then the pointer position is wrong. We can see that in the screenshot, the pointer positions of the two cursors are not identical. If you want to draw your own cursor, use locking - that's the intended interface for it. I'm refusing to investigate non issues. Rendering own cursor without locking is not supported.
I've tried in a full Plasma session now and it seems the problem with one wl_pointer not reacting to set_cursor(NULL) (as with weston-confine) is limited to running KWin in X11 or Wayland nested mode. Still a bug, but whatever. I'm curious about what problem pointer locking will solve once the double wl_pointer is sorted out, but this is clearly not the place to discuss that. I'll try to hit you up on IRC.
I'm not on IRC.
Fair enough (and I gather that you are not interested in continuing this discussion). Thanks for your input so far.
Your conclusion is not really correct. Martin hasn't been on IRC since ages. If you still believe there is an issue in KWin, you could also use the kwin mailing list to discuss it or to share minimal working examples.