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.
> 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;
2. Users only want to get the raw values. So, these axes will post raw
values instead of scroll events.
> I think this covers all cases but if you have more, please let me know.
>
Let me know if I've missed the point.
Ping
------------------------------------------------------------------------------
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
