Re: [Linuxwacom-devel] [PATCH 00/10] xsetwacom UI changes
On Thu, Feb 3, 2011 at 11:20 AM, Adam Bark wrote: > > I figure the code is 0.10.10 so until it hits 1.x I won't assume > anything. As for Favux's comment you don't have to update immediately > it's only just been checked in so won't be in a release for a little while. > Assuming 0.x will have unstable interfaces is great, but I've noticed some projects retain a vestigal "0." prefix for several years, despite being mostly stable (VLC is the poster-child for this, taking 13 years to hit 1.0). I'm new to the list (joined a few days ago) so I don't really know the project history or roadmap very well, but if the point releases are any indication of interface stability, then "major changes" happen about every two years. That's pretty stable, despite its 0.x status. On Thu, Feb 3, 2011 at 1:54 PM, Peter Hutterer wrote: > would something like: > xsetwacom get RelWUp > "RelWUp is obsolete. Please use RelWheelUp instead" This seems like the best solution to me. I'm all for making things more readable, but we shouldn't suddenly pull the carpet out from the people who have been using the existing xsetwacom interface for literally years... Jason -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 4/4] Interpret threshold for button click relative to pressure curve.
Is [0..2024] really the normalized pressure range? Wouldn't [0..2048]
be correct since its the range of the pressure curve mapping? (Also
applies to patch 3/4 as well)
Sorry about the dupe Peter... Looks like I missed the 'Reply All' button...
Jason
On Mon, Feb 7, 2011 at 9:06 PM, Peter Hutterer wrote:
> Don't interpret the button press pressure threshold as an absolute number
> but as a relative one in relation to the pressure curve.
>
> Reported-by: Chris Bagwell
> Signed-off-by: Peter Hutterer
> ---
> man/wacom.man | 4 ++--
> src/wcmCommon.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/man/wacom.man b/man/wacom.man
> index 18cee4c..80d54c6 100644
> --- a/man/wacom.man
> +++ b/man/wacom.man
> @@ -193,8 +193,8 @@ xsetwacom, which comes with linuxwacom package.
> .TP 4
> .B Option \fI"Threshold"\fP \fI"number"\fP
> sets the pressure threshold used to generate a button 1 events of stylus.
> -The threshold applies to the normalised pressure range of [0..2024].
> -The default is 27.
> +The threshold applies to the normalised pressure range of [0..2024] after
> +applying the pressure curve. The default is 27.
> .RE
> .SH "SEE ALSO"
> Xorg(1x), xorg.conf(5x), xorgconfig(1x), Xserver(1x), X(7).
> diff --git a/src/wcmCommon.c b/src/wcmCommon.c
> index d62ce3d..664a900 100644
> --- a/src/wcmCommon.c
> +++ b/src/wcmCommon.c
> @@ -1236,8 +1236,8 @@ static void commonDispatchDevice(WacomCommonPtr common,
> unsigned int channel,
> if (IsStylus(priv) || IsEraser(priv))
> {
> filtered.pressure = normalizePressure(priv, &filtered);
> - filtered.buttons = setPressureButton(priv, &filtered);
> filtered.pressure = applyPressureCurve(priv,&filtered);
> + filtered.buttons = setPressureButton(priv, &filtered);
> }
>
> else if (IsCursor(priv) && !priv->oldHwProx)
> --
> 1.7.3.5
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> Linuxwacom-devel mailing list
> Linuxwacom-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
>
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH] Fix spelling error
s/none /non-/
Signed-off-by: Jason Gerecke
---
man/wacom.man |2 +-
tools/xsetwacom.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/man/wacom.man b/man/wacom.man
index 73082af..772f862 100644
--- a/man/wacom.man
+++ b/man/wacom.man
@@ -133,7 +133,7 @@ Tablet PCs with touch feature; "off" for all other models.
.B Option \fI"Capacity"\fP \fI"number"\fP
sets touch sensitivity level for capacitive touch device, where number
can be an integer from -1 to 5. Default is 3 for capacitive tools and
--1 for none capacitive tools.
+-1 for non-capacitive tools.
.TP 4
.B Option \fI"Speed"\fP \fI"Rspeed"\fP
sets the cursor's relative movement speed to Rspeed. The default
value is 1.0.
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index b5f938f..fb7c030 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -437,7 +437,7 @@ static param_t parameters[] =
{
.name = "Capacity",
.desc = "Touch sensitivity level (default is 3, "
- "-1 for none capacitive tools).",
+ "-1 for non-capacitive tools).",
.prop_name = WACOM_PROP_CAPACITY,
.prop_format = 32,
.prop_offset = 0,
--
1.7.1
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH] Fix a racing condition that causes hotplugging crash occasionally
On Mon, Feb 14, 2011 at 9:07 PM, Ping Cheng wrote: > On Mon, Feb 14, 2011 at 6:03 PM, Peter Hutterer >> >> quote: >> "init in the config is quite different to init during hotplugging. >> the server will call, PreInit for all devices, DEVICE_INIT for all >> devices, then DEVICE_ON for all devices. >> >> For hotplugging, it's PreInit first device, PreInit + DEVICE_INIT + >> DEVICE_ON for all dependent devices in order, then DEVICE_INIT and >> DEVICE_ON for the first device." >> >> so with this patch, whenever DEVICE_ENABLE is called, you have >> common->wcmNumTools being equal to common->fd_refs. which means it'll go >> happily past the condition in wcmDevReadInput if a device sends events >> before all devices are enabled. >> I can confirm Peter's hotplug trace under Ubuntu 10.10 (X version 1.9.0) with xf86-input-wacom from git. Hotplugging WITHOUT an xorg.conf gives the following: === 1. udev adds a new device 2. wcmPreInit and NewWcmPreInit are called for a device with NULL type 3. Driver assumes type is 'stylus' and sets up appropriately 4. 'stylus' reports "hotplugging dependent devices" 5. wcmPreInit and NewWcmPreInit for a newly-created 'eraser' called 6. DEVICE_INIT and DEVICE_ON sent to 'eraser' 7. wcmPreInit and NewWcmPreInit for a newly-created 'cursor' called 8. DEVICE_INIT and DEVICE_ON sent to 'cursor' 9. 'stylus' reports hotplugging complete 10. DEVICE_INIT and DEVICE_ON sent to 'stylus' Hotplugging WITH a minimal xorg.conf gives the following: 1. wcmPreInit and NewWcmPreInit are called for the 'stylus' device 2. DEVICE_INIT and DEVICE_ON sent to 'stylus' 3. wcmPreInit and NewWcmPreInit are called for the 'eraser' device 4. DEVICE_INIT and DEVICE_ON sent to 'eraser' ... etc. N. udev attempts to add the device, but we ignore it since its already in use In either case, fd_refs and wcmNumTools are incremented in (near) lockstep. All I see it doing is narrowing the window of opportunity to crash the driver, not truly plugging the hole. Empirical results of the patch aside, it still seems like it needs some work before we can actually call this problem "solved". Jason -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] Retiring CVS
After consulting with Ping, the CVS repositories are going to be retired. With SourceForge hinting at a possible end-of-life for CVS service it seems like a good idea to take a preemptive step and consolidate everything under Git. However, while preparing the pull the plug I've run into a small snag: the legacy linuxwacom code is hosted in three repositories that all disagree to some extent. The linuxwacom-dev and linuxwacom-prod repositories on CVS are the most up-to-date as far as version tags go, but have different histories and tags. The linuxwacom repository on Git is slightly less up-to-date, but does have a few patches the others don't -- including the complete removal of kernel code. Any thoughts on which version we want to use, or how we should merge the code/commits/tags between them? Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Heading towards regular releases
On Wed, Feb 16, 2011 at 7:45 PM, Peter Hutterer wrote: > What I'd like to commit to is regular releases. While the misc cleanup is > still going strong, we can't and shouldn't just line up with X server > releases. So what I propose is an approcimately monthly release with a > driver release ever first week of the month. > This sounds reasonable. The median release time is between 4 and 5 weeks (depending on if you count .10 and .11) which lines up nicely with your proposal. I do share Ping's concern about providing a testing period though. Whether this means a code freeze on master, a tag/branch in that people can checkout and test, or a packaged RC which is uploaded to SourceForge... I'm still too new to this project to even pretend to know the best route. > This requires some more discipline, so I'll simply stop merging intrusive > patches on the 1st of each month and focus on dealbreakers only for a couple > of days. anything else will simply go on -next, which will then be merged > whenever the previous release is out. > This kinda conflicts with both itself and the paragraph above... Are you saying: 1. Release the first week of each month. Just prior to release, stop merging intrusive patches entirely to give people time to test. Sometime after release, resume merging intrusive patches. 2. Release the first week of each month. Just prior to release, create a -next branch where intrusive patches can go while people test. Sometime after release, merge "-next" back into master. 2. Release the first week of each month. Just after release, stop merging intrusive patches entirely to give the code a stable base while we fix reported bugs. Sometime later, resume merging intrusive patches. 3. Release the first week of each month. Just after release, create a -next branch where intrusive patches can go so master remains stable while we fix reported bugs. Sometime later, merge "-next" back into master. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Retiring CVS
CVS IS DEAD! input-wacom and linuxwacom-dev have both been imported to Git. If for some reason you have an old copy of the linuxwacom Git repo lying around (for posterity??) you should probably nuke it since the history was rewritten. ... looks like I missed 'Reply to All' yet again ... Sorry Peter! Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH] Require PROP_FLAG_BOOLEAN params to be 'off' or 'on'
Do some additional checking to ensure the user provides valid values
for boolean parameters. Also, provide a helpful error if the user
goes astray.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index fa98e3e..7544872 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1424,10 +1424,14 @@ static int convert_value_from_user(param_t
*param, char *value)
{
int val;
- if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value,
"off") == 0)
+ if (param->prop_flags & PROP_FLAG_BOOLEAN) {
+ if (strcmp(value, "off") == 0)
val = 0;
- else if ((param->prop_flags & PROP_FLAG_BOOLEAN) &&
strcmp(value, "on") == 0)
+ else if (strcmp(value, "on") == 0)
val = 1;
+ else
+ val = -1;
+ }
else
val = atoi(value);
@@ -1508,6 +1512,11 @@ static void set(Display *dpy, int argc, char **argv)
for (i = 0; i < nvals; i++)
{
val = convert_value_from_user(param, values[i]);
+ if (param->prop_flags & PROP_FLAG_BOOLEAN && (val != 0
&& val != 1)) {
+ fprintf(stderr, "Property '%s' is a boolean.
Set it with 'on' or 'off'.\n",
+ param->name);
+ goto out;
+ }
switch(param->prop_format)
{
--
1.7.1
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH] Fix minor doc style inconsitencies
Add/move periods and whitespace, make defaults consistent, and clarify
where necessary.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 46 +++---
1 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index fa98e3e..36b1154 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -115,7 +115,7 @@ static param_t parameters[] =
{
{
.name = "Area",
- .desc = "Valid tablet area in device coordinates.",
+ .desc = "Valid tablet area in device coordinates. ",
.prop_name = WACOM_PROP_TABLET_AREA,
.prop_format = 32,
.prop_offset = 0,
@@ -129,8 +129,8 @@ static param_t parameters[] =
},
{
.name = "ToolDebugLevel",
- .desc = "Level of debugging trace for individual tools, "
- "default is 0 (off). ",
+ .desc = "Level of debugging trace for individual tools "
+ "(default is 0 [off]). ",
.prop_name = WACOM_PROP_DEBUGLEVELS,
.prop_format = 8,
.prop_offset = 0,
@@ -139,29 +139,29 @@ static param_t parameters[] =
.name = "TabletDebugLevel",
.desc = "Level of debugging statements applied to shared "
"code paths between all tools "
- "associated with the same tablet. default is 0 (off). ",
+ "associated with the same tablet (default is 0 [off]). ",
.prop_name = WACOM_PROP_DEBUGLEVELS,
.prop_format = 8,
.prop_offset = 1,
},
{
.name = "Suppress",
- .desc = "Number of points trimmed, default is 2. ",
+ .desc = "Number of points trimmed (default is 2). ",
.prop_name = WACOM_PROP_SAMPLE,
.prop_format = 32,
.prop_offset = 1,
},
{
.name = "RawSample",
- .desc = "Number of raw data used to filter the points, "
- "default is 4. ",
+ .desc = "Number of raw data used to filter the points "
+ "(default is 4). ",
.prop_name = WACOM_PROP_SAMPLE,
.prop_format = 32,
.prop_offset = 0,
},
{
.name = "PressureCurve",
- .desc = "Bezier curve for pressure (default is 0 0 100 100). ",
+ .desc = "Bezier curve for pressure (default is 0 0 100
100 [linear]). ",
.prop_name = WACOM_PROP_PRESSURECURVE,
.prop_format = 32,
.prop_offset = 0,
@@ -169,15 +169,15 @@ static param_t parameters[] =
},
{
.name = "Mode",
- .desc = "Switches cursor movement mode (default is
absolute/on). ",
+ .desc = "Switches cursor movement mode (default is absolute). ",
.set_func = set_mode,
.get_func = get_mode,
},
{
.name = "TabletPCButton",
- .desc = "Turns on/off Tablet PC buttons. "
- "default is off for regular tablets, "
- "on for Tablet PC. ",
+ .desc = "Turns on/off Tablet PC buttons "
+ "(default is off for regular tablets, "
+ "on for Tablet PC). ",
.prop_name = WACOM_PROP_HOVER,
.prop_format = 8,
.prop_offset = 0,
@@ -185,7 +185,7 @@ static param_t parameters[] =
},
{
.name = "Touch",
- .desc = "Turns on/off Touch events (default is enable/on). ",
+ .desc = "Turns on/off Touch events (default is on). ",
.prop_name = WACOM_PROP_TOUCH,
.prop_format = 8,
.prop_offset = 0,
@@ -194,7 +194,7 @@ static param_t parameters[] =
{
.name = "Gesture",
.desc = "Turns on/off multi-touch gesture events "
- "(default is enable/on). ",
+ "(default is on). ",
.prop_name = WACOM_PROP_ENABLE_GESTURE,
.prop_format = 8,
.prop_offset = 0,
@@ -226,8 +226,8 @@ static param_t parameters[] =
},
{
.name = "Capacity",
- .desc = "Touch sensitivity level (default is 3, "
- "-1 for non-capacitive tools).",
+
[Linuxwacom-devel] RawFilter option broken (and duplicated?)
While making my last two patches, I noticed that the RawFilter option is broken for me on master. What I see: xsetwacom --set "Wacom Cintiq 21UX stylus" rawfilter on RawFilter = format mismatch (32) xsetwacom --set "Wacom Cintiq 21UX stylus" rawfilter off RawFilter = format mismatch (32) Looking through the code, it appears that RawFilter sets the same thing as RawSample (the .prop_name and .prop_offset are identical). Changing RawFilter to also have a format of 32 gets rid of the errors, but I still wonder why we have two options pointing to the same thing... Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v2] Require PROP_FLAG_BOOLEAN params to be 'off' or 'on'
Do additional checking to ensure the user provides valid values
for boolean parameters. Also, provide a helpful error if the user
goes astray.
Signed-off-by: Jason Gerecke
---
Changes to previous version:
- convert_value_from_user now returns conversion success and requires a return
pointer
- atoi() swapped to strtol() for better error checking
- error message more generic
- extra crazy to safely handle memory de/allocation
tools/xsetwacom.c | 51 ---
1 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index fa98e3e..04feed5 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -24,6 +24,8 @@
#include
#include "Xwacom.h"
+#include
+#include
#include
#include
#include
@@ -1420,18 +1422,30 @@ error:
return;
}
-static int convert_value_from_user(param_t *param, char *value)
+static Bool convert_value_from_user(param_t *param, char *value, int
*return_value)
{
- int val;
+ if (!return_value)
+ return False;
- if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value, "off") ==
0)
- val = 0;
- else if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value, "on")
== 0)
- val = 1;
- else
- val = atoi(value);
+ if (param->prop_flags & PROP_FLAG_BOOLEAN)
+ {
+ if (strcmp(value, "off") == 0)
+ *return_value = 0;
+ else if (strcmp(value, "on") == 0)
+ *return_value = 1;
+ else
+ return False;
+ } else {
+ char *end;
+ long conversion = strtol(value, &end, 10);
+ if (end == value || *end != '\0' || errno == ERANGE ||
+ conversion < INT_MIN || conversion > INT_MAX)
+ return False;
+
+ *return_value = (int)conversion;
+ }
- return val;
+ return True;
}
static void set(Display *dpy, int argc, char **argv)
@@ -1507,7 +1521,22 @@ static void set(Display *dpy, int argc, char **argv)
for (i = 0; i < nvals; i++)
{
- val = convert_value_from_user(param, values[i]);
+ int *retval = calloc(1,sizeof(int));
+ if (!retval)
+ {
+ fprintf(stderr, "calloc failled\n");
+ exit(EXIT_FAILURE);
+ }
+ Bool success = convert_value_from_user(param, values[i],
retval);
+ int val = *retval;
+ free(retval);
+
+ if (!success)
+ {
+ fprintf(stderr, "'%s' is not a valid value for the '%s'
property.\n",
+ values[i], param->name);
+ goto out;
+ }
switch(param->prop_format)
{
--
1.7.1
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v2] Fix minor doc style inconsitencies
Add/move periods and whitespace, make defaults consistent, and clarify
where necessary.
Signed-off-by: Jason Gerecke
---
Changes
- Now with 100% less linewrapping! (...hopefully...)
tools/xsetwacom.c | 46 +++---
1 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index fa98e3e..36b1154 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -115,7 +115,7 @@ static param_t parameters[] =
{
{
.name = "Area",
- .desc = "Valid tablet area in device coordinates.",
+ .desc = "Valid tablet area in device coordinates. ",
.prop_name = WACOM_PROP_TABLET_AREA,
.prop_format = 32,
.prop_offset = 0,
@@ -129,8 +129,8 @@ static param_t parameters[] =
},
{
.name = "ToolDebugLevel",
- .desc = "Level of debugging trace for individual tools, "
- "default is 0 (off). ",
+ .desc = "Level of debugging trace for individual tools "
+ "(default is 0 [off]). ",
.prop_name = WACOM_PROP_DEBUGLEVELS,
.prop_format = 8,
.prop_offset = 0,
@@ -139,29 +139,29 @@ static param_t parameters[] =
.name = "TabletDebugLevel",
.desc = "Level of debugging statements applied to shared "
"code paths between all tools "
- "associated with the same tablet. default is 0 (off). ",
+ "associated with the same tablet (default is 0 [off]). ",
.prop_name = WACOM_PROP_DEBUGLEVELS,
.prop_format = 8,
.prop_offset = 1,
},
{
.name = "Suppress",
- .desc = "Number of points trimmed, default is 2. ",
+ .desc = "Number of points trimmed (default is 2). ",
.prop_name = WACOM_PROP_SAMPLE,
.prop_format = 32,
.prop_offset = 1,
},
{
.name = "RawSample",
- .desc = "Number of raw data used to filter the points, "
- "default is 4. ",
+ .desc = "Number of raw data used to filter the points "
+ "(default is 4). ",
.prop_name = WACOM_PROP_SAMPLE,
.prop_format = 32,
.prop_offset = 0,
},
{
.name = "PressureCurve",
- .desc = "Bezier curve for pressure (default is 0 0 100 100). ",
+ .desc = "Bezier curve for pressure (default is 0 0 100 100
[linear]). ",
.prop_name = WACOM_PROP_PRESSURECURVE,
.prop_format = 32,
.prop_offset = 0,
@@ -169,15 +169,15 @@ static param_t parameters[] =
},
{
.name = "Mode",
- .desc = "Switches cursor movement mode (default is
absolute/on). ",
+ .desc = "Switches cursor movement mode (default is absolute). ",
.set_func = set_mode,
.get_func = get_mode,
},
{
.name = "TabletPCButton",
- .desc = "Turns on/off Tablet PC buttons. "
- "default is off for regular tablets, "
- "on for Tablet PC. ",
+ .desc = "Turns on/off Tablet PC buttons "
+ "(default is off for regular tablets, "
+ "on for Tablet PC). ",
.prop_name = WACOM_PROP_HOVER,
.prop_format = 8,
.prop_offset = 0,
@@ -185,7 +185,7 @@ static param_t parameters[] =
},
{
.name = "Touch",
- .desc = "Turns on/off Touch events (default is enable/on). ",
+ .desc = "Turns on/off Touch events (default is on). ",
.prop_name = WACOM_PROP_TOUCH,
.prop_format = 8,
.prop_offset = 0,
@@ -194,7 +194,7 @@ static param_t parameters[] =
{
.name = "Gesture",
.desc = "Turns on/off multi-touch gesture events "
- "(default is enable/on). ",
+ "(default is on). ",
.prop_name = WACOM_PROP_ENABLE_GESTURE,
.prop_format = 8,
.prop_offset = 0,
@@ -226,8 +226,8 @@ static param_t parameters[] =
},
{
.name = "Capacity",
- .desc = "Touch sensitivity level (default is 3, "
- "-1
[Linuxwacom-devel] [PATCH 1/4] Remove RawFilter option from driver
This option was mostly removed from the driver at some point in
the past, with only these vestigal lines remaining.
Signed-off-by: Jason Gerecke
---
src/wcmCommon.c |2 +-
src/wcmConfig.c |2 +-
src/wcmValidateDevice.c |4
src/xf86WacomDefs.h |2 --
4 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index 4641cc1..315aa4e 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -906,7 +906,7 @@ void wcmEvent(WacomCommonPtr common, unsigned int channel,
}
/* Optionally filter values only while in proximity */
- if (RAW_FILTERING(common) && common->wcmModel->FilterRaw &&
+ if (common->wcmModel->FilterRaw &&
ds.proximity && ds.device_type != PAD_ID)
{
/* Start filter fresh when entering proximity */
diff --git a/src/wcmConfig.c b/src/wcmConfig.c
index afb5e0a..5d9d85b 100644
--- a/src/wcmConfig.c
+++ b/src/wcmConfig.c
@@ -89,7 +89,7 @@ static int wcmAllocate(InputInfoPtr pInfo)
/* JEJ - throttle sampling code */
priv->throttleLimit = -1;
- common->wcmFlags = RAW_FILTERING_FLAG; /* various flags */
+ common->wcmFlags = 0; /* various flags */
common->wcmDevices = priv;
common->wcmProtocolLevel = WCM_PROTOCOL_4; /* protocol level */
common->wcmTPCButton = 0; /* set Tablet PC button on/off */
diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
index 1b6c4e2..9d68abd 100644
--- a/src/wcmValidateDevice.c
+++ b/src/wcmValidateDevice.c
@@ -551,10 +551,6 @@ int wcmParseOptions(InputInfoPtr pInfo, int hotplugged)
(common->wcmFlags & TILT_REQUEST_FLAG)))
common->wcmFlags |= TILT_REQUEST_FLAG;
- if (xf86SetBoolOption(pInfo->options, "RawFilter",
- (common->wcmFlags & RAW_FILTERING_FLAG)))
- common->wcmFlags |= RAW_FILTERING_FLAG;
-
/* pressure curve takes control points x1,y1,x2,y2
* values in range from 0..100.
* Linear curve is 0,0,100,100
diff --git a/src/xf86WacomDefs.h b/src/xf86WacomDefs.h
index db83ddb..891f6a6 100644
--- a/src/xf86WacomDefs.h
+++ b/src/xf86WacomDefs.h
@@ -382,7 +382,6 @@ extern WacomDeviceClass gWacomISDV4Device;
#define TILT_REQUEST_FLAG 1
#define TILT_ENABLED_FLAG 2
-#define RAW_FILTERING_FLAG 4
#define MAX_CHANNELS 3
#define PAD_CHANNEL (MAX_CHANNELS-1)
@@ -481,7 +480,6 @@ struct _WacomCommonRec
};
#define HANDLE_TILT(comm) ((comm)->wcmFlags & TILT_ENABLED_FLAG)
-#define RAW_FILTERING(comm) ((comm)->wcmFlags & RAW_FILTERING_FLAG)
/**
* WacomTool
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 2/4] Remove RawFilter from xsetwacom
With support for the option completely removed from the driver,
remove it from xsetwacom as well. Also modify the deprecation
warning to handle cases like this where we don't want a replacement.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 23 ++-
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 07d8e26..e42c4fc 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -315,15 +315,6 @@ static param_t parameters[] =
.set_func = map_wheels,
},
{
- .name = "RawFilter",
- .desc = "Enables and disables filtering of raw data, "
- "default is true/on.",
- .prop_name = WACOM_PROP_SAMPLE,
- .prop_format = 8,
- .prop_offset = 0,
- .prop_flags = PROP_FLAG_BOOLEAN
- },
- {
.name = "Threshold",
.desc = "Sets tip/eraser pressure threshold "
"(default is 27)",
@@ -402,6 +393,7 @@ struct deprecated
{"CursorProx", "CursorProximity"},
{"xyDefault", "ResetArea"},
{"ClickForce", "Threshold"},
+ {"RawFilter", NULL},
{NULL, NULL}
};
@@ -427,8 +419,13 @@ is_deprecated_parameter(const char *name)
}
if (is_deprecated)
- printf("Parameter '%s' is no longer in use. "
- "It was replaced with '%s'.\n", name, d->replacement);
+ {
+ printf("Parameter '%s' is no longer in use. ", name);
+ if (d->replacement != NULL)
+ printf("It was replaced with '%s'.\n", d->replacement);
+ else
+ printf("Its use has been deprecated.\n");
+ }
return is_deprecated;
@@ -2191,8 +2188,8 @@ static void test_parameter_number(void)
* deprecated them.
* Numbers include trailing NULL entry.
*/
- g_assert(ArrayLength(parameters) == 34);
- g_assert(ArrayLength(deprecated_parameters) == 15);
+ g_assert(ArrayLength(parameters) == 33);
+ g_assert(ArrayLength(deprecated_parameters) == 16);
}
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 3/4] Enable RawSample and Suppress
The driver apparently didn't look at the RawSample option, and
xsetwacom confused it's offset with Suppress. In other words:
if you thought you've been tweaking Suppress, you've been tweaking
RawSample. If you thought you were tewaking RawSample, you weren't
doing anything.
Signed-off-by: Jason Gerecke
---
src/wcmValidateDevice.c |3 +++
tools/xsetwacom.c |4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
index 9d68abd..755d417 100644
--- a/src/wcmValidateDevice.c
+++ b/src/wcmValidateDevice.c
@@ -537,6 +537,9 @@ int wcmParseOptions(InputInfoPtr pInfo, int hotplugged)
}
}
+ common->wcmRawSample = xf86SetIntOption(pInfo->options, "RawSample",
+ common->wcmRawSample);
+
common->wcmSuppress = xf86SetIntOption(pInfo->options, "Suppress",
common->wcmSuppress);
if (common->wcmSuppress != 0) /* 0 disables suppression */
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index e42c4fc..82a7bbf 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -149,7 +149,7 @@ static param_t parameters[] =
.desc = "Number of points trimmed, default is 2. ",
.prop_name = WACOM_PROP_SAMPLE,
.prop_format = 32,
- .prop_offset = 1,
+ .prop_offset = 0,
},
{
.name = "RawSample",
@@ -157,7 +157,7 @@ static param_t parameters[] =
"default is 4. ",
.prop_name = WACOM_PROP_SAMPLE,
.prop_format = 32,
- .prop_offset = 0,
+ .prop_offset = 1,
},
{
.name = "PressureCurve",
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 4/4] Require RawSample to be at least 1
I made the mistake of setting this to zero and then bringing my pen into proximity. Ooops. X crashed. Looks like mathematics still can't handle getting the average of zero things ;) Signed-off-by: Jason Gerecke --- src/wcmXCommand.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c index 4207dbe..e589e37 100644 --- a/src/wcmXCommand.c +++ b/src/wcmXCommand.c @@ -620,7 +620,7 @@ int wcmSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop, if ((values[0] < 0) || (values[0] > 100)) return BadValue; - if ((values[1] < 0) || (values[1] > XWACOM_MAX_SAMPLES)) + if ((values[1] < 1) || (values[1] > XWACOM_MAX_SAMPLES)) return BadValue; if (!checkonly) -- 1.7.1 -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 4/4 v2] Perform bounds checking on RawSample
I made the mistake of setting this to zero and then bringing my
pen into proximity. Ooops. X crashed. Looks like mathematics
still can't handle getting the average of zero things ;)
Signed-off-by: Jason Gerecke
---
Changes in v2:
- Modified patch subject to better match 2nd change
- Add lower and upper bounds checking into wcmParseOptions
src/wcmValidateDevice.c |6 ++
src/wcmXCommand.c |2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
index 755d417..af6b8d2 100644
--- a/src/wcmValidateDevice.c
+++ b/src/wcmValidateDevice.c
@@ -539,6 +539,12 @@ int wcmParseOptions(InputInfoPtr pInfo, int hotplugged)
common->wcmRawSample = xf86SetIntOption(pInfo->options, "RawSample",
common->wcmRawSample);
+ if (common->wcmRawSample < 1 || common->wcmRawSample >
XWACOM_MAX_SAMPLES)
+ {
+ xf86Msg(X_ERROR, "%s: RawSample setting '%d' out of range
[1..%d]. Using default.\n",
+ pInfo->name, common->wcmRawSample, XWACOM_MAX_SAMPLES);
+ common->wcmRawSample = DEFAULT_SAMPLES;
+ }
common->wcmSuppress = xf86SetIntOption(pInfo->options, "Suppress",
common->wcmSuppress);
diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c
index 4207dbe..e589e37 100644
--- a/src/wcmXCommand.c
+++ b/src/wcmXCommand.c
@@ -620,7 +620,7 @@ int wcmSetProperty(DeviceIntPtr dev, Atom property,
XIPropertyValuePtr prop,
if ((values[0] < 0) || (values[0] > 100))
return BadValue;
- if ((values[1] < 0) || (values[1] > XWACOM_MAX_SAMPLES))
+ if ((values[1] < 1) || (values[1] > XWACOM_MAX_SAMPLES))
return BadValue;
if (!checkonly)
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH] Remove XWACOM_MAX_SAMPLES
XWACOM_MAX_SAMPLES is a duplicate of MAX_SAMPLES, and appears to have
no reason to be included in the Xwacom.h header. We remove it and
retarget all references.
Signed-off-by: Jason Gerecke
---
include/Xwacom.h|2 --
src/wcmValidateDevice.c |4 ++--
src/wcmXCommand.c |2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/Xwacom.h b/include/Xwacom.h
index b06e8ff..3ca8573 100644
--- a/include/Xwacom.h
+++ b/include/Xwacom.h
@@ -43,8 +43,6 @@
#define ROTATE_CCW 2
#define ROTATE_HALF3
-#define XWACOM_MAX_SAMPLES 20
-
/* The following flags are used for button action property values to mark
* the type of event that should be emitted when that button is pressed;
* combined together they form an Action Code (AC). Each button has up to
diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
index af6b8d2..0d838fb 100644
--- a/src/wcmValidateDevice.c
+++ b/src/wcmValidateDevice.c
@@ -539,10 +539,10 @@ int wcmParseOptions(InputInfoPtr pInfo, int hotplugged)
common->wcmRawSample = xf86SetIntOption(pInfo->options, "RawSample",
common->wcmRawSample);
- if (common->wcmRawSample < 1 || common->wcmRawSample >
XWACOM_MAX_SAMPLES)
+ if (common->wcmRawSample < 1 || common->wcmRawSample > MAX_SAMPLES)
{
xf86Msg(X_ERROR, "%s: RawSample setting '%d' out of range
[1..%d]. Using default.\n",
- pInfo->name, common->wcmRawSample, XWACOM_MAX_SAMPLES);
+ pInfo->name, common->wcmRawSample, MAX_SAMPLES);
common->wcmRawSample = DEFAULT_SAMPLES;
}
diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c
index e589e37..4f702b7 100644
--- a/src/wcmXCommand.c
+++ b/src/wcmXCommand.c
@@ -620,7 +620,7 @@ int wcmSetProperty(DeviceIntPtr dev, Atom property,
XIPropertyValuePtr prop,
if ((values[0] < 0) || (values[0] > 100))
return BadValue;
- if ((values[1] < 1) || (values[1] > XWACOM_MAX_SAMPLES))
+ if ((values[1] < 1) || (values[1] > MAX_SAMPLES))
return BadValue;
if (!checkonly)
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v2] Require PROP_FLAG_BOOLEAN params to be 'off' or 'on
This patch set breaks apart the referenced patch into its component changes as requested by Peter. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v2 2/5] Detect boolean conversion failure in convert_value_from_user
Properties with PROP_FLAG_BOOLEAN set can only take on a restricted
set of values. We detect if the string matches any of the allowed
values and convert if possible. If not possible, the caller is notified.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 4497e72..2a819c7 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1440,10 +1440,15 @@ error:
*/
static Bool convert_value_from_user(param_t *param, char *value, int
*return_value)
{
- if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value, "off") ==
0)
+ if (param->prop_flags & PROP_FLAG_BOOLEAN)
+ {
+ if (strcmp(value, "off") == 0)
*return_value = 0;
- else if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value, "on")
== 0)
+ else if (strcmp(value, "on") == 0)
*return_value = 1;
+ else
+ return False;
+ }
else
*return_value = atoi(value);
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v2 1/5] Change signature of convert_value_from_user
Have it return true/false to indicate conversion success/failure.
Note that in its current state the function cannot tell if there
was a conversion failure...
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 47 +++
1 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 3435389..4497e72 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1425,18 +1425,29 @@ error:
return;
}
-static int convert_value_from_user(param_t *param, char *value)
-{
- int val;
+/**
+ * Performs intelligent string->int conversion. In addition to converting
strings
+ * of digits into their corresponding integer values, it converts special
string
+ * constants such as "off" (0) and "on" (1).
+ *
+ * The caller is expected to allocate and free memory for return_value.
+ *
+ * @param paramthe property paramaters
+ * @param valuethe string to be converted
+ * @param[out] return_value the integer representation of the 'value' parameter
+ * @return TRUE if the conversion succeeded, FALSE otherwise
+ */
+static Bool convert_value_from_user(param_t *param, char *value, int
*return_value)
+{
if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value, "off") ==
0)
- val = 0;
+ *return_value = 0;
else if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value, "on")
== 0)
- val = 1;
+ *return_value = 1;
else
- val = atoi(value);
+ *return_value = atoi(value);
- return val;
+ return True;
}
static void set(Display *dpy, int argc, char **argv)
@@ -1512,7 +1523,27 @@ static void set(Display *dpy, int argc, char **argv)
for (i = 0; i < nvals; i++)
{
- val = convert_value_from_user(param, values[i]);
+ Bool success;
+ int val;
+ int *retval;
+
+ retval = calloc(1, sizeof(int));
+ if (!retval)
+ {
+ fprintf(stderr, "calloc failed\n");
+ exit(EXIT_FAILURE);
+ }
+
+ success = convert_value_from_user(param, values[i], retval);
+ val = *retval;
+ free(retval);
+
+ if (!success)
+ {
+ fprintf(stderr, "'%s' is not a valid value for the '%s'
property.\n",
+ values[i], param->name);
+ goto out;
+ }
switch(param->prop_format)
{
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v2 5/5] Add tests for convert_value_from_user
Some basic tests to ensure booleans and non-booleans act like we
want them to.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index d867982..f7b2e58 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -2238,6 +2238,48 @@ static void test_parameter_number(void)
g_assert(ArrayLength(deprecated_parameters) == 16);
}
+static void test_convert_value_from_user(void)
+{
+ param_t test_nonbool =
+ {
+ .name = "Test",
+ .desc = "NOT A REAL PARAMETER",
+ .prop_flags = 0,
+ };
+
+ param_t test_bool =
+ {
+ .name = "Test",
+ .desc = "NOT A REAL PARAMETER",
+ .prop_flags = PROP_FLAG_BOOLEAN,
+ };
+
+ int *retval = calloc(1, sizeof(int));
+ if (!retval)
+ {
+ fprintf(stderr, "calloc failed\n");
+ exit(EXIT_FAILURE);
+ }
+
+ g_assert(convert_value_from_user(&test_nonbool, "1", retval) == True);
+ g_assert(convert_value_from_user(&test_nonbool, "-8", retval) == True);
+ g_assert(convert_value_from_user(&test_nonbool, "+314", retval) ==
True);
+ g_assert(convert_value_from_user(&test_nonbool, "36893488147419103232",
retval) == False); //2^65 > MAX_INT
+ g_assert(convert_value_from_user(&test_nonbool, "123abc", retval) ==
False);
+ g_assert(convert_value_from_user(&test_nonbool, "123 abc", retval) ==
False);
+
+ g_assert(convert_value_from_user(&test_bool, "true", retval) == True);
+ g_assert(convert_value_from_user(&test_bool, "On", retval) == True);
+ g_assert(convert_value_from_user(&test_bool, "oFf", retval) == True);
+ g_assert(convert_value_from_user(&test_bool, "FALSE", retval) == True);
+ g_assert(convert_value_from_user(&test_bool, "0", retval) == False);
+ g_assert(convert_value_from_user(&test_bool, "1", retval) == False);
+ g_assert(convert_value_from_user(&test_bool, " on", retval) == False);
+ g_assert(convert_value_from_user(&test_bool, "off ", retval) == False);
+
+ free(retval);
+}
+
int main(int argc, char** argv)
{
@@ -2245,6 +2287,7 @@ int main(int argc, char** argv)
g_test_add_func("/xsetwacom/parameter_number", test_parameter_number);
g_test_add_func("/xsetwacom/is_modifier", test_is_modifier);
g_test_add_func("/xsetwacom/convert_specialkey",
test_convert_specialkey);
+ g_test_add_func("/xsetwacom/convert_value_from_user",
test_convert_value_from_user);
return g_test_run();
}
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v2 3/5] Use strtol instead of atoi in convert_value_from_user
atoi provides only the most basic string conversion capabilities,
and makes determining if conversion was successful difficult (both
"abc" and "0" would return 0). We use strtol and checks to ensure
that it converted the entire string sucessfully before returning True.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 2a819c7..ee353fa 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -24,6 +24,8 @@
#include
#include "Xwacom.h"
+#include
+#include
#include
#include
#include
@@ -1450,7 +1452,15 @@ static Bool convert_value_from_user(param_t *param, char
*value, int *return_val
return False;
}
else
- *return_value = atoi(value);
+ {
+ char *end;
+ long conversion = strtol(value, &end, 10);
+ if (end == value || *end != '\0' || errno == ERANGE ||
+ conversion < INT_MIN || conversion > INT_MAX)
+ return False;
+
+ *return_value = (int)conversion;
+ }
return True;
}
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v2 4/5] Expand recognized boolean input for convert_value_from_user
We remove the case sensitivity requirement for off/on and also
allow the use of "true" and "false"
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index ee353fa..d867982 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1431,7 +1431,7 @@ error:
/**
* Performs intelligent string->int conversion. In addition to converting
strings
* of digits into their corresponding integer values, it converts special
string
- * constants such as "off" (0) and "on" (1).
+ * constants such as "off" or "false" (0) and "on" or "true" (1).
*
* The caller is expected to allocate and free memory for return_value.
*
@@ -1444,9 +1444,9 @@ static Bool convert_value_from_user(param_t *param, char
*value, int *return_val
{
if (param->prop_flags & PROP_FLAG_BOOLEAN)
{
- if (strcmp(value, "off") == 0)
+ if (strcasecmp(value, "off") == 0 || strcasecmp(value, "false")
== 0)
*return_value = 0;
- else if (strcmp(value, "on") == 0)
+ else if (strcasecmp(value, "on") == 0 || strcasecmp(value,
"true") == 0)
*return_value = 1;
else
return False;
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH] Fix button assignment bug introduced in 22bc3028
I just noticed I was unable to map button presses to keys and after some investigation (yay git bisect!) found the following commit caused the bug: 22bc3028effbdc79d426c0b3dcf586734d4c7532 It appears the original comment accompaning the argc check was wrong. The original 'if' statement was "if (argc > 0)" which would imply XChangeDeviceProperty was to be called if we were *setting* a property, not *unsetting*. This patch should probably be checked more thoroughly since I haven't actually tried to figure out how this function works. At first glance, it seems like the first "nitems" hunk of a6b9416148e5423c5a0c2632d88dbee5589615 was actually on the right track... Signed-off-by: Jason Gerecke --- tools/xsetwacom.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c index 3435389..1d7265d 100644 --- a/tools/xsetwacom.c +++ b/tools/xsetwacom.c @@ -1194,7 +1194,7 @@ static void special_map_property(Display *dpy, XDevice *dev, Atom btnact_prop, i fprintf(stderr, "Cannot parse keyword '%s'\n", words[i]); } - if (unset_prop) + if (!unset_prop) XChangeDeviceProperty(dpy, dev, prop, XA_INTEGER, 32, PropModeReplace, (unsigned char*)data, nitems); -- 1.7.1 -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH] Fix button assignment bug introduced in 22bc3028
On Sun, Mar 13, 2011 at 11:00 PM, Peter Hutterer wrote: > On Fri, Mar 11, 2011 at 04:02:56PM -0800, Jason Gerecke wrote: >> I just noticed I was unable to map button presses to keys and after >> some investigation (yay git bisect!) found the following commit >> caused the bug: >> >> 22bc3028effbdc79d426c0b3dcf586734d4c7532 >> >> It appears the original comment accompaning the argc check was wrong. >> The original 'if' statement was "if (argc > 0)" which would imply >> XChangeDeviceProperty was to be called if we were *setting* a property, >> not *unsetting*. >> >> This patch should probably be checked more thoroughly since I haven't >> actually tried to figure out how this function works. At first glance, >> it seems like the first "nitems" hunk of >> a6b9416148e5423c5a0c2632d88dbee5589615 > > I don't seem to have this ref in my tree. is this one that hasn't been > applied yet? > > Patch looks good though, but I do wonder where this sha came from. > > Cheers, > Peter > > Looks like I somehow missed the first two hex digits in the SHA. Should be eba6b9416148e5423c5a0c2632d88dbee5589615. The commit subject was "xsetwacom: fix button action unsetting". Regardless, after spending far too much time figuring out this function I think this actually needs to be a patch set... What we want to happen is: 1. If the parse fails, leave the function without applying any changes. 2. If we parsed something, call XChangeDeviceProperty for 'param' to apply the necessary side-effects. If we parsed nothing, restore the default and call XDeleteDeviceProperty to remove 'param'. 3. Call XChangeDeviceProperty for 'btnact_prop' to update the master list. Simply going with "!unset_prop" or "nitems > 0" (or any boolean combination of the two) will get button assignments working again, but leaves a small hole in #2. I'm going to withdraw this patch for now -- going with "nitems > 0" is actually more in line with what we need in the end. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v3 1/5] Change signature of convert_value_from_user
Have it return true/false to indicate conversion success/failure.
Note that in its current state the function cannot tell if there
was a conversion failure...
Signed-off-by: Jason Gerecke
---
Changes from v2:
* Use &val instead of allocating memory
tools/xsetwacom.c | 36
1 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 3435389..c1e7e36 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1425,18 +1425,29 @@ error:
return;
}
-static int convert_value_from_user(param_t *param, char *value)
-{
- int val;
+/**
+ * Performs intelligent string->int conversion. In addition to converting
strings
+ * of digits into their corresponding integer values, it converts special
string
+ * constants such as "off" (0) and "on" (1).
+ *
+ * The caller is expected to allocate and free memory for return_value.
+ *
+ * @param paramthe property paramaters
+ * @param valuethe string to be converted
+ * @param[out] return_value the integer representation of the 'value' parameter
+ * @return TRUE if the conversion succeeded, FALSE otherwise
+ */
+static Bool convert_value_from_user(param_t *param, char *value, int
*return_value)
+{
if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value, "off") ==
0)
- val = 0;
+ *return_value = 0;
else if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value, "on")
== 0)
- val = 1;
+ *return_value = 1;
else
- val = atoi(value);
+ *return_value = atoi(value);
- return val;
+ return True;
}
static void set(Display *dpy, int argc, char **argv)
@@ -1512,7 +1523,16 @@ static void set(Display *dpy, int argc, char **argv)
for (i = 0; i < nvals; i++)
{
- val = convert_value_from_user(param, values[i]);
+ Bool success;
+ int val = 0;
+
+ success = convert_value_from_user(param, values[i], &val);
+ if (!success)
+ {
+ fprintf(stderr, "'%s' is not a valid value for the '%s'
property.\n",
+ values[i], param->name);
+ goto out;
+ }
switch(param->prop_format)
{
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v3 5/5] Add tests for convert_value_from_user
Some basic tests to ensure booleans and non-booleans act like we
want them to.
Signed-off-by: Jason Gerecke
---
Changes from v2:
* Use &val instead of allocating memory
tools/xsetwacom.c | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index c9db2e7..8cc7292 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -2227,6 +2227,43 @@ static void test_parameter_number(void)
g_assert(ArrayLength(deprecated_parameters) == 16);
}
+static void test_convert_value_from_user(void)
+{
+ param_t test_nonbool =
+ {
+ .name = "Test",
+ .desc = "NOT A REAL PARAMETER",
+ .prop_flags = 0,
+ };
+
+ param_t test_bool =
+ {
+ .name = "Test",
+ .desc = "NOT A REAL PARAMETER",
+ .prop_flags = PROP_FLAG_BOOLEAN,
+ };
+
+ int val;
+
+ g_assert(convert_value_from_user(&test_nonbool, "1", &val) == True);
+ g_assert(convert_value_from_user(&test_nonbool, "-8", &val) == True);
+ g_assert(convert_value_from_user(&test_nonbool, "+314", &val) == True);
+ g_assert(convert_value_from_user(&test_nonbool, "36893488147419103232",
&val) == False); //2^65 > MAX_INT
+ g_assert(convert_value_from_user(&test_nonbool, "123abc", &val) ==
False);
+ g_assert(convert_value_from_user(&test_nonbool, "123 abc", &val) ==
False);
+
+ g_assert(convert_value_from_user(&test_bool, "true", &val) == True);
+ g_assert(convert_value_from_user(&test_bool, "On", &val) == True);
+ g_assert(convert_value_from_user(&test_bool, "oFf", &val) == True);
+ g_assert(convert_value_from_user(&test_bool, "FALSE", &val) == True);
+ g_assert(convert_value_from_user(&test_bool, "0", &val) == False);
+ g_assert(convert_value_from_user(&test_bool, "1", &val) == False);
+ g_assert(convert_value_from_user(&test_bool, " on", &val) == False);
+ g_assert(convert_value_from_user(&test_bool, "off ", &val) == False);
+
+ free(retval);
+}
+
int main(int argc, char** argv)
{
@@ -2234,6 +2271,7 @@ int main(int argc, char** argv)
g_test_add_func("/xsetwacom/parameter_number", test_parameter_number);
g_test_add_func("/xsetwacom/is_modifier", test_is_modifier);
g_test_add_func("/xsetwacom/convert_specialkey",
test_convert_specialkey);
+ g_test_add_func("/xsetwacom/convert_value_from_user",
test_convert_value_from_user);
return g_test_run();
}
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v4 1/5] Change signature of convert_value_from_user
Have it return true/false to indicate conversion success/failure.
Note that in its current state the function cannot tell if there
was a conversion failure...
Signed-off-by: Jason Gerecke
---
Changes from v3:
* Less PEBKAC. (no default needed on our int val...)
tools/xsetwacom.c | 36
1 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index bb120c0..aa95538 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1423,18 +1423,29 @@ error:
return;
}
-static int convert_value_from_user(param_t *param, char *value)
-{
- int val;
+/**
+ * Performs intelligent string->int conversion. In addition to converting
strings
+ * of digits into their corresponding integer values, it converts special
string
+ * constants such as "off" (0) and "on" (1).
+ *
+ * The caller is expected to allocate and free memory for return_value.
+ *
+ * @param paramthe property paramaters
+ * @param valuethe string to be converted
+ * @param[out] return_value the integer representation of the 'value' parameter
+ * @return TRUE if the conversion succeeded, FALSE otherwise
+ */
+static Bool convert_value_from_user(param_t *param, char *value, int
*return_value)
+{
if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value, "off") ==
0)
- val = 0;
+ *return_value = 0;
else if ((param->prop_flags & PROP_FLAG_BOOLEAN) && strcmp(value, "on")
== 0)
- val = 1;
+ *return_value = 1;
else
- val = atoi(value);
+ *return_value = atoi(value);
- return val;
+ return True;
}
static void set(Display *dpy, int argc, char **argv)
@@ -1510,7 +1521,16 @@ static void set(Display *dpy, int argc, char **argv)
for (i = 0; i < nvals; i++)
{
- val = convert_value_from_user(param, values[i]);
+ Bool success;
+ int val;
+
+ success = convert_value_from_user(param, values[i], &val);
+ if (!success)
+ {
+ fprintf(stderr, "'%s' is not a valid value for the '%s'
property.\n",
+ values[i], param->name);
+ goto out;
+ }
switch(param->prop_format)
{
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 1/2] Fix X crash after remapping touchstrips and wheels
Crash first appears in ab311bf20535acd6e7201e024bc311e0e15b5b6b. This commit rewrote wcmUpdateButtonKeyActions with one-indexed arrays in mind and extended the 'keys' array in _WacomDeviceRec to make room. However, the 'wheel_keys' and 'strip_keys' were not updated. Running e.g. `xsetwacom --set pad StripLeftDown button 4` results in a call to wcmUpdateButtonKeyActions. Its call to memset oversteps the array bounds and just happens to zero the 'common' pointer. The next tablet event results in a segfault as the driver tries to dereference the pointer. Signed-off-by: Jason Gerecke --- src/xf86WacomDefs.h | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/src/xf86WacomDefs.h b/src/xf86WacomDefs.h index e80afb0..5f5d969 100644 --- a/src/xf86WacomDefs.h +++ b/src/xf86WacomDefs.h @@ -240,16 +240,18 @@ struct _WacomDeviceRec int wheelup; int wheeldn; /* keystrokes assigned to wheel events (default is the buttons above). -* Order is relup, reldwn, wheelup, wheeldn. */ - unsigned wheel_keys[4][256]; +* Order is relup, reldwn, wheelup, wheeldn. Like 'keys', this array +* is one-indexed */ + unsigned wheel_keys[4+1][256]; int striplup; int stripldn; int striprup; int striprdn; /* keystrokes assigned to strip events (default is the buttons above). -* Order is striplup, stripldn, striprup, striprdn. */ - unsigned strip_keys[4][256]; +* Order is striplup, stripldn, striprup, striprdn. Like 'keys', this +* array is one-indexed */ + unsigned strip_keys[4+1][256]; int nbuttons; /* number of buttons for this subdevice */ int naxes; /* number of axes */ /* FIXME: always 6, and the code relies on that... */ -- 1.7.1 -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 2/2] Clear the correct amount of memory
Though this doesn't result in any bad behavior at the moment, it
could cause some serious headaches in the future.
Signed-off-by: Jason Gerecke
---
src/wcmXCommand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c
index 4f702b7..29b20ab 100644
--- a/src/wcmXCommand.c
+++ b/src/wcmXCommand.c
@@ -300,7 +300,7 @@ static void wcmUpdateButtonKeyActions(DeviceIntPtr dev,
XIPropertyValuePtr prop,
for (i = 0; i < prop->size; i++)
{
/* keys is one based array to align with X buttons */
- memset(keys[i+1], 0, sizeof(keys[i]));
+ memset(keys[i+1], 0, sizeof(keys[i+1]));
if (!values[i])
continue;
--
1.7.1
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 1/2] Fix X crash after remapping touchstrips and wheels
*grumble, grumble* There has got to be a GMail extension that makes "Reply to all" more prominent than "Reply" for lists... On Mon, Mar 21, 2011 at 9:11 PM, Peter Hutterer wrote: > On Fri, Mar 18, 2011 at 06:01:16PM -0700, Jason Gerecke wrote: >> Crash first appears in ab311bf20535acd6e7201e024bc311e0e15b5b6b. >> This commit rewrote wcmUpdateButtonKeyActions with one-indexed >> arrays in mind and extended the 'keys' array in _WacomDeviceRec >> to make room. However, the 'wheel_keys' and 'strip_keys' were >> not updated. >> >> Running e.g. `xsetwacom --set pad StripLeftDown button 4` results >> in a call to wcmUpdateButtonKeyActions. Its call to memset oversteps >> the array bounds and just happens to zero the 'common' pointer. The >> next tablet event results in a segfault as the driver tries to >> dereference the pointer. > > doh. i think some audit in the driver is needed to switch to either > one-indexed or zero-indexed buttons everywhere. right now, we seem to have > both mixed and that's rather fatal. > That would probably be good a good idea. Any idea why one-indexing was switched to? I guess it'd make writing user interface code easier (you just index into the button array at the number they give), but violates the principle of least astonishment... > are you sure this is the right patch though? wcmCommon.c seems to use the > right indices (minus the patch I've just CC'd you on). so it looks like > there's more out of whack than just the array size. > wcmCommon.c might be using the right indicies, or it might not. It's difficult to say at the moment since strip mapping (and I assume wheel mapping since they're virtually identical) stopped working back in August with commit eea34fad. Between fixing that and switching everything to use zero- or one-indexed arrays, this bit of code needs some love. This patch was more of a stop-gap to fix the crash before I got around to restoring mapping functionality. Hopefully I can have everything done before the April 1 freeze (not sure how much code I'll need to touch, so I'd rather not try to slip it in after...) but I'm not sure I have the time. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH] wcmUSB: change MOD_BUTTONS macro into a function
On Mon, Mar 21, 2011 at 9:16 PM, Peter Hutterer
wrote:
> +/**
> + * Flip the mask bit in buttons corresponding to btn to the specified state.
> + *
> + * @param buttons The current button mask
> + * @param btn Zero-indexed button number to change
> + * @param state Zero to unset, non-zero to set the mask for the button
> + *
> + * @return The new button mask
> + */
> +static int mod_buttons(int buttons, int btn, int state)
> +{
> + int mask = 1 << btn;
> +
> + if (btn >= sizeof(int))
> + {
> + xf86Msg(X_ERROR, "%s: Invalid button number %d. Insufficient "
> + "storage\n", __func__, btn);
> + return buttons;
> + }
> +
> + if (state)
> + buttons |= mask;
> + else
> + buttons &= ~mask;
> +
> + return buttons;
> +}
>
Would it be too nitpicky of me to want the shift occuring after the
test? I do prefer it when functions fail as fast as possible...
Jason
---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 1/2] Fix X crash after remapping touchstrips and wheels
As I'm working on the X11 wheel mapping, I'm finding a few weird quirks in the code. I pretty much understand 'how' things work, but I'm not sure why some things are the way they are... 1. Why does WACOM_PROP_BUTTON_ACTIONS have room for only 16 buttons, yet priv->btn_actions (storing the same data) have space for 32? The functional difference between WCM_MAX_BUTTONS and WCM_MAX_MOUSE_BUTTONS is not clear. 2. Why maintain a seperate raw button codepath when the "actions" codepath already does the same thing when given a 'button' action? 3. Why does xsetwacom take X11 buttons as the first argument to "Button X"? I can't be alone in thinking it was weird my cintiq was missing two buttons (6 & 7) and that two other buttons (4 & 5) only responded to changes via the Strip(Left|Right)(Up|Down) command. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 1/2] Fix X crash after remapping touchstrips and wheels
On Wed, Mar 23, 2011 at 6:30 PM, Peter Hutterer wrote: > On Wed, Mar 23, 2011 at 12:58:21PM -0700, Jason Gerecke wrote: >> As I'm working on the X11 wheel mapping, I'm finding a few weird >> quirks in the code. I pretty much understand 'how' things work, but >> I'm not sure why some things are the way they are... >> >> 1. Why does WACOM_PROP_BUTTON_ACTIONS have room for only 16 buttons, >> yet priv->btn_actions (storing the same data) have space for 32? The >> functional difference between WCM_MAX_BUTTONS and >> WCM_MAX_MOUSE_BUTTONS is not clear. > > 7d149431c63c43c0ab5b046387b565488ea3d159 has some explanation what > WCM_MAX_BUTTONS is, but I can't remember any more details. > They were introduced in 2debfce6f9d6bfb206da2e1711d04f42cddd71e1, but > the comments in that commit don't really clarify things for me. > I was hoping it was related to some kind of X server limitation, but if you don't have any ideas... I guess I'll stare at it and scratch my head some more :D >> 2. Why maintain a seperate raw button codepath when the "actions" >> codepath already does the same thing when given a 'button' action? > > simplicity mainly (and the raw path was there before). note that the button > action can be combined with a key action, so "key +ctrl button 1 key -ctrl" > is a valid action. > Would there be any objection to me tearing the raw path out of the driver? The two paths are very similar, and nearly duplicate each other. The only substantial difference is that non-raw buttons have their keys[] interpreted. >> 3. Why does xsetwacom take X11 buttons as the first argument to >> "Button X"? I can't be alone in thinking it was weird my cintiq was >> missing two buttons (6 & 7) and that two other buttons (4 & 5) only >> responded to changes via the Strip(Left|Right)(Up|Down) command. > > This should be documented better. Button mapping in X is complicated to say > the least. http://who-t.blogspot.com/2009/06/button-mapping-in-x.html > > xsetwacom takes x11 buttons because for simple button mappings, it uses > XSetDeviceButtonMappings (which requires X buttons). > X buttons have the advantage of being easy to debug (for users). A > driver-internal button mapping is private to the driver and hard to figure > out at the best of times. e.g. which button on your device is Button 1? > running xev or xinput will only tell you the logical button 1, not the > physical button 1. > That's a pretty good argument, I suppose. It seems ugly and has non-intuitive side-effects, but it has its benefits. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Area Option Relative
On Thu, Mar 24, 2011 at 12:29 PM, Cedric Sodhi wrote: > Hello, I find it rather inconvenient that the Area Option (rather recent > GIT) appears to depend on the output device and is relative to the > screen area. > Meaning that the same Area Options have different effects when I use two > different screen setups. > > Is there a particular reason why that is the case? I think the Area > Option should be independent of that. > > -- > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > ___ > Linuxwacom-devel mailing list > Linuxwacom-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel > Could you explain the problem in a little more detail? Does Area have a different effect than setting TopX/TopY/BottomX/BottomY used to? Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 1/4] Return from function on parse error
If the arguments to this function are only parseable up to a point,
the function prints a warning but still makes the (partial!) requested
change. For example, if the user runs:
xsetwacom --set 10 Button 1 "key +a notakeyword -a"
The program prints a warning about it not recognizing "notakeyword" and
maps Button 1 to "key +a". Instead of making partial changes, xsetwacom
should instead bail at the first sign of a problem.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 130abb5..80766d1 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1193,7 +1193,10 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
}
if (!keyword_found)
+ {
fprintf(stderr, "Cannot parse keyword '%s'\n",
words[i]);
+ return;
+ }
}
if (unset_prop || nitems > 0)
--
1.7.4.1
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 4/4] Make set/unset code easier to understand
Between the parsing code seperating the two halves of set/unset
and the code being confusing in general, I've rewritten this
to hopefully make its operation a little clearer for the next
person.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 108
1 files changed, 66 insertions(+), 42 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 70331b5..9f88e6d 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1116,6 +1116,24 @@ static int convert_wheel_prop(Display *dpy, XDevice
*dev, Atom btnact_prop)
}
+/**
+ * Maps sub-properties (e.g. the 3rd button in WACOM_PROP_BUTTON_ACTIONS)
+ * to actions. This function leverages the several available parsing
+ * functions to convert plain-text descriptions into a list of actions
+ * the driver can understand.
+ *
+ * Once we have a list of actions, we can store it in the appropriate
+ * child property. If none exists, we must first create one and update
+ * the parent list. If we want no action to occur, we can delete the
+ * child property and have the parent point to '0' instead.
+ *
+ * @param dpy X display we want to query
+ * @param dev X device we want to modify
+ * @param btnact_prop Parent property
+ * @param offset Offset into the parent's list of child properties
+ * @param argcNumber of command line arguments we've been passed
+ * @param argvCommand line arguments we need to parse
+ */
static void special_map_property(Display *dpy, XDevice *dev, Atom btnact_prop,
int offset, int argc, char **argv)
{
unsigned long *data, *btnact_data;
@@ -1126,43 +1144,6 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
int nwords = 0;
char **words = NULL;
- XGetDeviceProperty(dpy, dev, btnact_prop, 0, 100, False,
- AnyPropertyType, &type, &format, &btnact_nitems,
- &bytes_after, (unsigned char**)&btnact_data);
-
- if (offset > btnact_nitems)
- return;
-
- /* Prop is currently 8 bit integer, i.e. plain button
-* mappings. Convert to 32 bit Atom actions first.
-*/
- if (format == 8 && type == XA_INTEGER)
- {
- if (convert_wheel_prop(dpy, dev, btnact_prop))
- return;
-
- XGetDeviceProperty(dpy, dev, btnact_prop, 0, 100, False,
- AnyPropertyType, &type, &format,
- &btnact_nitems, &bytes_after,
- (unsigned char**)&btnact_data);
- }
-
- if (argc == 0) /* unset property */
- {
- prop = btnact_data[offset];
- btnact_data[offset] = 0;
- } else if (btnact_data[offset])
- /* some atom already assigned, modify that */
- prop = btnact_data[offset];
- else
- {
- char buff[64];
- sprintf(buff, "Wacom button action %d", (offset + 1));
- prop = XInternAtom(dpy, buff, False);
-
- btnact_data[offset] = prop;
- }
-
data = calloc(sizeof(long), 256);
nitems = 0;
@@ -1197,18 +1178,61 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
}
}
+ /* obtain the button actions Atom */
+ XGetDeviceProperty(dpy, dev, btnact_prop, 0, 100, False,
+ AnyPropertyType, &type, &format, &btnact_nitems,
+ &bytes_after, (unsigned char**)&btnact_data);
+
+ if (offset > btnact_nitems)
+ return;
+
+ if (format == 8 && type == XA_INTEGER)
+ {
+ /* Prop is currently 8 bit integer, i.e. plain button
+* mappings. Convert to 32 bit Atom actions first.
+*/
+ if (convert_wheel_prop(dpy, dev, btnact_prop))
+ return;
+
+ XGetDeviceProperty(dpy, dev, btnact_prop, 0, 100, False,
+ AnyPropertyType, &type, &format,
+ &btnact_nitems, &bytes_after,
+ (unsigned char**)&btnact_data);
+ }
+
+ /* set or unset the property */
+ prop = btnact_data[offset];
if (nitems > 0)
+ { //Setting a new or existing property
+ if (!prop)
+ {
+ char buff[64];
+ sprintf(buff, "Wacom button action %d", (offset + 1));
+ prop = XInternAtom(dpy, buff, False);
+ btnact_data[offset] = prop;
+
+ XChangeDeviceProperty(dpy, dev, btnact_prop, XA_A
[Linuxwacom-devel] [PATCH 2/4] Make parse error more helpful
When a set of arguments cannot be parsed, knowing the word that
did not make sense doesn't help if you've used it more than once.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 80766d1..fea79d0 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1194,7 +1194,7 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
if (!keyword_found)
{
- fprintf(stderr, "Cannot parse keyword '%s'\n",
words[i]);
+ fprintf(stderr, "Cannot parse keyword '%s' at position
%d\n", words[i], i+1);
return;
}
}
--
1.7.4.1
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 3/4] Don't use unset_prop
We don't need to bother changing the device property if
we're unsetting since we're just going to be deleting it
anyway.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index fea79d0..70331b5 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1125,7 +1125,6 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
int i;
int nwords = 0;
char **words = NULL;
- int unset_prop = 0;
XGetDeviceProperty(dpy, dev, btnact_prop, 0, 100, False,
AnyPropertyType, &type, &format, &btnact_nitems,
@@ -1152,7 +1151,6 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
{
prop = btnact_data[offset];
btnact_data[offset] = 0;
- unset_prop = 1;
} else if (btnact_data[offset])
/* some atom already assigned, modify that */
prop = btnact_data[offset];
@@ -1199,7 +1197,7 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
}
}
- if (unset_prop || nitems > 0)
+ if (nitems > 0)
XChangeDeviceProperty(dpy, dev, prop, XA_INTEGER, 32,
PropModeReplace,
(unsigned char*)data, nitems);
--
1.7.4.1
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 4v2/4] Make set/unset code easier to understand
Between the parsing code seperating the two halves of set/unset
and the code being confusing in general, I've rewritten this
to hopefully make its operation a little clearer for the next
person.
Signed-off-by: Jason Gerecke
---
Changes:
* Broke parsing code out into its own function. Might as well
go whole-hog for readability.
tools/xsetwacom.c | 159 ++--
1 files changed, 104 insertions(+), 55 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 70331b5..9860e57 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1115,59 +1115,30 @@ static int convert_wheel_prop(Display *dpy, XDevice
*dev, Atom btnact_prop)
return 0;
}
-
-static void special_map_property(Display *dpy, XDevice *dev, Atom btnact_prop,
int offset, int argc, char **argv)
+/**
+ * This function parses the given strings to produce a list of actions that
+ * the driver can carry out. We first combine the strings and then split
+ * on spaces to produce a wordlist. Begining with the first word, we let each
+ * registered keyword parser try to parse the string; if one succeeds in
+ * parsing a portion, we jump ahead to the first word it could not parse
+ * and repeat the process. Each parser builds up the list of actions with
+ * those commands it can interpret.
+ *
+ * @param dpy X11 display to query
+ * @param argc Length of argv
+ * @param argv String data to be parsed
+ * @param data Parsed action data
+ * @return 'true' if the whole string was parsed sucessfully, else 'false'
+ */
+static Bool parse_actions(Display *dpy, int argc, char **argv, unsigned long*
data, unsigned long *nitems)
{
- unsigned long *data, *btnact_data;
- Atom type, prop = 0;
- int format;
- unsigned long btnact_nitems, nitems, bytes_after;
- int i;
- int nwords = 0;
+ int i;
+ int nwords = 0;
char **words = NULL;
- XGetDeviceProperty(dpy, dev, btnact_prop, 0, 100, False,
- AnyPropertyType, &type, &format, &btnact_nitems,
- &bytes_after, (unsigned char**)&btnact_data);
-
- if (offset > btnact_nitems)
- return;
-
- /* Prop is currently 8 bit integer, i.e. plain button
-* mappings. Convert to 32 bit Atom actions first.
-*/
- if (format == 8 && type == XA_INTEGER)
- {
- if (convert_wheel_prop(dpy, dev, btnact_prop))
- return;
-
- XGetDeviceProperty(dpy, dev, btnact_prop, 0, 100, False,
- AnyPropertyType, &type, &format,
- &btnact_nitems, &bytes_after,
- (unsigned char**)&btnact_data);
- }
-
- if (argc == 0) /* unset property */
- {
- prop = btnact_data[offset];
- btnact_data[offset] = 0;
- } else if (btnact_data[offset])
- /* some atom already assigned, modify that */
- prop = btnact_data[offset];
- else
- {
- char buff[64];
- sprintf(buff, "Wacom button action %d", (offset + 1));
- prop = XInternAtom(dpy, buff, False);
-
- btnact_data[offset] = prop;
- }
-
- data = calloc(sizeof(long), 256);
- nitems = 0;
-
/* translate cmdline commands */
words = strjoinsplit(argc, argv, &nwords);
+
for (i = 0; i < nwords; i++)
{
int j = 0;
@@ -1180,7 +1151,7 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
{
parsed = keywords[j].func(dpy, nwords - i - 1,
&words[i + 1],
- &nitems, data);
+ nitems, data);
i += parsed;
keyword_found = 1;
}
@@ -1193,22 +1164,100 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
if (!keyword_found)
{
fprintf(stderr, "Cannot parse keyword '%s' at position
%d\n", words[i], i+1);
- return;
+ return False;
}
}
+ free(words);
+
+ return True;
+}
+
+/**
+ * Maps sub-properties (e.g. the 3rd button in WACOM_PROP_BUTTON_ACTIONS)
+ * to actions. This function leverages the several available parsing
+ * functions to convert plain-text descriptions into a list of actions
+ * the driver can understand.
+ *
+ * Once we have a list of actions, we can store it in the appropriate
+ * child property.
Re: [Linuxwacom-devel] [PATCH 2/4] Make parse error more helpful
On Sun, Mar 27, 2011 at 10:25 PM, Peter Hutterer
wrote:
> On Thu, Mar 24, 2011 at 06:02:54PM -0700, Jason Gerecke wrote:
>> When a set of arguments cannot be parsed, knowing the word that
>> did not make sense doesn't help if you've used it more than once.
>>
>> Signed-off-by: Jason Gerecke
>> ---
>> tools/xsetwacom.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
>> index 80766d1..fea79d0 100644
>> --- a/tools/xsetwacom.c
>> +++ b/tools/xsetwacom.c
>> @@ -1194,7 +1194,7 @@ static void special_map_property(Display *dpy, XDevice
>> *dev, Atom btnact_prop, i
>>
>> if (!keyword_found)
>> {
>> - fprintf(stderr, "Cannot parse keyword '%s'\n",
>> words[i]);
>> + fprintf(stderr, "Cannot parse keyword '%s' at position
>> %d\n", words[i], i+1);
>
>
> not that it really matters, but is there any way a keyword can succeed once
> and then fail at the second position?
>
> Cheers,
> Peter
>
>> return;
>> }
>> }
>> --
>> 1.7.4.1
>>
>>
>> --
>> Enable your software for Intel(R) Active Management Technology to meet the
>> growing manageability and security demands of your customers. Businesses
>> are taking advantage of Intel(R) vPro (TM) technology - will your software
>> be a part of the solution? Download the Intel(R) Manageability Checker
>> today! http://p.sf.net/sfu/intel-dev2devmar
>> ___
>> Linuxwacom-devel mailing list
>> Linuxwacom-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
>>
>
I wrote this patch while intentionally trying to break things, so it
may not actually be needed. Its pretty easy to come up with cases
(define 'key' actions, 'button' actions, and then forget to specify
'key' before giving more key actions), though they're pretty
pathological.
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] Change hardcoded string to already-defined constant
WACOM_PROP_BUTTON_ACTIONS is already defined in wacom-properties.h
Lets use it instead of all those magic constants.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 9df0403..1cc3da9 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -126,6 +126,7 @@ static param_t parameters[] =
{
.name = "Button",
.desc = "X11 event to which the given button should be mapped.
",
+ .prop_name = WACOM_PROP_BUTTON_ACTIONS,
.set_func = map_button,
.get_func = get_button,
},
@@ -1298,7 +1299,7 @@ static void special_map_buttons(Display *dpy, XDevice
*dev, param_t* param,
TRACE("Special %s map for device %ld.\n", param->name, dev->device_id);
- btnact_prop = XInternAtom(dpy, "Wacom Button Actions", True);
+ btnact_prop = XInternAtom(dpy, WACOM_PROP_BUTTON_ACTIONS, True);
if (!btnact_prop)
return;
@@ -1726,7 +1727,7 @@ static int get_special_button_map(Display *dpy, XDevice
*dev,
int i;
char buff[1024] = {0};
- btnact_prop = XInternAtom(dpy, "Wacom Button Actions", True);
+ btnact_prop = XInternAtom(dpy, WACOM_PROP_BUTTON_ACTIONS, True);
if (!btnact_prop)
return 0;
--
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] Area Option Relative
On Sun, Mar 27, 2011 at 1:56 AM, Cedric Sodhi wrote: > I'm not sure whether Area has a different effect than (Top|Bottom)(X|Y) > used to have, as I don't have the old version to compare. Again the > problem: > > If I set the same "Area" on two different screen sizes, it has two > different effects. > > Example: > > When I set "Area " so that the pad maps to my laptop-screen when > only that screen is on, I get a proper mapping. > > But when I set the same "Area " when an external Monitor is > activated the mapping changes. > > > On Thu, Mar 24, 2011 at 12:57:37PM -0700, Jason Gerecke wrote: >> On Thu, Mar 24, 2011 at 12:29 PM, Cedric Sodhi wrote: >> > Hello, I find it rather inconvenient that the Area Option (rather recent >> > GIT) appears to depend on the output device and is relative to the >> > screen area. >> > Meaning that the same Area Options have different effects when I use two >> > different screen setups. >> > >> > Is there a particular reason why that is the case? I think the Area >> > Option should be independent of that. >> > >> > -- >> > Enable your software for Intel(R) Active Management Technology to meet the >> > growing manageability and security demands of your customers. Businesses >> > are taking advantage of Intel(R) vPro (TM) technology - will your software >> > be a part of the solution? Download the Intel(R) Manageability Checker >> > today! http://p.sf.net/sfu/intel-dev2devmar >> > ___ >> > Linuxwacom-devel mailing list >> > Linuxwacom-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel >> > >> >> Could you explain the problem in a little more detail? Does Area have >> a different effect than setting TopX/TopY/BottomX/BottomY used to? >> >> Jason >> >> --- >> Day xee-nee-svsh duu-'ushtlh-ts'it; >> nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. >> Huu-chan xuu naa~-gha. >> >> -- >> Enable your software for Intel(R) Active Management Technology to meet the >> growing manageability and security demands of your customers. Businesses >> are taking advantage of Intel(R) vPro (TM) technology - will your software >> be a part of the solution? Download the Intel(R) Manageability Checker >> today! http://p.sf.net/sfu/intel-dev2devmar >> ___ >> Linuxwacom-devel mailing list >> Linuxwacom-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel > > -- > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > ___ > Linuxwacom-devel mailing list > Linuxwacom-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel > I think I'm understanding your problem now. I assume you're trying to keep the tablet mapped to your laptop screen, and are noticing that the "Area" which properly mapped it without the external monitor does not do the job when the monitor is plugged in. "Area" really isn't the tool to do this. It can, but its very inconvenient as you've noticed. Really, Area is supposed to be used to define the active area of your tablet. This would be used (for example) if your tablet has a 4:3 aspect ratio and you're using it on a 16:9 monitor. If you were to trace a perfect circle on the tablet, you'd wind up with an oval on your screen because the driver scales the tablet to fill the screen. By setting Area appropriately, the tablet can utilize a 16:9 portion of its surface instead, getting around that problem. What you're probably looking for is the "MapToOutput" option. By default, the driver maps the defined Area to the entire desktop. If you only want the tablet to work on a specific screen, you can use MapToOutput to tell it which one you want to use. You'll still need to re-run the MapToOutput each time your display settings change though (or if you want
Re: [Linuxwacom-devel] [PATCH] Change hardcoded string to already-defined constant
On Tue, Mar 29, 2011 at 1:08 AM, Peter Hutterer
wrote:
> On Mon, Mar 28, 2011 at 10:06:56AM -0700, Jason Gerecke wrote:
>> WACOM_PROP_BUTTON_ACTIONS is already defined in wacom-properties.h
>> Lets use it instead of all those magic constants.
>>
>> Signed-off-by: Jason Gerecke
>
> applied, thanks.
>
> Cheers,
> Peter
>
>> ---
>> tools/xsetwacom.c | 5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
>> index 9df0403..1cc3da9 100644
>> --- a/tools/xsetwacom.c
>> +++ b/tools/xsetwacom.c
>> @@ -126,6 +126,7 @@ static param_t parameters[] =
>> {
>> .name = "Button",
>> .desc = "X11 event to which the given button should be mapped.
>> ",
>> + .prop_name = WACOM_PROP_BUTTON_ACTIONS,
>> .set_func = map_button,
>> .get_func = get_button,
>> },
>> @@ -1298,7 +1299,7 @@ static void special_map_buttons(Display *dpy, XDevice
>> *dev, param_t* param,
>>
>> TRACE("Special %s map for device %ld.\n", param->name, dev->device_id);
>>
>> - btnact_prop = XInternAtom(dpy, "Wacom Button Actions", True);
>> + btnact_prop = XInternAtom(dpy, WACOM_PROP_BUTTON_ACTIONS, True);
>> if (!btnact_prop)
>> return;
>>
>> @@ -1726,7 +1727,7 @@ static int get_special_button_map(Display *dpy,
>> XDevice *dev,
>> int i;
>> char buff[1024] = {0};
>>
>> - btnact_prop = XInternAtom(dpy, "Wacom Button Actions", True);
>> + btnact_prop = XInternAtom(dpy, WACOM_PROP_BUTTON_ACTIONS, True);
>>
>> if (!btnact_prop)
>> return 0;
>> --
>> 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
>>
>
I'm not seeing it on origin/master... You sure it made it in?
Jason
---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 3/9] Add WACOM_PROP_WHEELBUTTONS to cursor devices
This enables the "Wacom Wheel Buttons" property for cursor devices,
allowing xsetwacom to set (rel|abs)wheel(up|down) actions. I'm not
sure if there are non-puck cursor devices which should *not* have
this enabled, but until somebody says otherwise... :)
Signed-off-by: Jason Gerecke
---
src/wcmXCommand.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c
index 60deb51..64ebb8d 100644
--- a/src/wcmXCommand.c
+++ b/src/wcmXCommand.c
@@ -171,7 +171,10 @@ void InitWcmDeviceProperties(InputInfoPtr pInfo)
values[2] = priv->striprup;
values[3] = priv->striprdn;
prop_strip_buttons = InitWcmAtom(pInfo->dev,
WACOM_PROP_STRIPBUTTONS, 8, 4, values);
+ }
+ if (IsPad(priv) || IsCursor(priv))
+ {
values[0] = priv->relup;
values[1] = priv->reldn;
values[2] = priv->wheelup;
--
1.7.4.1
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 0/9] Patchset overview
This patchset can be broken down into two pieces: * 01..04 Fix miscelaneous bugs - Several small one-off patches * 04..09 Shift xsetwacom away from "buttons" and toward "actions" - Replaces raw button mapping with action button mapping - Fixes set/get issues with simple/raw maps on wheels/strips - Gets things ready for removing raw buttons from the driver itself Jason Gerecke (9): Fix "buttons must be set twice" bug from d650b139 Fix strip/wheel mapping Add WACOM_PROP_WHEELBUTTONS to cursor devices Make it clearer when actions are sent Allow parse_actions to parse simple button maps Remove map_button_simple Remove 'special_map_wheels' and 'special_map_buttons' Merge 'map_wheels' and 'map_button' into a unified 'map_actions' Revamp button/wheel/strip getters src/wcmCommon.c | 21 ++-- src/wcmXCommand.c |3 + tools/xsetwacom.c | 371 +++-- 3 files changed, 233 insertions(+), 162 deletions(-) -- 1.7.4.1 -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 1/9] Fix "buttons must be set twice" bug from d650b139
*facepalm* I simply can't believe I didn't test this, but there's
no denying the bug exists. Looks like the change to 'btnact_prop'
*must* occur after the change to 'prop'. If it happens beforehand,
then the driver appears to be eternally one step behind xsetwacom.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 1cc3da9..f545f95 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1236,17 +1236,17 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
sprintf(buff, "Wacom button action %d", (offset + 1));
prop = XInternAtom(dpy, buff, False);
btnact_data[offset] = prop;
+ }
- XChangeDeviceProperty(dpy, dev, btnact_prop, XA_ATOM,
32,
+
+ XChangeDeviceProperty(dpy, dev, prop, XA_INTEGER, 32,
+ PropModeReplace,
+ (unsigned char*)data, nitems);
+
+ XChangeDeviceProperty(dpy, dev, btnact_prop, XA_ATOM, 32,
PropModeReplace,
(unsigned char*)btnact_data,
btnact_nitems);
- }
-
-
- XChangeDeviceProperty(dpy, dev, prop, XA_INTEGER, 32,
- PropModeReplace,
- (unsigned char*)data, nitems);
}
else if (prop)
{ /* Unsetting a property that exists */
--
1.7.4.1
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 2/9] Fix strip/wheel mapping
Commit 2ce1c6b4 fixed a bug where X would crash after remapping
strips or wheels. It made all the "keys" arrays one-indexed so that
wcmUpdateButtonKeys would not write beyond the end of the arrays.
This patch syncs the action lookup code with the use of one-indexed
arrays so that the proper action is returned.
Signed-off-by: Jason Gerecke
---
src/wcmCommon.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index 736a53c..39ae983 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -333,7 +333,7 @@ static int getWheelButton(InputInfoPtr pInfo, const
WacomDeviceState* ds,
{
value = ds->relwheel;
fakeButton = (value > 0) ? priv->relup : priv->reldn;
- *fakeKey = (value > 0) ? priv->wheel_keys[0] :
priv->wheel_keys[1];
+ *fakeKey = (value > 0) ? priv->wheel_keys[0+1] :
priv->wheel_keys[1+1];
}
/* emulate events for absolute wheel when it is a touch ring (on pad) */
@@ -358,7 +358,7 @@ static int getWheelButton(InputInfoPtr pInfo, const
WacomDeviceState* ds,
value = wrap_delta;
fakeButton = (value > 0) ? priv->wheelup : priv->wheeldn;
- *fakeKey = (value > 0) ? priv->wheel_keys[2] :
priv->wheel_keys[3];
+ *fakeKey = (value > 0) ? priv->wheel_keys[2+1] :
priv->wheel_keys[3+1];
}
/* emulate events for left strip */
@@ -367,7 +367,7 @@ static int getWheelButton(InputInfoPtr pInfo, const
WacomDeviceState* ds,
value = ds->stripx - priv->oldStripX;
fakeButton = (value > 0) ? priv->striplup : priv->stripldn;
- *fakeKey = (value > 0) ? priv->strip_keys[0] :
priv->strip_keys[1];
+ *fakeKey = (value > 0) ? priv->strip_keys[0+1] :
priv->strip_keys[1+1];
}
/* emulate events for right strip */
@@ -376,7 +376,7 @@ static int getWheelButton(InputInfoPtr pInfo, const
WacomDeviceState* ds,
value = ds->stripy - priv->oldStripY;
fakeButton = (value > 0) ? priv->striprup : priv->striprdn;
- *fakeKey = (value > 0) ? priv->strip_keys[2] :
priv->strip_keys[3];
+ *fakeKey = (value > 0) ? priv->strip_keys[2+1] :
priv->strip_keys[3+1];
}
DBG(10, priv, "send fakeButton %x with value = %d \n",
--
1.7.4.1
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 6/9] Remove map_button_simple
With parse_actions now handling simple button mappings, we remove
this function which essentially duplicates its functionality.
Note that there is a small difference in how the new parse_actions
code and the old map_button_simple code handle things. The former
Translates a single numeric argument into an action (e.g. "3" is
turned into "button +3"). The latter cleared any existing action
and used XSetDeviceButtonMapping to have X remap button events.
To better explain the difference, consider the two following commands
run in sequence:
xsetwacom --set $id button 2 3
xsetwacom --set $id button 3 button 2
Under the old map_button_simple code, both buttons 2 and 3 would
produce a right-click event. This is because the first command has
X remap all "button 2" events into "button 3" events. Since both
button 2 (by driver's priv->button[]) and button 3 (by the explicit
action) produce a "button 2" event, X remaps both events into "button 3"
events.
Under the new parse_actions code, things are what you'd expect: button
2 produces a right click and button 3 produces a middle click. If the
user wants, they can use `xinput set-button-map` to remap the buttons
the same way that map_button_simple did.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 30 +-
1 files changed, 1 insertions(+), 29 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 7eb95d7..f6626d3 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1321,29 +1321,6 @@ static void special_map_buttons(Display *dpy, XDevice
*dev, param_t* param,
special_map_property(dpy, dev, btnact_prop, button, argc, argv);
}
-
-static void map_button_simple(Display *dpy, XDevice *dev, param_t* param,
- int button, int mapping)
-{
- int nmap = 256;
- unsigned char map[nmap];
-
- nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
- if (button > nmap)
- {
- fprintf(stderr, "Button number does not exist on device.\n");
- return;
- }
-
- TRACE("Mapping button %d to %d.\n", button, mapping);
-
- map[button - 1] = mapping;
- XSetDeviceButtonMapping(dpy, dev, map, nmap);
- XFlush(dpy);
-
- /* If there's a property set, unset it */
- special_map_buttons(dpy, dev, param, button, 0, NULL);
-}
/*
Supports two variations, simple mapping and special mapping:
xsetwacom set device Button 1 1
@@ -1361,12 +1338,7 @@ static void map_button(Display *dpy, XDevice *dev,
param_t* param, int argc, cha
TRACE("Mapping %s for device %ld.\n", param->name, dev->device_id);
-
- /* --set "device" Button1 3 */
- if (argc > 1 && sscanf(argv[1], "%d", &mapping) == 1)
- map_button_simple(dpy, dev, param, button, mapping);
- else
- special_map_buttons(dpy, dev, param, button, argc - 1,
&argv[1]);
+ special_map_buttons(dpy, dev, param, button, argc - 1, &argv[1]);
}
static void set_xydefault(Display *dpy, XDevice *dev, param_t* param, int
argc, char **argv)
--
1.7.4.1
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 4/9] Make it clearer when actions are sent
When I first saw this, I thought somebody forgot to put an else
clause here; I completely missed that tiny return statement. This
makes the reality a little clearer.
Signed-off-by: Jason Gerecke
---
src/wcmCommon.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index 39ae983..2548ccf 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -411,13 +411,14 @@ static void sendWheelStripEvents(InputInfoPtr pInfo,
const WacomDeviceState* ds,
xf86PostButtonEventP(pInfo->dev, is_absolute(pInfo), fakeButton
& AC_CODE,
0, first_val, num_vals, VCOPY(valuators,
num_vals));
- return;
}
-
- sendAction(pInfo, 1, fakeKey, ARRAY_SIZE(priv->wheel_keys[0]),
- first_val, num_vals, valuators);
- sendAction(pInfo, 0, fakeKey, ARRAY_SIZE(priv->wheel_keys[0]),
- first_val, num_vals, valuators);
+ else
+ {
+ sendAction(pInfo, 1, fakeKey, ARRAY_SIZE(priv->wheel_keys[0]),
+ first_val, num_vals, valuators);
+ sendAction(pInfo, 0, fakeKey, ARRAY_SIZE(priv->wheel_keys[0]),
+ first_val, num_vals, valuators);
+ }
}
/*
--
1.7.4.1
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 5/9] Allow parse_actions to parse simple button maps
If argv contains only a single numeric argument, we assume the
intent is to perform a button press. We add the necessary keywords
to make the parser happy, and then parse as normal.
This allows map_wheels to handle the "raw button" case that it has
been missing. While map_button_simple also does the same* thing,
that's another commit :)
*Actually, map_button_simple does /almost/ the same thing, but I
highly doubt anyone relies on the subtle difference in behavior.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 23 ++-
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index f545f95..7eb95d7 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1133,13 +1133,30 @@ static int convert_wheel_prop(Display *dpy, XDevice
*dev, Atom btnact_prop)
*/
static Bool parse_actions(Display *dpy, int argc, char **argv, unsigned long*
data, unsigned long *nitems)
{
- int i;
+ int i = 0;
int nwords = 0;
char **words = NULL;
/* translate cmdline commands */
words = strjoinsplit(argc, argv, &nwords);
+ if (nwords==1 && sscanf(words[0], "%d", &i) == 1)
+ { //Mangle "simple" button maps into proper actions
+ char **new_words = realloc(words, 2);
+ if (new_words == NULL)
+ {
+ fprintf(stderr, "Unable to reallocate memory.\n");
+ return False;
+ }
+
+ sprintf(new_words[0], "+%d", i);
+ new_words[1] = new_words[0];
+ new_words[0] = "button";
+
+ words = new_words;
+ nwords = 2;
+ }
+
for (i = 0; i < nwords; i++)
{
int j = 0;
@@ -1284,10 +1301,6 @@ static void map_wheels(Display *dpy, XDevice *dev,
param_t* param, int argc, cha
TRACE("Mapping wheel %s for device %ld.\n", param->name,
dev->device_id);
- /* FIXME:
- if value is simple number, change back to 8 bit integer
-*/
-
special_map_wheels(dpy, dev, param, argc, argv);
}
--
1.7.4.1
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 7/9] Remove 'special_map_wheels' and 'special_map_buttons'
Since neither function actually do anything that couldn't just
be done in 'map_wheels' and 'map_button' respectively, we simply
squash them together.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 44 ++--
1 files changed, 14 insertions(+), 30 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index f6626d3..2ff3b22 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1280,11 +1280,15 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
XFlush(dpy);
}
-
-static void special_map_wheels(Display *dpy, XDevice *dev, param_t* param, int
argc, char **argv)
+static void map_wheels(Display *dpy, XDevice *dev, param_t* param, int argc,
char **argv)
{
Atom wheel_prop;
+ if (argc <= 0)
+ return;
+
+ TRACE("Mapping wheel %s for device %ld.\n", param->name,
dev->device_id);
+
wheel_prop = XInternAtom(dpy, param->prop_name, True);
if (!wheel_prop)
return;
@@ -1294,33 +1298,6 @@ static void special_map_wheels(Display *dpy, XDevice
*dev, param_t* param, int a
special_map_property(dpy, dev, wheel_prop, param->prop_offset, argc,
argv);
}
-static void map_wheels(Display *dpy, XDevice *dev, param_t* param, int argc,
char **argv)
-{
- if (argc <= 0)
- return;
-
- TRACE("Mapping wheel %s for device %ld.\n", param->name,
dev->device_id);
-
- special_map_wheels(dpy, dev, param, argc, argv);
-}
-
-/* Handles complex button mappings through button actions. */
-static void special_map_buttons(Display *dpy, XDevice *dev, param_t* param,
- int button, int argc, char **argv)
-{
- Atom btnact_prop;
-
- TRACE("Special %s map for device %ld.\n", param->name, dev->device_id);
-
- btnact_prop = XInternAtom(dpy, WACOM_PROP_BUTTON_ACTIONS, True);
- if (!btnact_prop)
- return;
-
- button--; /* property is zero-indexed, button numbers are 1-indexed */
-
- special_map_property(dpy, dev, btnact_prop, button, argc, argv);
-}
-
/*
Supports two variations, simple mapping and special mapping:
xsetwacom set device Button 1 1
@@ -1330,6 +1307,7 @@ static void special_map_buttons(Display *dpy, XDevice
*dev, param_t* param,
*/
static void map_button(Display *dpy, XDevice *dev, param_t* param, int argc,
char **argv)
{
+ Atom btnact_prop;
int button, /* button to be mapped */
mapping;
@@ -1338,7 +1316,13 @@ static void map_button(Display *dpy, XDevice *dev,
param_t* param, int argc, cha
TRACE("Mapping %s for device %ld.\n", param->name, dev->device_id);
- special_map_buttons(dpy, dev, param, button, argc - 1, &argv[1]);
+ btnact_prop = XInternAtom(dpy, WACOM_PROP_BUTTON_ACTIONS, True);
+ if (!btnact_prop)
+ return;
+
+ button--; /* property is zero-indexed, button numbers are 1-indexed */
+
+ special_map_property(dpy, dev, btnact_prop, button, argc - 1, &argv[1]);
}
static void set_xydefault(Display *dpy, XDevice *dev, param_t* param, int
argc, char **argv)
--
1.7.4.1
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 8/9] Merge 'map_wheels' and 'map_button' into a unified 'map_actions'
These two functions are very similar, and have been merged together
to provide a single conduit for all action mappings. Button-handling
code requires a little bit of special-casing (we need to be sure to
get a button to modify, and to change the arguments appropriately),
but nothing remotely worthy of breaking into its own function.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 98 -
1 files changed, 52 insertions(+), 46 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 2ff3b22..d881289 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -98,8 +98,7 @@ typedef struct _param
/* get_func/set_func calls for special parameters */
-static void map_button(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
-static void map_wheels(Display *dpy, XDevice *dev, param_t* param, int argc,
char **argv);
+static void map_actions(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void set_mode(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void get_mode(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void get_button(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
@@ -127,7 +126,7 @@ static param_t parameters[] =
.name = "Button",
.desc = "X11 event to which the given button should be mapped.
",
.prop_name = WACOM_PROP_BUTTON_ACTIONS,
- .set_func = map_button,
+ .set_func = map_actions,
.get_func = get_button,
},
{
@@ -259,7 +258,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_WHEELBUTTONS,
.prop_format = 8,
.prop_offset = 0,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "RelWheelDown",
@@ -267,7 +266,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_WHEELBUTTONS,
.prop_format = 8,
.prop_offset = 1,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "AbsWheelUp",
@@ -275,7 +274,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_WHEELBUTTONS,
.prop_format = 8,
.prop_offset = 2,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "AbsWheelDown",
@@ -283,7 +282,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_WHEELBUTTONS,
.prop_format = 8,
.prop_offset = 3,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "StripLeftUp",
@@ -291,7 +290,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_STRIPBUTTONS,
.prop_format = 8,
.prop_offset = 0,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "StripLeftDown",
@@ -299,7 +298,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_STRIPBUTTONS,
.prop_format = 8,
.prop_offset = 1,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "StripRightUp",
@@ -307,7 +306,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_STRIPBUTTONS,
.prop_format = 8,
.prop_offset = 2,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "StripRightDown",
@@ -315,7 +314,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_STRIPBUTTONS,
.prop_format = 8,
.prop_offset = 3,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "Threshold",
@@ -1280,49 +1279,56 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
XFlush(dpy);
}
-static void map_wheels(Display *dpy, XDevice *dev, param_t* param, int argc,
char **argv)
-{
- Atom wheel_prop;
-
- if (argc <= 0)
- return;
-
- TRACE("Mapping wheel %s for device %ld.\n", param->name,
dev->device_id);
-
- wheel_prop = XInternAtom(dpy, param->prop_name, True);
- if (!wheel_prop)
- return;
-
- TRACE("Wheel property %s (%ld)\n", param->prop_name, wheel_prop);
-
- special_map_property(dpy, dev, wheel_prop, param->prop_offset, argc,
argv);
-}
-
-/*
- Supports two variati
[Linuxwacom-devel] [PATCH 9/9] Revamp button/wheel/strip getters
'get_map' is the new getter entrypoint and attempts to determine
the mapping present on buttons, wheels, and strips. It calls on
'get_actions' (essentially get_special_button_map) and 'get_button'
(an 8-bit XA_INTEGER version of the same) to determine this. If
both fail to find a mapping, it falls back to the method originally
used for non-actions: punt and ask XGetDeviceButtonMapping for
something.
When raw buttons are removed from the driver, it should be possible
to replace 'get_map' with 'get_actions' (since everything will be
an action at that point).
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 188 +++--
1 files changed, 140 insertions(+), 48 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index d881289..e33b5b4 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -101,7 +101,7 @@ typedef struct _param
static void map_actions(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void set_mode(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void get_mode(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
-static void get_button(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
+static void get_map(Display *dpy, XDevice *dev, param_t *param, int argc, char
**argv);
static void set_rotate(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void get_rotate(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void set_xydefault(Display *dpy, XDevice *dev, param_t *param, int
argc, char **argv);
@@ -127,7 +127,7 @@ static param_t parameters[] =
.desc = "X11 event to which the given button should be mapped.
",
.prop_name = WACOM_PROP_BUTTON_ACTIONS,
.set_func = map_actions,
- .get_func = get_button,
+ .get_func = get_map,
},
{
.name = "ToolDebugLevel",
@@ -259,6 +259,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 0,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "RelWheelDown",
@@ -267,6 +268,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 1,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "AbsWheelUp",
@@ -275,6 +277,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 2,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "AbsWheelDown",
@@ -283,6 +286,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 3,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "StripLeftUp",
@@ -291,6 +295,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 0,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "StripLeftDown",
@@ -299,6 +304,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 1,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "StripRightUp",
@@ -307,6 +313,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 2,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "StripRightDown",
@@ -315,6 +322,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 3,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "Threshold",
@@ -1691,50 +1699,57 @@ static void get_rotate(Display *dpy, XDevice *dev,
param_t* param, int argc, cha
return;
}
-static int get_special_button_map(Display *dpy, XDevice *dev,
- param_t *param, int btn_no)
+/**
+ * Try to print the value of the action mapped to the given parameter's
+ * property. If the property contains data in the wrong format/type then
+ * nothing will be printed.
+ *
+ * @param dpyX11 display to connect to
+ * @param devDevice to query
+ * @param param Info about parameter to query
+ * @param offset Offset into property specified in param
+ * @return 0 on failure, 1 otherwise
+ */
+static int get_actions(Display *dpy, XDevice *dev,
+ param_t *para
Re: [Linuxwacom-devel] Moving towards 0.11
On Tue, Mar 29, 2011 at 3:55 PM, Peter Hutterer wrote: > It's been a few weeks since 0.10.11, 114 patches already and I think it's > high time for another release. As we discussed after the 0.10.11 release we > should change the release tactics. So here is what I'd like to do. > > - If you have any larger features, cleanup works or other intrusive stuff, > please nominate them _now_ so we can assess them if they're appropriate to > wait for. > - I'll tag the first RC on Friday and push tarballs out for testing. > - From then on, I'd like us to focus on bugs only. Regressions since 0.10.11 > or earlier, broken buttons, jumping cursors, invalid values and so on. > Additional test cases are always accepted of course. > - 0.11 should be out in mid-April then, after one or two more RCs. > > I know I've removed a number of features over the last year, so we're not > focusing on those just yet. They'll be re-implemented (if appropriate) for > 0.12. Let's concentrate on getting a rock-steady driver out before we add > features again. > > Sounds good? > > Cheers, > Peter > > -- > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > ___ > Linuxwacom-devel mailing list > Linuxwacom-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel > Sounds great! I'm really looking forward to this release :) I've got one more set of four patches I want to get in, but I just found a small problem earlier today so held off from putting them in with my latest patchset. I'll try to get it fixed later tonight for submission. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 9/9] Revamp button/wheel/strip getters
On Tue, Mar 29, 2011 at 9:21 PM, Peter Hutterer
wrote:
> On Tue, Mar 29, 2011 at 04:18:38PM -0700, Jason Gerecke wrote:
>> @@ -1782,41 +1797,118 @@ static int get_special_button_map(Display *dpy,
>> XDevice *dev,
>>
>> TRACE("%s\n", buff);
>>
>> - XFree(btnact_data);
>> + XFree(data);
>>
>> print_value(param, "%s", buff);
>>
>> return 1;
>> }
>>
>> -static void get_button(Display *dpy, XDevice *dev, param_t *param, int argc,
>> - char **argv)
>> +/**
>> + * Try to print the value of the raw button mapped to the given parameter's
>> + * property. If the property contains data in the wrong format/type then
>> + * nothing will be printed.
>> + *
>> + * @param dpy X11 display to connect to
>> + * @param dev Device to query
>> + * @param param Info about parameter to query
>> + * @param offset Offset into the property specified in param
>> + * @return 0 on failure, 1 otherwise
>> + */
>> +static int get_button(Display *dpy, XDevice *dev, param_t *param, int
>> offset)
>> {
>> - int nmap = 256;
>> - unsigned char map[nmap];
>> - int button = 0;
>> + Atom prop, type;
>> + int format;
>> + unsigned long nitems, bytes_after;
>> + unsigned char *data;
>>
>> - if (argc < 1 || (sscanf(argv[0], "%d", &button) != 1))
>> - return;
>> + prop = XInternAtom(dpy, param->prop_name, True);
>> +
>> + if (!prop)
>> + return 0;
>> +
>> + XGetDeviceProperty(dpy, dev, prop, 0, 100, False,
>> + AnyPropertyType, &type, &format, &nitems,
>> + &bytes_after, (unsigned char**)&data);
>> +
>> + if (offset >= nitems)
>> + {
>> + XFree(data);
>> + return 0;
>> + }
>> +
>> + prop = data[offset];
>> + XFree(data);
>> +
>> + if (format != 8 || type != XA_INTEGER || !prop)
>> + {
>> + return 0;
>> + }
>> +
>> + print_value(param, "%d", prop);
>> +
>> + return 1;
>> +}
>> +
>> +/**
>> + * Print the current button/wheel/strip mapping, be it a raw button or
>> + * an action. Button map requests require the button number as the first
>> + * argument in argv.
>> + *
>> + * @param dpy X11 display to connect to
>> + * @param dev Device to query
>> + * @param param Info about parameter to query
>> + * @param argc Length of argv
>> + * @param argv Command-line arguments
>> + */
>> +static void get_map(Display *dpy, XDevice *dev, param_t *param, int argc,
>> char** argv)
>> +{
>> + int offset = param->prop_offset;
>>
>> TRACE("Getting button map for device %ld.\n", dev->device_id);
>>
>> - /* if there's a special map, print it and return */
>> - if (get_special_button_map(dpy, dev, param, button))
>> - return;
>> + if (param->prop_name == WACOM_PROP_BUTTON_ACTIONS)
>
> in your testing, this should have always been false. you need a strcmp here.
> Can you please re-test this?
> applies to 8/9 as well which has the same condition.
>
I can test to be sure, though I was pretty sure this worked. Way up
where parameters[] is defined, we do "prop_name =
WACOM_PROP_BUTTON_ACTIONS". Unless another function changes the
prop_name to an identical string at a different location (i.e., they
ignored the already-defined constant and used a hard-coded string
instead) I don't see why there'd be a problem.
Though, I can certainly do a strcmp if you want (or if I'm mistaken
about it working) :)
>> + {
>> + if (argc == 0)
>> + {
>> + fprintf(stderr, "Too few arguments provided.\n");
>> + return;
>> + }
>>
>> - nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
>> + if (sscanf(argv[0], "%d", &offset) != 1)
>> + {
>> + fprintf(stderr, "'%s' is not a valid button
>> number.\n", argv[0]);
>> + return;
>> + }
>>
>> - if (button > nmap)
>> - {
>> - fprintf(stderr, "Button number does not exist on device.\n");
>> - return;
>> + offset--;
Re: [Linuxwacom-devel] [PATCH 1/9] Fix "buttons must be set twice" bug from d650b139
On Tue, Mar 29, 2011 at 9:03 PM, Peter Hutterer wrote: > applied, but from a cursory glance I'm not sure why. In fact, I would have > guessed the other way round. anyway, I've added a comment to avoid this in > the future (at least until we find the reason why and fixed it). > > Cheers, > Peter > I thought it was curious as well. I tried things both ways around and was surprised to see that this was the order that worked. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 9/9] Revamp button/wheel/strip getters
On Tue, Mar 29, 2011 at 11:37 PM, Peter Hutterer
wrote:
> On Tue, Mar 29, 2011 at 11:21:58PM -0700, Jason Gerecke wrote:
>> On Tue, Mar 29, 2011 at 9:21 PM, Peter Hutterer
>> wrote:
>> > On Tue, Mar 29, 2011 at 04:18:38PM -0700, Jason Gerecke wrote:
>> >> @@ -1782,41 +1797,118 @@ static int get_special_button_map(Display *dpy,
>> >> XDevice *dev,
>> >>
>> >> TRACE("%s\n", buff);
>> >>
>> >> - XFree(btnact_data);
>> >> + XFree(data);
>> >>
>> >> print_value(param, "%s", buff);
>> >>
>> >> return 1;
>> >> }
>> >>
>> >> -static void get_button(Display *dpy, XDevice *dev, param_t *param, int
>> >> argc,
>> >> - char **argv)
>> >> +/**
>> >> + * Try to print the value of the raw button mapped to the given
>> >> parameter's
>> >> + * property. If the property contains data in the wrong format/type then
>> >> + * nothing will be printed.
>> >> + *
>> >> + * @param dpy X11 display to connect to
>> >> + * @param dev Device to query
>> >> + * @param param Info about parameter to query
>> >> + * @param offset Offset into the property specified in param
>> >> + * @return 0 on failure, 1 otherwise
>> >> + */
>> >> +static int get_button(Display *dpy, XDevice *dev, param_t *param, int
>> >> offset)
>> >> {
>> >> - int nmap = 256;
>> >> - unsigned char map[nmap];
>> >> - int button = 0;
>> >> + Atom prop, type;
>> >> + int format;
>> >> + unsigned long nitems, bytes_after;
>> >> + unsigned char *data;
>> >>
>> >> - if (argc < 1 || (sscanf(argv[0], "%d", &button) != 1))
>> >> - return;
>> >> + prop = XInternAtom(dpy, param->prop_name, True);
>> >> +
>> >> + if (!prop)
>> >> + return 0;
>> >> +
>> >> + XGetDeviceProperty(dpy, dev, prop, 0, 100, False,
>> >> + AnyPropertyType, &type, &format, &nitems,
>> >> + &bytes_after, (unsigned char**)&data);
>> >> +
>> >> + if (offset >= nitems)
>> >> + {
>> >> + XFree(data);
>> >> + return 0;
>> >> + }
>> >> +
>> >> + prop = data[offset];
>> >> + XFree(data);
>> >> +
>> >> + if (format != 8 || type != XA_INTEGER || !prop)
>> >> + {
>> >> + return 0;
>> >> + }
>> >> +
>> >> + print_value(param, "%d", prop);
>> >> +
>> >> + return 1;
>> >> +}
>> >> +
>> >> +/**
>> >> + * Print the current button/wheel/strip mapping, be it a raw button or
>> >> + * an action. Button map requests require the button number as the first
>> >> + * argument in argv.
>> >> + *
>> >> + * @param dpy X11 display to connect to
>> >> + * @param dev Device to query
>> >> + * @param param Info about parameter to query
>> >> + * @param argc Length of argv
>> >> + * @param argv Command-line arguments
>> >> + */
>> >> +static void get_map(Display *dpy, XDevice *dev, param_t *param, int
>> >> argc, char** argv)
>> >> +{
>> >> + int offset = param->prop_offset;
>> >>
>> >> TRACE("Getting button map for device %ld.\n", dev->device_id);
>> >>
>> >> - /* if there's a special map, print it and return */
>> >> - if (get_special_button_map(dpy, dev, param, button))
>> >> - return;
>> >> + if (param->prop_name == WACOM_PROP_BUTTON_ACTIONS)
>> >
>> > in your testing, this should have always been false. you need a strcmp
>> > here.
>> > Can you please re-test this?
>> > applies to 8/9 as well which has the same condition.
>> >
>> I can test to be sure, though I was pretty sure this worked. Way up
>> where parameters[] is defined, we do "prop_name =
>> WACOM_PROP_BUTTON_ACTIONS". Unless another function changes the
>> prop_name to an identical string at
[Linuxwacom-devel] [PATCH 8v2/9] Merge 'map_wheels' and 'map_button' into a unified 'map_actions'
These two functions are very similar, and have been merged together
to provide a single conduit for all action mappings. Button-handling
code requires a little bit of special-casing (we need to be sure to
get a button to modify, and to change the arguments appropriately),
but nothing remotely worthy of breaking into its own function.
Signed-off-by: Jason Gerecke
---
Changes from v1:
* Use strcmp instead of ==
tools/xsetwacom.c | 98 -
1 files changed, 52 insertions(+), 46 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 2ff3b22..18155aa 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -98,8 +98,7 @@ typedef struct _param
/* get_func/set_func calls for special parameters */
-static void map_button(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
-static void map_wheels(Display *dpy, XDevice *dev, param_t* param, int argc,
char **argv);
+static void map_actions(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void set_mode(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void get_mode(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void get_button(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
@@ -127,7 +126,7 @@ static param_t parameters[] =
.name = "Button",
.desc = "X11 event to which the given button should be mapped.
",
.prop_name = WACOM_PROP_BUTTON_ACTIONS,
- .set_func = map_button,
+ .set_func = map_actions,
.get_func = get_button,
},
{
@@ -259,7 +258,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_WHEELBUTTONS,
.prop_format = 8,
.prop_offset = 0,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "RelWheelDown",
@@ -267,7 +266,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_WHEELBUTTONS,
.prop_format = 8,
.prop_offset = 1,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "AbsWheelUp",
@@ -275,7 +274,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_WHEELBUTTONS,
.prop_format = 8,
.prop_offset = 2,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "AbsWheelDown",
@@ -283,7 +282,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_WHEELBUTTONS,
.prop_format = 8,
.prop_offset = 3,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "StripLeftUp",
@@ -291,7 +290,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_STRIPBUTTONS,
.prop_format = 8,
.prop_offset = 0,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "StripLeftDown",
@@ -299,7 +298,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_STRIPBUTTONS,
.prop_format = 8,
.prop_offset = 1,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "StripRightUp",
@@ -307,7 +306,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_STRIPBUTTONS,
.prop_format = 8,
.prop_offset = 2,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "StripRightDown",
@@ -315,7 +314,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_STRIPBUTTONS,
.prop_format = 8,
.prop_offset = 3,
- .set_func = map_wheels,
+ .set_func = map_actions,
},
{
.name = "Threshold",
@@ -1280,49 +1279,56 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
XFlush(dpy);
}
-static void map_wheels(Display *dpy, XDevice *dev, param_t* param, int argc,
char **argv)
-{
- Atom wheel_prop;
-
- if (argc <= 0)
- return;
-
- TRACE("Mapping wheel %s for device %ld.\n", param->name,
dev->device_id);
-
- wheel_prop = XInternAtom(dpy, param->prop_name, True);
- if (!wheel_prop)
- return;
-
- TRACE("Wheel property %s (%ld)\n", param->prop_name, wheel_prop);
-
- special_map_property(dpy, dev, wheel_prop, param->prop_offset,
[Linuxwacom-devel] [PATCH 9v2/9] Revamp button/wheel/strip getters
'get_map' is the new getter entrypoint and attempts to determine
the mapping present on buttons, wheels, and strips. It calls on
'get_actions' (essentially get_special_button_map) and 'get_button'
(an 8-bit XA_INTEGER version of the same) to determine this. If
both fail to find a mapping, it falls back to the method originally
used for non-actions: punt and ask XGetDeviceButtonMapping for
something.
When raw buttons are removed from the driver, it should be possible
to replace 'get_map' with 'get_actions' (since everything will be
an action at that point).
Signed-off-by: Jason Gerecke
---
Changes since v1:
* Use strcmp instead of ==
* Change comment style
tools/xsetwacom.c | 188 +++--
1 files changed, 140 insertions(+), 48 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 18155aa..41e4ced 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -101,7 +101,7 @@ typedef struct _param
static void map_actions(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void set_mode(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void get_mode(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
-static void get_button(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
+static void get_map(Display *dpy, XDevice *dev, param_t *param, int argc, char
**argv);
static void set_rotate(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void get_rotate(Display *dpy, XDevice *dev, param_t *param, int argc,
char **argv);
static void set_xydefault(Display *dpy, XDevice *dev, param_t *param, int
argc, char **argv);
@@ -127,7 +127,7 @@ static param_t parameters[] =
.desc = "X11 event to which the given button should be mapped.
",
.prop_name = WACOM_PROP_BUTTON_ACTIONS,
.set_func = map_actions,
- .get_func = get_button,
+ .get_func = get_map,
},
{
.name = "ToolDebugLevel",
@@ -259,6 +259,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 0,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "RelWheelDown",
@@ -267,6 +268,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 1,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "AbsWheelUp",
@@ -275,6 +277,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 2,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "AbsWheelDown",
@@ -283,6 +286,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 3,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "StripLeftUp",
@@ -291,6 +295,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 0,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "StripLeftDown",
@@ -299,6 +304,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 1,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "StripRightUp",
@@ -307,6 +313,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 2,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "StripRightDown",
@@ -315,6 +322,7 @@ static param_t parameters[] =
.prop_format = 8,
.prop_offset = 3,
.set_func = map_actions,
+ .get_func = get_map,
},
{
.name = "Threshold",
@@ -1691,50 +1699,57 @@ static void get_rotate(Display *dpy, XDevice *dev,
param_t* param, int argc, cha
return;
}
-static int get_special_button_map(Display *dpy, XDevice *dev,
- param_t *param, int btn_no)
+/**
+ * Try to print the value of the action mapped to the given parameter's
+ * property. If the property contains data in the wrong format/type then
+ * nothing will be printed.
+ *
+ * @param dpyX11 display to connect to
+ * @param devDevice to query
+ * @param param Info about parameter to query
+ * @param offset Offset into property specified in param
+ * @return 0 on failure, 1 otherwise
+ */
+static int get_action
[Linuxwacom-devel] [PATCH 7/7] Fix get_map to return proper wheel/strip button number
Adding to the only-kinda-hackish use of XGetDeviceButtonMapping,
in get_map, this total hackjob of a patch "fixes" the problem with
us having no way of knowing the driver's defaults for wheels and
strips.
Thankfully, the defaults aren't changing anytime soon so its
not likely to break. Additionally, once the raw button path is
removed from the driver, the entire 'get_map' function can go
the way of the dodo.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 36
1 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 38002cb..1c0f43f 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1884,22 +1884,34 @@ static void get_map(Display *dpy, XDevice *dev, param_t
*param, int argc, char**
else if (get_button(dpy, dev, param, offset))
return;
else
- {
- int nmap = 256;
- unsigned char map[nmap];
+ { /* FIXME: Ugly hack because there's no way to get default buttons */
+ if (strcmp(param->prop_name, WACOM_PROP_BUTTON_ACTIONS) == 0)
+ {
+ int nmap = 256;
+ unsigned char map[nmap];
- nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
+ nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
- if (offset >= nmap)
- {
- fprintf(stderr, "Button number does not exist on
device.\n");
- return;
- }
+ if (offset >= nmap)
+ {
+ fprintf(stderr, "Button number does not exist
on device.\n");
+ return;
+ }
- print_value(param, "%d", map[offset]);
+ print_value(param, "%d", map[offset]);
- XSetDeviceButtonMapping(dpy, dev, map, nmap);
- XFlush(dpy);
+ XSetDeviceButtonMapping(dpy, dev, map, nmap);
+ XFlush(dpy);
+ }
+ else
+ {
+ switch (offset) {
+ case 0: print_value(param, "4"); break;
+ case 1: print_value(param, "5"); break;
+ case 2: print_value(param, "4"); break;
+ case 3: print_value(param, "5"); break;
+ }
+ }
}
}
--
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
[Linuxwacom-devel] [PATCH 0/7] Patchset summary
Patches 1-4 improve argument validation and make xsetwacom noiser when it fails. Patches 5-7 finish up the remaining raw button removal from xsetwacom. Jason Gerecke (7): Fail with warnings where possible More explicit input check for set_rotate Change from prop_extra to arg_count More strict argument-count checking Decrease minimum number of args to 'set' [allow wheels/strips "reset"] Have wheel and strip properties be "actions" instead of "buttons" Fix get_map to return proper wheel/strip button number src/wcmXCommand.c | 28 +++ tools/xsetwacom.c | 245 - 2 files changed, 141 insertions(+), 132 deletions(-) -- 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
[Linuxwacom-devel] [PATCH 2/7] More explicit input check for set_rotate
Because of how atoi() works, any single non-number (other than the
expected cw,ccw,half,none) would be interpreted as being equivlent
to 'none'. Since the number of valid arguments is very small, we
explicitly check each.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 337aa88..4194781 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1428,19 +1428,19 @@ static void set_rotate(Display *dpy, XDevice *dev,
param_t* param, int argc, cha
TRACE("Rotate '%s' for device %ld.\n", argv[0], dev->device_id);
- if (strcasecmp(argv[0], "cw") == 0)
+ if (strcasecmp(argv[0], "cw") == 0 || strcasecmp(argv[0], "1") == 0)
rotation = 1;
- else if (strcasecmp(argv[0], "ccw") == 0)
+ else if (strcasecmp(argv[0], "ccw") == 0 || strcasecmp(argv[0], "2") ==
0)
rotation = 2;
- else if (strcasecmp(argv[0], "half") == 0)
+ else if (strcasecmp(argv[0], "half") == 0 || strcasecmp(argv[0], "3")
== 0)
rotation = 3;
- else if (strcasecmp(argv[0], "none") == 0)
+ else if (strcasecmp(argv[0], "none") == 0 || strcasecmp(argv[0], "0")
== 0)
rotation = 0;
- else if (strlen(argv[0]) == 1)
+ else
{
- rotation = atoi(argv[0]);
- if (rotation < 0 || rotation > 3)
- goto error;
+ fprintf(stderr, "'%s' is not a valid value for the '%s'
property.\n",
+ argv[0], param->name);
+ return;
}
prop = XInternAtom(dpy, param->prop_name, True);
--
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
[Linuxwacom-devel] [PATCH 1/7] Fail with warnings where possible
For many commands, improper arguments cause a silent failure. The
user is often given no indication if their command succeeded or
failed. I've tried to find all the silent "return;" statements and
provide some kind of warning message where possible.
In some cases I've added in new checks to ensure that we have the
correct number of arguments. I've tried to make checks as pedantic
as possible, e.g. throwing errors about number of arguments even if
the function ignores arguments.
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 41e4ced..337aa88 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1234,7 +1234,10 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
&bytes_after, (unsigned char**)&btnact_data);
if (offset > btnact_nitems)
+ {
+ fprintf(stderr, "Invalid offset into %s property.\n",
XGetAtomName(dpy, btnact_prop));
return;
+ }
if (format == 8 && type == XA_INTEGER)
{
@@ -1242,7 +1245,10 @@ static void special_map_property(Display *dpy, XDevice
*dev, Atom btnact_prop, i
* mappings. Convert to 32 bit Atom actions first.
*/
if (convert_wheel_prop(dpy, dev, btnact_prop))
+ {
+ fprintf(stderr, "Error creating wheel action.\n");
return;
+ }
XGetDeviceProperty(dpy, dev, btnact_prop, 0, 100, False,
AnyPropertyType, &type, &format,
@@ -1347,6 +1353,12 @@ static void set_xydefault(Display *dpy, XDevice *dev,
param_t* param, int argc,
unsigned long nitems, bytes_after;
long *ldata;
+ if (argc != 0)
+ {
+ fprintf(stderr, "Incorrect number of arguments supplied.\n");
+ return;
+ }
+
prop = XInternAtom(dpy, param->prop_name, True);
if (!prop)
{
@@ -1632,7 +1644,10 @@ static void get_mode(Display *dpy, XDevice *dev,
param_t* param, int argc, char
}
if (!ndevices) /* device id 0 is reserved and can't be our device */
+ {
+ fprintf(stderr, "Unable to locate device.\n");
return;
+ }
TRACE("Getting mode for device %ld.\n", dev->device_id);
@@ -1658,6 +1673,12 @@ static void get_rotate(Display *dpy, XDevice *dev,
param_t* param, int argc, cha
unsigned char* data;
unsigned long nitems, bytes_after;
+ if (argc != 0)
+ {
+ fprintf(stderr, "Incorrect number of arguments supplied.\n");
+ return;
+ }
+
prop = XInternAtom(dpy, param->prop_name, True);
if (!prop)
{
@@ -1937,7 +1958,11 @@ static void _set_matrix_prop(Display *dpy, XDevice *dev,
const float fmatrix[9])
&bytes_after, (unsigned char**)&data);
if (format != 32 || type != XInternAtom(dpy, "FLOAT", True))
+ {
+ fprintf(stderr, "Property for '%s' has unexpected type - this
is a bug.\n",
+ "Coordinate Transformation Matrix");
return;
+ }
XChangeDeviceProperty(dpy, dev, matrix_prop, type, format,
PropModeReplace, (unsigned char*)matrix, 9);
@@ -1954,6 +1979,12 @@ static void set_output(Display *dpy, XDevice *dev,
param_t *param, int argc, cha
XRROutputInfo *output_info;
XRRCrtcInfo *crtc_info;
+ if (argc != 1)
+ {
+ fprintf(stderr, "Incorrect number of arguments supplied.\n");
+ return;
+ }
+
output_name = argv[0];
if (!XRRQueryExtension(dpy, &maj, &min)) /* using min/maj as dummy */
--
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
[Linuxwacom-devel] [PATCH 3/7] Change from prop_extra to arg_count
When setting an XInternAtom property, 'prop_extra' listed
the number of extra properties beyond the first that needed
to be set. For instance WACOM_PROP_TABLET_AREA had a total
of 4 properties, so prop_extra=3.
To provide better argument validation though, we change this
to 'arg_count' and list the total number of arguments
expected. This doesn't really do anything for normal properties
(since arg_count = prop_extra + 1), but does let us check
for the proper number of arguments in odd cases (e.g.
ResetArea takes 0 arguments).
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 40 +---
1 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 4194781..ae35996 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -86,7 +86,7 @@ typedef struct _param
const char *prop_name; /* property name */
const int prop_format; /* property format */
const int prop_offset; /* offset (index) into the property values */
- const int prop_extra; /* extra number of items after first one */
+ const int arg_count; /* extra number of items after first one */
const unsigned int prop_flags;
void (*set_func)(Display *dpy, XDevice *dev, struct _param *param, int
argc, char **argv); /* handler function, if appropriate */
void (*get_func)(Display *dpy, XDevice *dev, struct _param *param, int
argc, char **argv); /* handler function for getting, if appropriate */
@@ -120,12 +120,13 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_TABLET_AREA,
.prop_format = 32,
.prop_offset = 0,
- .prop_extra = 3
+ .arg_count = 4,
},
{
.name = "Button",
.desc = "X11 event to which the given button should be mapped.
",
.prop_name = WACOM_PROP_BUTTON_ACTIONS,
+ .arg_count = 1,
.set_func = map_actions,
.get_func = get_map,
},
@@ -136,6 +137,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_DEBUGLEVELS,
.prop_format = 8,
.prop_offset = 0,
+ .arg_count = 1,
},
{
.name = "TabletDebugLevel",
@@ -145,6 +147,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_DEBUGLEVELS,
.prop_format = 8,
.prop_offset = 1,
+ .arg_count = 1,
},
{
.name = "Suppress",
@@ -152,6 +155,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_SAMPLE,
.prop_format = 32,
.prop_offset = 0,
+ .arg_count = 1,
},
{
.name = "RawSample",
@@ -160,6 +164,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_SAMPLE,
.prop_format = 32,
.prop_offset = 1,
+ .arg_count = 1,
},
{
.name = "PressureCurve",
@@ -167,11 +172,12 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_PRESSURECURVE,
.prop_format = 32,
.prop_offset = 0,
- .prop_extra = 3,
+ .arg_count = 4,
},
{
.name = "Mode",
.desc = "Switches cursor movement mode (default is absolute). ",
+ .arg_count = 1,
.set_func = set_mode,
.get_func = get_mode,
},
@@ -183,6 +189,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_HOVER,
.prop_format = 8,
.prop_offset = 0,
+ .arg_count = 1,
.prop_flags = PROP_FLAG_BOOLEAN
},
{
@@ -191,6 +198,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_TOUCH,
.prop_format = 8,
.prop_offset = 0,
+ .arg_count = 1,
.prop_flags = PROP_FLAG_BOOLEAN
},
{
@@ -200,6 +208,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_ENABLE_GESTURE,
.prop_format = 8,
.prop_offset = 0,
+ .arg_count = 1,
.prop_flags = PROP_FLAG_BOOLEAN
},
{
@@ -209,6 +218,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_GESTURE_PARAMETERS,
.prop_format = 32,
.prop_offset = 0,
+ .arg_count = 1,
},
{
.name = "ScrollDistance",
@@ -217,6 +227,7 @@ static param_t parameters[] =
.prop_name = WACOM_PROP_GESTURE_PARAMETERS,
.prop_format = 32,
.prop_offset = 1,
+
[Linuxwacom-devel] [PATCH 4/7] More strict argument-count checking
Add/replace checks in functions to ensure that they have the right
number of arguments to do their job properly. The worst offender
here was the set() function -- providing too many arguments would
result in it walking off the end of data structures (often resulting
in a segfault)
Signed-off-by: Jason Gerecke
---
tools/xsetwacom.c | 60 +++-
1 files changed, 36 insertions(+), 24 deletions(-)
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index ae35996..d99a671 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1349,14 +1349,14 @@ static void map_actions(Display *dpy, XDevice *dev,
param_t* param, int argc, ch
return;
}
- if (strcmp(param->prop_name, WACOM_PROP_BUTTON_ACTIONS) == 0)
+ if (argc < param->arg_count)
{
- if (argc == 0)
- {
- fprintf(stderr, "Too few arguments provided.\n");
- return;
- }
+ fprintf(stderr, "Too few arguments provided.\n");
+ return;
+ }
+ if (strcmp(param->prop_name, WACOM_PROP_BUTTON_ACTIONS) == 0)
+ {
if (sscanf(argv[0], "%d", &offset) != 1)
{
fprintf(stderr, "'%s' is not a valid button number.\n",
argv[0]);
@@ -1379,9 +1379,10 @@ static void set_xydefault(Display *dpy, XDevice *dev,
param_t* param, int argc,
unsigned long nitems, bytes_after;
long *ldata;
- if (argc != 0)
+ if (argc != param->arg_count)
{
- fprintf(stderr, "Incorrect number of arguments supplied.\n");
+ fprintf(stderr, "'%s' requires exactly %d value(s).\n",
param->name,
+ param->arg_count);
return;
}
@@ -1418,9 +1419,11 @@ out:
static void set_mode(Display *dpy, XDevice *dev, param_t* param, int argc,
char **argv)
{
int mode = Absolute;
- if (argc < 1)
+
+ if (argc != param->arg_count)
{
- usage();
+ fprintf(stderr, "'%s' requires exactly %d value(s).\n",
param->name,
+ param->arg_count);
return;
}
@@ -1449,8 +1452,12 @@ static void set_rotate(Display *dpy, XDevice *dev,
param_t* param, int argc, cha
unsigned char* data;
unsigned long nitems, bytes_after;
- if (argc != 1)
- goto error;
+ if (argc != param->arg_count)
+ {
+ fprintf(stderr, "'%s' requires exactly %d value(s).\n",
param->name,
+ param->arg_count);
+ return;
+ }
TRACE("Rotate '%s' for device %ld.\n", argv[0], dev->device_id);
@@ -1493,10 +1500,6 @@ static void set_rotate(Display *dpy, XDevice *dev,
param_t* param, int argc, cha
XFlush(dpy);
return;
-
-error:
- fprintf(stderr, "Usage: xsetwacom Rotate [none | cw | ccw
| half]\n");
- return;
}
@@ -1607,6 +1610,13 @@ static void set(Display *dpy, int argc, char **argv)
values = strjoinsplit(argc - 2, &argv[2], &nvals);
+ if (nvals != param->arg_count)
+ {
+ fprintf(stderr, "'%s' requires exactly %d value(s).\n",
param->name,
+ param->arg_count);
+ goto out;
+ }
+
for (i = 0; i < nvals; i++)
{
Bool success;
@@ -1914,14 +1924,15 @@ static void get_map(Display *dpy, XDevice *dev, param_t
*param, int argc, char**
TRACE("Getting button map for device %ld.\n", dev->device_id);
- if (strcmp(param->prop_name, WACOM_PROP_BUTTON_ACTIONS) == 0)
+ if (argc != param->arg_count)
{
- if (argc == 0)
- {
- fprintf(stderr, "Too few arguments provided.\n");
- return;
- }
+ fprintf(stderr, "'%s' requires exactly %d value(s).\n",
param->name,
+ param->arg_count);
+ return;
+ }
+ if (strcmp(param->prop_name, WACOM_PROP_BUTTON_ACTIONS) == 0)
+ {
if (sscanf(argv[0], "%d", &offset) != 1)
{
fprintf(stderr, "'%s' is not a valid button number.\n",
argv[0]);
@@ -2005,9 +2016,10 @@ static void set_output(Display *dpy, XDevice *dev,
param_t *param, int argc, cha
XRROutputInfo *output_info;
XRRCrtcInfo *crtc_info;
- if (argc != 1)
+ if (argc != param->arg_count)
{
- fprintf(stderr, "Incorrect number of arguments suppli
[Linuxwacom-devel] [PATCH 5/7] Decrease minimum number of args to 'set' [allow wheels/strips "reset"]
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
---
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
[Linuxwacom-devel] [PATCH 6/7] Have wheel and strip properties be "actions" instead of "buttons"
Continuing with removing raw button code, we create the wheel and
strip properties ready to hold actions. Prior to this, the properties
would be initialized with the raw buttons; before xsetwacom could
set them to actions they would need to be converted.
This does away with the conversion step by following the mold already
in place for buttons. With no more need for conversion, we can also
nuke the conversion-related bits from xsetwacom.
Signed-off-by: Jason Gerecke
---
src/wcmXCommand.c | 28
tools/xsetwacom.c | 74 +++--
2 files changed, 15 insertions(+), 87 deletions(-)
diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c
index 64ebb8d..f1228b2 100644
--- a/src/wcmXCommand.c
+++ b/src/wcmXCommand.c
@@ -165,23 +165,6 @@ void InitWcmDeviceProperties(InputInfoPtr pInfo)
values[3] = priv->serial;
prop_serials = InitWcmAtom(pInfo->dev, WACOM_PROP_SERIALIDS, 32, 4,
values);
- if (IsPad(priv)) {
- values[0] = priv->striplup;
- values[1] = priv->stripldn;
- values[2] = priv->striprup;
- values[3] = priv->striprdn;
- prop_strip_buttons = InitWcmAtom(pInfo->dev,
WACOM_PROP_STRIPBUTTONS, 8, 4, values);
- }
-
- if (IsPad(priv) || IsCursor(priv))
- {
- values[0] = priv->relup;
- values[1] = priv->reldn;
- values[2] = priv->wheelup;
- values[3] = priv->wheeldn;
- prop_wheel_buttons = InitWcmAtom(pInfo->dev,
WACOM_PROP_WHEELBUTTONS, 8, 4, values);
- }
-
if (IsCursor(priv)) {
values[0] = common->wcmCursorProxoutDist;
prop_cursorprox = InitWcmAtom(pInfo->dev,
WACOM_PROP_PROXIMITY_THRESHOLD, 32, 1, values);
@@ -220,6 +203,17 @@ void InitWcmDeviceProperties(InputInfoPtr pInfo)
memset(values, 0, sizeof(values));
prop_btnactions = InitWcmAtom(pInfo->dev, WACOM_PROP_BUTTON_ACTIONS,
-32, WCM_MAX_MOUSE_BUTTONS, values);
+ if (IsPad(priv)) {
+ memset(values, 0, sizeof(values));
+ prop_strip_buttons = InitWcmAtom(pInfo->dev,
WACOM_PROP_STRIPBUTTONS, -32, 4, values);
+ }
+
+ if (IsPad(priv) || IsCursor(priv))
+ {
+ memset(values, 0, sizeof(values));
+ prop_wheel_buttons = InitWcmAtom(pInfo->dev,
WACOM_PROP_WHEELBUTTONS, -32, 4, values);
+ }
+
#ifdef DEBUG
values[0] = priv->debugLevel;
values[1] = common->debugLevel;
diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
index 59b0cb1..38002cb 100644
--- a/tools/xsetwacom.c
+++ b/tools/xsetwacom.c
@@ -1093,62 +1093,6 @@ static char** strjoinsplit(int argc, char **argv, int
*nwords)
return words;
}
-static const char *wheel_act_prop[] = {
- "Wacom Rel Wheel Up Action",
- "Wacom Rel Wheel Down Action",
- "Wacom Abs Wheel Up Action",
- "Wacom Abs Wheel Down Action",
-};
-
-/**
- * Convert the given property from an 8 bit integer property into an action
- * atom property. In the default case, this means that a property with
- * values "4 5 4 5" ends up to have the values
- * "Wacom RHU Action" "Wacom RHW Action" "Wacom AWU Action" "Wacom AWD
- * Action"
- * with each of the properties having :
- * AC_BUTTON | AC_KEYBTNPRESS | 4 (or 5)
- * AC_BUTTON | 4 (or 5)
- *
- * return 0 on success or 1 on failure.
- */
-static int convert_wheel_prop(Display *dpy, XDevice *dev, Atom btnact_prop)
-{
- int i;
- Atom type;
- int format;
- unsigned long btnact_nitems, bytes_after;
- unsigned char *btnact_data; /* current values (button mappings) */
- unsigned long *btnact_new_data; /* new values (action atoms) */
-
- XGetDeviceProperty(dpy, dev, btnact_prop, 0, 100, False,
- AnyPropertyType, &type, &format, &btnact_nitems,
- &bytes_after, (unsigned char**)&btnact_data);
-
- btnact_new_data = calloc(btnact_nitems, sizeof(Atom));
- if (!btnact_new_data)
- return 1;
-
- for (i = 0; i < btnact_nitems; i++) {
- unsigned long action_data[2];
- Atom prop = XInternAtom(dpy, wheel_act_prop[i], False);
-
- action_data[0] = AC_BUTTON | AC_KEYBTNPRESS | btnact_data[i];
- action_data[1] = AC_BUTTON | btnact_data[i];
-
- XChangeDeviceProperty(dpy, dev, prop, XA_INTEGER, 32,
- PropModeReplace,
- (unsigned char*)action_data, 2);
-
- btnact_new_data[i] = prop;
- }
-
- XChangeDeviceProperty(dpy, dev, btnact_prop, XA_ATOM, 32,
- PropModeReplace,
-
Re: [Linuxwacom-devel] [PATCH 5/7] Decrease minimum number of args to 'set' [allow wheels/strips "reset"]
On Wed, Mar 30, 2011 at 9:04 PM, Peter Hutterer 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
Re: [Linuxwacom-devel] [PATCH 1/7] Fail with warnings where possible
On Wed, Mar 30, 2011 at 8:57 PM, Peter Hutterer
wrote:
> On Wed, Mar 30, 2011 at 01:54:41PM -0700, Jason Gerecke wrote:
>> For many commands, improper arguments cause a silent failure. The
>> user is often given no indication if their command succeeded or
>> failed. I've tried to find all the silent "return;" statements and
>> provide some kind of warning message where possible.
>>
>> In some cases I've added in new checks to ensure that we have the
>> correct number of arguments. I've tried to make checks as pedantic
>> as possible, e.g. throwing errors about number of arguments even if
>> the function ignores arguments.
>>
>
> as a follow-up, it would be useful to have fprintf(stderr) replaced by an
> error() function.
>
I wholeheartedly agree, but was having trouble coming up with a good
error() function I liked.
>> Signed-off-by: Jason Gerecke
>> ---
>> tools/xsetwacom.c | 31 +++
>> 1 files changed, 31 insertions(+), 0 deletions(-)
>>
>> diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
>> index 41e4ced..337aa88 100644
>> --- a/tools/xsetwacom.c
>> +++ b/tools/xsetwacom.c
>> @@ -1234,7 +1234,10 @@ static void special_map_property(Display *dpy,
>> XDevice *dev, Atom btnact_prop, i
>> &bytes_after, (unsigned char**)&btnact_data);
>>
>> if (offset > btnact_nitems)
>> + {
>> + fprintf(stderr, "Invalid offset into %s property.\n",
>> XGetAtomName(dpy, btnact_prop));
>> return;
>> + }
>>
>> if (format == 8 && type == XA_INTEGER)
>> {
>> @@ -1242,7 +1245,10 @@ static void special_map_property(Display *dpy,
>> XDevice *dev, Atom btnact_prop, i
>> * mappings. Convert to 32 bit Atom actions first.
>> */
>> if (convert_wheel_prop(dpy, dev, btnact_prop))
>> + {
>> + fprintf(stderr, "Error creating wheel action.\n");
>> return;
>> + }
>>
>> XGetDeviceProperty(dpy, dev, btnact_prop, 0, 100, False,
>> AnyPropertyType, &type, &format,
>> @@ -1347,6 +1353,12 @@ static void set_xydefault(Display *dpy, XDevice *dev,
>> param_t* param, int argc,
>> unsigned long nitems, bytes_after;
>> long *ldata;
>>
>> + if (argc != 0)
>> + {
>> + fprintf(stderr, "Incorrect number of arguments supplied.\n");
>> + return;
>> + }
>> +
>> prop = XInternAtom(dpy, param->prop_name, True);
>> if (!prop)
>> {
>> @@ -1632,7 +1644,10 @@ static void get_mode(Display *dpy, XDevice *dev,
>> param_t* param, int argc, char
>> }
>>
>> if (!ndevices) /* device id 0 is reserved and can't be our device */
>> + {
>> + fprintf(stderr, "Unable to locate device.\n");
>> return;
>> + }
>>
>> TRACE("Getting mode for device %ld.\n", dev->device_id);
>>
>> @@ -1658,6 +1673,12 @@ static void get_rotate(Display *dpy, XDevice *dev,
>> param_t* param, int argc, cha
>> unsigned char* data;
>> unsigned long nitems, bytes_after;
>>
>> + if (argc != 0)
>> + {
>> + fprintf(stderr, "Incorrect number of arguments supplied.\n");
>> + return;
>> + }
>> +
>> prop = XInternAtom(dpy, param->prop_name, True);
>> if (!prop)
>> {
>> @@ -1937,7 +1958,11 @@ static void _set_matrix_prop(Display *dpy, XDevice
>> *dev, const float fmatrix[9])
>> &bytes_after, (unsigned char**)&data);
>>
>> if (format != 32 || type != XInternAtom(dpy, "FLOAT", True))
>> + {
>> + fprintf(stderr, "Property for '%s' has unexpected type - this
>> is a bug.\n",
>> + "Coordinate Transformation Matrix");
>
> this should use a define instead of typing the same property name twice..
>
Good call there.
>
>> return;
>> + }
>>
>> XChangeDeviceProperty(dpy, dev, matrix_prop, type, format,
>> PropModeReplace, (unsigned char*)matrix, 9);
>> @@ -1954,6 +1979,12 @@ static void set_output(Display *dpy, XDevice *dev,
>> param_t *param,
Re: [Linuxwacom-devel] [PATCH 7/7] Fix get_map to return proper wheel/strip button number
On Wed, Mar 30, 2011 at 9:20 PM, Peter Hutterer
wrote:
> On Wed, Mar 30, 2011 at 01:54:47PM -0700, Jason Gerecke wrote:
>> Adding to the only-kinda-hackish use of XGetDeviceButtonMapping,
>> in get_map, this total hackjob of a patch "fixes" the problem with
>> us having no way of knowing the driver's defaults for wheels and
>> strips.
>>
>> Thankfully, the defaults aren't changing anytime soon so its
>> not likely to break. Additionally, once the raw button path is
>> removed from the driver, the entire 'get_map' function can go
>> the way of the dodo.
>
> This seems to solve the wrong problem. How about we decide that xsetwacom
> controls the physical buttons on the device? That way, anyone wanting to
> configure logical mapping can use the X tools and xsetwacom is
> driver-specific and stays (documented so!) driver-specific. which of course
> also means we need to check that the Button xorg.conf option does the right
> thing.
>
That would make a number of things easier, but also comes with its own
drawbacks. I think we should probably figure out where hassle,
correctness, and compatibility collide first.
>> ---
>> tools/xsetwacom.c | 36
>> 1 files changed, 24 insertions(+), 12 deletions(-)
>>
>> diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
>> index 38002cb..1c0f43f 100644
>> --- a/tools/xsetwacom.c
>> +++ b/tools/xsetwacom.c
>> @@ -1884,22 +1884,34 @@ static void get_map(Display *dpy, XDevice *dev,
>> param_t *param, int argc, char**
>> else if (get_button(dpy, dev, param, offset))
>> return;
>> else
>> - {
>> - int nmap = 256;
>> - unsigned char map[nmap];
>> + { /* FIXME: Ugly hack because there's no way to get default buttons */
>> + if (strcmp(param->prop_name, WACOM_PROP_BUTTON_ACTIONS) == 0)
>> + {
>> + int nmap = 256;
>> + unsigned char map[nmap];
>>
>> - nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
>> + nmap = XGetDeviceButtonMapping(dpy, dev, map, nmap);
>>
>> - if (offset >= nmap)
>> - {
>> - fprintf(stderr, "Button number does not exist on
>> device.\n");
>> - return;
>> - }
>> + if (offset >= nmap)
>> + {
>> + fprintf(stderr, "Button number does not exist
>> on device.\n");
>> + return;
>> + }
>>
>> - print_value(param, "%d", map[offset]);
>> + print_value(param, "%d", map[offset]);
>>
>> - XSetDeviceButtonMapping(dpy, dev, map, nmap);
>> - XFlush(dpy);
>> + XSetDeviceButtonMapping(dpy, dev, map, nmap);
>
> I didn't pick this up in 155a4b9 but I don't think the
> XSetDeviceButtonMapping actually does anything here. Not sure why it's
> there, looks like a copy paste error (4d2c3d19dce4).
>
I remember being confused when I saw it, but didn't want to touch it.
I figured it was some arcane intricacy of X.
>
>> + XFlush(dpy);
>> + }
>> + else
>> + {
>> + switch (offset) {
>> + case 0: print_value(param, "4"); break;
>> + case 1: print_value(param, "5"); break;
>> + case 2: print_value(param, "4"); break;
>> + case 3: print_value(param, "5"); break;
>> + }
>> + }
>> }
>> }
>>
>> --
>> 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"]
On Thu, Mar 31, 2011 at 9:21 PM, Peter Hutterer 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 >> 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 7/7] Fix get_map to return proper wheel/strip button number
On Thu, Mar 31, 2011 at 9:28 PM, Peter Hutterer wrote: > On Thu, Mar 31, 2011 at 12:07:32AM -0700, Jason Gerecke wrote: >> On Wed, Mar 30, 2011 at 9:20 PM, Peter Hutterer >> wrote: >> > On Wed, Mar 30, 2011 at 01:54:47PM -0700, Jason Gerecke wrote: >> >> Adding to the only-kinda-hackish use of XGetDeviceButtonMapping, >> >> in get_map, this total hackjob of a patch "fixes" the problem with >> >> us having no way of knowing the driver's defaults for wheels and >> >> strips. >> >> >> >> Thankfully, the defaults aren't changing anytime soon so its >> >> not likely to break. Additionally, once the raw button path is >> >> removed from the driver, the entire 'get_map' function can go >> >> the way of the dodo. >> > >> > This seems to solve the wrong problem. How about we decide that xsetwacom >> > controls the physical buttons on the device? That way, anyone wanting to >> > configure logical mapping can use the X tools and xsetwacom is >> > driver-specific and stays (documented so!) driver-specific. which of course >> > also means we need to check that the Button xorg.conf option does the right >> > thing. >> > >> That would make a number of things easier, but also comes with its own >> drawbacks. I think we should probably figure out where hassle, >> correctness, and compatibility collide first. > > just checked the man page again: > > Option "ButtonM" "AC" > reports an action AC when button M is pressed, where M is one of the > device supported button numbers, it can be 1 to 32. Wacom uses a > driver-internal button mapping, where any physical button appears to the > X server as the button specified by the ButtonM mapping. Hence, if two > physical buttons have the same ButtonM mapping, the server will think > they are the same physical button. The default action reported to the X > server is mouse button M click. Because X uses buttons 4, 5, 6, and 7 as > the four scrolling directions, physical buttons 4 and higher are mapped > to 8 and higher by default. To ignore the button click, i.e., to not > report any button click event to the X server, use "0" or "button 0". > > so at least for the xorg.conf option, we already say that this is the > _physical_ button mapping. I guess it makes sense then to have xsetwacom do > the same on the physical buttons and leave the X specific stuff up to the X > tools. > > Cheers, > Peter > And xsetwacom's man page is wholly silent on just what its version 'M' is, so deferring to the existing docs would make sense. Of course, despite the lack of official documentation, its "expected" by users familiar with xsetwacom that it use the X button number. Don't get me wrong -- I'd love to see the change. I just hate breaking things for our users/customers without good cause. :) Then again, we already broke compatibility in the last release, so... 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"]
On Sun, Apr 3, 2011 at 8:26 PM, Peter Hutterer 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 >> 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 >> >> 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 st
Re: [Linuxwacom-devel] [linuxwacom-announce] [ANNOUNCE] xf86-input-wacom 0.10.99.1
On Sun, Apr 3, 2011 at 10:42 PM, Peter Hutterer wrote: > On Mon, Apr 04, 2011 at 07:32:44AM +0200, Andrzej Giniewicz wrote: >> > are you scrolling through gestures? afaict the scrolling code is hardcoded >> > to use 4/5 6/7 instead of the button mapping. >> >> yes, that was of course using gestures. It worked in 0.10.11 so I >> believe it was recent change to hardcode it? > > what changed was the way how xsetwacom worked. it used to set the X logical > button mapping but that's not the case anymore for simple button > mappings. > > Jason can tell you more but in the meantime xinput set-button-map "device > name" ... will get you there. > > Cheers, > Peter > If gesture code is hardcoded to use 4/5 (or to use e.g. relup/reldn) then that would actually explain the bug perfectly. Like Peter said, `xinput set-button-map` should work around the issue for now, but I'll try to see if I can get my hands on a bamboo and find where/how gestures are handled. 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"]
On Mon, Apr 4, 2011 at 6:50 PM, Peter Hutterer wrote: > On Mon, Apr 04, 2011 at 10:15:16AM -0700, Jason Gerecke wrote: >> On Sun, Apr 3, 2011 at 8:26 PM, Peter Hutterer >> 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 > I can be a little dense at times, so that could have been part of the problem :) I'll reword the commit message with v2 of my patchset to make it more accurate. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- 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
[Linuxwacom-devel] [PATCH 1/2] Allow gestures to use action button maps
Commit e9e7397cd1f1bc37f27992114cebd39f4ad93e12 changed xsetwacom
so that it no longer used XSetDeviceButtonMapping to handle "simple"
button mapping (parse_actions was modified to handle the translation
in the prior commit).
This patch modifies gestures so they work like buttons et.al. The
sendAButton function now sends an action if it exists, falling back
to the hardcoded defaults otherwise.
NOTE: The zoom gesture uses CTRL+ to zoom in and out.
If buttons 4 or 5 are remapped to press keyboard keys, the net
effect is the same as if CTRL were being held. This should be obvious
to users who understand how zooming works in most applications,
but is mentioned here for full disclosure.
Signed-off-by: Jason Gerecke
---
src/wcmCommon.c |2 +-
src/wcmTouchFilter.c | 23 ---
src/xf86Wacom.h |3 +++
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index a1eb742..0d3e8d8 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -199,7 +199,7 @@ static int countPresses(int keybtn, unsigned int* keys, int
size)
return count;
}
-static void sendAction(InputInfoPtr pInfo, int press,
+void sendAction(InputInfoPtr pInfo, int press,
unsigned int *keys, int nkeys,
int first_val, int num_val, int *valuators)
{
diff --git a/src/wcmTouchFilter.c b/src/wcmTouchFilter.c
index 4afede2..d8cb260 100644
--- a/src/wcmTouchFilter.c
+++ b/src/wcmTouchFilter.c
@@ -95,6 +95,7 @@ static void wcmSendButtonClick(WacomDevicePtr priv, int
button, int state)
int x = 0;
int y = 0;
int mode = is_absolute(priv->pInfo);
+ int valuators[priv->naxes];
if (mode)
{
@@ -102,10 +103,26 @@ static void wcmSendButtonClick(WacomDevicePtr priv, int
button, int state)
y = priv->oldY;
}
- /* send button event in state */
- xf86PostButtonEvent(priv->pInfo->dev, mode,button,
- state,0,priv->naxes,x,y,0,0,0,0);
+ valuators[0] = x;
+ valuators[1] = y;
+ valuators[2] = 0;
+ valuators[3] = 0;
+ valuators[4] = 0;
+ valuators[5] = 0;
+ if (!priv->keys[button][0])
+ {
+ /* No button action configured, send button */
+ xf86PostButtonEventP(priv->pInfo->dev, mode,
+button, (state != 0),
+0, priv->naxes, valuators);
+ }
+ else
+ {
+ sendAction(priv->pInfo, (state != 0), priv->keys[button],
+ ARRAY_SIZE(priv->keys[button]),
+ 0, priv->naxes, valuators);
+ }
/* We have changed the button state (from down to up) for the device
* so we need to update the record */
if (button == 1)
diff --git a/src/xf86Wacom.h b/src/xf86Wacom.h
index e5149b3..08ae858 100644
--- a/src/xf86Wacom.h
+++ b/src/xf86Wacom.h
@@ -153,6 +153,9 @@ extern void wcmChangeScreen(InputInfoPtr pInfo, int value);
extern int wcmTilt2R(int x, int y, double offset);
extern void wcmGestureFilter(WacomDevicePtr priv, int channel);
extern void wcmEmitKeycode(DeviceIntPtr keydev, int keycode, int state);
+extern void sendAction(InputInfoPtr pInfo, int press,
+ unsigned int *keys, int nkeys,
+ int first_val, int num_val, int *valuators);
extern void wcmSoftOutEvent(InputInfoPtr pInfo);
extern void wcmRotateTablet(InputInfoPtr pInfo, int value);
--
1.7.4.1
--
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
[Linuxwacom-devel] [PATCH 2/2] Fix cursor freeze after performing gesture - RFC
The prior patch has gestures use button mapping like buttons et.al.,
but for some reason this results in the cursor being "stuck" at the
top left of the screen when:
1) A gesture is performed
2) The gesture uses a button with an associated action
3) The action presses a button but does not release it
After much testing, I've found that this patch solves the issue and
also works for non-gesture code.
To be honest, I'm not sure why the old code didn't work but this does.
I see only see one difference in execution (the old code executed for
all 256 actions, '0' or not), but that change alone doesn't appear to
fix the bug...
Signed-off-by: Jason Gerecke
---
src/wcmCommon.c | 61 --
1 files changed, 23 insertions(+), 38 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index 0d3e8d8..ff70d64 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -206,7 +206,7 @@ void sendAction(InputInfoPtr pInfo, int press,
int i;
/* Actions only trigger on press, not release */
- for (i = 0; press && i < nkeys; i++)
+ for (i = 0; i < nkeys; i++)
{
unsigned int action = keys[i];
@@ -219,6 +219,17 @@ void sendAction(InputInfoPtr pInfo, int press,
{
int btn_no = (action & AC_CODE);
int is_press = (action &
AC_KEYBTNPRESS);
+
+ if (!press)
+ {
+ if (!is_press)
+ break;
+ if (countPresses(btn_no,
&keys[i], nkeys - i))
+ is_press = 0;
+ else
+ break;
+ }
+
xf86PostButtonEventP(pInfo->dev,
is_absolute(pInfo),
btn_no,
is_press,
first_val, num_val,
@@ -229,6 +240,17 @@ void sendAction(InputInfoPtr pInfo, int press,
{
int key_code = (action & AC_CODE);
int is_press = (action &
AC_KEYBTNPRESS);
+
+ if (!press)
+ {
+ if (!is_press)
+ break;
+ if (countPresses(key_code,
&keys[i], nkeys - i))
+ is_press = 0;
+ else
+ break;
+ }
+
wcmEmitKeycode(pInfo->dev, key_code,
is_press);
}
break;
@@ -239,43 +261,6 @@ void sendAction(InputInfoPtr pInfo, int press,
break;
}
}
-
- /* Release all non-released keys for this button. */
- for (i = 0; !press && i < nkeys; i++)
- {
- unsigned int action = keys[i];
-
- switch ((action & AC_TYPE))
- {
- case AC_BUTTON:
- {
- int btn_no = (action & AC_CODE);
-
- /* don't care about releases here */
- if (!(action & AC_KEYBTNPRESS))
- break;
-
- if (countPresses(btn_no, &keys[i],
nkeys - i))
- xf86PostButtonEvent(pInfo->dev,
-
is_absolute(pInfo), btn_no,
- 0, first_val,
num_val,
-
VCOPY(valuators, num_val));
- }
- break;
- case AC_KEY:
- {
- int key_code = (action & AC_CODE);
-
- /* don't care about releases here */
- if (!(action & AC_KEYBTNPRESS))
-
Re: [Linuxwacom-devel] [PATCH 2/2] Fix cursor freeze after performing gesture - RFC
On Tue, Apr 5, 2011 at 1:00 PM, Jason Gerecke wrote:
> The prior patch has gestures use button mapping like buttons et.al.,
> but for some reason this results in the cursor being "stuck" at the
> top left of the screen when:
>
> 1) A gesture is performed
> 2) The gesture uses a button with an associated action
> 3) The action presses a button but does not release it
>
> After much testing, I've found that this patch solves the issue and
> also works for non-gesture code.
>
> To be honest, I'm not sure why the old code didn't work but this does.
> I see only see one difference in execution (the old code executed for
> all 256 actions, '0' or not), but that change alone doesn't appear to
> fix the bug...
>
> Signed-off-by: Jason Gerecke
> ---
> src/wcmCommon.c | 61 --
> 1 files changed, 23 insertions(+), 38 deletions(-)
>
> diff --git a/src/wcmCommon.c b/src/wcmCommon.c
> index 0d3e8d8..ff70d64 100644
> --- a/src/wcmCommon.c
> +++ b/src/wcmCommon.c
> @@ -206,7 +206,7 @@ void sendAction(InputInfoPtr pInfo, int press,
> int i;
>
> /* Actions only trigger on press, not release */
> - for (i = 0; press && i < nkeys; i++)
> + for (i = 0; i < nkeys; i++)
> {
> unsigned int action = keys[i];
>
> @@ -219,6 +219,17 @@ void sendAction(InputInfoPtr pInfo, int press,
> {
> int btn_no = (action & AC_CODE);
> int is_press = (action &
> AC_KEYBTNPRESS);
> +
> + if (!press)
> + {
> + if (!is_press)
> + break;
> + if (countPresses(btn_no,
> &keys[i], nkeys - i))
> + is_press = 0;
> + else
> + break;
> + }
> +
> xf86PostButtonEventP(pInfo->dev,
>
> is_absolute(pInfo), btn_no,
> is_press,
> first_val, num_val,
> @@ -229,6 +240,17 @@ void sendAction(InputInfoPtr pInfo, int press,
> {
> int key_code = (action & AC_CODE);
> int is_press = (action &
> AC_KEYBTNPRESS);
> +
> + if (!press)
> + {
> + if (!is_press)
> + break;
> + if (countPresses(key_code,
> &keys[i], nkeys - i))
> + is_press = 0;
> + else
> + break;
> + }
> +
> wcmEmitKeycode(pInfo->dev, key_code,
> is_press);
> }
> break;
> @@ -239,43 +261,6 @@ void sendAction(InputInfoPtr pInfo, int press,
> break;
> }
> }
> -
> - /* Release all non-released keys for this button. */
> - for (i = 0; !press && i < nkeys; i++)
> - {
> - unsigned int action = keys[i];
> -
> - switch ((action & AC_TYPE))
> - {
> - case AC_BUTTON:
> - {
> - int btn_no = (action & AC_CODE);
> -
> - /* don't care about releases here */
> - if (!(action & AC_KEYBTNPRESS))
> - break;
> -
> - if (countPresses(btn_no, &keys[i],
> nkeys - i))
> -
> xf86PostButtonEvent(pInfo->dev,
> -
> is_absolute(pInfo), btn_no,
> - 0, first_val,
> num_val,
> -
[Linuxwacom-devel] [PATCH] Cause '-V' option to xsetwacom to exit like '--version'
Unexpected difference in behavior between two ways of specifying the same thing. '-V' no longer prints the version and continues to run the rest of the program. Signed-off-by: Jason Gerecke --- tools/xsetwacom.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c index 8c6d35d..28b42bc 100644 --- a/tools/xsetwacom.c +++ b/tools/xsetwacom.c @@ -2227,7 +2227,7 @@ int main (int argc, char **argv) break; case 'V': version(); - break; + return 0; case 'h': default: usage(); -- 1.7.4.1 -- 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
[Linuxwacom-devel] [PATCH] Correct order of arguments to calloc
Not that there's much difference between 4*(256 bytes) and 256*(4 bytes) of memory... Signed-off-by: Jason Gerecke --- tools/xsetwacom.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c index 8a84e9a..8c6d35d 100644 --- a/tools/xsetwacom.c +++ b/tools/xsetwacom.c @@ -1225,7 +1225,7 @@ static void special_map_property(Display *dpy, XDevice *dev, Atom btnact_prop, i unsigned long btnact_nitems, bytes_after; unsigned long nitems = 0; - data = calloc(sizeof(long), 256); + data = calloc(256, sizeof(long)); if (!parse_actions(dpy, argc, argv, data, &nitems)) return; -- 1.7.4.1 -- 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
[Linuxwacom-devel] [PATCH 1/3] Have man page reflect per-tablet nature of 'Rotate' option
Change documentation to indicate that rotation affects all tools associated with the same tablet. Signed-off-by: Jason Gerecke --- man/xsetwacom.man |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/man/xsetwacom.man b/man/xsetwacom.man index 2a8dd18..647921b 100644 --- a/man/xsetwacom.man +++ b/man/xsetwacom.man @@ -142,9 +142,9 @@ Set the tablet to the given rotation: cw: the tablet is rotated 90 degrees clockwise ccw: the tablet is rotated 90 degrees counter-clockwise -Rotation is tool-specific, rotation of one does not affect other input tools. -When the tablet is physically rotated, rotate all tools to the corresponding -orientation. Default: none +Rotation is a tablet-wide option: rotation of one tool affects all other tools +associated with the same tablet. When the tablet is physically rotated, rotate +any tool to the corresponding orientation. Default: none .TP \fBSuppress\fR level Set the delta (difference) cutoff level for further processing of incoming -- 1.7.4.1 -- 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
[Linuxwacom-devel] [PATCH 3/3] Expand manpage documentation for "Button" parameter
Include list of parameters that are supported, as well as an example of mixing keywords in one action. Signed-off-by: Jason Gerecke --- man/xsetwacom.man | 22 +++--- 1 files changed, 15 insertions(+), 7 deletions(-) diff --git a/man/xsetwacom.man b/man/xsetwacom.man index 608cef0..e7a47a9 100644 --- a/man/xsetwacom.man +++ b/man/xsetwacom.man @@ -98,13 +98,21 @@ applied. Input outside of these coordinates will be clipped to the edges of the area defined. Default: 0 0 x2 y2; with x2 and y2 tablet specific. .TP \fBButton\fR button-number [mapping] -Set the specified button. The mapping may be a button number to map -the physical button to. e.g. a mapping of button 1 to 3 means -a button 1 press will be interpreted as right click. Alternatively, a -mapping in the form of "key +a +shift b -shift -a" converts the button into a series -of keystrokes, in this example "press a, press shift, press and release b, -release shift, release a". Such key mappings need to be reapplied whenever -the keyboard layout changes. +Set a mapping for the specified button-number. Mappings take the form of +either a single numeric button or an 'action' to be performed. If no mapping +is provided, the default mapping is restored. + +Numeric button mappings indicate what X11 button number the given button-number +should correspond to. For example, a mapping of "3" means a press of the given +button-number will produce as a press of X11 button 3 (i.e. right click). + +Action mappings allow button presses to perform many events. They take the form +of a string of keywords and arguments. For example, "key +a +shift b -shift -a" +converts the button into a series of keystrokes, in this example "press a, press +shift, press and release b, release shift, release a". In addition to the "key" +keyword, "button" and "modetoggle" are also recognized. Multiple keywords may +be present in one action if desired: for example "key +ctrl button 5 key -ctrl" +will cause some applications to zoom out one level. .TP \fBMapToOutput\fR output Map the tablet's input area to the given output (e.g. "VGA1"). The output -- 1.7.4.1 -- 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
[Linuxwacom-devel] [PATCH 2/3] Swap range of 'RawSample' and 'Suppress' in man page
Looks like the range of these two options was confused a while back. Switch them so that the right option has the right range. Signed-off-by: Jason Gerecke --- man/xsetwacom.man |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/man/xsetwacom.man b/man/xsetwacom.man index 647921b..608cef0 100644 --- a/man/xsetwacom.man +++ b/man/xsetwacom.man @@ -133,7 +133,7 @@ all four values. .TP \fBRawSample\fR level Set the sample window size (a sliding average sampling window) for incoming -input tool raw data points. Default: 4, range of 1 to 100. +input tool raw data points. Default: 4, range of 1 to 20. .TP \fBRotate\fR none|half|cw|ccw Set the tablet to the given rotation: @@ -156,7 +156,7 @@ absolute wheel (AbsWheel) or Tilt value the delta between it and the previous value must be equal to or greater than the Suppress value in order to be sent on. Suppress is a tablet wide parameter. A specified delta level for one input tool is applied to all input tool coordinates. To -disable suppression use a level of 0. Default: 2, range of 0 to 20. +disable suppression use a level of 0. Default: 2, range of 0 to 100. .TP \fBTabletDebugLevel\fR level Set the debug level for this tablet to the given level. This only affects -- 1.7.4.1 -- 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
[Linuxwacom-devel] [PATCH 3v2/3] Expand manpage documentation for "Button" parameter
Include list of parameters that are supported, as well as an example of mixing keywords in one action. Signed-off-by: Jason Gerecke --- Changes from v1: * Remove superfluous mention of zoom man/xsetwacom.man | 21 ++--- 1 files changed, 14 insertions(+), 7 deletions(-) diff --git a/man/xsetwacom.man b/man/xsetwacom.man index 608cef0..e5643f9 100644 --- a/man/xsetwacom.man +++ b/man/xsetwacom.man @@ -98,13 +98,20 @@ applied. Input outside of these coordinates will be clipped to the edges of the area defined. Default: 0 0 x2 y2; with x2 and y2 tablet specific. .TP \fBButton\fR button-number [mapping] -Set the specified button. The mapping may be a button number to map -the physical button to. e.g. a mapping of button 1 to 3 means -a button 1 press will be interpreted as right click. Alternatively, a -mapping in the form of "key +a +shift b -shift -a" converts the button into a series -of keystrokes, in this example "press a, press shift, press and release b, -release shift, release a". Such key mappings need to be reapplied whenever -the keyboard layout changes. +Set a mapping for the specified button-number. Mappings take the form of +either a single numeric button or an 'action' to be performed. If no mapping +is provided, the default mapping is restored. + +Numeric button mappings indicate what X11 button number the given button-number +should correspond to. For example, a mapping of "3" means a press of the given +button-number will produce as a press of X11 button 3 (i.e. right click). + +Action mappings allow button presses to perform many events. They take the form +of a string of keywords and arguments. For example, "key +a +shift b -shift -a" +converts the button into a series of keystrokes, in this example "press a, press +shift, press and release b, release shift, release a". In addition to the "key" +keyword, "button" and "modetoggle" are also recognized. Multiple keywords may +be present in one action if desired: for example "key +ctrl button 5 key -ctrl". .TP \fBMapToOutput\fR output Map the tablet's input area to the given output (e.g. "VGA1"). The output -- 1.7.4.1 -- 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
[Linuxwacom-devel] Cintiq: TabletPCButton = on?
Right now the man page indicates that TabletPCButton is 'on' for TabletPCs and 'off' for everything else. It appears that this option is also 'on' for my Cintiq 21UX. Is this just less-than-clear documentation, or a driver bug? I was leaning to the first (as they're both "transparent" tablets), but the default behavior under Windows appears to be equivalent to 'off'. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Forrester Wave Report Recovery time is now measured in hours and minutes not days. key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Cintiq: TabletPCButton = on?
Yup, that seems to be the case. Looks like WCM_TPC is defined as (0x200 | WCM_LCD) in an effort to ensure that the "LCD" feature flag is also set. When wcmParseOptions uses TabletHasFeature to check for Tablet PCs, LCDs are included as well. I could remove WCM_LCD from the definition of WCM_TPC but I think the more correct fix would actually be changing TabletHasFeature(common, feature): from (((common->tablet_type) & (feature)) != 0) to (((common->tablet_type) & (feature)) == feature) I'll be working on some other patches first in case anybody wants to give some more feedback. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. On Mon, Apr 11, 2011 at 11:42 AM, Favux ... wrote: > Hi Jason, > > It should be off for a Cintiq as far as I know. Maybe WCM_LCD and > WCM_TPC are getting confabulated somewhere? > > Favux > > On Mon, Apr 11, 2011 at 1:33 PM, Jason Gerecke wrote: >> Right now the man page indicates that TabletPCButton is 'on' for >> TabletPCs and 'off' for everything else. It appears that this option >> is also 'on' for my Cintiq 21UX. Is this just less-than-clear >> documentation, or a driver bug? I was leaning to the first (as they're >> both "transparent" tablets), but the default behavior under Windows >> appears to be equivalent to 'off'. >> >> Jason >> >> --- >> Day xee-nee-svsh duu-'ushtlh-ts'it; >> nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. >> Huu-chan xuu naa~-gha. >> > -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [RFC PATCH] Add mask checking macros. (was Cintiq: TabletPCButton = on?)
On Mon, Apr 11, 2011 at 6:15 PM, Peter Hutterer
wrote:
>
> Signed-off-by: Peter Hutterer
> ---
>
>> I could remove WCM_LCD from the definition of WCM_TPC but I think the
>> more correct fix would actually be changing TabletHasFeature(common,
>> feature):
>>
>> from
>>
>> (((common->tablet_type) & (feature)) != 0)
>>
>> to
>>
>> (((common->tablet_type) & (feature)) == feature)
>>
>> I'll be working on some other patches first in case anybody wants to
>> give some more feedback.
>
> I've had this patch in my devel tree for a while but haven't started using
> it yet. Was born of the same problem that the == 0 check didn't cover what I
> needed at the time. Maybe we should use these instead.
>
> src/xf86WacomDefs.h | 14 ++
> test/wacom-tests.c | 21 +
> 2 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/src/xf86WacomDefs.h b/src/xf86WacomDefs.h
> index cae441c..9063fc0 100644
> --- a/src/xf86WacomDefs.h
> +++ b/src/xf86WacomDefs.h
> @@ -104,6 +104,20 @@
> #define OFF(x) ((x)%BITS_PER_LONG)
> #define LONG(x) ((x)/BITS_PER_LONG)
>
> +/**
> + * Test if the mask is set in the given bitfield.
> + * @return TRUE if set or FALSE otherwise.
> + */
> +#define MaskIsSet(bitfield, mask) !!(((bitfield) & (mask)) == (mask))
> +/**
> + * Set the given mask for the given bitfield.
> + */
> +#define MaskSet(bitfield, mask) ((bitfield) |= (mask))
> +/**
> + * Clear the given mask from the given bitfield
> + */
> +#define MaskClear(bitfield, mask) ((bitfield) &= ~(mask))
> +
> /**
> * Forward Declarations
> */
> diff --git a/test/wacom-tests.c b/test/wacom-tests.c
> index 42a7557..e0891ae 100644
> --- a/test/wacom-tests.c
> +++ b/test/wacom-tests.c
> @@ -531,6 +531,26 @@ static void test_set_type(void)
> #undef reset
> }
>
> +static int test_flag_set(void)
> +{
> + int i;
> + unsigned int flags = 0;
> +
> + for (i = 0; i < sizeof(flags); i++)
> + {
> + int mask = 1 << i;
> + flags = 0;
> +
> + assert(!MaskIsSet(flags, mask));
> + MaskSet(flags, mask);
> + assert(flags != 0);
> + assert(MaskIsSet(flags, mask));
> + MaskClear(flags, mask);
> + assert(!MaskIsSet(flags, mask));
> + assert(flags == 0);
> + }
> +}
> +
> int main(int argc, char** argv)
> {
> test_common_ref();
> @@ -541,6 +561,7 @@ int main(int argc, char** argv)
> test_tilt_to_rotation();
> test_mod_buttons();
> test_set_type();
> + test_flag_set();
> return 0;
> }
>
> --
> 1.7.4.2
>
Those look solid to me, and I'd be fine with them migrating their way
out of development. :)
Jason
---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 2/4] man: Fix hyphenation error
What else needs to be said? Signed-off-by: Jason Gerecke --- man/xsetwacom.man |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/man/xsetwacom.man b/man/xsetwacom.man index 910f873..5e6c3f0 100644 --- a/man/xsetwacom.man +++ b/man/xsetwacom.man @@ -117,7 +117,7 @@ be present in one action if desired: for example "key +ctrl button 5 key -ctrl". Map the tablet's input area to the given output (e.g. "VGA1"). The output must specify one of those available through the XRandR extension. A list of outputs may be obtained with the xrandr tool. The output mapping -configuration is a onetime setting and does not track output +configuration is a one-time setting and does not track output reconfigurations; the command needs to be re-run whenever the output configuration changes. When used with tablet rotation, the tablet must be rotated before it is mapped to the new screen. -- 1.7.4.1 -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 3/4] man: Fix __drivername__ macro
It seems we've been having this macro dangling in our manpage since 0862aa3d74378abbf9f23289ab864a4d07305d0d Signed-off-by: Jason Gerecke --- man/Makefile.am |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/man/Makefile.am b/man/Makefile.am index 993dff8..ec0add2 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -39,6 +39,9 @@ CLEANFILES = $(driverman_DATA) $(xsetwacomman_DATA) SUFFIXES = .$(DRIVER_MAN_SUFFIX) $(APP_MAN_SUFFIX) .man # String replacements in MAN_SUBSTS now come from xorg-macros.m4 via configure +MAN_SUBSTS += \ + -e 's|__drivername__|$(DRIVER_NAME)|g' + .man.$(DRIVER_MAN_SUFFIX): $(AM_V_GEN)$(SED) $(MAN_SUBSTS) < $< > $@ .man.$(APP_MAN_SUFFIX): -- 1.7.4.1 -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 4/4] man: Use __drivername__ instead of "wacom"
Because hardcoding things is uncool Signed-off-by: Jason Gerecke --- man/wacom.man |2 +- man/xsetwacom.man |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/man/wacom.man b/man/wacom.man index 8911294..a26dad1 100644 --- a/man/wacom.man +++ b/man/wacom.man @@ -1,7 +1,7 @@ .ds q \N'34' .TH WACOM __drivermansuffix__ __vendorversion__ .SH NAME -wacom \- Wacom input driver +__drivername__ \- Wacom input driver .SH SYNOPSIS .nf .B "Section \*qInputDevice\*q" diff --git a/man/xsetwacom.man b/man/xsetwacom.man index 5e6c3f0..2ac11c7 100644 --- a/man/xsetwacom.man +++ b/man/xsetwacom.man @@ -202,6 +202,6 @@ TabletDebugLevel. Default: 0, range of 0 to 12. Peter Hutterer .SH "SEE ALSO" -__xservername__(__appmansuffix__), wacom(__drivermansuffix__), +__xservername__(__appmansuffix__), __drivername__(__drivermansuffix__), xorg.conf(__filemansuffix__), X(__miscmansuffix__) -- 1.7.4.1 -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 1/4] man: Update usage information
The usage provided by '--help' is more accurate than that provided in the man page, and some arguments to '--set' do not require a value. Signed-off-by: Jason Gerecke --- man/xsetwacom.man |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/man/xsetwacom.man b/man/xsetwacom.man index 37eb95a..910f873 100644 --- a/man/xsetwacom.man +++ b/man/xsetwacom.man @@ -6,7 +6,7 @@ xsetwacom \- commandline utility to query and modify __drivername__ driver settings. .SH "SYNOPSIS" .LP -xsetwacom [options] command [device_name] [parameter] [value] +xsetwacom [options] [command [arguments]] .SH "DESCRIPTION" .LP @@ -79,7 +79,7 @@ added to the InputDevice section in the xorg.conf. .SS "SET COMMANDS" .TP -\fBset\fR device_name parameter value +\fBset\fR device_name parameter [value] Set the parameter value on the given device to the value provided. Note that not all parameters are writable, some are read-only and result in an error when trying to be modified. -- 1.7.4.1 -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 2/4] man: Fix hyphenation error
On Tue, Apr 12, 2011 at 12:53 PM, Favux ... wrote: > Onetime does not require a hyphen. Either usage is correct: > http://www.merriam-webster.com/dictionary/onetime It was substituted > as a synonym for one-off (once-off in Australian). > > I feel silly talking about this again. :( > > On Tue, Apr 12, 2011 at 2:06 PM, Jason Gerecke wrote: >> What else needs to be said? >> >> Signed-off-by: Jason Gerecke >> --- >> man/xsetwacom.man | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/man/xsetwacom.man b/man/xsetwacom.man >> index 910f873..5e6c3f0 100644 >> --- a/man/xsetwacom.man >> +++ b/man/xsetwacom.man >> @@ -117,7 +117,7 @@ be present in one action if desired: for example "key >> +ctrl button 5 key -ctrl". >> Map the tablet's input area to the given output (e.g. "VGA1"). The output >> must specify one of those available through the XRandR extension. A list of >> outputs may be obtained with the xrandr tool. The output mapping >> -configuration is a onetime setting and does not track output >> +configuration is a one-time setting and does not track output >> reconfigurations; the command needs to be re-run whenever the output >> configuration changes. When used with tablet rotation, the tablet must be >> rotated before it is mapped to the new screen. >> -- >> 1.7.4.1 >> >> Ahh, English. Such a crazy language. I hadn't realized that was an acceptable rendering. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [linuxwacom-announce] [ANNOUNCE] xf86-input-wacom 0.10.99.2
On Thu, Apr 14, 2011 at 5:20 AM, Andrzej Giniewicz wrote: > Some more tests done. First of all, I made tests for 2.6.38.2 and it > seems to work just as well as on 2.6.37.5 which I had before. > > Anyway, when doing more tests I noticed few new odd things in > gestures, things that as far as I remember worked better in 0.10.11 > (better as in better than now, but not necessarily 100% correctly) so > I believe this stuff can be labelled as regressions: > > First of all it's very very easy to generate multiple (usually 2 or 3) > RMB events when tapping second finger. It happens almost every time > for me. Is there some parameter to control it? LMB tapping works just > well with my setup. (I'm doing simple tests with: "xev | grep > Button"), maybe RMB events aren't respecting some parameters? Or > maybe, after successful tap and RMB generated, it should wait another > TapTime before accepting next event like that? > > Second thing is that when I align fingers correctly for scroll and > start moving them, for some time (approx half, maybe quarter of > second) the cursor moves and after that time, it starts to generate > normal scroll events like it should. > > There is also one thing that was reported for earlier versions too, > i.e. the jumps. Lets say I label fingers as A and B, If I put fingers > on the tablet in order A then B I have to remove them in exactly > reverse order, like B then A, or the cursor will jump by value that is > I believe difference between place where finger A started gesture to > on tablet where it is put now. Simple experiment: > > 1) Put finger A in top-right of tablet > 2) Put finger B right to it > 3) remove finger A from tablet > 4) remove finger B from tablet (actually, no gesture or events have to > be generated during this as far as I see) > 5) put finger in bottom-left corner, you should observe very big > absolute jump. The xev reports something like: > > MotionNotify event, serial 40, synthetic NO, window 0x181, > root 0x15d, subw 0x0, time 1918061, (1654,22), root:(1654,43), > state 0x0, is_hint 0, same_screen YES > > MotionNotify event, serial 40, synthetic NO, window 0x181, > root 0x15d, subw 0x0, time 1919525, (1004,386), root:(1004,407), > state 0x0, is_hint 0, same_screen YES > > MotionNotify event, serial 40, synthetic NO, window 0x181, > root 0x15d, subw 0x0, time 1919561, (1004,386), root:(1004,407), > state 0x0, is_hint 0, same_screen YES > > (those are 3 events, just before jump, the one generating jump and one > after the jump. There are no other events in between) > > I will play with it more, but those are all odd things I found for now > > Cheers, > Andrzej. > I'm interested in knowing if you're seeing these behaviors with my RFC gesture patch in place or not (and if so, whether you've remapped the scroll direction). Its the only overt change to gesture code I can remember off the top of my head, but wasn't included in the 0.10.99.2 release. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 4/4] man: Describe ToolSerials option
From: Alexia Death Adds a description of the "ToolSerials" option to the driver manpage. Slightly modified from Alexia's original patch (breaks the list of types out into the description) Signed-off-by: Jason Gerecke --- man/wacom.man |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/man/wacom.man b/man/wacom.man index a26dad1..d5dc9f1 100644 --- a/man/wacom.man +++ b/man/wacom.man @@ -206,6 +206,13 @@ option is only available on wacom V devices (Intuos series and Cintiq 21U). To see which serial number belongs to a device, you need to run the utility program, xsetwacom, which comes with linuxwacom package. .TP 4 +.B Option \fI"ToolSerials"\fP \fI"number[,type[,label]][;...]"\fP +sets the list of serial numbered devices that need to be hotplugged for a physical +device. The 'type' option may be any of "pen", "airbrush", "artpen", or "cursor". +This option is only available on wacom V devices (Intuos series and Cintiq 21U). +To see which serial number belongs to a device, you need to run the utility program, +xsetwacom, that comes with this driver. +.TP 4 .B Option \fI"Threshold"\fP \fI"number"\fP sets the pressure threshold used to generate a button 1 events of stylus. The threshold applies to the normalised pressure range of [0..2048]. -- 1.7.4.1 -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 3/4] Allow serial hotplugging only on protocol 5 devices
Since only protocol 5 devices (Intuos, Cintiq) allow tool-specific
serial numbers, we limit hotplugging to devices supporting that
protocol.
For this to work, we need to move the call to wcmInitModel (which
several calls down sets common->wcmProtocolLevel) before the call
to wcmParseOptions. From what I can tell, the order of calls shouldn't
otherwise matter here.
Signed-off-by: Jason Gerecke
---
src/wcmConfig.c |4 ++--
src/wcmValidateDevice.c |6 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/wcmConfig.c b/src/wcmConfig.c
index 5fa8271..1b4fc42 100644
--- a/src/wcmConfig.c
+++ b/src/wcmConfig.c
@@ -564,10 +564,10 @@ static int wcmPreInit(InputDriverPtr drv, InputInfoPtr
pInfo, int flags)
if (!wcmSetType(pInfo, type))
goto SetupProc_fail;
- if (!wcmParseOptions(pInfo, need_hotplug, is_dependent))
+ if (!wcmInitModel(pInfo))
goto SetupProc_fail;
- if (!wcmInitModel(pInfo))
+ if (!wcmParseOptions(pInfo, need_hotplug, is_dependent))
goto SetupProc_fail;
if (need_hotplug)
diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
index 8e4f4cd..0785c21 100644
--- a/src/wcmValidateDevice.c
+++ b/src/wcmValidateDevice.c
@@ -578,6 +578,12 @@ int wcmParseSerials (InputInfoPtr pInfo)
return 0; /*Parse has been already done*/
}
+ if (common->wcmProtocolLevel != WCM_PROTOCOL_5)
+ {
+ xf86Msg(X_WARNING, "ToolSerials option not valid on this
device.\n");
+ return 0;
+ }
+
s = xf86SetStrOption(pInfo->options, "ToolSerials", NULL);
if (s) /*Dont parse again, if the commons have values already*/
{
--
1.7.4.1
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 1/4] Add ToolSerials option for hotplugging pens
From: Alexia Death
Provide a new "ToolSerials" option which describes tools that should
be automatically hotplugged along with the standard devices. This is
achieved by parsing "ToolSerials" while the master device is being
initialized to create a WacomTool list. This list is then used while
hotplugging child devices to create tool-specific devices with the
"Serial" option set appropriately.
The "ToolSerials" option should be added to the 50-wacom.conf file
in /etc/X11/xorg.conf.d so that it is applied to hotplugged tablets.
The option takes the following format:
Option "ToolSerials" "serial[,type[,label]][;...]"
Or, for a more concrete example:
Option "ToolSerials" "113246231,airbrush,Airbrush;85983311,artpen,Artpen"
ToolSerials recognizes the "pen", "airbrush", "artpen", and "cursor"
types. Unknown (or unspecified) types default to creating "pen"-type
tools with both 'stylus' and 'eraser' devices.
Signed-off-by: Alexia Death
Acked-by: Jason Gerecke
---
src/wcmCommon.c |7 ++
src/wcmValidateDevice.c | 144 +--
src/xf86Wacom.h |2 +
src/xf86WacomDefs.h | 21 +++
4 files changed, 169 insertions(+), 5 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index 99e2bb6..822306c 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -1390,6 +1390,13 @@ void wcmFreeCommon(WacomCommonPtr *ptr)
if (--common->refcnt == 0)
{
free(common->private);
+ while (--common->nserials >= 0)
+ {
+ DBG(10, common, "Free common serial %d: %d %s\n",
common->nserials,
+
common->serials[common->nserials]->serial,
+
common->serials[common->nserials]->name);
+ free(common->serials[common->nserials]);
+ }
free(common);
}
*ptr = NULL;
diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
index 7fcc351..1a67994 100644
--- a/src/wcmValidateDevice.c
+++ b/src/wcmValidateDevice.c
@@ -306,9 +306,12 @@ int wcmDeviceTypeKeys(InputInfoPtr pInfo)
/**
* Duplicate xf86 options, replace the "type" option with the given type
* (and the name with "$name $type" and convert them to InputOption */
-static InputOption *wcmOptionDupConvert(InputInfoPtr pInfo, const char*
basename, const char *type)
+static InputOption *wcmOptionDupConvert(InputInfoPtr pInfo, const char*
basename, const char *type, int iserial)
{
+ WacomDevicePtr priv = pInfo->private;
+ WacomCommonPtr common = priv->common;
pointer original = pInfo->options;
+ WacomToolSerialPtr ser = common->serials[iserial];
InputOption *iopts = NULL, *new;
char *name;
pointer options;
@@ -325,13 +328,26 @@ static InputOption *wcmOptionDupConvert(InputInfoPtr
pInfo, const char* basename
options = dummy.options;
}
#endif
+ if (iserial > -1)
+ {
+
+ if (strlen(ser->name) > 0)
+ rc = asprintf(&name, "%s %s %s", basename, ser->name,
type);
+ else
+ rc = asprintf(&name, "%s %d %s", basename, ser->serial,
type);
+ }
+ else
+ rc = asprintf(&name, "%s %s", basename, type);
- rc = asprintf(&name, "%s %s", basename, type);
if (rc == -1) /* if asprintf fails, strdup will probably too... */
name = strdup("unknown");
options = xf86ReplaceStrOption(options, "Type", type);
options = xf86ReplaceStrOption(options, "Name", name);
+
+ if (iserial > -1)
+ options = xf86ReplaceIntOption(options, "Serial", ser->serial);
+
free(name);
while(options)
@@ -435,7 +451,7 @@ wcmHotplugDevice(ClientPtr client, pointer closure )
* @param basename The base name for the device (type will be appended)
* @param type Type name for this tool
*/
-static void wcmQueueHotplug(InputInfoPtr pInfo, const char* basename, const
char *type)
+static void wcmQueueHotplug(InputInfoPtr pInfo, const char* basename, const
char *type, int iserial)
{
WacomHotplugInfo *hotplug_info;
@@ -447,13 +463,42 @@ static void wcmQueueHotplug(InputInfoPtr pInfo, const
char* basename, const char
return;
}
- hotplug_info->input_options = wcmOptionDupConvert(pInfo, basename,
type);
+ hotplug_info->input_options = wcmOptionDupConvert(pInfo, basename,
type, iserial);
#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 11
hotplug_info-
[Linuxwacom-devel] [PATCH 2/4] Have ToolSerials patch re-use existing infrastructure
This tweaks the prior ToolSerials patch to use the existing
infrastructure where appropriate. For instance, using the 'WacomTool'
struct instead of the custom 'WacomToolSerial' struct.
This should actually be integrated as a "fixup", but is included
here to more easily see the changes from the original.
Signed-off-by: Jason Gerecke
---
src/wcmCommon.c | 13 +---
src/wcmValidateDevice.c | 69 +++
src/xf86WacomDefs.h | 22 +-
3 files changed, 44 insertions(+), 60 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index 822306c..3905b07 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -1390,12 +1390,15 @@ void wcmFreeCommon(WacomCommonPtr *ptr)
if (--common->refcnt == 0)
{
free(common->private);
- while (--common->nserials >= 0)
+ while (common->serials)
{
- DBG(10, common, "Free common serial %d: %d %s\n",
common->nserials,
-
common->serials[common->nserials]->serial,
-
common->serials[common->nserials]->name);
- free(common->serials[common->nserials]);
+ DBG(10, common, "Free common serial: %d %s\n",
+ common->serials->serial,
+ common->serials->name);
+
+ WacomToolPtr next = common->serials->next;
+ free(common->serials);
+ common->serials = next;
}
free(common);
}
diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
index 1a67994..8e4f4cd 100644
--- a/src/wcmValidateDevice.c
+++ b/src/wcmValidateDevice.c
@@ -311,7 +311,7 @@ static InputOption *wcmOptionDupConvert(InputInfoPtr pInfo,
const char* basename
WacomDevicePtr priv = pInfo->private;
WacomCommonPtr common = priv->common;
pointer original = pInfo->options;
- WacomToolSerialPtr ser = common->serials[iserial];
+ WacomToolPtr ser = common->serials;
InputOption *iopts = NULL, *new;
char *name;
pointer options;
@@ -330,6 +330,8 @@ static InputOption *wcmOptionDupConvert(InputInfoPtr pInfo,
const char* basename
#endif
if (iserial > -1)
{
+ while (ser->serial && ser->serial != iserial)
+ ser = ser->next;
if (strlen(ser->name) > 0)
rc = asprintf(&name, "%s %s %s", basename, ser->name,
type);
@@ -474,29 +476,26 @@ void wcmHotplugSerials(InputInfoPtr pInfo, const char
*basename)
{
WacomDevicePtr priv = (WacomDevicePtr)pInfo->private;
WacomCommonPtr common = priv->common;
-int i;
+ WacomToolPtrser = common->serials;
- if (common->nserials > 0)
+ while (ser)
{
- for (i = 0; i < common->nserials; i++)
- {
- WacomToolSerialPtr ser = common->serials[i];
- xf86Msg(X_INFO, "%s: hotplugging serial %d.\n",
pInfo->name, ser->serial);
+ xf86Msg(X_INFO, "%s: hotplugging serial %d.\n", pInfo->name,
ser->serial);
- if (wcmIsAValidType(pInfo, "stylus") &&
- (ser->types & SERIAL_HAS_STYLUS))
- wcmQueueHotplug(pInfo, basename, "stylus", i);
+ if (wcmIsAValidType(pInfo, "stylus") &&
+ (ser->typeid & STYLUS_ID))
+ wcmQueueHotplug(pInfo, basename, "stylus", ser->serial);
- if (wcmIsAValidType(pInfo, "eraser") &&
- (ser->types & SERIAL_HAS_ERASER))
- wcmQueueHotplug(pInfo, basename, "eraser", i);
+ if (wcmIsAValidType(pInfo, "eraser") &&
+ (ser->typeid & ERASER_ID))
+ wcmQueueHotplug(pInfo, basename, "eraser", ser->serial);
- if (wcmIsAValidType(pInfo, "cursor") &&
- (ser->types & SERIAL_HAS_CURSOR))
- wcmQueueHotplug(pInfo, basename, "cursor", i);
- }
- }
+ if (wcmIsAValidType(pInfo, "cursor") &&
+ (ser->typeid & CURSOR_ID))
+ wcmQueueHotplug(pInfo, basename, "cursor", ser->serial);
+ ser = ser->next;
Re: [Linuxwacom-devel] [PATCH 2/4] Have ToolSerials patch re-use existing infrastructure
On Mon, Apr 18, 2011 at 11:26 AM, Jason Gerecke wrote: > This tweaks the prior ToolSerials patch to use the existing > infrastructure where appropriate. For instance, using the 'WacomTool' > struct instead of the custom 'WacomToolSerial' struct. > > This should actually be integrated as a "fixup", but is included > here to more easily see the changes from the original. > > Signed-off-by: Jason Gerecke > --- > src/wcmCommon.c | 13 +--- > src/wcmValidateDevice.c | 69 > +++ > src/xf86WacomDefs.h | 22 +- > 3 files changed, 44 insertions(+), 60 deletions(-) > > [Patch goes here :D] > Just as a note, I also really wanted to re-use the wcmTool variable but it seems to be used in a slightly different and incompatible way. Oh well. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
