undefined | Better HN

0 pointssandreas2y ago0 comments

> Peter has done a great job on libinput for the most part, but he is 100% wrong about inertial scrolling (and button remapping, among a few other things).

Maybe you're right. However, this should not about individual persons / projects... this is more about that I'm still uncertain, why so many experts cannot get this thing right by just working together finding a suitable solution :-) There must by more than one way of solving this.

I'd argue that he is right about the fact, that the "driver" (libinput) should not send "simulated" events, that are not really there. Whereas the cursor movement should defintely stop the scrolling behaviour, the driver is not the place to care about this, I think it is more a compositor / window manager thing, but I'm not an expert.

However, if he would implement an opt in solution (2 config options) for lets say:

  libinput.simulateKineticScrolling=1
  libinput.kineticScrollingSpeed=0.22

a lot of people would be really happy, but this probably is a really dirty hack.

0 comments

jmole2y ago

> the "driver" (libinput) should not send "simulated" events

scrolling itself is a simulated event. So is any two-finger gesture that isn't directly represented as an affine transform from one pair of coordinates to another.

crotchfire2y ago

that the "driver" (libinput) should not send "simulated" events

As long as they are marked as being synthetic, why not?

If you mark them with a "this is a synthetic event" bit, the compositor/windowmanager has all the information it needs to decide whether or not to ignore the event (because, for example, the pointer moved out of one window and into another).

The driver generates the synthetic events, the compositor/windowmanager decides whether or not to drop them. Done.

j / k navigate · click thread line to collapse