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