On Wed, Aug 17, 2011 at 09:52:41PM -0700, Ping Cheng wrote: > On Wed, Aug 17, 2011 at 12:53 AM, Peter Hutterer > <[email protected]>wrote: > > > In case you're not following the discussion on the xorg-devel list, a short > > summary from the thread here: > > http://lists.freedesktop.org/archives/xorg-devel/2011-August/024394.html > > and particulary the last one in this thread here: > > http://lists.freedesktop.org/archives/xorg-devel/2011-August/024474.html > > > > XI 2.1 will include a new feature called "smooth scrolling". In the past > > scrolling in X was emulated through logical button clicks 4-7. with this > > change, scrolling information is exported through valuators. Axes that > > function as scrolling axes are marked as such. Thus, your average wheel > > mouse will now have three axes: > > Rel X > > Rel Y > > Rel Wheel (XIAxisVertScroll) > > > > And if the wheel triggers an event by 3 units, you you get one motion event > > with value 3 on Rel Wheel. This allows clients to provide a smoother > > scrolling experience than right now. so far, so good. > > > > Since we don't expect all clients to switch to smooth scrolling overnight, > > we will continue to also send button events. These events are flagged with > > XIPointerEmulated, so clients that support smooth scrolling can safely > > ignore these events. For the example above, the wheel turn by 3 will thus > > generate these events: > > XI_Motion: valuator Rel Wheel: 3 > > XI_ButtonPress:5 (XIPointerEmulated) > > XI_ButtonRelease: 5 (XIPointerEmulated) > > XI_ButtonPress: 5 (XIPointerEmulated) > > XI_ButtonRelease: 5 (XIPointerEmulated) > > XI_ButtonPress: 5 (XIPointerEmulated) > > XI_ButtonRelease: 5 (XIPointerEmulated) > > > > So far, so good. > > > > Doing this for the wacom driver i more complicated with the following > > issues > > identified so far: > > > > On a typical scroll wheel, a turn by three units is the equivalent of 3 > > scroll events. On the I4 scroll ring, 3 units are 1 scroll event. The > > solution to this is to expose the step increment to the client so > > they can calculate what comprises one unit of scrolling. > > > I think we can leave it as 3 units if it works fine or rescale it to > something more user friendly (after some testing). I don't see why it is an > issue. Maybe I've missed something.
the three issues mentioned were addressed, in this case by exposing the step increment so that a client that uses smooth scrolling knows that 3 units are one unit of scrolling. without this, it's an issue as the scroll ring would otherwise scroll 3 times as fast/often. To make the original email easier to understand: it was actually written when all three were still unsolved. I just had the necessary ideas while writing it, so I implemented all the fixes and then adjusted the text. So read this as "these issues we found, here's the solution, anything we're missing". > > Problem two was the I4 scroll ring that wraps around and jumps from 71 to > > 0. That too could be solved by an extra axis flag XIAxisWrapAround. Bonus: > > handy for clients to know this if they're dealing with the raw valuator > > information. > > > This is not an issue either, is it? > > > The biggest issue was custom scroll configuration. On a wheel, down is > > down. > > on our strips this isn't as clear-cut and left strip up may mean scroll > > down. If the server emulates button events, it needs to know which buttons > > to emulate for each valuator. This is solved by marking an axis as either > > vertical or horizontal and allowing for a negative increment for axis > > inversion. > > > > So, what else do we need to do for this one? > > > > For complicated mapping (Ctrl+, Ctrl-), we can simply unflag the axis as > > scrolling axis so it isn't interpreted by the clients anymore. > > > There are two cases here, I think. > > 1. Users want to map those wheels/strips to a predefined events, such > as keystrokes. We do not need to post the actual values, i.e., no valuators > are reported. Just emit the keystrokes for them; as I understand, this isn't something we do now. we always post the raw valuators in addition to whatever button/key sequences are assigned. so implementing the above would be a behaviour change. > 2. Users only want to get the raw values. So, these axes will post raw > values instead of scroll events. This cannot work. we have more than one client and a client can't just disable scroll events globally if they don't want them. The new flag means that they know which events are emulated and they can then ignore them. Cheers, Peter ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
