[tannhaeuser]

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]

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]

> 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]

> 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]

> 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]

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.

[MisterKent]

Alt + Tab

[crotchfire]

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

Wait what?

I'm pretty sure Hutterer was the one who pushed it into the App layer. He's the maintainer of libinput, and refused to do kinetic scroll within libinput (like the libsynapse driver did for X11). If he wanted to do it centrally in libinput there's nobody else to block him from doing that -- he can just do it.

[sandreas]

> I'm pretty sure Hutterer was the one who pushed it into the App layer.

I'm not sure what he did and I'm not trying to do fingerpointing. I thought he just pushed it away from libinput stating that it's the wrong place to handle it and wanting to keep libinput as "clean" as possible - even if this might be a questionable argument in this case.

To answer one of your other comments...

> 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).

Yeah, this would be one of the many possible partial solutions. Don't get me wrong, I'm totally fine with this suggestion, but let's think that through:

libinput implements "simulated" events algorithm for intertial scrolling. It also would probably need a config setting for "speed" or "intensity". Nevertheless, this would not help without changes in at least one of the other layers I mentioned (Compositor, Window Manager, Apps) to either ignore or handle these events. In my opinion the App layer is the wrong place, because so every App developer / maintainer who want's to support inertial scrolling had to implement it AGAIN for his personal app which would create a tremendous amount of additional effort and different implementations acting differently. Not a great user experience...

So, the (additional) implementation has to be done somewhere between libinput and the App layer, which means either compositor or window manager.

Now, if an implementation in one of these layers is inevitable to get it working, why should it be implemented in libinput? Issues would spread over two projects, instead of one and getting pushed back and forth. This is of course my personal opinion.

Instead NOBODY implemented it and App developers and Framework Developers (QT, GTK, etc.) put in the effort to workaround this problem. That just feels wrong to me.

I wish at least one project just had shown good will to do it, in my opinion it would have been better to implement it everywhere (with optional disable) instead of nowhere, but I think it's just a too heated topic to solve it easily :-)

[crotchfire]

this would not help without changes in at least one of the other layers I mentioned (Compositor, Window Manager, Apps) to either ignore or handle these events

Yes, certainly. But it's basically one or two lines of code with zero configuration knobs:

    if (ev->is_synthetic && focus_changed_since_last_nonsynthetic) return;

Compare this to the current state of affairs, where every toolkit/compositor/app has to reimplement momentum scrolling on its own. That is multiple pages of fairly tricky code and several configuration knobs -- all of them replicated (differently) in each different thing that sits on top of libinput.

why should it be implemented in libinput?

Because libinput is the "narrow waist" in the input stack.

Doing this in libinput puts all the new configuration knobs, and all but one or two lines of code ("if focus changed then drop") in the one place where they can live without having to be duplicated.

Any higher up the stack and you end up replicating this functionality.

Issues would spread over two projects, instead of one and getting pushed back and forth.

I don't think so. If the problem is that a marked-as-synthetic event is/isn't being dropped when it shouldn't/should, that's the problem of some layer above libinput. Any other problem is libinput's. I know nobody wants to own these problems, but we can't make them disappear -- somebody has to own them. If they are owned at or below the libinput layer we can fix each bug once and be done. If we fix them anywhere above the libinput layer we will end up having the same bugs occur in multiple independent implementations and they will have to get fixed independently.

in my opinion it would have been better to implement it everywhere (with optional disable) instead of nowhere

I don't agree with this either. This "multiple reimplementations of the exact same thing" is becoming entrenched! We could get stuck in this situation, permanently. This isn't a question like "what should a titlebar look like" where different toolkits can legitimately have different opinions about it.

In my opinion the App layer is the wrong place

I agree.

Some part of this has to be done somewhere at-or-above the compositor layer, since those are the only layers that are aware of focus changes. Unfortunately there seems to be no traction for e.g. wayland to require that all compositors do this. So the replication gets amplified even further by pushing it up into every compositor or toolkit. That's why it's so important to limit the size of the bit that gets pushed up the stack to being two lines of code.

Perhaps a viable compromise would be to insert a new layer above libinput. For argument's sake, call it "libgesture" (*). It's responsible for consuming libinput events and emitting synthetic events like momentum scrolling. It would have exactly the same API as libinput, except events would have an additional `is_synthetic` field. I've actually built something similar to this (but at the kernel evdev level) for my own use.

Perhaps that would make everybody happy.

(*) This is unrelated to `libei` -- I have this sinking feeling that many apps (especially chromium) will reject any event that smells "emulated" to them "because muh bots" or something stupid like that. Trying to use libei for this is likely to backfire once the chromium devs decide that "emulated" means "bad for Web Environment Integrity". The indicator for gesture-synthesized events like momentum scrolling really needs to be completely separate from any marker indicating that the event was in any way emulated.*

[sandreas]

Very convincing pitch

> Perhaps a viable compromise would be to insert a new layer above libinput.

Since I think this probably will never get integrated in libinput, this might be the best solution for everyone - also opt in. Unfortunately I don't think anyone is ever gonna implement it in a way that everyone can agree on.

However, if someone would implement patches for libinput as well as e.g. mutter that work flawlessly, are documented and gain acceptance, this would put a lot of pressure on all other projects to integrate this.

If you have such patches and they are open source, you surely would have my support. I would definetely use it...