input/cursor: refactor cursor logic for reuse in tablet/touch

[Xyene]

Fixes #5232 and hopefully other tablet bugs.

Will need rebasing after #5222 is merged.

[Xyene]

Note for reviewer: the original code had

enum wlr_edges edge = find_resize_edge(node->sway_container, surface, cursor);

...but following the control flow, surface was guaranteed to always be NULL at that point.

[Xyene]

I'm not super big on the semantics of having this function exported from here; if anyone has a better home for it I'm happy to move it.

[Xyene]

I think this should be ready for review, but maybe not merging without a bit more testing. The commits are probably best viewed in order, rather than through the full-PR diff.

I'm running the following patches on my system, based on the latest master (which has the rest of the tablet fixes merged now):

• this
• config/output: reconfigure input devices after full output init #5256 merged
• input/tablet: query tablet focused surface for cursor image check #5258 merged
• input/cursor: release simulated tool tip button when over v2 surface #5259

...and hopefully if there are issues I'll run into them in the next few days. That said, these patches fix most of the issues I've personally encountered with tablets. @David96 or @imyxh, if either of you are feeling particularly brave, some more tablet user testing of these patches would go a long way 😄

Copy-pasteable commands if you choose to do so:

$ cd /path/to/sway
$ curl -L https://github.com/swaywm/sway/pull/5254.diff | patch -p1
$ curl -L https://github.com/swaywm/sway/pull/5259.diff | patch -p1

Currently, this only adds a seatop handler for tablet motion. I think we ought to have one more at least for seatop_down, so that you can move a floating tablet v2 surface by tablet pen (currently, you can't, even without this patchset) — but I think that would best be done in a separate PR.

I would also like to rename the existing button, motion, and axis handlers to pointer_button, pointer_motion etc. to be unambiguous, but the resulting diff will be quite large. @emersion if you're OK with that, I can go ahead and do it.

I think there are definitely some opportunities for reducing code duplication here, but I think it'd be best to figure out whether the current logic is buggy or not before adding abstractions to it.

[emersion]

I would also like to rename the existing button, motion, and axis handlers to pointer_button, pointer_motion etc. to be unambiguous, but the resulting diff will be quite large. @emersion if you're OK with that, I can go ahead and do it.

Yes, please do in a separate commit.

[emersion]

Looks pretty good apart from these comments

[David96]

Is there any specific operations you would like us to test?

I just pulled your changes and am running sway with it right now - so far resizing windows appears to be smooth and from a superficial test, using the pen buttons seems to work better than ever (I have one eraser button and one that I bound to a select tool in my note taking app, the 2nd one never quite seemed to work right, now it does).

Only thing I'm not sure about: that one button seems to be supposed to work as right click? At least in FF it does. I also was able to at one point use it together with my modifier key to resize a window without grabbing its border (a 1px one in my case, quite hard to grab with the pen ^^) - but in this case the resizing wasn't quite working. As soon as the pen touched the screen it stopped and in general it was quite sluggish (maybe the offset between cursor and border was added to the window size upon resize start? Felt like something like that). And after playing around with it a bit I'm now no longer able to resize a window with this method at all. The window I was using is alacritty so I think without native tablet tool support. But this might be a general thing and not related to this pull request - I never played around with resizing windows so far, as I usually use my keyboard for that.

Also, I don't seem to be able to move windows supporting tablet tool events (tried with nemo and FF) using Mod+Pen. The events are just "eaten" by the client acting as if no modifier key was pressed.

[emersion]

LGTM, thanks!

[Xyene]

Thanks for testing @David96, I didn't really have much of a test plan other than "it seems to work better" :)

I just pulled your changes and am running sway with it right now - so far resizing windows appears to be smooth and from a superficial test, using the pen buttons seems to work better than ever

Great!

Only thing I'm not sure about: that one button seems to be supposed to work as right click?

I don't actually use the buttons on my pen so I've never noticed this, but I can confirm there's something weird going on here. My pen has two buttons. If I start gedit (by default, it binds tablet input) and press the "bottom" one, the right-click context menu opens. If I start GDK_BACKEND=x11 gedit, which doesn't bind tablet input, then I need to press the "top" button on my pen to trigger the same. So, there's some inconsistency there.

Also, I don't seem to be able to move windows supporting tablet tool events (tried with nemo and FF) using Mod+Pen. The events are just "eaten" by the client acting as if no modifier key was pressed.

This is since we map tool tip down to left button press, and only enter the "move" state on left button press. On a v2 surface, we don't do this mapping, so never enter the move move. I've opened #5293 to track this.