sway
sway copied to clipboard
Improve tablet tool button handling.
This change allows the tablet tool button to be used for floating mod resize. In addition, it attempts to ensure that tablet tool events are consistent such that tablet v2 events and pointer events will never be interleaved, and such that the tool buttons count will never fall out of sync and cause tool button emulation to break.
Some of this logic is similar to what is done for tablet tool tip, but not quite identical, because of the complication that we have to deal with multiple inputs that can overlap each-other.
The logic described to fix this in #7036 is not sufficient as it does not account for the inverse case (going from tablet events to pointer events.) Implementing the fix this way leads to much better behavior if you, for example, use a tool button to open a menu, then before releasing the tool button, hold the modifier key down.
(Note: I'm currently unable to compile SwayWM from master as I do not have the ability to run meson>=0.60 right now, among other deps. So although I made a best effort to ensure this patch is right for SwayWM master, I could not actually test this yet on my own setup. Sorry.)
Fixes #7036.
I'm sure bandwidth is limited, but I'd love to get this good for merge since it is quite a massive quality-of-life improvement for using SwayWM with graphics tablets. Is there anything in particular I can do to help here? I just rebased since it has been a couple months.
Thanks for taking a look! I've been a little busy myself lately, coincidentally. I've integrated the suggestions.
As for the bug with floating windows, I am oddly unable to reproduce this even if I get the cursor clearly off of the window. I'm actually not entirely sure why this works: I'd assume if node_at_coords changed mid-resize, it would break. I tried both XWayland windows and native windows on top of each-other, nothing breaks. It also doesn't break if I try to resize it too small and drag the cursor entirely past the bounds of the window. I wonder what I'm missing....
If I had to guess, it's because https://github.com/swaywm/sway/blob/master/sway/input/seatop_resize_floating.c is unimplemented for tablets, so things only work if under pointer emulation. See https://github.com/swaywm/sway/blob/master/sway/input/seatop_move_floating.c for reference (moving floating windows with the tablet works). Being in seatop_resize_floating should prevent focus from changing until the tool is released.
Yeah, that's why this PR forces pointer emulation when resizing. I'll try to take another look, but even using gedit and Firefox I can't get the same behavior—it's working as expected when I try.
(edit: Also, it seems I made a mistake earlier and didn't commit the simplification to the WLR_BUTTON_RELEASED case, sorry! Fixed now.)
@Xyene I've messed around trying to figure out how to reproduce the issue you're having, but I'm just unable to. I've tried with gedit and Firefox in XWayland, gedit and Firefox in xdg_shell, tried the reverse, tried releasing mod while moving the cursor... I'm interested in fixing the issue, but I simply can't figure out what's going on. Do you have any ideas? Maybe your setup differs from mine in some fundamental way.
New year, new rebase. Hello again.
I'm still daily-driving this patch. I still can't reproduce the issue with resizing. That said, especially since this fixes the issue where tool buttons stop entirely, I'd really like it if we could make some progress here somehow...
Of course I'd love to address the problems. I've tried to reproduce them to no avail. On my end, no matter what combination of floating windows, where I start the drag, or how violently I move the cursor, the resize doesn't break for me when using this patch. I can only reproduce that without this patch. If there's more information that might enable me to reproduce an issue, I'd love to hear it.
That said, even if there was an issue with floating resize, I think the status quo in this PR is still a lot better than on master and in 1.8. I'd love to remove this from my local patchset by the time 1.9 comes out, and bring a much better graphics tablet experience to other Sway users who don't run patches. Can we make it happen?
No problem, thanks for taking another look. I would like to still keep working on graphics tablet robustness, so I hope we can figure it out eventually. If it's happening for you, I'm sure it's going to happen for others. For now though, I'm just glad that 1.9 should ship without the tablet tool button bug. 👍