date:20110324

Re: [Linuxwacom-devel] [PATCH 1/2] Resolve the oldHwProx puzzle

2011-03-24 Thread Ping Cheng

I found two typoes in the commit comment. I'll update them if changes are
needed in the code. Otherwise, please amend them before merging.

Thanks,

Ping

On Fri, Mar 25, 2011 at 6:35 AM, Ping Cheng  wrote:

> Change oldHwProx to oldCursorHwProx to better refect its use.
>

reflect


> Protocol 5 distance starts from the MaxCursorDist (256) when
> getting in the prox while protocol 4 distance is 0 when
> getting in the prox.
>
> oldCursorHwProx keeps the hardware in/out prox state so we can
> we set the MaxCursorDist for the next round of relative cursor
>

 extra we.


> movement when tool first comes in prox.
>
> Signed-off-by: Ping Cheng 
> ---
>  src/wcmCommon.c |   24 ++--
>  src/wcmConfig.c |2 +-
>  src/wcmUSB.c|4 
>  src/xf86Wacom.c |6 --
>  src/xf86WacomDefs.h |2 +-
>  5 files changed, 12 insertions(+), 26 deletions(-)
>
> diff --git a/src/wcmCommon.c b/src/wcmCommon.c
> index 0f858eb..845cf6e 100644
> --- a/src/wcmCommon.c
> +++ b/src/wcmCommon.c
> @@ -31,6 +31,8 @@
>  #define THRESHOLD_TOLERANCE (FILTER_PRESSURE_RES / 125)
>  #define DEFAULT_THRESHOLD (FILTER_PRESSURE_RES / 75)
>
> +#define MAX_CURSOR_DISTANCE 256
> +
>  /* X servers pre 1.9 didn't copy data passed into xf86Post*Event.
>  * Data passed in would be modified, requiring the driver to copy the
>  * data beforehand.
> @@ -1138,14 +1140,6 @@ static void commonDispatchDevice(WacomCommonPtr
> common, unsigned int channel,
>/* Device transformations come first */
>priv = pInfo->private;
>
> -   if (IsUSBDevice(common))
> -   {
> -   if (IsTouch(priv) && !ds->proximity)
> -   priv->oldHwProx = 0;
> -   else if (IsStylus(priv) || IsEraser(priv))
> -   priv->oldHwProx = 1;
> -   }
> -
>/* send a touch out for USB Tablet PCs */
>if (IsUSBDevice(common) && !IsTouch(priv)
>&& common->wcmTouchDefault && !priv->oldProximity)
> @@ -1180,19 +1174,18 @@ static void commonDispatchDevice(WacomCommonPtr
> common, unsigned int channel,
>filtered.pressure = applyPressureCurve(priv,&filtered);
>}
>
> -   else if (IsCursor(priv) && !priv->oldHwProx)
> +   else if (IsCursor(priv) && !priv->oldCursorHwProx)
>{
>/* initial current max distance for Intuos series */
>if ((TabletHasFeature(common, WCM_ROTATION)) ||
>(TabletHasFeature(common, WCM_DUALINPUT)))
> -   common->wcmMaxCursorDist = 256;
> +   common->wcmMaxCursorDist = MAX_CURSOR_DISTANCE;
>else
>common->wcmMaxCursorDist = 0;
>}
>
> -   /* Store current hard prox for next use */
> -   if (!IsTouch(priv))
> -   priv->oldHwProx = ds->proximity;
> +   /* Store cursor hardware prox for next use */
> +   priv->oldCursorHwProx = ds->proximity;
>
>/* User-requested filtering comes next */
>
> @@ -1227,14 +1220,17 @@ static void commonDispatchDevice(WacomCommonPtr
> common, unsigned int channel,
>/* force out-prox when distance is outside wcmCursorProxoutDist for
> pucks */
>if (IsCursor(priv))
>{
> -   /* force out-prox when distance is outside
> wcmCursorProxoutDist. */
>if (common->wcmProtocolLevel == WCM_PROTOCOL_5)
>{
> +   /* protocol 5 distance starts from the
> MaxCursorDist
> +* when getting in the prox.
> +*/
>if (common->wcmMaxCursorDist > filtered.distance)
>common->wcmMaxCursorDist =
> filtered.distance;
>}
>else
>{
> +   /* protocol 4 distance is 0 when getting in the
> prox */
>if (common->wcmMaxCursorDist < filtered.distance)
>common->wcmMaxCursorDist =
> filtered.distance;
>}
> diff --git a/src/wcmConfig.c b/src/wcmConfig.c
> index 2bf0ed3..6235d3c 100644
> --- a/src/wcmConfig.c
> +++ b/src/wcmConfig.c
> @@ -62,7 +62,7 @@ static int wcmAllocate(InputInfoPtr pInfo)
>priv->next = NULL;
>priv->pInfo = pInfo;
>priv->common = common;   /* common info pointer */
> -   priv->oldHwProx = 1; /* previous hardware proximity */
> +   priv->oldCursorHwProx = 0;   /* previous cursor hardware proximity
> */
>priv->nPressCtrl [0] = 0;/* pressure curve x0 */
>priv->nPressCtrl [1] = 0;/* pressure curve y0 */
>priv->nPressCtrl [2] = 100;  /* pressure curve x1 */
> diff --git a/src/wcmUSB.c b/src/wcmUSB.c
> index 5f0dbe2..e65f24f 100644
> --- a/src/wcmUSB.c
> +++ b/src/wcmUSB.c
> @@ -394,10 +394,6 @@ static void usbInitProtocol5(WacomCommonPtr common,
> const char* id,
>
>/* tilt enabled */

[Linuxwacom-devel] [PATCH 3/4] Don't use unset_prop

2011-03-24 Thread Jason Gerecke

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 2/4] Make parse error more helpful

2011-03-24 Thread Jason Gerecke

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 4/4] Make set/unset code easier to understand

2011-03-24 Thread Jason Gerecke

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_ATOM, 
32,
+   PropModeReplace,
+   (unsigned char*)btnact_data,
+

[Linuxwacom-devel] [PATCH 1/4] Return from function on parse error

2011-03-24 Thread Jason Gerecke

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

Re: [Linuxwacom-devel] [PATCH 1/2] Fix X crash after remapping touchstrips and wheels

2011-03-24 Thread Peter Hutterer

On Thu, Mar 24, 2011 at 10:54:26AM -0700, Jason Gerecke wrote:
> 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

the server has a MAX_BUTTONS define of 256. it may have been 32 in the past.
though what I suspect is that this was copied from the mouse driver which
had a maxbuttons define for 32. the core protocol certainly supports up to
256 buttons.

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

no objection. code readability and simplification beats run-time efficiency
any day :)
(note though that the raw button path happens if there is no property
assigned to it but I guess you're aware of that already)

Cheers,
  Peter

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

--
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/2] Add CursorProximity to xsetwacom.man

