On Thu, Jun 04, 2015 at 01:49:26PM +0800, Jonas Ådahl wrote: > On Thu, Jun 04, 2015 at 03:28:15PM +1000, Peter Hutterer wrote: > > On Thu, Jun 04, 2015 at 01:09:06PM +0800, Jonas Ådahl wrote: > > > On Thu, Jun 04, 2015 at 02:41:52PM +1000, Peter Hutterer wrote: > > > > To group separate vertical/horizontal scroll events together. Likewise > > > > it > > > > enables axis_stop events to be grouped so that the final vector for > > > > kinetic > > > > scrolling may be calculated correctly. > > > > > > > > Multiple scroll sources within the same frame is not expected, but the > > > > protocol allows this use-case, i.e. axis_frame events are not > > > > deliniators for > > > > axis_source switches. > > > > > > What is the intended use case for mixing sources within the same > > > sequence? How would it ever be possible to trigger, given that different > > > sources will, by the fact that they come from different places, never > > > come at the same time? If we disallow it, we can make the semantics > > > slighty simpler by saying that wl_pointer.axis_frame is always the > > > "committing" event for all axis state, instead of the current proposal > > > which is "axis_stop and axis, or just axis" depending on what event. > > > > > > It is also a bit unclear how much sense it makes to have interpret a > > > motion vector that contains both mouse wheel scroll distance and the > > > touchpad scroll distance. They don't really logically belong together in > > > any way I can think of. > > > > not with the current sources, but the future case I mentioned in the other > > email of thumb vs finger could trigger this. I'm not exactly sure _how_ yet > > though, mainly since we don't have touchpads that could reliably detect > > thumbs, at least not widespread enough. > > > > That said even then it's arguably better to separate them by frames so I'm > > not going to fight this too hard. Having a single source per frame would > > simplify things and cut the number of events down, though realistically > > probably not by as much as the frame adds in the first place :) > > Not sure how I should interpret finger and thumb scroll "grouped > logically" either. Also since the as well come at different places > (anatomically) and thus different point in times (as long as I don't move > my thumb and finger during the same millisecond, whey will always come > separately anyway. Or would a thumb AND finger have both sources, but > emit separate events that originated from some algorithm using both as > input?
yeah, this is mostly where my fantasy starts giving in too, I honestly don't know how to trigger this with the technology we have atm. Maybe a finger+thumb pinch gesture? then again, if we strain to find a current use-case it's better to ignore this for now and add to the protocol later when we need to. Cheers, Peter _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
