swipe.settings seemingly ignored

[haarp]

Hello,

I'm currently testing gebaar, with the intent of having it replace libinput-gestures. I'm going to write an Gentoo ebuild for it later.

Right now I'm running into weird effects. My config looks like this:

[swipe.commands.three]
up = "xdotool key control+t"
down = "xdotool key control+w"
left = "xdotool click 8"
right = "xdotool click 9"
left_down = ""
right_down = ""
left_up = ""
right_up = ""

[swipe.commands.four]
up = ""
down = ""
left = ""
right = ""
left_down = ""
right_down = ""
left_up = ""
right_up = ""

[swipe.settings]
threshold = 5.0
one_shot = true
trigger_on_release = false

[pinch.commands]
in = ""
out = ""

[pinch.settings]
threshold = 0.25
one_shot = false

swipe.commands.three is picked up by gebaard. swipe.settings however appears to not be. The actual threshold is close to 0, meaning the tiniest movement with three fingers in any direction triggers the corresponding event. I've tried increasing the threshold as high as 5000 with no difference whatsoever. Similarly, toggling one_shot to false does not allow repeated events, nor does trigger_on_release=true actually trigger on release. It seems this section of the config is simply ignored.

Any ideas? Thanks!

[haarp]

It gets weirder. Not even changing the settings.swipe.* value_or() parameters in config/config.cpp and commenting them in the config instead seems to have any influence on swipe behavior whatsoever.

This is with libinput-1.14.3 on kernel 5.4.6

[osleg]

This is indeed weird, are you sure your config file is in correct location and being read by the deamon? It feels like it doesn't able to read config file.

[haarp]

are you sure your config file is in correct location and being read by the deamon?

Yes, it is using the correct commands for the swipes, which can only come from the config.

[osleg]

Here is my config file for example

[swipe.commands.three]
up = "xdotool key Control_L+F10"
down = "xdotool key Alt_L+Tab"
right = "xdotool key Alt_L+Left"
left = "xdotool key Alt_L+Right"

#[swipe.commands.four]
#up = "amixer set Master 5%+"
#down = "amixer set Master 5%-"

[pinch.commands.two]
out = "xdotool key Control_L+equal"
in = "xdotool key Control_L+minus"

[pinch.commands.rotate]
right = "xdotool key XF86AudioRaiseVolume"
left = "xdotool key XF86AudioLowerVolume"

[pinch.settings]
threshold = 0.25
one_shot = false

[swipe.settings]
threshold = 0.1
one_shot = true
trigger_on_release = false

[haarp]

I think something else is going on that none of the swipe settings have an effect.

[iwismer]

I also have this issue, but the upstream build of gebaar works for some reason. It must be something that has changed in the repo. If there are any logs or anything that would be helpful to solve this, just ask.

[haarp]

After two years I managed to have another look at this bug. @iwismer pointed me i nthe right direction and with a git bisect I identified 068a4c0 as the cause of this bug. The commit too big for me to figure out. It's possible that it's not a config parsing bug after all, but something in the swipe logic.

[osleg]

@haarp I can't test anything as I don't have linux anywhere but I can help you with that commit you pasted.
It actually has very little changes it only looks big because of formatting.

The only real change happened here:

068a4c0#diff-819af9a6c978bce40372813c8b356818d71ccf0e1c7c5c7e1314315a2ab34a74R156

Which changes the thresholds calculation

I also added

#define SWIPE_X_THRESHOLD       1000
#define SWIPE_Y_THRESHOLD       500

to header as well.

This change basically just mulitplies values from the settings

The rest of the changes are just cosmetics.

Also, IIRC, the value of settings should be 0.0 >= 1.0

[haarp]

Thanks. Still trying to figure out what is going on. The interaction between trigger_on_release and threshold is very weird. With 068a4c0 reverted and t_o_r set to true, swipes trigger either:
a) Always without releasing after a long swipe (proportional to the threshold value)
b) On release after swiping any distance.
And theshold can be >1.0 too.

Disabling t_o_r simply removes b).

I'm going to see if I can fix 068a40.

[osleg]

How it was:

     int threshold = config->settings.swipe_threshold * 100;

threshold was multiplied by 100 to convert it to higher value

    gesture_swipe_event.x += libinput_event_gesture_get_dx(gev);
    gesture_swipe_event.y += libinput_event_gesture_get_dy(gev);

Get the distance gesture traveled with acceleration counted in

    if (abs(gesture_swipe_event.x) > threshold || abs(gesture_swipe_event.y) > threshold) {
       trigger_swipe_command();
       gesture_swipe_event.executed = true;
    }

Trigger

That caused to have an issue with continuous swipe which would cause threshold to appear higer than expected because of acceleration

So the change introduced 2 multipliers for x and y separately and getting un-accelerated distance travelled

and added the inc_step in the trigger.

I say it could be the issue with the maths.

And threshold >1 doesn't make sense in this commit as 5*1000 would yield 5k when an average touchpad has about 3-5k....