With the new support for wheel actions, the actual action would be delayed
by one invocation, i.e. any action would always reflect the last xsetwacom
command, not the current one.
Caused by the driver now calls XIGetProperty() during the update but the
property hasn't actually set the value yet. Hack around this by always
updating the parent property, triggering a reload of all actions.
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
---
this goes on top of the wheel-keys branch.
tools/xsetwacom.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 5e4171c..385b3b4 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1630,11 +1630,10 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
PropModeReplace,
(unsigned char*)data, nitems);
- if (need_update)
- XChangeDeviceProperty(dpy, dev, btnact_prop, XA_ATOM, 32,
- PropModeReplace,
- (unsigned char*)btnact_data,
- btnact_nitems);
+ XChangeDeviceProperty(dpy, dev, btnact_prop, XA_ATOM, 32,
+ PropModeReplace,
+ (unsigned char*)btnact_data,
+ btnact_nitems);
XFlush(dpy);
}
--
1.7.2
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
