Recently, support was added for mouse pointer warp on Wayland. The traditional methods don’t work on Wayland because, as I understand it, Wayland’s design philosophy incorporates a combination of “pointer warp is a huge security hole” and “pointer warp is unavoidably bad UI/UX”, though they did finally recently accede to a “pointer_warp_v1” Wayland protocol.
Before “pointer_warp_v1” was introduced, though, it was necessary to use a work-around based on the “pointer_constraints_unstable_v1” protocol. The thing is, this protocol’s documentation pretty much on every other line says, “You shouldn’t expect this to actually work or have predictable behaviour.” Specifically, mouse constraints are documented as essentially being hints to the compositor. The compositor may at some point in the future apply them to the mouse pointer, but it also might never apply it. Furthermore, the app gets no notification either way.
The latest SDL code implements both of these, as I understand it, trying “pointer_warp_v1”, and falling back on “pointer_constraints_unstable_v1” using a constraint region if it isn’t available.
I am wondering if anyone has experience with this and knows whether the work-around is reliable. If my app has functionality that really needs pointer warp to work, and which will definitely be a bad user experience without pointer warp, can I rely on the work-around or do I basically need to disable the functionality if running on Wayland and the new “pointer_warp_v1” protocol (which is currently only implemented by one compositor) isn’t available?
I don’t personally use Wayland. I have an installation with it but it’s just using the default compositor, and the documentation for Wayland protocol support indicates that there are like two dozen options these days.