On Tue, Oct 25, 2016 at 07:17:33PM +0000, Alexis BRENON @Wayland wrote: > Hello everyone, > > Thanks for the feedbacks! > > @christian: Thanks for the links, I'll give them a look. > > @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... > > 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.
I don't think this would help much. Adding a new source means we need it supported on the client side by toolkits. And at that point you might as well get proper kinetic scrolling implemented there. Cheers, Peter > Le mar. 25 oct. 2016 à 19:48, Bill Spitzak <[email protected]> a écrit : > > > On Mon, Oct 24, 2016 at 5:31 PM, Peter Hutterer > > <[email protected]> wrote: > > > 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? How about *normal* scroll events. Seems to be no problem with > > sending them "when the document is at the bottom". Amazingly the > > client apps have logic and are able to ignore these events! Will > > wonders never cease! > > > > > 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. > > > > What? Can you give an example of an api where scrolling that is > > accepted by a client can also cause the focus to change? Also it sure > > seems like if scrolling can change the focus then the compositor > > better be well aware of the events. Of course if "kinetic scrolling" > > should not change the focus, but "normal scrolling" does, this is > > trivially solved by making these be different events. > > > > ? 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. > > > > All of these are good reasons for libinput to do it. Then there is > > consistent behavior between clients, rather than every toolkit and > > client doing it's own thing. > > > > > 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. > > > > The solution to all your objections is trivial: make the kinetic > > scroll events distinguishable from the normal scroll events. Then if a > > client really can't deal with the kinetic scrolling supplied by > > libinput, it can ignore these events and do it itself. > > _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