2011-03-24 Thread Ping Cheng

Signed-off-by: Ping Cheng 
---
 man/xsetwacom.man |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/man/xsetwacom.man b/man/xsetwacom.man
index 0d44366..2a8dd18 100644
--- a/man/xsetwacom.man
+++ b/man/xsetwacom.man
@@ -171,6 +171,11 @@ to work.  If off, stylus buttons will work once the stylus 
is in proximity
 of the tablet (regardless of whether it is touching the screen).  Default:  on
 for Tablet PCs; off for all other models.
 .TP
+\fBCursorProximity\fR distance
+sets the max distance from tablet to stop reporting movement for cursor in
+relative mode. Default for Intuos series is 10, for Graphire series (including
+Volitos) is 42. Only available for the cursor/puck device.
+.TP
 \fBThreshold\fR level
 Set the minimum pressure necessary to generate a Button event for the stylus
 tip, eraser, or touch.  The pressure levels of all tablets are normalized to
-- 
1.7.4


--
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/2] Resolve the oldHwProx puzzle

2011-03-24 Thread Ping Cheng

Change oldHwProx to oldCursorHwProx to better refect its use.

Protocol 5 distance starts from the MaxCursorDist (256) when
getting in the prox while protocol 4 distance is 0 when
getting in the prox.

oldCursorHwProx keeps the hardware in/out prox state so we can
we set the MaxCursorDist for the next round of relative cursor
movement when tool first comes in prox.

Signed-off-by: Ping Cheng 
---
 src/wcmCommon.c |   24 ++--
 src/wcmConfig.c |2 +-
 src/wcmUSB.c|4 
 src/xf86Wacom.c |6 --
 src/xf86WacomDefs.h |2 +-
 5 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index 0f858eb..845cf6e 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -31,6 +31,8 @@
 #define THRESHOLD_TOLERANCE (FILTER_PRESSURE_RES / 125)
 #define DEFAULT_THRESHOLD (FILTER_PRESSURE_RES / 75)
 
+#define MAX_CURSOR_DISTANCE 256
+
 /* X servers pre 1.9 didn't copy data passed into xf86Post*Event.
  * Data passed in would be modified, requiring the driver to copy the
  * data beforehand.
@@ -1138,14 +1140,6 @@ static void commonDispatchDevice(WacomCommonPtr common, 
unsigned int channel,
/* Device transformations come first */
priv = pInfo->private;
 
-   if (IsUSBDevice(common))
-   {
-   if (IsTouch(priv) && !ds->proximity)
-   priv->oldHwProx = 0;
-   else if (IsStylus(priv) || IsEraser(priv))
-   priv->oldHwProx = 1;
-   }
-
/* send a touch out for USB Tablet PCs */
if (IsUSBDevice(common) && !IsTouch(priv)
&& common->wcmTouchDefault && !priv->oldProximity)
@@ -1180,19 +1174,18 @@ static void commonDispatchDevice(WacomCommonPtr common, 
unsigned int channel,
filtered.pressure = applyPressureCurve(priv,&filtered);
}
 
