SUMMARY When using Barrier (https://github.com/debauchee/barrier), the freer version of Synergy, when you share the cursor from the server machine on a client machine running Plasma on Wayland, the cursor itself is invisible, although moving and clicking does affect elements on the desktop. STEPS TO REPRODUCE 1. Run barrier as a client on a machine running Plasma Wayland 2. Share the cursor from your server machine OBSERVED RESULT Cursor is invisible, although it is "present" as you can see the effects of hovering and clicking on elements. EXPECTED RESULT Cursor should be visible. SOFTWARE/OS VERSIONS Operating System: KDE neon Testing Edition KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.3 Kernel Version: 5.11.0-41-generic (64-bit) Graphics Platform: Wayland Graphics Processor: Mesa Intel® HD Graphics 5500 ADDITIONAL INFORMATION
Synergy-like apps are unsupported on wayland at the moment. My guess why it sort of works right now is that it uses xtest, i.e. it runs via xwayland. Since the input doesn't go through the compositor (kwin), the cursor is not updated. There's libeis, it can be used by synergy-like apps for faking input, but as far as I know no compositor provides support for it yet (because libeis is still sort of unstable). We refactored input abstractions in kwin to add support for this kind of thing. Something for later.
> There's libeis libei* (libeis is only for server side)
kwin does offer a way to do fake mouse input on Wayland (via a custom protocol). We use that in KDE Connect. However it's less likely that a third-party project uses a KWin-specific solution
Understood. This is not a deal-breaker. I was actually surprised that it worked to a certain degree at all, as, in the past, it has not. That said, I do look forward to the day when all these things work fully, though. Thanks!
As per comment 1, kwin's cursor is not being moved. It should be fixed with libeis, but it's unstable. Closing this bug report for now as there's nothing that we can do about it yet.