Kinetic scroll in libinput Xorg driver

Tue Oct 25 12:14:47 UTC 2016

On the 25.10.2016 13:08, Peter Hutterer wrote:
> On 25/10/2016 18:48 , Alexis BRENON @Wayland wrote:
>> Hi Peter,
>>
>> Thanks for the feedback.
>>
>> I really understand the rationales behind this choice nevertheless, it
>> comes with some drawbacks...
>>
>> You say that the kinetic scroll must be implemented by toolkits and
>> applications, this implies to choose at which level? Desktop
>> Environment, Window Manager, End-User Application.
>
> in the wayland protocol, the axis sources are implemented in a similar 
> way, enabling the end-user application (or rather, the toolkit) to do 
> kinetic scrolling. In the end it's the only one that can do it, 
> nothing else has the semantic context required.
>
>>   * In the case of DE, what about users not using one?
>
> ok, this will be unpopular with the internets, but the times of "I 
> don't want to have a DE" are over. yes, you can still do it. you can 
> run scripts in xinit to set up things, but the vast majority of users 
> will need to/want to have a DE running that takes care of things 
> dynamically. Hardware has moved on since the 80s, so has the 
> functionality we've come to expect. It's not enough anymore to throw a 
> few pieces of metal on the ground and say "here's your car". you can 
> still do it, but you're now talking about a tiny subset of users that 
> want things that way.
>
> so the case of no DE is niche in X, and effectively non-existent in 
> wayland (because you *need* a compositor).
>
>>   * In the case of End-User Application, the user will have to define
>>     his friction factor in each one, each using a different
>>     implementation leading to inconsistent behavior... Moreover, it will
>>     be a feature not directly related to the app, and I fear that some
>>     (if not most) will not implement it at all...
>
> then complain to the app. just because we could force it onto apps in 
> libinput doesn't mean we should. especially given all the other 
> drawbacks.
>
>>   * Finally, my window manager is not ready to change to Wayland
>>     (http://www.mail-archive.com/awesome@naquadah.org/msg05058.html),
>>     and so is far from implementing features lacking from Wayland 
>> drivers.
>
> again, a rather unpopular opinion but: change window managers. or 
> stick with synaptics, or maintain a patchset on top of 
> libinput/xf86-input-libinput (as you pointed out below). I understand 
> why awesome can't switch (manpower is the main issue, I guess) but the 
> same applies for us having to maintain features we think are a bad 
> design decision.
>
> sorry, I don't have any happier solutions for you there. In case of 
> emergency, I've heard there are kitten videos on youtube though ;)
>
>> Well, that said, I'm a real newbie about Wayland, libinput and Weston
>> (that I just discovered yesterday). So I think that this question was
>> already debated. If this is the case I'm really interested to see the
>> thread (I didn't find it in the archive).
>
> it's been coming up repeatedly, but I'm not sure there's a single 
> thread that I can point you to, sorry.
>
> Cheers,
>   Peter
>
>
Similar points were discussed in relation with libinput in the following 
threads for example:
[1.] Ignore devices that have joystick buttons; started 25.Nov.2014
[2.] Using Soft Keys with Weston & Libinput; started 04.Feb.2016.

The support for such kinetic UI functions and the support of other 
hardware such as gamepads and joysticks will come, definitely. But here 
on my side, we are not at the point of implementing something at this time.

Actually, my recommendation so far is to look at e.g. SDL, as discussed 
very briefly in [2.] and follow Peter's advices here and there. This 
might lead to the investment of some time at first at your side, but in 
the long term it is the best way to go.

Best regards
Christian Stroetmann

>
>>
>> Finally, I will probably implement the kinetic scrolling for myself. If
>> someone else is interested, let me know.
>>
>> Kind,
>> Alexis
>>
>>
>> Le mar. 25 oct. 2016 02:31, Peter Hutterer <peter.hutterer at who-t.net
>> <mailto:peter.hutterer at who-t.net>> a écrit :
>>
>>     On Mon, Oct 24, 2016 at 06:42:31PM +0000, Alexis BRENON @Wayland 
>> wrote:
>> > Hello everyone,
>> >
>> > I would like to implement kinetic scroll in the libinput driver
>>     for Xorg.
>> >
>> > I know that it's probably not the intended use of libinput ; as
>>     explained
>> > in the documentation, it's the client that have to manage that.
>> >
>> > However, as an Xorg user not happy with the synaptics driver, I
>>     would like
>> > to add a similar feature (fixing small disagreements encountered with
>> > synaptics) to libinput, allowing Xorg users to easily move to libinput
>> > without losing this feature.
>> >
>> > My first idea is to implement the kinetic scroll using a thread
>>     that sends
>> > axis events as long as there is no button event, key event or
>>     motion event
>> > higher than a threshold.
>> >
>> > It makes some time since the last time I developed in C, and maybe
>>     it's not
>> > the better way to do it. I would be happy to hear your advices.
>> >
>> > One thing I'm thinking of is then to add some options in the Xorg
>> > configuration file to enable/disable this feature, choose the events
>> > stopping the kinetic scroll and change some thresholds. This will
>>     allow to
>> > easily disable this feature in the future in case the clients
>>     manage the
>> > kinetic scroll on their own.
>> >
>> > What do you think of this? Is there someone already working on it?
>>     Is my
>> > proposition a good way to implement it?
>>
>>     simple answer - "no". sorry :)
>>
>>     there are two reasons we didn't implement kinetic scrolling in
>>     libinput. one
>>     is the series of bugs we have in synaptics with stopping scrolling
>>     at the
>>     right time (leading to inadvertent zooms, etc.). that's easier in
>>     libinput
>>     because we know about all devices but the fundamental problem
>>     remains - a
>>     driver cannot know when kinetic scrolling is appropriate. e.g. 
>> sending
>>     scroll events when the document is already at the bottom? What's the
>>     threshold going to be? A single pixel movement may land you in 
>> another
>>     window that you don't want to send scroll events to. A two-pixel
>>     movement
>>     may be considered acceptable to not stop scroll events.
>>     A shift+scroll may be acceptable in one application but not in 
>> another.
>>
>>     Pushing this to the toolkits and applications is the only sane 
>> long-term
>>     solution. Anything else gives us a short-term solution that in 
>> two-three
>>     years time we'll just waste time having to working around.
>>
>>     Cheers,
>>        Peter
>>
>