4 ms·

Worth mentioning that before libinput, the synapse driver handled kinetic scroll very well IMO, but AIU the developers removed the device-specific coefficients

Worth mentioning that before libinput, the synapse driver handled kinetic scroll very well IMO, but AIU the developers removed the device-specific coefficients and other parameters because they said it couldn't be tested and became a mess or something. I remember looking at my Linux (Wayland, gnome3) notebook in anticipation of physical pain, at which point I switched to Mac OS permanently. To this date, I still don't understand why Linux desktop developers had to throw everything away and valued their grand refactorings more than a working desktop, especially when absolutely no new desktop apps are being developed anyway, but I guess that's what you get with a "hobby" (= developer motivation rather than demand driven) OS after all.

sandreas 3y ago
While is may be true from a user perspective, this "kinetic scrolling simulation" was removed, because it could lead to unexpected behaviour. Example: If you where scrolling in a window, the driver kept sending scroll events for a short time to simulate kinetic scrolling. Now, if you moved the cursor to another window, the other window started scrolling, because of the simulated events. This is not the case on macOS. Changing window focus doesn't change the scrolling. So, while working from a user perspective (in my opionion this would have been better, than NO kinetic scrolling at all), technically, it is a bug / unsolvable behaviour :-), because this problem cannot be solved on the driver level - there is no reference to the current focussed "window" / active element. That's probably the reason why they thought: This must be solved at App level, which was the worst decision they could make. Putting the effort on the shoulders of App developers instead of solving it at one place leads to so much wasted developer time, that could have been put into new features or solved issues. I was shocked about how nobody seemed to notice that. However, they are not "hobby" at all. Peter Hutterer is awesome and he understands the problem very well - but as a single developer it's hard to convince a whole community, that partly does not even (want to) understand the problem. And he's responsible for libinput, not for the compositors - so it's clearly not his fault. I think the problem lies in separated responsibilities. They are trying to keep the projects (driver, compositor, window manager) separated / independent, but in this case, the problem is spanning the whole stack.
- jmole 3y ago
  > Now, if you moved the cursor to another window, the other window started scrolling, because of the simulated events. This is such a trivial thing to fix, you just stop sending scroll events when the cursor moves. 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).
  - sandreas 3y ago
    > 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.
    - jmole 3y 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.
    - crotchfire 3y 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.

sandreas 3y ago

While is may be true from a user perspective, this "kinetic scrolling simulation" was removed, because it could lead to unexpected behaviour. Example: If you where scrolling in a window, the driver kept sending scroll events for a short time to simulate kinetic scrolling. Now, if you moved the cursor to another window, the other window started scrolling, because of the simulated events. This is not the case on macOS. Changing window focus doesn't change the scrolling. So, while working from a user perspective (in my opionion this would have been better, than NO kinetic scrolling at all), technically, it is a bug / unsolvable behaviour :-), because this problem cannot be solved on the driver level - there is no reference to the current focussed "window" / active element. That's probably the reason why they thought: This must be solved at App level, which was the worst decision they could make. Putting the effort on the shoulders of App developers instead of solving it at one place leads to so much wasted developer time, that could have been put into new features or solved issues. I was shocked about how nobody seemed to notice that. However, they are not "hobby" at all. Peter Hutterer is awesome and he understands the problem very well - but as a single developer it's hard to convince a whole community, that partly does not even (want to) understand the problem. And he's responsible for libinput, not for the compositors - so it's clearly not his fault. I think the problem lies in separated responsibilities. They are trying to keep the projects (driver, compositor, window manager) separated / independent, but in this case, the problem is spanning the whole stack.

jmole 3y ago
> Now, if you moved the cursor to another window, the other window started scrolling, because of the simulated events. This is such a trivial thing to fix, you just stop sending scroll events when the cursor moves. 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).
- sandreas 3y ago
  > 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.
  - jmole 3y 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.
  - crotchfire 3y 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.