On Fri, Apr 01, 2011 at 11:17:15AM -0700, Jason Gerecke wrote: > On Thu, Mar 31, 2011 at 9:21 PM, Peter Hutterer > <peter.hutte...@who-t.net> wrote: > > On Wed, Mar 30, 2011 at 11:51:22PM -0700, Jason Gerecke wrote: > >> On Wed, Mar 30, 2011 at 9:04 PM, Peter Hutterer > >> <peter.hutte...@who-t.net> wrote: > >> > On Wed, Mar 30, 2011 at 01:54:45PM -0700, Jason Gerecke wrote: > >> >> Since the worker functions now check that they have the appropriate > >> >> number of arguments, its possible to decrease the number of arguments > >> >> required by 'set'. Since all it really needs is a device number and > >> >> a property, the minimum argc is now 2. > >> >> > >> >> A handy side-effect of this change is that its now possible to run > >> >> e.g. `xsetwacom --set $ID StripLeftDown` to reset the action to > >> >> its default. > >> > > >> > is that because we delete the property then so it falls back to using the > >> > button mapping? > >> > > >> Correct. > >> > >> > this formulation is a bit unfortunate, since it doesn't actually set to > >> > the > >> > default. if I map the button to say 8, then run the above command it > >> > would > >> > revert back to 8, not to the default (4 or whatever it is), right? > >> > > >> > Cheers, > >> > Peter > >> > > >> I'm not quite sure what you mean here. If no action has been defined, > >> the driver falls back to its predefined button. If you run e.g. > >> `xsetwacom --set $ID LeftStripUp 8`, the action "button +8" is > >> assigned (because of parse_action's simple button handling). When you > >> move your finger along the strip, the driver notices an action has > >> been set and will send the button 8 event. If you then run `xsetwacom > >> --set $ID LeftStripUp` the action is deleted. Moving your finger along > >> the strip again, the driver will not find an action and fall back to > >> its predefined mapping (which should be button 5) > > > > Where is this 5 coming from? shouldn't this be the equivalent of "button > > +5" in the driver? > > > > Cheers, > > Peter > > > getWheelButton (in wcmCommon.c) is responsible for finding both the > "fakeButton" and "fakeKey" that could be associated with various > device events. In the case of our hypothetical "strip left up", it > gets the button from 'priv->striplup' and the key from > 'priv->strip_keys[0]'. The former is defined during wcmAllocate and is > never changed.
in spirit with the other discussion of allowing physical mappings, this should probably be adjustable. > The latter is changed by wcmUpdateButtonKeyActions > (after a long call chain beginning with wcmSetProperty) whenever X > detects a change in the WACOM_PROP_STRIPBUTTONS property. > getWheelButton then returns both of these to sendWheelStripEvents. If > a "key" is defined, it will preferentially decode it and send the > necessary events. Otherwise, it interprets the raw integer fakeButton > as the X button to send a button press event for. > > When xsetwacom is given arguments to StripLeftUp, it converts them > into an action and modifies the appropriate offset into > WACOM_PROP_STRIPBUTTONS. When the appropriate motion is made the > driver notices an action is sent and sends it. When it is run without > arguments, it clears the offset, so the same motion results in the > driver not finding an action and sending the default button. Note that > xsetwacom works the same way for "Button X"! Running with arguments > sets an action the driver will preferentially use; running without > arguments clears the action, forcing the driver to fall back on the > raw integer defined in the button[] array. right, so if I understand this correctly, the "default button" it uses then is the (essentially hardcoded) striplup value. which brings me back to my original question: it doesn't reset to the default value but rather removes the new button mapping. if you could change striplup, removing a button mapping would reset to whatever striplup has as current value (and that may not be the _default_). currently this works, but only because we don't seem to have a way to change it. it's really just the wording that matters to me here, even if it appears to be overly anal :) > The only thing I find a little mystifying is how priv->strip_keys is > initially set. My first thought was that it was done when the > properties were first created -- this doesn't look to be true. My > second thought was that perhaps the entire priv structure was zeroed > out prior to initialization -- can't find evidence of this either. I > would think unless strip_keys[] were initialized somewhere it'd be > filled with random junk, defeating the logic used and resulting in > completely undefined behavior... all memory in the wacom driver is calloc'd, which means it's initialized to 0 from the onset. Cheers, Peter ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
