Developer of lan-mouse here:
I initially started working on this project with only wlroots compositors in mind or more precisely
- any compositor that supports the layer-shell protocol could be used for capturing input
- any compositor that supports wlr-virtual-pointer and virtual-keyboard could be used for input emulation
The main motivation was really to learn more about wayland at that point.
Then later I started to expand the project to support additional backends for e.g. Windows and MacOS (which currently only support input emulation) and of course Libei to get Gnome working as well (and likely KDE in the future).
For input emulation there is also support for the xdg-remote-desktop-portal which seems to be the only option for emulating input on KDE wayland until libei is supported there.
Input Capture using Libei is WIP since the whole project and particularly also the Rust bindings are in a pretty early state right now (thank you so much ids1024 for providing the reis libei bindings, if you are reading this!)
I agree, it's a shame that Wayland is so fragmented among the different DEs. Especially wlr-layer-shell support would be very nice to see on the Gnome Side (it was much easier to work with than libei!...) but I'm pretty sure that's not going to happen.
On the other hand I must also say that supporting wayland through the mentioned interfaces was a more pleasant experience than supporting Xorg with hacks like Xtst (Except for the broken implementation of the remote desktop interface in xdg-desktop-portal-kde maybe, which left me with permanently stuck keys several times...) and I'm still figuring out input capture which is likely also going to rely on more hacks than the wayland side of things.
I have also played with the idea of writing some sort of wlroots -> libei bridge that implements an eis server using the mentioned wlroots specific protocols.
This would reduce the amount of backends required in lan-mouse but add an additional layer of indirection between the application and the compositor, so I'm not sure its such a great idea.
For the foreseeable future, I will definitely keep support for everything within lan-mouse itself.
The main motivation was really to learn more about wayland at that point.
Then later I started to expand the project to support additional backends for e.g. Windows and MacOS (which currently only support input emulation) and of course Libei to get Gnome working as well (and likely KDE in the future).
For input emulation there is also support for the xdg-remote-desktop-portal which seems to be the only option for emulating input on KDE wayland until libei is supported there.
Input Capture using Libei is WIP since the whole project and particularly also the Rust bindings are in a pretty early state right now (thank you so much ids1024 for providing the reis libei bindings, if you are reading this!)
I agree, it's a shame that Wayland is so fragmented among the different DEs. Especially wlr-layer-shell support would be very nice to see on the Gnome Side (it was much easier to work with than libei!...) but I'm pretty sure that's not going to happen.
On the other hand I must also say that supporting wayland through the mentioned interfaces was a more pleasant experience than supporting Xorg with hacks like Xtst (Except for the broken implementation of the remote desktop interface in xdg-desktop-portal-kde maybe, which left me with permanently stuck keys several times...) and I'm still figuring out input capture which is likely also going to rely on more hacks than the wayland side of things.
I have also played with the idea of writing some sort of wlroots -> libei bridge that implements an eis server using the mentioned wlroots specific protocols. This would reduce the amount of backends required in lan-mouse but add an additional layer of indirection between the application and the compositor, so I'm not sure its such a great idea. For the foreseeable future, I will definitely keep support for everything within lan-mouse itself.