Move libinput device reporting corrections down into kernel where possible.
https://who-t.blogspot.com/2018/07/why-its-not-good-idea-to-handle-evdev.html I read this and it most reads do not use evdev because its broken and we in libinput are working around the defects.
As you're happily processing your deltas, you notice that on some touchpads you get motion before you touch the touchpad. Ooops, we need a way to tell whether a finger is down. Luckily the kernel gives you BTN_TOUCH for that event, so you switch your implementation to only calculate deltas when BTN_TOUCH is set. But then you realise that is effectively a hardcoded threshold in the kernel and does not match a lot of devices. Some devices require too-hard finger pressure to trigger BTN_TOUCH, others send it on super-light pressure or even while hovering .
This is 100 percent a bug. Hard coded value that is wrong.
After grinding some enamel away you find that many touchpads give you ABS_PRESSURE. Awesome, let's make touches pressure-based instead. Let's use a threshold, no, I mean a device-specific threshold (because if two touchpads would be the same the universe will stop doing whatever a universe does, I clearly haven't thought this through). Luckily we already have the device database so we just add the thresholds there.
This is 100 percent a bug as well. Yes even two touchpads same model can give you different ABS_PRESSURE for the same force. So general device database kind of works but does not work perfectly. You need a per device fix. Both lead to lack of configuration at kernel level.
Like we don't want to add a driver per device to the kernel for every touchpad/input device in existence.
https://lwn.net/Articles/747551/ With bpfilter being done for networking. There is not reason why edev could not have a ebpf support. The ability to correction ebpf on to input device would allow a lot of input correction to be done kernel side.
Why do we want correction done kernel side. You have a flatpak/snap shipped program with a old version of libinput that does not support you hardware. At this point with current design you in trouble.
If the corrections can be made like ebpf upload on input devices the userspace library does not need to be doing device corrections.
All this is just handling features that users have come to expect. Examples for non-features that you'll have to implement: on some Lenovo series (*50 and newer) you will get a pointer jump after a series of of events that only have pressure information. You'll have to detect and discard that jump. The HP Pavilion DM4 touchpad has random jumps in the slot data. Synaptics PS/2 touchpads may 'randomly' end touches and restart them on the next event frame 10ms later. If you don't handle that you'll get ghost taps. And so on and so forth.
This read to me like network noise that you use in networking firewalling to clean up. This is why I am looking at bpfilter. Devices with these issue you upload a ebpf correction program on and then programs in userspace would not have to correct this stuff.
Really I do suspect you have been fixing these faults at the wrong level. Before ebpf in kernel where you would have had to make a driver per device to fix correcting in userspace made sense. Now that we have the possibility of ebpf in kernel space and upload device corrections this could be a path to follow.
This is something that if it is a path to follow with take quite some time to get into production.
My point of view is Linux is a monolithic kernel. A monolithic kernel hardware issues are meant to be handled by the kernel.
Maybe extending evdev to supporting filtering and correction the need for libinput over time might go away.