Ah of course. I should have thought of that, but I'm not used to
fiddling with drivers and modules. (I even spent a few minutes making
doubly sure that I had recompiled after patching and was running the
patched version, but for some reason I didn't think about the drivers)

After unplugging, unloading the wacom module, replugging and reloading
the module, the changes seem to have taken effect. Now it behaves
correctly. After setting StripLeftUp followed by Button 1,
StripLeftUp's output is not affected and xsetwacom --get reports the
correct values for both.

I'm assuming that means you no longer need to see the output of "xinput
list-props <id>", but here's the relevant bit in case you need to check
anything:
Wacom Button Actions (311):     "Wacom Button Actions action
1" (794), "None" (0), "None" (0), "None" (0), "None" (0), "None" (0),
"None" (0), "None" (0), "None" (0), "None" (0), "None" (0), "None" (0),
"None" (0), "None" (0), "None" (0), "None" (0)
Wacom Strip Buttons (321):      "Wacom Strip Buttons action 1" (793),
"None" (0), "None" (0), "None" (0)
Wacom Wheel Buttons (319):      "None" (0), "None" (0), "None" (0),
"None" (0), "None" (0), "None" (0) Device Product ID (312):
1386, 177
Wacom Debug Levels (313):       0, 0
Wacom Strip Buttons action 1 (793):     1114154, 65578
Wacom Button Actions action 1 (794):    1114155, 65579

Thanks again for the speedy fix.
Tom

On Wed, 14 Mar 2012 13:43:04 -0700
Jason Gerecke <killert...@gmail.com> wrote:

> Could you provide the output of "xinput list-props <id>" after running
> your test case (<id> will be the numeric ID of "Wacom Intuos3 6x8 pad"
> displayed in "xsetwacom list")? It sounds like the new naming scheme
> hasn't overwritten the old one. So far I've only been able to trigger
> this behavior if the old names were already set -- if you haven't
> unplugged and replugged your tablet after installing the patched
> driver, that could explain things.
> 
> Jason
> 
> ---
> Day xee-nee-svsh duu-'ushtlh-ts'it;
> nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
> Huu-chan xuu naa~-gha.
> 
> 
> On Wed, Mar 14, 2012 at 1:18 PM, T Hall <tahall...@gmail.com> wrote:
> > Thanks for the quick response.
> >
> > I tried the patch. It does not appear to solve the issue. I
> > tried the same test case as before:
> >
> > $ xsetwacom --set "Wacom Intuos3 6x8 pad" "StripLeftUp" "key +g -g"
> > $ xsetwacom --get "Wacom Intuos3 6x8 pad" "StripLeftUp"
> > key +g -g
> > $ xsetwacom --set "Wacom Intuos3 6x8 pad" "Button" "1" "key +h -h"
> > $ xsetwacom --get "Wacom Intuos3 6x8 pad" "StripLeftUp"
> > key +h -h
> > StripLeftUp outputs "g" after this (which is correct), but xsetwacom
> > --get output is still wrong.
> >
> > Regards,
> > T Hall
> >
> > On Wed, 14 Mar 2012 12:36:06 -0700
> > Jason Gerecke <killert...@gmail.com> wrote:
> >
> >> The names of action atoms are currently created without regard to
> >> the property they will be stored in. This results in both e.g.
> >> button 1 and StripLeftUp using atoms with the name "Wacom button
> >> action 1". When setting either button 1 or StripLeftUp, we ask
> >> the server for an atom named "Wacom button action 1" and in both
> >> cases receive the *same* atom. This means button 1 is nothing
> >> more than an alias for StripLeft up (and similarly for the other
> >> actions which share the same name).
> >>
> >> This patch uses the name of the property the action will be stored
> >> in as the prefix to prevent this aliasing from occuring.
> >>
> >> 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 2c546b1..7cf0d05 100644
> >> --- a/tools/xsetwacom.c
> >> +++ b/tools/xsetwacom.c
> >> @@ -1264,7 +1264,7 @@ static void special_map_property(Display
> >> *dpy, XDevice *dev, Atom btnact_prop, i if (!prop)
> >>               {
> >>                       char buff[64];
> >> -                     sprintf(buff, "Wacom button action %d",
> >> (offset + 1));
> >> +                     sprintf(buff, "%s action %d",
> >> XGetAtomName(dpy, btnact_prop), (offset + 1)); prop =
> >> XInternAtom(dpy, buff, False); btnact_data[offset] = prop;
> >>               }
> >


------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to