On Wed, Jan 12, 2011 at 08:20:46PM -0600, ch...@cnpbagwell.com wrote: > From: Chris Bagwell <ch...@cnpbagwell.com> > > let me define terminology since I do not 100% know X's terminology. > > 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 a value to converts X physical to X logical > buttons. > > key mappings - "xsetwacom --set X Button N "key 1"" creates a > button-to-key mapping. This key mapping used internal button > numbers instead of X physical buttons. For case of more then > 3 buttons, there was a mismatch.
> New Bamboo driver maps two middle pad buttons map to 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. urgh. this is a bit chaotic. first of all, your terminology is correct, or close enough anyway, there's no single terminology. I called them "device buttons" in the past, but "internal buttons" is the same thing. http://who-t.blogspot.com/2009/06/button-mapping-in-x.html the driver should not to expose the driver-internal buttons at all. aside from the "skip over 4/5/6/7", the mapping is static. this way we get clients to use the x protocol mappings instead of having yet another driver-specific method for button configuration. so doing the same for keys certainly seems to make sense. for this patch, I'd rather you create a temporary variable so the code is more obvious to read in the future. int mapped_button; /* phys button number as it appears to X */ and then replace all priv->button[button] calls with mapped_button. and as usual, a comment in xf86WacomDefs.h explaining what button[] stands for would be a useful addition to save the next developer from having to figure it out for themselves :) Cheers, Peter > This is a long explaination for small patch that makes key > mappings use X physical button names for consistency. > > Signed-off-by: Chris Bagwell <ch...@cnpbagwell.com> > --- > src/wcmCommon.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/wcmCommon.c b/src/wcmCommon.c > index 0fc9cb6..050ca5b 100644 > --- a/src/wcmCommon.c > +++ b/src/wcmCommon.c > @@ -280,7 +280,7 @@ static void sendAButton(InputInfoPtr pInfo, int button, > int mask, > button, mask, priv->button[button], > (priv->button[button] & AC_CORE) ? "yes" : "no"); > > - if (!priv->keys[button][0]) > + if (!priv->keys[priv->button[button]][0]) > { > /* No button action configured, send button */ > xf86PostButtonEventP(pInfo->dev, is_absolute(pInfo), > priv->button[button], (mask != 0), > @@ -288,8 +288,8 @@ static void sendAButton(InputInfoPtr pInfo, int button, > int mask, > return; > } > > - sendAction(pInfo, (mask != 0), priv->keys[button], > - ARRAY_SIZE(priv->keys[button]), > + sendAction(pInfo, (mask != 0), priv->keys[priv->button[button]], > + ARRAY_SIZE(priv->keys[priv->button[button]]), > first_val, num_val, valuators); > } > > -- > 1.7.3.4 ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
