Touch screen drag moves windows and tap does not focus

[TheZoq2]

After the "recent" 9.3.1 update, touch screen compatibility seems broken.

I have bspwm configured with focus_follows_pointer which works fine for mouse input, but to focus a window on my touch screen I have to tap the window between 2 and 3 times for the focus to work.

Additionally, dragging an unfocused window moves that window instead of doing nothing. This is without any modifiers being pressed. After that has happened the same thing can be done by dragging the mouse, until a new window is focused.

This did not happen in 9.2.1

My dotfiles can be found here: https://github.com/thezoq2/dotfiles

[msteen]

I just checked the differences made between those two versions: https://github.com/baskerville/bspwm/compare/0482a74ceb9ebac35039696d52a31e547eec0aa0...835ab36709c9793859e48f0c715b923a7d4de6c0

@baskerville You would know best, but from what I can see the most likely candidates for the regression is either the removal of these snippets:

if (focus_follows_pointer) {
  listen_enter_notify(root, true_or_false)
}

Or maybe the way buttons are grabbed in void grab_buttons(void).

Most changes are additional features, which seem unlikely to be the cause.

[TheZoq2]

After doing some more testing, I have noticed that the windows are not reveiving the touch input. Sometimes it works but most of the time the only thing that the touch screen does is move windows around

[msteen]

@TheZoq2 You are sure it is the update of bspwm that causes the problem? If you updated bspwm along with other software it might be caused by something else (drivers?). If so, maybe check xev or xinput to see whether the touch events are registered properly independent of the window manager. I am curious, could you try bspc config click_to_focus any, maybe that solves your problem. Of course that would be a workaround to the real issue, but still, it would give you solution in the meantime and it would probably make it easier to pinpoint the bug.

[TheZoq2]

Yes, im sure it is caused by the bspwm update because reverting just that package fixes the problems. I will try click to focus and see if it makes a difference.

[TheZoq2]

Ok. bspc config click_to_focus any did not make a difference.

xev produces some events on tap but it doesn't look like it produces any events on drag, do events caught by bspwm or sxhkd get reported by xev?

Edit, I checked in 9.2.1 and it seems like xev receives more events there. Do I have to give it any special flags to check if they get registered independent of the WM?

[msteen]

I am quite sure you should always see the events regardless of how they are handled using e.g. xev -root, but I have very limited experience with this, so I could very well be wrong. But if downgrading bspwm fixes the issue, the problem has to lie there, not with whether the events are produced correctly at the lower level.

[msteen]

One potential cause of your issue might be the following. If you look at the enter notify event handler of version 0.9.2, it also does a focus node under certain conditions, while the latest does not.

Another might be a missing call to grab_buttons. If you look at the setup code it does call it, but in the latest it does not.

That is all I can think of. I am not familiar enough with the codebase to know for sure. You will have to wait for @baskerville to take a look to know for sure.

[baskerville]

Another might be a missing call to grab_buttons. If you look at the setup code it does call it, but in the latest it does not.

This is intentional and comes from 01e4116fdaddbc86526e0e2092847ca0114cc827.

[msteen]

If not that specific call to grab_buttons, could it not be something else within 01e4116 that causes the regression? It is just that in seems the most likely to me that either one of those changes since version 0.9.2 is the cause of this regression, since it it seems to me that they are the only relevant changes to mouse / touch input.

[TheZoq2]

It looks like this issue was caused by the following lines in my .sxhkdrc

#Mouse stuff
# start move/resize
super + button{1-3}
    ; bspc pointer -g {move,resize_side,resize_corner}

# end move/resize
super + @button{1-3}
    bspc pointer -u

I'm not sure why they have the effect that they do, but it appears as if bspc pointer -g and -u are not the way thigns are done anymore which I assume has something to do with it

[TheZoq2]

Scratch that, tie issue is still present. I'm not sure how I got it working yesterday because its broken again now.

It looks like touch input works fine if there is only one window in a workspace, or if the window being touched is already focused. But when a window that is not focused is touched and dragged to another window, it moves there instead of getting input. It is also very hard to focus a window by taping it.

Edit: It looks like setting the value of pointer_action1 to none prevents windows from being moved, however, that allows me to sometimes resize them instead. Setting all the pointer_action variables to none fixes that as well, but it still resizes the windows by tiny steps if I spam tap them. Focus still requires several taps.

Dragging at the border between two windows also resizes them. Sometimes dragging next to the border also resizes them

[TheZoq2]

This problem seems to have got even worse in bspwm 0.9.4-1. It seems like touch events barley get sent to the windows at all, I have to tap 3 or 4 times every time I want to "click" something. Downgrading to 0.9.3-2 reverts the behaviour to what is reported here