On Tue, Apr 07, 2015 at 01:19:24PM +1000, Peter Hutterer wrote: > On Fri, Mar 27, 2015 at 10:23:43AM +0800, Jonas Ådahl wrote:
<snip> > > > > Follow up questions: > > > > Do we expect to get axis_stop on both the horizontal and vertical axes, > > and is the client supposed to trigger its kinetic scrolling when both > > axises has stopped or just the first one? How would one interpret only > > one axis receiving the stop event but not the other? > > I'm not sure here tbh. I think it'd be good enough to say that this affects > all scroll directions currently active, but that's based on a couple of > conditions: > * the case of kinetic scrolling on two devices independently is a niche case > we don't care about. that's easy Yea that sounds a bit unusual. One touchpad for each hand, one for horizontal and one for vertical movements? :P > * we only have scroll axes so far, if we add unrelated axes to the > wl_pointer.axes set this gets a bit hairy. e.g. does a kinetic scrolling > stop affect a future rotation axis? > the solution here could be to add flags to the stop event to specify the > axes that stopped scrolling. Given what you said above (axis_stop affecting all scroll directions), it'd mean it'd have to be an array, since we otherwise would need two axis_stop events to get an atomic end event. Or say "any axis_stop on a "scroll" axis stops the other one as well. > > > Will we ever send axis_stop when the source is 'continuous' (or any > > other possibe source), and how to determine what source had its movement > > stopped in that case? With the current version, "axis_stop" is rather > > hard coded to "axis_finger_lifted" behind a generic name (which maybe is > > not that bad anyway though). > > I'll have to double check the code but iirc we send axis stop events in > libinput for some continuous scrolling. e.g. trackstick middle button > scrolling - releasing the middle button sends the scroll termination event. > we don't have a pre-notification in libinput though, so you won't know until > you get that stop event that you will get one. That's fixable but whether > it's needed is another matter: if you get it you'll get it fast enough to > trigger kinetics, otherwise you time out (and the stop event may come in > after the timeout). True, I suppose there is no usefulness with a warning. > > the axis_source is still prefixed to the axis_stop event, but that doesn't > scale if you have to independent scroll devices that use the same type. > Again, a question of whether that's required, if so we could assign some > sort of tracking ID to the scroll sequence like the touch sequences > have. Sounds a bit complex. If it ever turns out it is needed, that could be made into a separate extension IMHO. > > > > > > > + </event> > > > > > + > > > > > + <event name="axis_discrete" since="5"> > > > > > + <description summary="axis click event"> > > > > > + Scroll and other axis discrete step information. > > > > > + > > > > > + This event does not occur on its own. It is sent before a > > > > > + wl_pointer.axis event and carries the axis value of the > > > > > + wl_pointer.axis event in discrete steps (e.g. mouse wheel > > > > > clicks). > > > > > + > > > > > + This event is optional, continuous scrolling devices > > > > > + like two-finger scrolling on touchpads do not have discrete > > > > > + steps. > > > > > > > > Hmm. This means we wouldn't be able to convert the touch based scroll > > > > motions into the old scroll step clicks, since we wouldn't (reliably) > > > > know when a device would emit their own, since it doesn't specify > > > > exactly when to expect and not to expect. The client won't know whether > > > > there are "continuous scrolling devices" or not. > > > > > > > > Wouldn't it be easier to just provide XI2 style smooth scroll vectors, > > > > i.e. steps in "discrete scale", where a mouse scroll click is -1.0 or > > > > 1.0 and continuous scrolling is a fraction of such. Clients implementing > > > > version 5 can simply use the accumulation method for emitting scroll > > > > clicks without having to rely on the old "divide by 10" hack. > > > > > > > > This event is actually more like what I described in my previous mail > > > > that were more or less concluded to be not worth it, isn't it? > > > > > > the wl_pointer.axis documentation defines the axis events to be in the > > > same > > > coordinate space as motion data, there is nothing accommodating for mouse > > > wheel clicks. it's just magic knowledge with the value 10. > > > Adding this event set removes that magic knowledge, if you get an > > > axis_discrete event you can safely ignore the axis value and just scroll > > > by > > > the discrete value. > > > > > > I don't think the two should be merged into the same coordinate space. > > > It'd > > > be easier but also more error-prone. For example, on a touchpad you > > > probably > > > want scrolling to move at the same speed as the cursor would otherwise so > > > the content follows the finger (this is a lot more obvious when natural > > > scrolling is enabled). But a click is a click and maps to say 3 lines, or > > > a > > > page, or whatever in the context. They are physically two different > > > coordinate spaces, I don't think merging them will help. > > > > > > So I think of this less as "add continuous sources" because that's what > > > the > > > protocol already is. I think of it as adding wheel click information for > > > when a continuous space isn't right. Does that make sense or did I miss > > > the > > > point? > > > > I didn't say we should merge the coordinate spaces, but rather make > > axis_discrete value a wl_fixed_t value in discrete coordinate space. We > > cannot change wl_pointer.axis and doing so would loose information which > > is bad. The problem is that clients often still need to continue emulate > > "clicks" for all type of scrolling methods including touch scroll, and > > since the current proposal of wl_pointer.axis_discrete is only sent for > > actual scroll clicks, that situation isn't improved at all. We still > > need the magic / 10 in the clients, except now with an extra if (source > > != wheel). We'd also not get rid of the XI2 smooth scroll scaling in > > clients. > > > > Or are you saying we should keep the scroll click and XI2 smooth scroll > > emulation where they are now? > > tbh, I'm not a big fan of sending things we don't have. if a client needs to > convert a continuous space into discrete clicks, IMO it should do on its > own terms. changing to a wl_fixed_t as data type is no problem, but sending > discrete values for e.g. two-finger scrolling isn't ideal. I think changing the data type is pretty pointless if it'd only ever emit integer values. The only reason for making it wl_fixed_t would be to have the compositor emulate discrete scroll events in the same way as it is done in X today. Without it we still need to have clients do their own emulation. Jonas _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
