Pointer constraints are applied inconsistently to tablet pen input

[Xyene]

This issue is largely an RFC regarding what sway should do regarding tablet/touch pointer emulation in the face of pointer constraints. Any input or feedback would be much appreciated :)

On non-tablet-v2 surfaces, pen input is emulated as pointer input, it currently reuses the existing pointer code. As a side-effect, this makes tablet input over a non-v2 surface constrained by pointer-constraints-unstable-v1 confines.

However, this is pretty surprising, and leads to seemingly buggy (though actually expected) behavior. Consider the below window layout: gedit is on the left and binds tablet, kitty is in the top right and does not, and the game osu! (which sets up a pointer confine, and does not bind tablet) is in the bottom right.

If the game window is focused, input via mouse cannot leave the window. However, tablet input can leave the window through the left side (because it hits the tablet v2 handler for gedit), but it can't leave through the top (because kitty requires pointer emulation as well, so the pen input remains confined).

This is inconsistent. I think that either pointer constraints should be uniformly applied to tablet (and touch!) input, or not at all.

Pros of confining tablet input:

• An application that only expects pointer events to come from inside whatever confine it set would become confused by the emulated pointer events, which could land outside its confine. Hypothetically it could seriously misbehave, fail an assert, or something similar. I don't know of any such application, though it's possible to write one that does.
• Not confining is consistent with XGrabPointer from X11, and XWayland translates XGrabPointer into a pointer constraint. XWayland apps that expected to grab all input, including tablet input, will fail to do so.

Cons of confining tablet input:

• It's semantically wrong; the pointer constraint spec is explicitly about pointers. See also this.
• GNOME doesn't confine tablet input, so it would be inconsistent between compositors.

Neither option seems flawless. A middle ground might be to not confine the tablet input, but to stop sending events of any form to the surface owning the confine if the pen has left it. That would solve the issue of the pathological application that crashes... but it still doesn't feel like great solution.

Either implementation would be easy enough to do, but I think sway should pick one way and stick with it.

[emersion]

I think pointer-constraints should only apply to pointer input. To support the mentioned use-cases, we should make some wayland-protocols changes.