https://bugs.kde.org/show_bug.cgi?id=401921
d138e...@casix.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |d138e...@casix.org
--- Comment #6 from d138e...@casix.org ---
(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.
--
You are receiving this mail because:
You are watching all bug changes.
