Re: [Linuxwacom-devel] [PATCH 5/7] Decrease minimum number of args to 'set' [allow wheels/strips reset]

2011-04-04 Thread Jason Gerecke 
On Sun, Apr 3, 2011 at 8:26 PM, Peter Hutterer peter.hutte...@who-t.net 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
 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.

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

Re: [Linuxwacom-devel] [PATCH 5/7] Decrease minimum number of args to 'set' [allow wheels/strips reset]

2011-04-04 Thread Peter Hutterer 
On Mon, Apr 04, 2011 at 10:15:16AM -0700, Jason Gerecke wrote:
 On Sun, Apr 3, 2011 at 8:26 PM, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
  On Fri, Apr 01, 2011 at 11:17:15AM -0700, Jason Gerecke wrote:

[cutting some context. why? because I can!]

  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.

long story short - it doesn't really matter. we're mostly just
arguing about the wording in a commit message and I seem to be doing a
better job at confusing you than explaining myself :) I take it that
the behaviour of the strip can be set with actions now (including button 5
or somesuch). so to me, the matter is resolved.

Cheers,
  Peter

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 5/7] Decrease minimum number of args to 'set' [allow wheels/strips reset]

2011-04-03 Thread Peter Hutterer 
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

Re: [Linuxwacom-devel] [PATCH 5/7] Decrease minimum number of args to 'set' [allow wheels/strips reset]

2011-04-01 Thread Jason Gerecke 
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. 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.


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...

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
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Re: [Linuxwacom-devel] [PATCH 5/7] Decrease minimum number of args to 'set' [allow wheels/strips reset]

2011-03-31 Thread Jason Gerecke 
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)

Though, If you're talking about mapping through the equivalent of
`xinput set-button-map` you're correct. Of course, there's not much we
can do to stop that. The code which did the equivalent was removed
from xsetwacom in favor of parse_action transforming simple buttons
into proper actions.

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
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

[Linuxwacom-devel] [PATCH 5/7] Decrease minimum number of args to 'set' [allow wheels/strips reset]

2011-03-30 Thread Jason Gerecke 
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. Doing the same with buttons has been supported, but
wheels and strips were out of luck because they would require too
few arguments to 'set'.

Signed-off-by: Jason Gerecke killert...@gmail.com
---
 tools/xsetwacom.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index d99a671..59b0cb1 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1554,7 +1554,7 @@ static void set(Display *dpy, int argc, char **argv)
char **values;
int nvals;
 
-   if (argc  3)
+   if (argc  2)
{
usage();
return;
-- 
1.7.4.1


--
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

Re: [Linuxwacom-devel] [PATCH 5/7] Decrease minimum number of args to 'set' [allow wheels/strips reset]

2011-03-30 Thread Peter Hutterer 
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?

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

 Doing the same with buttons has been supported, but
 wheels and strips were out of luck because they would require too
 few arguments to 'set'.
 
 Signed-off-by: Jason Gerecke killert...@gmail.com
 ---
  tools/xsetwacom.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
 index d99a671..59b0cb1 100644
 --- a/tools/xsetwacom.c
 +++ b/tools/xsetwacom.c
 @@ -1554,7 +1554,7 @@ static void set(Display *dpy, int argc, char **argv)
   char **values;
   int nvals;
  
 - if (argc  3)
 + if (argc  2)
   {
   usage();
   return;
 -- 
 1.7.4.1

--
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