-   else if (IsCursor(priv) && !priv->oldHwProx)
+   else if (IsCursor(priv) && !priv->oldCursorHwProx)
{
/* initial current max distance for Intuos series */
if ((TabletHasFeature(common, WCM_ROTATION)) ||
(TabletHasFeature(common, WCM_DUALINPUT)))
-   common->wcmMaxCursorDist = 256;
+   common->wcmMaxCursorDist = MAX_CURSOR_DISTANCE;
else
common->wcmMaxCursorDist = 0;
}
 
-   /* Store current hard prox for next use */
-   if (!IsTouch(priv))
-   priv->oldHwProx = ds->proximity;
+   /* Store cursor hardware prox for next use */
+   priv->oldCursorHwProx = ds->proximity;
 
/* User-requested filtering comes next */
 
@@ -1227,14 +1220,17 @@ static void commonDispatchDevice(WacomCommonPtr common, 
unsigned int channel,
/* force out-prox when distance is outside wcmCursorProxoutDist for 
pucks */
if (IsCursor(priv))
{
-   /* force out-prox when distance is outside 
wcmCursorProxoutDist. */
if (common->wcmProtocolLevel == WCM_PROTOCOL_5)
{
+   /* protocol 5 distance starts from the MaxCursorDist
+* when getting in the prox.
+*/
if (common->wcmMaxCursorDist > filtered.distance)
common->wcmMaxCursorDist = filtered.distance;
}
else
{
+   /* protocol 4 distance is 0 when getting in the prox */
if (common->wcmMaxCursorDist < filtered.distance)
common->wcmMaxCursorDist = filtered.distance;
}
diff --git a/src/wcmConfig.c b/src/wcmConfig.c
index 2bf0ed3..6235d3c 100644
--- a/src/wcmConfig.c
+++ b/src/wcmConfig.c
@@ -62,7 +62,7 @@ static int wcmAllocate(InputInfoPtr pInfo)
priv->next = NULL;
priv->pInfo = pInfo;
priv->common = common;   /* common info pointer */
-   priv->oldHwProx = 1; /* previous hardware proximity */
+   priv->oldCursorHwProx = 0;   /* previous cursor hardware proximity */
priv->nPressCtrl [0] = 0;/* pressure curve x0 */
priv->nPressCtrl [1] = 0;/* pressure curve y0 */
priv->nPressCtrl [2] = 100;  /* pressure curve x1 */
diff --git a/src/wcmUSB.c b/src/wcmUSB.c
index 5f0dbe2..e65f24f 100644
--- a/src/wcmUSB.c
+++ b/src/wcmUSB.c
@@ -394,10 +394,6 @@ static void usbInitProtocol5(WacomCommonPtr common, const 
char* id,
 
/* tilt enabled */
common->wcmFlags |= TILT_ENABLED_FLAG;
-
-   /* reinitialize max here since 0 is for Graphire series */
-   common->wcmMaxCursorDist = 256;
-
 }
 
 static void usbInitProtocol4(WacomCommonPtr common, const char* id,
diff --git a/src/xf86Wacom.c b/src/xf86Wacom.c
index 6762a3d..a124ed3 100644
--- a/src/xf86Wacom.c
+++ b/src/xf86Wacom.c
@@ -442,12 +442,6 @@ static int wcmDevInit(DeviceIntPtr pWcm)

Re: [Linuxwacom-devel] Area Option Relative

2011-03-24 Thread Jason Gerecke

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

Re: [Linuxwacom-devel] Kernel driver for OLED support (was: OLED setting for xsetwacom)

2011-03-24 Thread Eduard Hasenleithner

2011/3/24 Ping Cheng :
> Happy hacking.

I have another question. Is there documentation (from Wacom) on how to
access the OLEDs? If not, how did Nicolas Hirsch manage to write the
patch?

It is just that I want to check if minor improvements to the IOCTL
interface can be done, and for that it might be good to know if
something is missing or implemented suboptimal.

Thanks,
Eduard

--
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] Area Option Relative

2011-03-24 Thread Cedric Sodhi

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

Re: [Linuxwacom-devel] [PATCH 1/2] Fix X crash after remapping touchstrips and wheels

2011-03-24 Thread Jason Gerecke

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] [PATCH 1/2] Resolve the oldHwProx puzzle

[Linuxwacom-devel] [PATCH 3/4] Don't use unset_prop

[Linuxwacom-devel] [PATCH 2/4] Make parse error more helpful

[Linuxwacom-devel] [PATCH 4/4] Make set/unset code easier to understand

[Linuxwacom-devel] [PATCH 1/4] Return from function on parse error

Re: [Linuxwacom-devel] [PATCH 1/2] Fix X crash after remapping touchstrips and wheels

[Linuxwacom-devel] [PATCH 2/2] Add CursorProximity to xsetwacom.man

[Linuxwacom-devel] [PATCH 1/2] Resolve the oldHwProx puzzle

Re: [Linuxwacom-devel] Area Option Relative

Re: [Linuxwacom-devel] Kernel driver for OLED support (was: OLED setting for xsetwacom)

[Linuxwacom-devel] Area Option Relative

Re: [Linuxwacom-devel] [PATCH 1/2] Fix X crash after remapping touchstrips and wheels

12 matches

Site Navigation

Mail list logo

Footer information