On Sun, Apr 3, 2011 at 8:26 PM, Peter Hutterer <[email protected]> wrote: > On Fri, Apr 01, 2011 at 11:17:15AM -0700, Jason Gerecke wrote: >> On Thu, Mar 31, 2011 at 9:21 PM, Peter Hutterer >> <[email protected]> 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 >> >> <[email protected]> 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. > See my reply below :)
>> 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 :) > I see now -- yes, you are understanding things correctly. However, In regards to this and your prior paragraph, I'm not sure I see the logic in letting the user change striplup. Why /should/ the user be able to modify it? If they don't like the mapping, why not use already-extant features like setting an action (i.e. modify strip_keys[0])? I've tried thinking of several possible motivations, but am coming up blank :( Also, what did you mean by "in spirit with the other discussion of allowing physical mappings"? I'm not sure I understand since the button[] array is already physical-button-indexed and the strip_keys[] and wheel_keys[] don't really /have/ physical buttons... IIRC only keys[] is X11-button-indexed, but that could be changed without too much hassle. >> 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. > Gotcha :) Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
