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. Kind, Alexis. 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
