On Thu, Mar 24, 2011 at 11:30:35AM +1000, Peter Hutterer wrote:
> On Wed, Mar 23, 2011 at 12:58:21PM -0700, Jason Gerecke wrote:
> > As I'm working on the X11 wheel mapping, I'm finding a few weird
> > quirks in the code. I pretty much understand 'how' things work, but
> > I'm not sure why some things are the way they are...
> > 
> > 1. Why does WACOM_PROP_BUTTON_ACTIONS have room for only 16 buttons,
> > yet priv->btn_actions (storing the same data) have space for 32? The
> > functional difference between WCM_MAX_BUTTONS and
> > WCM_MAX_MOUSE_BUTTONS is not clear.
> 
> 7d149431c63c43c0ab5b046387b565488ea3d159 has some explanation what
> WCM_MAX_BUTTONS is, but I can't remember any more details.
> They were introduced in 2debfce6f9d6bfb206da2e1711d04f42cddd71e1, but
> the comments in that commit don't really clarify things for me.
> 
> > 2. Why maintain a seperate raw button codepath when the "actions"
> > codepath already does the same thing when given a 'button' action?
> 
> simplicity mainly (and the raw path was there before). note that the button
> action can be combined with a key action, so "key +ctrl button 1 key -ctrl"
> is a valid action.
> 
> > 3. Why does xsetwacom take X11 buttons as the first argument to
> > "Button X"? I can't be alone in thinking it was weird my cintiq was
> > missing two buttons (6 & 7) and that two other buttons (4 & 5) only
> > responded to changes via the Strip(Left|Right)(Up|Down) command.
> 
> This should be documented better. Button mapping in X is complicated to say
> the least. http://who-t.blogspot.com/2009/06/button-mapping-in-x.html
> 
> xsetwacom takes x11 buttons because for simple button mappings, it uses
> XSetDeviceButtonMappings (which requires X buttons).
> X buttons have the advantage of being easy to debug (for users). A
> driver-internal button mapping is private to the driver and hard to figure
> out at the best of times. e.g. which button on your device is Button 1?
> running xev or xinput will only tell you the logical button 1, not the
> physical button 1.

I knew there was a commit for it but I didn't find it this morning:

commit ab311bf20535acd6e7201e024bc311e0e15b5b6b
Refs: xf86-input-wacom-0.10.10-88-gab311bf
Author:     Chris Bagwell <[email protected]>

    make key mappings align with button mappings.

    So commit is clear, let me define terminology used in describing
    change.

    internal buttons - xf86-input-wacom has a fixed set of buttons
    it maps to internal #0 to 4 (stylus buttons, mouse buttons, and pad 
buttons).
    It also has generic list of buttons BTN_0.. BTN_* that it defines to
    internal #0 to 27.

    X physical buttons - xf86-input-wacom uses a non-user editable
    priv->button[] array to map internal button #'s to X physical
    buttons.  The current usage of this array is to skip over
    physical buttons 4 to 7 since they are used for scrolling events
    by convention.

    X logical buttons - both "xinput set-button-map" and "xsetwacom
    --set X ButtonN N" modify an array that converts X physical buttons to
    X logical buttons.

    key mappings - "xsetwacom --set X Button N "key 1"" creates a
    button-to-key mapping.  Before this patch, the key mapping was
    "internal button" to key mappings; instead of X physical buttons
    to key mappings.

    New Bamboo driver maps two middle pad buttons to X physical buttons 8
    and 9 because internally they are 4 and 5.  This mean for
    button-to-button mappings, user used Button8/9 but for key mappings
    they used Button4/5 to change behavior.

    This is a long explaination for small patch that makes key
    mappings use X physical button names for consistency.  It
    also changes keys[] array to be ones based to allow with X
    physical buttons being ones based.



Cheers,
  Peter

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to