<div dir="ltr">Hello everyone,<div><br></div><div>Thanks for the feedbacks!</div><div><br></div><div>@christian: Thanks for the links, I'll give them a look.</div><div><br></div><div>@Bill: What Peter says is that there could be some applications that implement special behaviors when you scroll while at the end of the file/context/whatever. Scroll events are sends to the window below the mouse whatever the focus, and so moving the mouse over another window while a kinetic scroll is pending will send scroll events to this new window... Bad behavior...</div><div><br></div><div>Well, maybe using a new scroll source like LIBINPUT_POINTER_AXIS_SOURCE_KINETIC could be a solution. I'm very new to wayland and co. and I'm probably not legitimate to make this kind of choices.</div><div><br></div><div>Kind,<br>Alexis.</div></div><br><div class="gmail_quote"><div dir="ltr">Le mar. 25 oct. 2016 à 19:48, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Oct 24, 2016 at 5:31 PM, Peter Hutterer<br class="gmail_msg">
<<a href="mailto:peter.hutterer@who-t.net" class="gmail_msg" target="_blank">peter.hutterer@who-t.net</a>> wrote:<br class="gmail_msg">
> On Mon, Oct 24, 2016 at 06:42:31PM +0000, Alexis BRENON @Wayland wrote:<br class="gmail_msg">
>> Hello everyone,<br class="gmail_msg">
>><br class="gmail_msg">
>> I would like to implement kinetic scroll in the libinput driver for Xorg.<br class="gmail_msg">
>><br class="gmail_msg">
>> I know that it's probably not the intended use of libinput ; as explained<br class="gmail_msg">
>> in the documentation, it's the client that have to manage that.<br class="gmail_msg">
>><br class="gmail_msg">
>> However, as an Xorg user not happy with the synaptics driver, I would like<br class="gmail_msg">
>> to add a similar feature (fixing small disagreements encountered with<br class="gmail_msg">
>> synaptics) to libinput, allowing Xorg users to easily move to libinput<br class="gmail_msg">
>> without losing this feature.<br class="gmail_msg">
>><br class="gmail_msg">
>> My first idea is to implement the kinetic scroll using a thread that sends<br class="gmail_msg">
>> axis events as long as there is no button event, key event or motion event<br class="gmail_msg">
>> higher than a threshold.<br class="gmail_msg">
>><br class="gmail_msg">
>> It makes some time since the last time I developed in C, and maybe it's not<br class="gmail_msg">
>> the better way to do it. I would be happy to hear your advices.<br class="gmail_msg">
>><br class="gmail_msg">
>> One thing I'm thinking of is then to add some options in the Xorg<br class="gmail_msg">
>> configuration file to enable/disable this feature, choose the events<br class="gmail_msg">
>> stopping the kinetic scroll and change some thresholds. This will allow to<br class="gmail_msg">
>> easily disable this feature in the future in case the clients manage the<br class="gmail_msg">
>> kinetic scroll on their own.<br class="gmail_msg">
>><br class="gmail_msg">
>> What do you think of this? Is there someone already working on it? Is my<br class="gmail_msg">
>> proposition a good way to implement it?<br class="gmail_msg">
><br class="gmail_msg">
> simple answer - "no". sorry :)<br class="gmail_msg">
><br class="gmail_msg">
> there are two reasons we didn't implement kinetic scrolling in libinput. one<br class="gmail_msg">
> is the series of bugs we have in synaptics with stopping scrolling at the<br class="gmail_msg">
> right time (leading to inadvertent zooms, etc.). that's easier in libinput<br class="gmail_msg">
> because we know about all devices but the fundamental problem remains - a<br class="gmail_msg">
> driver cannot know when kinetic scrolling is appropriate. e.g. sending<br class="gmail_msg">
> scroll events when the document is already at the bottom?<br class="gmail_msg">
<br class="gmail_msg">
What? How about *normal* scroll events. Seems to be no problem with<br class="gmail_msg">
sending them "when the document is at the bottom". Amazingly the<br class="gmail_msg">
client apps have logic and are able to ignore these events! Will<br class="gmail_msg">
wonders never cease!<br class="gmail_msg">
<br class="gmail_msg">
> What's the<br class="gmail_msg">
> threshold going to be? A single pixel movement may land you in another<br class="gmail_msg">
> window that you don't want to send scroll events to.<br class="gmail_msg">
<br class="gmail_msg">
What? Can you give an example of an api where scrolling that is<br class="gmail_msg">
accepted by a client can also cause the focus to change? Also it sure<br class="gmail_msg">
seems like if scrolling can change the focus then the compositor<br class="gmail_msg">
better be well aware of the events. Of course if "kinetic scrolling"<br class="gmail_msg">
should not change the focus, but "normal scrolling" does, this is<br class="gmail_msg">
trivially solved by making these be different events.<br class="gmail_msg">
<br class="gmail_msg">
? A two-pixel movement<br class="gmail_msg">
> may be considered acceptable to not stop scroll events.<br class="gmail_msg">
> A shift+scroll may be acceptable in one application but not in another.<br class="gmail_msg">
<br class="gmail_msg">
All of these are good reasons for libinput to do it. Then there is<br class="gmail_msg">
consistent behavior between clients, rather than every toolkit and<br class="gmail_msg">
client doing it's own thing.<br class="gmail_msg">
<br class="gmail_msg">
> Pushing this to the toolkits and applications is the only sane long-term<br class="gmail_msg">
> solution. Anything else gives us a short-term solution that in two-three<br class="gmail_msg">
> years time we'll just waste time having to working around.<br class="gmail_msg">
<br class="gmail_msg">
The solution to all your objections is trivial: make the kinetic<br class="gmail_msg">
scroll events distinguishable from the normal scroll events. Then if a<br class="gmail_msg">
client really can't deal with the kinetic scrolling supplied by<br class="gmail_msg">
libinput, it can ignore these events and do it itself.<br class="gmail_msg">
</blockquote></div>