Re: [Linuxwacom-devel] Wrapping up DIGImend work
On 08/31/2016 02:58 PM, Nikolai Kondrashov wrote: > Hi everyone, > > I would like to regretfully inform you that I'm wrapping up my work on the > DIGImend project. Within two months I'm going to stop all work on the project, > with the exception of accepting patches, as time allows, if a replacement is > not found. Meanwhile I will be focusing on syncing with upstream kernel and > writing HOWTOs on diagnosing problems and adding tablet support. > > See more at http://localhost:4000/2016/07/31/Wrapping-up-DIGImend-work.html And of course I had to screw up the URL: http://spbnick.github.io/2016/07/31/Wrapping-up-DIGImend-work.html Nick -- ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] Wrapping up DIGImend work
Hi everyone, I would like to regretfully inform you that I'm wrapping up my work on the DIGImend project. Within two months I'm going to stop all work on the project, with the exception of accepting patches, as time allows, if a replacement is not found. Meanwhile I will be focusing on syncing with upstream kernel and writing HOWTOs on diagnosing problems and adding tablet support. See more at http://localhost:4000/2016/07/31/Wrapping-up-DIGImend-work.html Thanks everyone for your help over the years! Nick -- ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v3] Use kernel-reported tilt range and resolution
Use tilt range and, optionally, resolution reported by the kernel for event
devices.
Add a constant for resolution currently expected by applications: TILT_RES,
1 point per degree in kernel units (points/radian). Scale values to this
resolution for compatibility and specify it for corresponding valuators
(instead of 1) for future use by applications.
Add constants for currently reported value limits: TILT_MIN and TILT_MAX,
-64 and 63 respectively. Continue clamping values to [TILT_MIN, TILT_MAX]
for compatibility.
Values and ranges reported by currently supported tablets should remain
unchanged.
Signed-off-by: Nikolai Kondrashov
---
Renamed wcmTilt[XY] to wcmTilt[XY] to better match the
conventions.
Clarified range-centering comments.
Replaced TODO items with a cleaner one in the header.
src/wcmCommon.c |2 --
src/wcmFilter.c | 16 +-
src/wcmISDV4.c | 14 +++--
src/wcmUSB.c| 82 +--
src/xf86Wacom.c | 10 ---
src/xf86WacomDefs.h | 20 +++--
6 files changed, 124 insertions(+), 20 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index d10c1d1..650f8f5 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -1431,8 +1431,6 @@ WacomCommonPtr wcmNewCommon(void)
common->wcmMaxTouchY = 1024; /* max touch Y value */
common->wcmMaxStripX = 4096; /* Max fingerstrip X */
common->wcmMaxStripY = 4096; /* Max fingerstrip Y */
- common->wcmMaxtiltX = 128; /* Max tilt in X directory */
- common->wcmMaxtiltY = 128; /* Max tilt in Y directory */
common->wcmCursorProxoutDistDefault = PROXOUT_INTUOS_DISTANCE;
/* default to Intuos */
common->wcmSuppress = DEFAULT_SUPPRESS;
diff --git a/src/wcmFilter.c b/src/wcmFilter.c
index 47e958a..e55ef0f 100644
--- a/src/wcmFilter.c
+++ b/src/wcmFilter.c
@@ -298,16 +298,16 @@ int wcmFilterCoord(WacomCommonPtr common, WacomChannelPtr
pChannel,
ds->device_type == ERASER_ID))
{
ds->tiltx = tx / common->wcmRawSample;
- if (ds->tiltx > common->wcmMaxtiltX/2-1)
- ds->tiltx = common->wcmMaxtiltX/2-1;
- else if (ds->tiltx < -common->wcmMaxtiltX/2)
- ds->tiltx = -common->wcmMaxtiltX/2;
+ if (ds->tiltx > common->wcmTiltMaxX)
+ ds->tiltx = common->wcmTiltMaxX;
+ else if (ds->tiltx < common->wcmTiltMinX)
+ ds->tiltx = common->wcmTiltMinX;
ds->tilty = ty / common->wcmRawSample;
- if (ds->tilty > common->wcmMaxtiltY/2-1)
- ds->tilty = common->wcmMaxtiltY/2-1;
- else if (ds->tilty < -common->wcmMaxtiltY/2)
- ds->tilty = -common->wcmMaxtiltY/2;
+ if (ds->tilty > common->wcmTiltMaxY)
+ ds->tilty = common->wcmTiltMaxY;
+ else if (ds->tilty < common->wcmTiltMinY)
+ ds->tilty = common->wcmTiltMinY;
}
return 0; /* lookin' good */
diff --git a/src/wcmISDV4.c b/src/wcmISDV4.c
index 37c8ee3..2528254 100644
--- a/src/wcmISDV4.c
+++ b/src/wcmISDV4.c
@@ -405,8 +405,18 @@ static int isdv4GetRanges(InputInfoPtr pInfo)
common->wcmMaxY = reply.y_max;
if (reply.tilt_x_max && reply.tilt_y_max)
{
- common->wcmMaxtiltX = reply.tilt_x_max;
- common->wcmMaxtiltY = reply.tilt_y_max;
+ common->wcmTiltOffX = 0 - reply.tilt_x_max / 2;
+ common->wcmTiltFactX = 1.0;
+ common->wcmTiltMinX = 0 + common->wcmTiltOffX;
+ common->wcmTiltMaxX = reply.tilt_x_max +
+ common->wcmTiltOffX;
+
+ common->wcmTiltOffY = 0 - reply.tilt_y_max / 2;
+ common->wcmTiltFactY = 1.0;
+ common->wcmTiltMinY = 0 + common->wcmTiltOffY;
+ common->wcmTiltMaxY = reply.tilt_y_max +
+ common->wcmTiltOffY;
+
common->wcmFlags |= TILT_ENABLED_FLAG;
}
diff --git a/src/wcmUSB.c b/src/wcmUSB.c
index 1a1951d..f25116b 100644
--- a/src/wcmUSB.c
+++ b/src/wcmUSB.c
@@ -572,6 +572,82 @@ int usbWcmGetRanges(InputInfoPtr pInfo)
common->wcmMaxStripX = absinfo.maximum;
}
+ /* X tilt range */
+ if (ISBITSET(abs, ABS_TILT_X) &&
+ !ioctl(pInfo->fd, EVIOCGABS(ABS_TILT_X), &absinfo)
Re: [Linuxwacom-devel] [PATCH v2] Use kernel-reported tilt range and resolution
On 08/28/2012 09:16 PM, Jason Gerecke wrote: > On Mon, Aug 27, 2012 at 12:23 PM, Nikolai Kondrashov > wrote: >> + /* >> +* TODO: set to 0 once Wacom kernel driver is >> +* updated to report zero-centered values. >> +*/ > I don't think this TODO is necessary. > Ideally, when we change the kernel driver to report zero-centered values, > we'd also set the resolution and be handled by the above case. There would > be a slight accuracy penalty (the tilt factor would be 57.3/57 = 1.005 > instead of 1.000), but at 64 degrees we'd only be off by a third of a > degree. Even if we came out with hardware that somehow senses a full +-90 > degrees of tilt, the calculation would be off by just under half a degree > at the extremes. Nothing to worry about. Sure. Otherwise, we can specify tilt resolution to be, say, 573 and multiply values by 10 in the kernel to raise the precision. Or 917 and shift by 4 for extra neatness :) > Instead, I'd change the comment to note that this is for > backwards-compatibility with kernel drivers which don't follow use the > proper semantics. It can be removed (along with wcmTiltXOff) in the > future when these kernels are no longer in use. OK, will fix shortly. >> + /* >> +* TODO: set to 0 once Wacom kernel driver is >> +* updated to report zero-centered values. >> +*/ > Ditto above. Sure. > Great work! :) I think this patch hits all the issues squarely on the > head. We still need to decide when to get the kernel fix in place > (3.8?) 3.8 seems fine. > and poke the Qt/GTK developers to fix their frameworks, but > this patch should facilitate a nice smooth transition. Yes, that was the intention. > Reviewed-by: Jason Gerecke Thanks, Jason! Sincerely, Nick -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH v2] Use kernel-reported tilt range and resolution
Use tilt range and, optionally, resolution reported by the kernel for event
devices.
Add a constant for resolution currently expected by applications: TILT_RES,
1 point per degree in kernel units (points/radian). Scale values to this
resolution for compatibility and specify it for corresponding valuators
(instead of 1) for future use by applications.
Add constants for currently reported value limits: TILT_MIN and TILT_MAX,
-64 and 63 respectively. Continue clamping values to [TILT_MIN, TILT_MAX]
for compatibility.
Values and ranges reported by currently supported tablets should remain
unchanged.
Signed-off-by: Nikolai Kondrashov
---
In this version I tried accomodating everything we've discussed before.
However, it was a long time ago and it is hard to force myself to re-read
and remember everything, so I may have overlooked something.
This was tested with kernel 3.5 and Waltop Sirius Battery Free Tablet.
src/wcmCommon.c |2 --
src/wcmFilter.c | 16 +-
src/wcmISDV4.c | 14 +++--
src/wcmUSB.c| 82 +--
src/xf86Wacom.c | 10 ---
src/xf86WacomDefs.h | 17 +--
6 files changed, 121 insertions(+), 20 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index d10c1d1..650f8f5 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -1431,8 +1431,6 @@ WacomCommonPtr wcmNewCommon(void)
common->wcmMaxTouchY = 1024; /* max touch Y value */
common->wcmMaxStripX = 4096; /* Max fingerstrip X */
common->wcmMaxStripY = 4096; /* Max fingerstrip Y */
- common->wcmMaxtiltX = 128; /* Max tilt in X directory */
- common->wcmMaxtiltY = 128; /* Max tilt in Y directory */
common->wcmCursorProxoutDistDefault = PROXOUT_INTUOS_DISTANCE;
/* default to Intuos */
common->wcmSuppress = DEFAULT_SUPPRESS;
diff --git a/src/wcmFilter.c b/src/wcmFilter.c
index 47e958a..3802857 100644
--- a/src/wcmFilter.c
+++ b/src/wcmFilter.c
@@ -298,16 +298,16 @@ int wcmFilterCoord(WacomCommonPtr common, WacomChannelPtr
pChannel,
ds->device_type == ERASER_ID))
{
ds->tiltx = tx / common->wcmRawSample;
- if (ds->tiltx > common->wcmMaxtiltX/2-1)
- ds->tiltx = common->wcmMaxtiltX/2-1;
- else if (ds->tiltx < -common->wcmMaxtiltX/2)
- ds->tiltx = -common->wcmMaxtiltX/2;
+ if (ds->tiltx > common->wcmTiltXMax)
+ ds->tiltx = common->wcmTiltXMax;
+ else if (ds->tiltx < common->wcmTiltXMin)
+ ds->tiltx = common->wcmTiltXMin;
ds->tilty = ty / common->wcmRawSample;
- if (ds->tilty > common->wcmMaxtiltY/2-1)
- ds->tilty = common->wcmMaxtiltY/2-1;
- else if (ds->tilty < -common->wcmMaxtiltY/2)
- ds->tilty = -common->wcmMaxtiltY/2;
+ if (ds->tilty > common->wcmTiltYMax)
+ ds->tilty = common->wcmTiltYMax;
+ else if (ds->tilty < common->wcmTiltYMin)
+ ds->tilty = common->wcmTiltYMin;
}
return 0; /* lookin' good */
diff --git a/src/wcmISDV4.c b/src/wcmISDV4.c
index 37c8ee3..f6a861e 100644
--- a/src/wcmISDV4.c
+++ b/src/wcmISDV4.c
@@ -405,8 +405,18 @@ static int isdv4GetRanges(InputInfoPtr pInfo)
common->wcmMaxY = reply.y_max;
if (reply.tilt_x_max && reply.tilt_y_max)
{
- common->wcmMaxtiltX = reply.tilt_x_max;
- common->wcmMaxtiltY = reply.tilt_y_max;
+ common->wcmTiltXOff = 0 - reply.tilt_x_max / 2;
+ common->wcmTiltXFact = 1.0;
+ common->wcmTiltXMin = 0 + common->wcmTiltXOff;
+ common->wcmTiltXMax = reply.tilt_x_max +
+ common->wcmTiltXOff;
+
+ common->wcmTiltYOff = 0 - reply.tilt_y_max / 2;
+ common->wcmTiltYFact = 1.0;
+ common->wcmTiltYMin = 0 + common->wcmTiltYOff;
+ common->wcmTiltYMax = reply.tilt_y_max +
+ common->wcmTiltYOff;
+
common->wcmFlags |= TILT_ENABLED_FLAG;
}
diff --git a/src/wcmUSB.c b/src/wcmUSB.c
index 1a1951d..154f6cf 100644
--- a/src/wcmUSB.c
+++ b/src/wcmUSB.c
@@ -572,6 +572,82 @@ int usbWcmGetRanges(InputInfoPtr pInfo)
common->wcmMaxStripX = absinfo.maximum;
}
+ /* X tilt range
Re: [Linuxwacom-devel] [PATCH 1/1] Use kernel-reported tilt range and resolution
Hi everyone, On 05/19/2012 06:37 PM, Nikolai Kondrashov wrote: 2. Verify units Wacom uses by asking Wacom engineers and/or measuring it. Make kernel driver report it. Make kernel driver report zero-centered values. I can make the patches. I've had an opportunity to measure reported tilt values of a Wacom Cintiq 12WX today. It wasn't a very precise measurement, but it still showed that the reported values are much likely to be *sines* of the angles and *not* *degrees*. This matches what Waltop Sirius is producing, which is quite expected, considering they seem to use the same pen technology. I've attached my data, along with an OpenOffice.org Calc spreadsheet containing a graph of angle fractions vs. sine fractions vs. fractions of reported values. I'm not sure what to do with this, yet. Sincerely, Nick wacom_tilt_measurements.tar.gz Description: GNU Zip compressed data -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 1/1] Use kernel-reported tilt range and resolution
Hi Jason, Now, this has taken me some time, hasn't it? Sorry for such a huge delay. It took me some time, because I wasn't content with my arguments and the way I was expressing myself and I still am not. So, sorry if I'm hard to understand or I don't provide good enough arguments. On 03/31/2012 02:45 AM, Jason Gerecke wrote: > On Fri, Mar 30, 2012 at 3:11 AM, Nikolai Kondrashov wrote: >> I'm assuming applications don't actually expect reported values to be in >> degrees, but rather expect fractions of the maximum 60 degree angle. >> > It looks like the truth was somewhere between both of our assumptions. > We should report in integer degrees, and need to be clamped between > -60 and +60. It seems we should do so, at least for the time being. However, we should really inform toolkit and application developers about what we're actually producing. We should also look at what other drivers do and push for uniformity. >> I've tried looking at the GIMP and mypaint code and it looked like it, but >> I'm not 100% sure. At least both of them worked fine with the maximum of >> 105, which Waltop Sirius kernel driver currently produces. However, I don't >> have a Wacom or, in fact, any other tilt-reporting tablet to compare to. >> > GIMP, Inkscape, and MyPaint all treat the values they get from GTK as > the normalized length of the tool's projection along the corresponding > axis (they take the arctangent of the values to get an azimuth). > While GTK doesn't explicitly state that this is what applications receive, > its a reasonable reading of their documentation: "tilt attributes range > from -1.0 to 1.0 ... representing the maximum tilt to the left or up ... > [and] to the right or down". It looks like in practice GTK actually only > scales the tilt values it gets from X based on the minimum and maximum. > Its not what applications expect, but appears to work well enough that > nobody's bothered to file a bug. Now, this is interesting. So they're expecting sines instead of angles. Shall we do something about this? > Krita, however, does appear to depend on the magic number 60 when > dealing with tilt. Diving deeper, it appears that the Qt API actually > states applications will receive "the angle between the device (a pen, > for example) and the perpendicular" and that "the angle is in the > range -60 to +60 degrees". Qt itself doesn't enforce this at all, and > just stuffs whatever data it receives from X into the tilt variables. > That means that for now we've got to be careful to do the clamping > ourselves. I'll update my patch to convert to degrees and will send the new version. >> I'm OK with the fixed maximum angle, because there is only so much tilt a >> human hand is comfortable to do. Although I'm not sure it is exactly 60 >> degrees, I'm inclined to trust Wacom's judgement and expertise in this >> matter. >> > I'm of the opinion that if we should keep the maximum fidelity > possible when passing data up the stack. If a tablet comes out that > can sense a full 90 degrees of tilt, I figure its the driver's job to > provide applications with the full range. Of course, if things are > written assuming a limited range of motion (like Qt apparently was) > then we need to let them know the assumption was invalid and be > mindful of compatibility in the meantime. There are several things to consider. The root of the problem is that, AFAIK, the X input API doesn't allow describing non-linear valuators. I.e. xf86InitValuatorAxisStruct only accepts linear resolution in points/meter. The best way would be to change that. That would end our troubles, shifting them to toolkit or application developers, where it is maybe better handled. Though, I don't think this could happen easily. Thus, we're trying to circumvent the system by inventing an out-of-system convention. This is also done for tip pressure, but tip pressure was never assigned units and resolution (although in HID standard it can be) and this is compensated by pressure curves. We could agree that in case of tilt, the resolution specified through xf86InitValuatorAxisStruct actually means something relevant. However, this stretches the API definition a bit more, than simply specifying 1, meaning "undefined". I would rather go the full way of extending the API instead. Thus, we can't specify the resolution, at least for now, and should agree on either fixed resolution or fixed range. I assume you're suggesting fixing both the resolution and physical range for now and then leaving only the resolution fixed. I agree on the first part, but not the second. I think it is more practical to fix the physic
Re: [Linuxwacom-devel] Waltop class?
On 05/01/2012 03:56 PM, Nikolai Kondrashov wrote: > On 05/01/2012 03:44 PM, Nikolai Kondrashov wrote: >> I would very much like to have a single class for generic tablets instead. >> They're all very similar and the evdev interface is capable of providing all >> the required information about them. It does that for all the tablets >> handled by hid-waltop, hid-uclogic and hid-kye drivers, at least. >> >> I've been attempting to implement this maybe twice in the past, but didn't >> have time or dedication to finish it. > > Sorry, I confused libwacom classes with wcmUSB.c "protocols". I was talking > about the latter here. However, it probably applies to the former as well. I should really think and read the source before posting. I meant "models", actually, sorry. I.e. usbBamboo, usbIntuos4 and others, and how they are shoehorned on non-Wacom tablets. These should really be just a set of features. Further, I don't see the necessity to list all the models and their descriptions in xf86-input-wacom, and then in libwacom, while the kernel could provide all this and be the ultimate source of the information. Sincerely, Nick -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Waltop class?
On 05/01/2012 03:44 PM, Nikolai Kondrashov wrote: > I would very much like to have a single class for generic tablets instead. > They're all very similar and the evdev interface is capable of providing all > the required information about them. It does that for all the tablets > handled by hid-waltop, hid-uclogic and hid-kye drivers, at least. > > I've been attempting to implement this maybe twice in the past, but didn't > have time or dedication to finish it. Sorry, I confused libwacom classes with wcmUSB.c "protocols". I was talking about the latter here. However, it probably applies to the former as well. Sincerely, Nick -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Waltop class?
On 05/01/2012 07:30 AM, Favux ... wrote: > I gather the wcmUSB.c assignments were based on the attempted linux > driver Waltop had. At least they look very much like the ones in the original Waltop driver package. > If true those correspondences were determined by Waltop. I presume they > based that on features, resolution, and maybe pressure levels. I haven't > really tried to determine correspondence with features. The Waltop's can > have things like pad buttons or hot keys, scroll wheels, rings, and pucks > but they apparently aren't compatible with the Wacom equivalents which is > why Nick is putting them on the evdev driver. The original Waltop driver didn't support any frame controls. I'm putting them on evdev, because it's simpler and works well enough. > The major difference I see between Waltop tablets is that the latest > Waltop models have battery-less styli and resolutions comparable to > the Intuos4. So there are at least two classes. Three if resolution > is considered. > >> If so, just pick the model line that is the closest. If not, it's better to >> create new classes for each Waltop line of models instead of one Waltop >> class. > > I'll go with the wcmUSB.c until Nick decides differently. And by the > way there are a lot more Waltop PIDs in wcmUSB.c than those covered on > the DIGImend site. Right now there are seven data files which should > be it for while. That's mostly why I was thinking of one class. I would very much like to have a single class for generic tablets instead. They're all very similar and the evdev interface is capable of providing all the required information about them. It does that for all the tablets handled by hid-waltop, hid-uclogic and hid-kye drivers, at least. I've been attempting to implement this maybe twice in the past, but didn't have time or dedication to finish it. Sincerely, Nick -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 1/1] Use kernel-reported tilt range and resolution
Hi Przemo, 2012/4/4 Przemo Firszt : >> Do you still object to the FIXME and fixing the kernel driver? > > My thoughts on that "issue": if the device is reporting values in range > 0-127 the kernel driver shouldn't try to "improve" them just because it's > more convinient for the userspace. Changing 0-127 range to -63 to 64 > shouldn't happen in the kernel driver. > > I'd suggest to ask on linux-input if the mainaner will be happy to accept > a patch that converts 0-127 range to -63 to 64, before you include a > comment like "once the kernel is fixed" as it might never happen. The thing is, Wacom tablets are not the only ones reporting tilt. The way they report it is not the most straightforward and is not consistent with the HID spec. At least aiptek driver uses 0-centered tilt for quite a while. The Waltop Sirius tablet reports 0-centered tilt and the patch adding support for it was already accepted into the kernel. So, changing wacom driver to 0-centered tilt, would help make evdev protocol more consistent. Sincerely, Nick -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 1/1] Use kernel-reported tilt range and resolution
Hi Jason,
On Fri, Mar 30, 2012 at 4:21 AM, Jason Gerecke wrote:
> I've been meaning to get around to reviewing your patch (I'm glad to
> see you taking it on!), but have been pretty busy lately. Sorry for
> the delay...
No problem, thanks for reviewing it so extensively!
> On Thu, Mar 22, 2012 at 12:37 PM, Nikolai Kondrashov
> wrote:
>> --- a/src/wcmCommon.c
>> +++ b/src/wcmCommon.c
>> @@ -1466,8 +1466,12 @@ WacomCommonPtr wcmNewCommon(void)
>> common->wcmMaxTouchY = 1024; /* max touch Y value */
>> common->wcmMaxStripX = 4096; /* Max fingerstrip X */
>> common->wcmMaxStripY = 4096; /* Max fingerstrip Y */
>> - common->wcmMaxtiltX = 128; /* Max tilt in X directory */
>> - common->wcmMaxtiltY = 128; /* Max tilt in Y directory */
>> + common->wcmTiltXOff = -64; /* Tilt offset in X direction */
>> + common->wcmTiltXMin = -64; /* Min tilt in X direction */
>> + common->wcmTiltXMax = 64; /* Max tilt in X direction */
>> + common->wcmTiltYOff = -64; /* Tilt offset in Y direction */
>> + common->wcmTiltYMin = -64; /* Min tilt in Y direction */
>> + common->wcmTiltYMax = 64; /* Max tilt in Y direction */
>
> There's no need to initialize any of these variables here. Instead, they
> should
> be initialized in usbWcmGetRanges.
I wasn't sure that these are initialized properly in all the cases in
wcmISDV4.c and wcmUSB.c and it was there before me, after all. I'll read the
code more closely and will remove it if I don't find anything suspicious.
>> --- a/src/wcmFilter.c
>> +++ b/src/wcmFilter.c
>> @@ -298,16 +298,16 @@ int wcmFilterCoord(WacomCommonPtr common,
>> WacomChannelPtr pChannel,
>> ds->device_type == ERASER_ID))
>> {
>> ds->tiltx = tx / common->wcmRawSample;
>> - if (ds->tiltx > common->wcmMaxtiltX/2-1)
>> - ds->tiltx = common->wcmMaxtiltX/2-1;
>> - else if (ds->tiltx < -common->wcmMaxtiltX/2)
>> - ds->tiltx = -common->wcmMaxtiltX/2;
>> + if (ds->tiltx > common->wcmTiltXMax)
>> + ds->tiltx = common->wcmTiltXMax;
>> + else if (ds->tiltx < common->wcmTiltXMin)
>> + ds->tiltx = common->wcmTiltXMin;
>>
>> ds->tilty = ty / common->wcmRawSample;
>> - if (ds->tilty > common->wcmMaxtiltY/2-1)
>> - ds->tilty = common->wcmMaxtiltY/2-1;
>> - else if (ds->tilty < -common->wcmMaxtiltY/2)
>> - ds->tilty = -common->wcmMaxtiltY/2;
>> + if (ds->tilty > common->wcmTiltYMax)
>> + ds->tilty = common->wcmTiltYMax;
>> + else if (ds->tilty < common->wcmTiltYMin)
>> + ds->tilty = common->wcmTiltYMin;
>> }
>>
>> return 0; /* lookin' good */
>
> Why do we bother doing clamping in this function? git-blame indicates
> that the behavior is as old as the driver, but I can't find any
> compelling reason for keeping it around.
I was wondering about it too, and maybe it wasn't needed before, but now it
is needed to clamp the angles to 60 degrees for devices which have wider
range, like Waltop Sirius.
>> diff --git a/src/wcmISDV4.c b/src/wcmISDV4.c
>> index 892fbff..5aa68c5 100644
>> --- a/src/wcmISDV4.c
>> +++ b/src/wcmISDV4.c
>> @@ -405,8 +405,16 @@ static int isdv4GetRanges(InputInfoPtr pInfo)
>> common->wcmMaxY = reply.y_max;
>> if (reply.tilt_x_max && reply.tilt_y_max)
>> {
>> - common->wcmMaxtiltX = reply.tilt_x_max;
>> - common->wcmMaxtiltY = reply.tilt_y_max;
>> + common->wcmTiltXOff = -reply.tilt_x_max/2;
>> + common->wcmTiltXMin = 0 + common->wcmTiltXOff;
>> + common->wcmTiltXMax = reply.tilt_x_max +
>> + common->wcmTiltXOff;
>> +
>> + common->wcmTiltYOff = -reply.tilt_y_max/2;
>> + common->wcmTiltYMin = 0 + common->wcmTiltYOff;
>> + common->wcmTiltYMax = reply.tilt_y_max +
>> +
Re: [Linuxwacom-devel] [PATCH 1/1] Use kernel-reported tilt range and resolution
Hi Chris, On Thu, Mar 29, 2012 at 4:49 PM, Chris Bagwell wrote: > I've no objection to the code itself but I would prefer if the FIXME > was reduced to a TODO or left as only a comment on how current kernels > are behaving. > > If you update the kernels great but its not something that *has* to be > fixed on xf86-input-wacom side and I'd hate to see the FIXME's there > for ever in code thats working fine. I agree. I was actually wondering if I should make it a TODO instead, but didn't - should've thought better. I'll fix it, will try to find someone to test it and then resubmit. Thanks! Sincerely, Nick -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 1/1] Use kernel-reported tilt range and resolution
Hi Chris, On 03/23/2012 07:20 PM, Nikolai Kondrashov wrote: > On 03/23/2012 07:00 PM, Chris Bagwell wrote: >> On Thu, Mar 22, 2012 at 2:37 PM, Nikolai Kondrashov wrote: >>> + /* Center the reported range on zero */ >>> + /* FIXME remove once kernel is fixed */ >>> + common->wcmTiltXOff = - (absinfo.minimum + absinfo.maximum) / 2; >> >> Why is this a FIXME? It seems reasonable to center to zero here. For >> example, there is no intention to "fix" Wacom kernel drivers, are >> there? > > Well, I intended to "fix" them, actually. The thing is, the existing range > wacom drivers use is not straightforward and contradicts HID specification. > > I was hoping to make a patch for the kernel drivers, so, after a while (at > your discretion), this centering could be dropped. Do you still object to the FIXME and fixing the kernel driver? Thanks. Sincerely, Nick -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH 1/1] Use kernel-reported tilt range and resolution
On 03/23/2012 07:00 PM, Chris Bagwell wrote: > On Thu, Mar 22, 2012 at 2:37 PM, Nikolai Kondrashov wrote: >> + /* Center the reported range on zero */ >> + /* FIXME remove once kernel is fixed */ >> + common->wcmTiltXOff = - (absinfo.minimum + absinfo.maximum) >> / 2; > > Why is this a FIXME? It seems reasonable to center to zero here. For > example, there is no intention to "fix" Wacom kernel drivers, are > there? Well, I intended to "fix" them, actually. The thing is, the existing range wacom drivers use is not straightforward and contradicts HID specification. I was hoping to make a patch for the kernel drivers, so, after a while (at your discretion), this centering could be dropped. > If their driver is updated to send min/max (or are they already?), then > this logic is still needed for them to continue working as expected. Judging from the code, it seems wacom kernel drivers send meaningful min/max values already. However, I was hoping some of linuxwacom developers could verify this. > I'd resolve first (if anything to resolve) and delete FIXME before submitting. Resolving kernel first creates a window where the X driver won't work. > I've no other comments other than I hope a Intuos user can test patch first. Can you point me to one, so I could ask directly? Thanks! Sincerely, Nick -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH 1/1] Use kernel-reported tilt range and resolution
Use tilt range and, optionally, resolution reported by the kernel for event
devices.
Temporarily center the range on zero until kernel is fixed to do this.
Use resolution, if present, to determine the physical range and clamp/extend
it to 60 degrees either way as expected by applications, otherwise assume it
corresponds to this range.
This is needed to handle non-Wacom tablets reporting zero-centered tilt and
having physical range greater than 60 degrees.
---
This is in continuation of the "Tilt value meaning" thread:
http://sf.net/mailarchive/forum.php?thread_name=4F5F6C72.8080906%40gmail.com&forum_name=linuxwacom-devel
This is needed to support Waltop Sirius Battery Free Tablet patches:
http://thread.gmane.org/gmane.linux.kernel.input/24153
src/wcmCommon.c |8 -
src/wcmFilter.c | 16 +-
src/wcmISDV4.c | 12 +++-
src/wcmUSB.c| 74 +-
src/xf86Wacom.c |8 +++---
src/xf86WacomDefs.h | 11 ++-
6 files changed, 109 insertions(+), 20 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index 7199105..1d66209 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -1466,8 +1466,12 @@ WacomCommonPtr wcmNewCommon(void)
common->wcmMaxTouchY = 1024; /* max touch Y value */
common->wcmMaxStripX = 4096; /* Max fingerstrip X */
common->wcmMaxStripY = 4096; /* Max fingerstrip Y */
- common->wcmMaxtiltX = 128; /* Max tilt in X directory */
- common->wcmMaxtiltY = 128; /* Max tilt in Y directory */
+ common->wcmTiltXOff = -64; /* Tilt offset in X direction */
+ common->wcmTiltXMin = -64; /* Min tilt in X direction */
+ common->wcmTiltXMax = 64; /* Max tilt in X direction */
+ common->wcmTiltYOff = -64; /* Tilt offset in Y direction */
+ common->wcmTiltYMin = -64; /* Min tilt in Y direction */
+ common->wcmTiltYMax = 64; /* Max tilt in Y direction */
common->wcmCursorProxoutDistDefault = PROXOUT_INTUOS_DISTANCE;
/* default to Intuos */
common->wcmSuppress = DEFAULT_SUPPRESS;
diff --git a/src/wcmFilter.c b/src/wcmFilter.c
index 47e958a..3802857 100644
--- a/src/wcmFilter.c
+++ b/src/wcmFilter.c
@@ -298,16 +298,16 @@ int wcmFilterCoord(WacomCommonPtr common, WacomChannelPtr
pChannel,
ds->device_type == ERASER_ID))
{
ds->tiltx = tx / common->wcmRawSample;
- if (ds->tiltx > common->wcmMaxtiltX/2-1)
- ds->tiltx = common->wcmMaxtiltX/2-1;
- else if (ds->tiltx < -common->wcmMaxtiltX/2)
- ds->tiltx = -common->wcmMaxtiltX/2;
+ if (ds->tiltx > common->wcmTiltXMax)
+ ds->tiltx = common->wcmTiltXMax;
+ else if (ds->tiltx < common->wcmTiltXMin)
+ ds->tiltx = common->wcmTiltXMin;
ds->tilty = ty / common->wcmRawSample;
- if (ds->tilty > common->wcmMaxtiltY/2-1)
- ds->tilty = common->wcmMaxtiltY/2-1;
- else if (ds->tilty < -common->wcmMaxtiltY/2)
- ds->tilty = -common->wcmMaxtiltY/2;
+ if (ds->tilty > common->wcmTiltYMax)
+ ds->tilty = common->wcmTiltYMax;
+ else if (ds->tilty < common->wcmTiltYMin)
+ ds->tilty = common->wcmTiltYMin;
}
return 0; /* lookin' good */
diff --git a/src/wcmISDV4.c b/src/wcmISDV4.c
index 892fbff..5aa68c5 100644
--- a/src/wcmISDV4.c
+++ b/src/wcmISDV4.c
@@ -405,8 +405,16 @@ static int isdv4GetRanges(InputInfoPtr pInfo)
common->wcmMaxY = reply.y_max;
if (reply.tilt_x_max && reply.tilt_y_max)
{
- common->wcmMaxtiltX = reply.tilt_x_max;
- common->wcmMaxtiltY = reply.tilt_y_max;
+ common->wcmTiltXOff = -reply.tilt_x_max/2;
+ common->wcmTiltXMin = 0 + common->wcmTiltXOff;
+ common->wcmTiltXMax = reply.tilt_x_max +
+ common->wcmTiltXOff;
+
+ common->wcmTiltYOff = -reply.tilt_y_max/2;
+ common->wcmTiltYMin = 0 + common->wcmTiltYOff;
+ common->wcmTiltYMax = reply.tilt_y_max +
+ common->wcmTiltYOff;
+
common->wcmFlags |= TILT_ENABLED_FLAG;
}
diff --git a/src/wcmUSB.c b/src/wcmUSB.c
index d41ced6..1d2e58a 100644
--- a/src/wcmUSB.c
+++ b/src/wcmUSB.c
@@ -573,6 +573,76 @@ int usbWcmGetRanges(InputInfoPtr pInfo)
common->wcmMaxStripY = absinfo.maximum;
}
+ /* X tilt range */
+ if (ISBITSET(abs, ABS_TILT_X) &&
+ !ioctl(pInfo
[Linuxwacom-devel] [PATCH 1/1] conf: Only match tablet Waltop devices
Only match Waltop event devices classified as tablets. Advanced Waltop tablets have on-the-frame controls such as multifunction dials (controlling scrolling, zooming, volume and keyboard navigation) and keyboard modifier buttons. These are represented as separate event devices and are better handled by xf86-input-evdev. Signed-off-by: Nikolai Kondrashov --- conf/50-wacom.conf | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/conf/50-wacom.conf b/conf/50-wacom.conf index 5cf5fdf..febcef6 100644 --- a/conf/50-wacom.conf +++ b/conf/50-wacom.conf @@ -1,6 +1,6 @@ Section "InputClass" Identifier "Wacom class" - MatchProduct "Wacom|WACOM|WALTOP|Hanwang|PTK-540WL" + MatchProduct "Wacom|WACOM|Hanwang|PTK-540WL" MatchDevicePath "/dev/input/event*" Driver "wacom" EndSection @@ -17,6 +17,14 @@ Section "InputClass" Driver "wacom" EndSection +# Waltop tablets +Section "InputClass" + Identifier "Wacom class" + MatchProduct "WALTOP" + MatchIsTablet "on" + MatchDevicePath "/dev/input/event*" + Driver "wacom" +EndSection # N-Trig Duosense Electromagnetic Digitizer Section "InputClass" -- 1.7.9.1 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Tilt value meaning
On 03/09/2012 11:12 AM, Alexia Death wrote: > With the ink pen the effect isnt directly obvious. its a continuos and > tricky tool and rather lousy for tesing. For your purposes, even the > dev relase before last is fine. Last dev release had a huge dependency > bump and is pain to install on most current distros. In 2.7 series you > have the new dynamics system available for all paint tools. That lets > you do some fun things with tilt on all paint tools, including clearly > seenig the fect on a stamp. Thanks Alexia, I was able to get some effect from the ink pen on Gimp 2.6! Although I still don't know what it should be, I can see that at least something is there. I will probably need to get a Wacom tablet to be able to compare, but for now I'll just try to make sure the values resemble what was described by Jason Gerecke. Thanks everyone! Sincerely, Nick -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Tilt value meaning
On 03/08/2012 08:42 PM, Chris Bagwell wrote: > I believe tilt support is also in 2.6 but does seem to only work with > certain tools. The Ink Pen mentions setting tilt sensitivity. > > http://docs.gimp.org/en/gimp-tool-ink.html Thanks, Chris! I have gimp 2.6 and will try the ink pen. Sincerely, Nick -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Tilt value meaning
Hi Jason, On 03/08/2012 08:06 PM, Jason Gerecke wrote: > While I agree that [0, 127] isn't obvious, changing it to be > 0-symmetric isn't going to happen any time soon. The X driver > unfortunately expects that range -- it doesn't ask the kernel. Any > kernel change would have to come quite a while after the X driver was > modified to ask the kernel instead (otherwise we risk breaking tilt > for anyone with an old Xorg driver) Yes, I understand that. Can I suggest a plan? Have the X driver always center the range around zero. If axis resolution isn't specified, assume the range covers [-60,60] degrees. Otherwise, calculate the physical range from resolution (which is points/radian), clip it to values corresponding to [-60,60] physical degrees and report without scaling to the applications. This is, of course, assuming the Wacom driver would want to handle non-Wacom tablets. If not, then, for the sake of uniform evdev protocol, only centering needs to be added. After some time passes, say a year, update the kernel driver to center the range around zero, remove centering from the X driver and assume 0 is 0 degrees from normal. BTW, could it be that the driver does centering in a suitable way already? I'm not sure if anything should be done about the direction mismatch. > Is the range of values you get out of the kernel clipped to [-64,64], > or is evdev doing the clipping? I'm sorry, I didn't collect enough data. I've collected more input, which pushed the range to [-67,73]. > If the hardware is only sending data in that range there isn't much you > can do about it (aside from double-checking that you're reading the tilt > packets correctly). Well, I could still scale it. > Otherwise, I'd make sure the range you tell the kernel to expect is > correct -- I hope evdev doesn't have [-64,64] hardcoded, but we do the > same thing so It seems evdev doesn't do any special processing to the tilt axis, which I think is good. Now, aside from the strange range, the value change rate really looks more like the angle sine, than the angle itself. I.e. it seems the tablet reports fractions of the pen projection length. I did some measurements with a protractor and the values doesn't change at the same rate with angles. Even more, the negative values, seem to be offset somewhat and don't match the scale of the positive values closely, but they're still closer to a sine, than to an angle. This actually makes sense, since the tablet has no way to measure the angle directly and calculating it isn't a very suitable task for its CPU. > I usually use gimp for real-world testing, though I think you'll only > get tilt-sensitivity in gimp-2.7 (which is an unstable release...) I never used another tablet with tilt sensitivity with gimp. Could you suggest what output I should expect and with which tools? Thanks a lot for your comments and suggestions! Sincerely, Nick -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Tilt value meaning
On 03/08/2012 02:18 AM, Jason Gerecke wrote: > Our kernel driver reports values from [0, 127] with 0 corresponding to > top/left and 127 to bottom/right. The midpoint is assumed to be > vertical, with one unit of change corresponding roughly to one degree > of change. Thanks. This appears to me as not the most straight-forward range. I would expect kernel to report 0-symmetric values. Maybe it's not late to change that to have better compatibility with generic HID devices? > The Xorg driver centers the data from the kernel about zero > (resulting in a range [-64, 63]) and reports them for applications in > the 4th (X tilt) and 5th (Y tilt) valuators. So far I've got evdev to report ABS_TILT_X and ABS_TILT_Y as 4th and 5th valuators from the kernel as is. So I'll leave the kernel driver reporting 0-symmetric values for now. It seems the range is already clipped to [-64,64], although the original report descriptor states [-127,127]. Can you suggest a way to test the tilt with a real-world application, not just "xinput test" or "xev"? Thanks! Sincerely, Nick -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Tilt value meaning
On 03/08/2012 12:10 AM, Chris Bagwell wrote: > I do not have a tablet with tilt, nor experience on how userland uses > it. And probably I should have read that HID section before replying > but... Here is that part in full, for your reference: 16.3.2 Tilt Orientation X Tilt and Y Tilt are used together to specify the tilt away from normal of a digitizer transducer. In its normal position, the values of X Tilt and Y Tilt for a transducer are both zero. The X Tilt/Y Tilt orientation of a system does not specify the rotation of the transducer around its own normal axis. X Tilt DV – This quantity is used in conjunction with Y Tilt to represent the tilt away from normal of a transducer, such as a stylus. The X Tilt value represents the plane angle between the Y-Z plane and the plane containing the transducer axis and the Y axis. A positive X Tilt is to the right. Y Tilt DV – This value represents the angle between the X-Z and transducer-X planes. A positive Y Tilt is toward the user. > I do see all Wacom tablets with Tilt support report tilt X/Y declaring > a value between 0 and 127. I also see these tablets advertised on web > with Tilt Range of +/- 60 degrees. So I'm going to take a wild guess > since 60 + 60 ~= 127 the units are degrees. Thanks, Chris! > Hopefully, those missing degree's aren't hard coded in apps such as gimp! My guess is that nobody is relying on specific angles, at least yet, but instead focuses on the feel of it. Still, I'd like to match expected values. Sincerely, Nick -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] Tilt value meaning
Hi everyone, Today I've started implementing a driver for Waltop Sirius Battery Free tablet. As it turns out, it reports pen tilting, which is a rare thing for non-Wacom tablets! Could someone please explain what ABS_TILT_X and ABS_TILT_Y event values are supposed to mean? What are the units and ranges? Also, what the X applications are expecting as tilting valuator values? My expectation was that the values match the HID usage tables spec description of "X Tilt" and "Y Tilt" usages (see 16.3.2 Tilt Orientation). I.e. positive/negative fractions of the X/Y arcs, which probably cover 90 degrees both ways, since nobody is looking at the resolution. Interestingly enough, the spec says positive inclination is bottom right corner, but the tablet assumes top right. However, after reading xf86-input-wacom sources I got somewhat confused. Could someone clarify this? Thanks! Sincerely, Nick -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Waltop based VisTablet detects both stylus buttons as the same button
On 02/21/2011 08:24 AM, Collin Day wrote: > Anyway, my kernel version is 2.6.36 and I am using xf86-input-wacom > 0.10.11 ( I also tried the git repository with the same results ). I > know it isn't a wacom tablet specifically, but I was wondering if > anyone knows about this or would be interested in looking at it? The issue is the Waltop HID report descriptor. It doesn't describe buttons correctly. Please try applying my patches for 2.6.36 kernel [1], or use 2.6.37, which has them integrated. Sincerely, Nick [1] http://digimend.sourceforge.net/#proj-kernel-patches -- 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] Streamline the touch resolution
On 01/25/2011 05:03 PM, Chris Bagwell wrote: > I'll try to summarize where we are at. Thanks :) > 1) For some touch devices, kernel sets the maximum value of > ABS_RX/ABS_RX as HID's reported physical size of device in 0.001 of > cm's. Thist patch takes that value and converts to resolution and > stores in wcmTouchResolX/Y in units per meter. Before patch I guess > it was microns per unit and so buggy. Aha. Although I thought ABS_R[XYZ] were rotational axis and so reported in degrees or radians. > 2) There is a patch on linux-input from Ping that makes Tablet PC > report resolution as part of absinfo in units per mm. This > xf86-input-wacom patch converts that value to units per meter and also > store in same wcmTochResolX/Y. BTW: Same linux-input removes > ABS_RX/ABS_TX so its only uses one of two ways of reporting. > > 3) Peter points out header file states wcmTouchResolX/Y is in > points/mm which needs updating to points/meter. I also just noticed > it says wcmResolX/Y is in points/inches but thats now also > points/meter after a recent submit by Peter. So both need updating. > > And last, I'll soon submit a patch to linux-input to make Bamboo work > same as Tablet PC (unless Ping beats me to it). I also hope to submit > a patch that makes kernel send hardcoded resolutions per USB ID for > stylus devices in units/mm based on updated table in wcmUSB.c that > Peter made. This is great, at last things come into order :)! Thanks for explanations and your work, guys :) Sincerely, Nick -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH] Streamline the touch resolution
On 01/25/2011 02:07 AM, Ping Cheng wrote: > For kernels older than 2.6.30, resolution is not part of absinfo. > For kernels older than 2.6.35, kernel does not pass resolution to > the userland. I was quite lost in your discussion about the units and am not sure which you do use in the end. I just want to verify you're aware that the absinfo resolution was recently agreed to be units/mm. Although, I think Chris is aware of that, as he was participating in the discussion. Sincerely, Nick -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Using the pen as Airbrush
On 01/11/2011 09:52 PM, Ping Cheng wrote: > I am not sure if I understand the questions correctly or not. The > value reported through ABS_DISTANCE from the kernel is the raw > distance. For clients that sit on top of X server, we > (xf86-input-wacom) need to pass those vaules to XI through valuators. Oh, I'm sorry. I thought the matter was about choosing the axis to report from the kernel to xf86-input-wacom. I should've read the whole thread more carefully. Sincerely, Nick -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Using the pen as Airbrush
On Tue, Jan 11, 2011 at 4:07 AM, Peter Hutterer wrote: > it's a different axis. so instead of x, y, pressure, ... you get x, y, > pressure, distance, ... > that's the correct integration, mix-and-match with other axes will just come > back to bite us in the future.. Do you know anything about ABS_DISTANCE? Will it suit this case? ABS_Z maybe? Sincerely, Nick -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] BTN_TOUCH misunderstanding?
On 11/08/2010 07:02 AM, Peter Hutterer wrote: > BTN_TOUCH is used by touchpads and wacom tablets to indicate actual touch, > not a tool type of touch. both synaptics and evdev treat it that way, and > use BTN_TOOL_FINGER as tool choice. Thanks, this clears it a bit more. > the weakest point we have in the protocol is the lack of documentation, > which sometime causes conflicting implementations. > I guess once we've written it down what BTN_TOUCH should mean, we can at > least tell people off when using it differently. I completely agree. It was needed a long time ago, but now there are a lot of uses, so maybe now is the time to agree on something. Sincerely, Nick -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] BTN_TOUCH misunderstanding?
On 11/04/2010 08:26 PM, Chris Bagwell wrote: > I think its sneaking in from people that mostly concentrate on > touchpads and not tablets. Thanks :) This is what I suspected. I just wanted to make sure it's not me :) > For touchpad oriented drivers, the tablet concept of sending > BTN_TOOL_FINGER to claim "next set of events are related to this tool > but tool may or may not be touching" is not very useful because all > events are always related to single tool and proximity concept > needlessly complicates things. Also, the meaning of > BTN_TOOL_FINGER/BTN_TOOL_DOUBLETAP/BTN_TOOL_TRIPLETAP get tweaked and > those events get routed to finger count logic instead of proximity > related logic. It seems the touchpad and tablet code are better be clearly separated whenever they meet in a driver. This also seem to be a weak point in the evdev protocol. > So its easy for touchpad mindset to sneak into xf86-input-evdev since > it handles touchpads and it can treat BTN_TOOL_FINGER ~= BTN_TOUCH > since its more a safety net for any kernel driver that sends one or > the other but not both. Yes, it could be the case. > Treating remaining BTN_TOOL_* ~= BTN_TOUCH is probably asking for > trouble. Let me know if you see this assumption in today's > xf86-input-wacom for non-touchpad cases. No, I never seen anything like this, I only meant to point out that BTN_TOUCH is not a tool at all. > Now that you bring it up, I see I recently had my touchpad mindset > when I updated usbParseKeyEvent(). I detected touchpad by BTN_TOUCH > event but it would probably have been better if I detected in > BTN_TOOL_FINGER case... and for future "dumb tablets" support it > should probably be detected in BTN_TOOL_PEN. This is what triggered my message, along with Wayland code :) > I'll put it on my TODO list to clean up. Thanks :) Meanwhile I'm continuing attempts to make the wacom driver work with my very dumb tablet :) Sincerely, Nick -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] BTN_TOUCH misunderstanding?
Hi everybody, I've seen it several times, namely in evdev and wacom drivers, and now also in Wayland. Why everybody seem to think that BTN_TOUCH is roughly equivalent to BTN_TOOL_PEN or any BTN_TOOL_* code for that matter? In my experience with tablets it is only used to indicate the pen is touching the tablet surface. Is it me who misunderstands something? Thanks :) Sincerely, Nick -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] xf86-input-wacom and dumb tablets
On 10/30/2010 12:39 AM, Chris Bagwell wrote: > OK, patches have been committed to git to allow touchpad-like input > devices to be handled by xf86-input-wacom. If someone wants to add > new touchpad's beyond Bamboo Touch then they would need to modify > usbWcmInit() to set wcmProtocolLevel to WCM_PROTOCOL_GENERIC for any > unknown devices. > > The same goes to handle "dumb tablets" as well. There is one more > change that needs to be made for tablets and that is to modify > usbParseKeyEvent(). Look for the BTN_TOUCH case statement and address > the TODO somehow (copy&paste logic from BTN_TOOL_PEN case is easy way > to address). > > Nick, I hope this helps you in your goal. > > There is probably some minor things hiding in wcmDeviceTypeKeys() for > dumb tablets as well but I'm hoping the default values just work > (maybe that means force tablet_id to zero for non-wacom tablets?). Thanks Chris :) Unfortunately I've been too overwhelmed with other matters lately, but I hope it will settle down soon and I'll get back to wacom development. Sincerely, Nick -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Device Resolutions
On 09/26/2010 07:17 PM, Chris Bagwell wrote: > There isn't some info I'm missing in kernel that declares the units to > user land, right? I've never seen anything declaring the units in the kernel myself. I guess whoever was adding this feature was having some units in mind as well as some user space application as a target consumer. Maybe we should look in the logs and/or ask on linux-input. > Without synaptic history I was leaning towards units/meter for loss of > resolution reasons but with your USB info then I guess units/inch or > units/cm seems better. I should note that the HID report descriptor format has unit exponent item which could be applied to keep precision while using appropriate unit size (meters, millimeters, or whatever), but the base units (without the exponent) are as I described. Sincerely, Nick -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH TRIVIAL] Add isdv4-serial-debugger to tools/.gitignore
Add isdv4-serial-debugger to tools/.gitignore to avoid git messages about untracked files. Signed-off-by: Nikolai Kondrashov --- tools/.gitignore |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/.gitignore b/tools/.gitignore index 678631e..f80cd88 100644 --- a/tools/.gitignore +++ b/tools/.gitignore @@ -1,2 +1,3 @@ # Add & Override for this directory and it's subdirectories xsetwacom +isdv4-serial-debugger -- 1.7.1 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Device Resolutions
Hello Chris, On 09/26/2010 07:09 AM, Chris Bagwell wrote: > Related to xf86-input-synaptics, the kernel synaptics driver seems to > have standardized on units/mm. Unless there is some loss of info I > guess wacom should also report units/mm on kernel side. I would disagree. Units per inch is quite widely accepted resolution units even in the metric world and doing otherwise would confuse a lot of people. Plus most devices have resolution defined the same way and this would mean losing precision if represented as units per millimeters, especially considering we're using integers. The resolution calculation patch I sent to the kernel uses units per inch, plus I've chosen units per radian instead of units per degree just because there would be more units there. BTW, the HID specification has either units per centimeter (not millimeter!) or units per inch and I think it's for the same reason. Sincerely, Nick -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH/RFC] Replace numerical tablet IDs with symbolic ones
On 09/22/2010 09:54 PM, Ping Cheng wrote: > Yes, we can report resolution from the kernel driver. It is not hard > to do that since the values are already available in the driver > anyway. We just need someone to work on it and to make sure both the > kernel and the X server drivers work properly after the change. Chris, you've been looking through and changing the kernel driver a lot lately, as I could see from the linux-input maillist, do you want to do it? > Backward computability has to be considered in the X driver. So, the > code won't be truly clean for sometime, I think. Sure. Though I'd like to count on you for verifying correctness of my attempts :) > I like this approach. The only recommendation I have is: please make > gradual changes with small patches so we can review and test them > easily. Sure, that's why I did this patch instead of going ahead and doing it all. Do you have any comments on it, BTW? Thanks. Sincerely, Nick -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH/RFC] Replace numerical tablet IDs with symbolic ones
On 09/22/2010 08:24 PM, Chris Bagwell wrote:
> The WacomModelDesc[] is a type of whitelist which are always difficult
> to maintain. I wonder if we can get rid of it? Here's my ideas.
>
> 1) It contains X/Y resolution of all known devices. This same data
> can be and is queried from kernel side. Why not remove it and rely on
> kernel values? If we need to interop with older kernels that didn't
> report then we could maintain a much smaller "X/Y quirks" list for
> those smaller cases.
Yes I was nursing the same idea for a while. I've submitted a patch [1] to
core HID layer, which deals with this for devices correctly specifying their
physical extents in the report descriptor. Although there aren't many such
devices, it will work with tablets the fixed by me, at least. The patch is
currently in Jiri Kosina's review queue.
I think the Wacom kernel drivers should provide resolution explicitly, i.e.
the resolution information should be moved to the kernel.
> As best I can tell, that array really boils down to Protocol4 vs.
> Protocol5 families even though theres much more entries then that.
Good find.
> In another patch, I'm proposing a third family called
> Protocol0 that would be used for generic tablets (ones that do not
> send serial #'s).
Good idea.
> So we could reduce gWacomUSBDevice to only 2 or 3 entries.
Do you mean WacomModel?
> Non-Wacom Vendor ID's could default to Protocol0 and Wacom's could
> default to 4 vs. 5 based on Product ID ranges instead of hard coded in
> WacomModelDesc[].
>
> That would mean WacomModelDesc[] can be deleted if we prefer. In
> wcmUsbInit(), instead of for() loop, we use previous paragraph logic
> to set common->wcmModel. common->wcmResolX and wcmResolY would come
> from query.
>
> 3) The remaining usage of tablet_id are various hardware or kernel
> driver quirks and will always be needed. Making tablet_id be
> vendor+product as you have done makes sense to prevent the overlaps.
>
> If we get rid of the large WacomModelDesc[] (or at least limit to
> Wacom devices) then we can reduce the vendor+product ID's that we
> track to only the subset that have quirks for that need to define
> Protocol4 vs Protocol5.
I'd rather vote for getting rid of tablet_id entirely and referencing a
tablet model description structure directly. This structure should contain
the protocol version and a quirk set (probably a bitmask). The "ifs" dealing
with the tablet quirks on the basis of tablet ID should be updated to use
the model description quirk set.
So it could be like this:
typedef enum WacomProtocol {
WACOM_PROTOCOL_GENERIC,
WACOM_PROTOCOL_V4,
WACOM_PROTOCOL_V5,
} WacomProtocol;
typedef struct WacomModel {
unsigned intvendor_id;
unsigned intproduct_id;
WacomProtocol proto;
unsigned intquirks;
}
The list could be done and matched similarly to the kernel USB subsystem,
like this:
#define ANY_VENDOR_ID 0
#define ANY_PRODUCT_ID 0
WacomModel WacomModelDesc[] = {
{
.vendor_id = WACOM_VENDOR_ID,
.product_id = WACOM_PENPARTNER_PRODUCT_ID,
.proto = WACOM_PROTOCOL_V4
},
{
.vendor_id = WACOM_VENDOR_ID,
.product_id = WACOM_BAMBOO_TOUCH_PRODUCT_ID,
.proto = WACOM_PROTOCOL_V4,
.quirks = WACOM_QUIRK_JUMPY | WACOM_QUIRK_WHATEVER
},
{
.vendor_id = WACOM_VENDOR_ID,
.product_id = ANY_PRODUCT_ID,
.proto = WACOM_PROTOCOL_V5
}
{
.vendor_id = ANY_VENDOR_ID,
.product_id = ANY_PRODUCT_ID,
.proto = WACOM_PROTOCOL_GENERIC
}
};
The protocol could still be defined by a function or a reference to a
structure with functions, as an alternative.
This way we will gather all the information on "special" models in one
place, instead of scattering it all over the code.
Sincerely,
Nick
[1] http://article.gmane.org/gmane.linux.usb.general/36130
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] [PATCH/RFC] Replace numerical tablet IDs with symbolic ones
Add macros for USB tablet product IDs, tablet IDs generated from them.
Use macros instead of numbers all over the code.
Wacom tablet ID values remain the same, other tablet ID values now
contain USB vendor IDs.
Signed-off-by: Nikolai Kondrashov
---
This patch attempts to fix tablet ID clashes between various vendors. It
also replaces numerical tablet IDs used all over the code with symbolic ones
to improve readability.
I'm not sure if it is worth splitting this patch in two, but I could do it
if it is deemed appropriate. For now it is only a proposal.
I've tried to make this patch as non-intrusive as possible and to match the
naming scheme, such as there is. Could someone please comment on it?
Thank you :)
Sincerely,
Nick
src/wcmCommon.c |5 +-
src/wcmISDV4.c | 54 ++-
src/wcmUSB.c| 230 +++-
src/wcmValidateDevice.c | 74 +++---
src/xf86WacomDefs.h | 245 +-
5 files changed, 425 insertions(+), 183 deletions(-)
diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index 46e77c8..37588ed 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -1044,8 +1044,9 @@ void wcmEvent(WacomCommonPtr common, unsigned int channel,
}
/* ignore Bamboo touch data if point is abnormal */
- if ((ds.device_type == TOUCH_ID) && (common->tablet_id >= 0xd0
- && common->tablet_id <= 0xd3) && ds.proximity)
+ if ((ds.device_type == TOUCH_ID) &&
+ (common->tablet_id >= WACOM_BAMBOO_TOUCH_ID &&
+common->tablet_id <= WACOM_CTL_660_ID) && ds.proximity)
{
if (!(ds.x * ds.y) || (pLast->proximity &&
(abs(ds.x - pLast->x) > BAMBOO_TOUCH_JUMPED ||
diff --git a/src/wcmISDV4.c b/src/wcmISDV4.c
index ae14164..59287d9 100644
--- a/src/wcmISDV4.c
+++ b/src/wcmISDV4.c
@@ -209,7 +209,7 @@ static Bool isdv4ParseOptions(InputInfoPtr pInfo)
int baud;
/* Determine default baud rate */
- baud = (common->tablet_id == 0x90)? 19200 : 38400;
+ baud = (common->tablet_id == WACOM_TABLETPC_90_ID)? 19200 : 38400;
baud = xf86SetIntOption(pInfo->options, "BaudRate", baud);
@@ -412,7 +412,7 @@ static int isdv4GetRanges(InputInfoPtr pInfo)
/* default to no pen 2FGT if size is undefined */
if (!common->wcmMaxX || !common->wcmMaxY)
- common->tablet_id = 0xE2;
+ common->tablet_id = WACOM_TABLETPC_E2_ID;
DBG(2, priv, "Pen speed=%d "
"maxX=%d maxY=%d maxZ=%d resX=%d resY=%d \n",
@@ -445,29 +445,29 @@ static int isdv4GetRanges(InputInfoPtr pInfo)
{
case 0x00: /* resistive touch & pen */
common->wcmPktLength = ISDV4_PKGLEN_TOUCH93;
- common->tablet_id = 0x93;
+ common->tablet_id = WACOM_TABLETPC_93_ID;
break;
case 0x01: /* capacitive touch & pen */
common->wcmPktLength = ISDV4_PKGLEN_TOUCH9A;
- common->tablet_id = 0x9A;
+ common->tablet_id = WACOM_TABLETPC_9A_ID;
break;
case 0x02: /* resistive touch */
common->wcmPktLength = ISDV4_PKGLEN_TOUCH93;
- common->tablet_id = 0x93;
+ common->tablet_id = WACOM_TABLETPC_93_ID;
break;
case 0x03: /* capacitive touch */
common->wcmPktLength = ISDV4_PKGLEN_TOUCH9A;
- common->tablet_id = 0x9F;
+ common->tablet_id = WACOM_CAPPLUS_9F_ID;
break;
case 0x04: /* capacitive touch */
common->wcmPktLength = ISDV4_PKGLEN_TOUCH9A;
- common->tablet_id = 0x9F;
+ common->tablet_id = WACOM_CAPPLUS_9F_ID;
break;
case 0x05:
common->wcmPktLength = ISDV4_PKGLEN_TOUCH2FG;
/* a penabled */
- if (common->tablet_id == 0x90)
- common->tablet_id = 0xE3;
+ if (common->tablet_id == WACOM_TABLETPC_90_ID)
+ common->tablet_id =
WACOM_TABLETPC_E3_ID;
[Linuxwacom-devel] [PATCH] Add tabstop=8 to vim modelines
Add tabstop=8 to vim modelines in source code files to avoid incorrect shifting if the editor has other tabstop setting. Signed-off-by: Nikolai Kondrashov --- I have tabstop=4 by default (work coding guidelines) and commands shift by incorrect amount. Thanks. include/isdv4.h |2 +- src/wcmCommon.c |2 +- src/wcmConfig.c |2 +- src/wcmFilter.c |2 +- src/wcmISDV4.c|2 +- src/wcmTouchFilter.c |2 +- src/wcmUSB.c |2 +- src/wcmValidateDevice.c |2 +- src/wcmXCommand.c |2 +- src/xf86Wacom.c |2 +- src/xf86Wacom.h |2 +- src/xf86WacomDefs.h |2 +- tools/isdv4-serial-debugger.c |2 +- tools/xsetwacom.c |2 +- 14 files changed, 14 insertions(+), 14 deletions(-) diff --git a/include/isdv4.h b/include/isdv4.h index 33fc26b..fb10d08 100644 --- a/include/isdv4.h +++ b/include/isdv4.h @@ -218,4 +218,4 @@ static inline int isdv4ParseCoordinateData(const unsigned char *buffer, const si #endif /* ISDV4_H */ -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/wcmCommon.c b/src/wcmCommon.c index 7e50878..46e77c8 100644 --- a/src/wcmCommon.c +++ b/src/wcmCommon.c @@ -1951,4 +1951,4 @@ WacomCommonPtr wcmRefCommon(WacomCommonPtr common) return common; } -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/wcmConfig.c b/src/wcmConfig.c index 163f150..cf239f3 100644 --- a/src/wcmConfig.c +++ b/src/wcmConfig.c @@ -602,4 +602,4 @@ _X_EXPORT XF86ModuleData wacomModuleData = wcmUnplug }; -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/wcmFilter.c b/src/wcmFilter.c index eff7822..f2cbec1 100644 --- a/src/wcmFilter.c +++ b/src/wcmFilter.c @@ -312,4 +312,4 @@ void wcmTilt2R(WacomDeviceStatePtr ds) ds->rotation = -ds->rotation; } -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/wcmISDV4.c b/src/wcmISDV4.c index 0dfb4fd..ae14164 100644 --- a/src/wcmISDV4.c +++ b/src/wcmISDV4.c @@ -948,4 +948,4 @@ static int isdv4ProbeKeys(InputInfoPtr pInfo) return tablet_id; } -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/wcmTouchFilter.c b/src/wcmTouchFilter.c index bc2adf0..6050697 100644 --- a/src/wcmTouchFilter.c +++ b/src/wcmTouchFilter.c @@ -487,4 +487,4 @@ static void wcmFingerZoom(WacomDevicePtr priv) } } -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/wcmUSB.c b/src/wcmUSB.c index 09dca73..efc3f52 100644 --- a/src/wcmUSB.c +++ b/src/wcmUSB.c @@ -1184,4 +1184,4 @@ static int usbProbeKeys(InputInfoPtr pInfo) } -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c index 0a21a89..cfa9d80 100644 --- a/src/wcmValidateDevice.c +++ b/src/wcmValidateDevice.c @@ -725,4 +725,4 @@ error: return 0; } -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/wcmXCommand.c b/src/wcmXCommand.c index 30e6a4d..a4c4a81 100644 --- a/src/wcmXCommand.c +++ b/src/wcmXCommand.c @@ -910,4 +910,4 @@ int wcmSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop, return Success; } -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/xf86Wacom.c b/src/xf86Wacom.c index cb05adb..8fcd820 100644 --- a/src/xf86Wacom.c +++ b/src/xf86Wacom.c @@ -983,4 +983,4 @@ out: return rc; } -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/xf86Wacom.h b/src/xf86Wacom.h index 3afd415..465ad7c 100644 --- a/src/xf86Wacom.h +++ b/src/xf86Wacom.h @@ -186,4 +186,4 @@ extern WacomCommonPtr wcmNewCommon(void); // #endif /* __XF86WACOM_H */ -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/src/xf86WacomDefs.h b/src/xf86WacomDefs.h index dcd21fc..27dc1af 100644 --- a/src/xf86WacomDefs.h +++ b/src/xf86WacomDefs.h @@ -485,4 +485,4 @@ struct _WacomToolArea #endif /*__XF86_XF86WACOMDEFS_H */ -/* vim: set noexpandtab shiftwidth=8: */ +/* vim: set noexpandtab tabstop=8 shiftwidth=8: */ diff --git a/tools/isdv4-serial-debugger.c b/tools/isdv4-serial-debugger.c index 6834e3e..e581848 100644 --- a/tools/isdv4-serial-debugger.c +++ b/tools/isdv4-serial-debugger.c @@ -582,4 +582,4 @@ int main (int argc, char **argv) return event_loop(fd); } -/* vim: set noexpandtab shiftw
Re: [Linuxwacom-devel] Waltop (VisTablet PenPad) support
On 09/07/2010 12:52 AM, Favux ... wrote: > Ouch! We just figured out how to get them from raw. What else is > needed? We'd be trying to compile the hid-waltop.ko for the Lucid > 2.6.32 kernel. Please send the changes. Here is the patch for 2.6.36-rc3: http://digimend.git.sourceforge.net/git/gitweb.cgi?p=digimend/kernel-patches.git;a=blob_plain;f=vanilla/2.6.36-rc3.patch;hb=HEAD It would take me a while to backport it to 2.6.32. So a better course of action for you would be to try and build the "for-next" branch of the mentioned git repository. I could help you with that, if you need. Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Waltop (VisTablet PenPad) support
On 09/06/2010 07:15 PM, H:S /he29 wrote: > There's however one other thing that surprised me - I've just noticed, > that the wacom kernel module isn't even loaded, the tablet just works > without it (and loading it manually doesn't change anything). So is the > Waltop tablet (without the manufacturer's kernel patch) acting as some > universal HID compatible "mouse", which just happen to be compatible with > xf86-input-wacom driver, or what? Sorry, forgot to answer this. The wacom kernel driver doesn't handle Waltop tablets currently. So yes, you were using your tablet through the generic HID driver, which tries to support it to the level the tablet describes itself through a HID report descriptor, which is not very high. Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Waltop (VisTablet PenPad) support
On 09/07/2010 02:08 AM, H:S /he29 wrote: > Success. :) > Using your hid_waltop module, the buttons are now working correctly, > everything else seems to be working as well (tested with xidump and GIMP). Great :)! > The only issue I've encountered was when I got in the GIMP preferences > and suddenly it didn't respond to any clicks, not even using the button > on NB touchpad (but keyboard was working). Few minutes later, the same > thing happened in Opera; sometimes it just returns to normal after few > random switches between applications. Anyway, it was not the first time > it happened and xidump continued to report all events correctly, so I > don't think it is related to the tablet drivers. I've seen it myself several times with other tablets and I'm inclined to think it is some X.org or X framework issue. > Thank you for the waltop driver ^^ You're welcome :) I'll need to publish my patches in a better format, though. Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Waltop (VisTablet PenPad) support
On 09/06/2010 08:11 PM, Favux ... wrote: > I'm having the same problem as Martin. When I clone your git I just > see a vanilla kernel hid section and can't find your hid-waltop.c in > it anywhere. It is not my git, it is Jiri Kosina's (HID maintainer) tree. You could use "git checkout for-next" to switch to the "for-next" branch and try it. > Haven't bothered to figure out what kernel version it is. I guess it is 2.6.36-rc1 plus various HID-related patches. > If I use your other link I have the hid-waltop.c and the > hid-ids.h, but with line numbers. It was only for illustration, you shouldn't use it. > If I could get a clean copy of your current hid-waltop.c and the > hid-ids.h (or a patch for the hid-ids.h) I'm reasonably sure I could > talk Ubuntu users through patching a vanilla version of their current > kernel to generate a hid-waltop.ko they could test with. The hid-waltop.c and hid-ids.h changes won't be enough, unfortunately. You could take my patches from my reply to Martin, if the list maintainer approves it. Otherwise I could send them to you personally. Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] xf86-input-wacom and dumb tablets
On 09/06/2010 09:30 AM, Peter Hutterer wrote: > one example would be having a button switch the stylus between screens in a > multi-screen setup (I don't think that works right now, but it used to). > all that can be worked around in the client side, provided we actually have > a client that handles this :) Understood. Thanks :) I'll try to see what happens if my drivers use a single device then. >> Are you going to do anything about it, or does it have a reason to be there? > tbh, I'm not quite sure what the question here is. the wacom kernel driver > exposes a single kernel device. we need multiple X devices for it, hence we > have in-driver device creation/hotplugging/whatever you want to call it. > > I've got some preliminary code for evdev to do the same but not ready yet. OK, now I understand what we're talking about. I confused this hotplugging with the usual kind of hotplugging. Thanks :) Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] xf86-input-wacom and dumb tablets
On 09/06/2010 03:06 AM, Peter Hutterer wrote: > depends. there is some advantage to having the same driver handle both > devices in that a button can change properties on the stylus and the other > way round. You're losing this ability when you have multiple kernel devices > because then you need an extra property to match the devices up. I just want to be absolutely sure: are we talking about the buttons on the stylus itself or about the buttons located around the tablet working area, on the frame? I'm inclined to think it's the latter, but still. Surely, I don't want a separate device for the former. As for the latter, could you please provide an exampe of the properties which these buttons could change, which would need them to be on the same device? > it's currently the only X driver with driver-internal hotplugging support > anyway. Are you going to do anything about it, or does it have a reason to be there? Thanks for the answers :) Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] xf86-input-wacom and dumb tablets
On 09/05/2010 12:37 AM, Chris Bagwell wrote: > Can you briefly say how those three BTN_* are used? For example, does > one represent when your using certain end of the pen (eraser)? Or > does BTN_TOUCH represent when pen is touching and others represent the > buttons on the pen? Well, quite naturally and simple: BTN_TOUCH - the tip is touching BTN_STYLUS - the first barell button BTN_STYLUS2 - the second barell button Like this: | | | |: -- BTN_STYLUS2 | | | |: -- BTN_STYLUS | | `v' --- BTN_TOUCH / / / / / / > Yeah, its really udev doing the work here for MatchIsTablet. See > test_pointers() from this file: > > http://udev.sourcearchive.com/documentation/148/input__id_8c-source.html > > So anything reporting BTN_STYLUS or BTN_TOOL_PEN is considered a tablet. Thanks for the reference :) >> Could you say that the basic issue is solved from what I've written above? >> Because I'm not sure I understood everything right. > > I think we can say its answered. It sounds like drivers your working > on will be detected as IS_INPUT_TABLET by udev because they all have > common thread of BTN_STYLUS and one also has BTN_TOOL_PEN. > > So one initial update to xf86-input-wacom to make it more generic > would require places were it check to see if this is a pen vs. mouse > vs. whatever tool that it can say BTN_TOOL_PEN || BTN_STYLUS. Thanks, that sounds great :) I'll continue reading the sources and then will try to provide a patch, if nobody does it before me. >> Also, from what I've seen in the code, I came to the conclusion that >> MSC_SERIAL is necessary for selecting a channel. Am I wrong? Plus, it seems >> BTN_TOOL_PEN is necessary too, but there is some additional check for >> "_source" option in wcmIsAValidType which I don't yet understand, but which >> allows the device to not have it. Could you please explain in short what >> does it do and what "_source" option exactly is? > > Let me first point you to this following post. It explains kernel > side interface for wacom devices and may help to decode what > xf86-input-wacom is trying to parse. > > http://www.mail-archive.com/linuxwacom-devel@lists.sourceforge.net/msg00959.html > > A channel in xf86-input-wacom is loosely defined as maximum # of > multiplexed tools on single input device that can be in proximity at > the same time. MSC_SERIAL is not strictly required and it will default > to channel 0 (see wcmUSB.c:usbChooseChannel). Thanks. I got the impression it defaults to -1, which is considered invalid and leads to an ignored event. Oh, well, I will recheck that. > Most dumb devices can get away with single channel but we will > eventually need to figure out how they report button presses on > physical tablet because thats what second channel is mostly for. For > these simple devices, I think there must be some way we can allow > buttons to be associated with the PEN channel and not required to be a > fully independent device. Wouldn't it be better to route such buttons to a separate /dev/input/event* and deal with them separately either in the wacom or in some other driver? > The wcmIsValidType is used during initialization time. X driver > creates internally a device for each of the multiplex tools reported > over single input device. What do you mean by the "X driver" - the wacom driver, or some generic X code? > The _source helps detect if its a real device or a fake device that X > created. Your devices will only have BTN_TOOL_PEN/BTN_STYLUS so it won't > hit the logic to create this other devices... Aha, thanks :) Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Waltop (VisTablet PenPad) support
On 09/05/2010 02:12 AM, H:S /he29 wrote: > I can confirm another Waltop tablet working quite well with recent > input-wacom driver from GIT, but it has the same issue concerning buttons > on the pen (both of them send the same button event). It doesn't require > the kernel patch for waltop tablets. Could you please try with my Waltop kernel driver? You could simply build and run a "waltop" or "for-next" branch of Jiri Kosina repository here: http://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git Alternatively, theoretically, I can provide patches for your kernel version. The buttons on Waltop's are quirky - the tablets advertise the button report as a bit map, whereas it is an index. My driver fixes this. Regarding the "kernel patch for waltop tablets" and the manufacturer's driver for that matter: they're really better for some tablets, the big ones, at least. The default mode of the Waltop tablets tries to be HID-compliant unsuccessfully, it cripples the resolution on big tablets and it doesn't support "wheels" well. The tablets have another mode which is probably not even possible to express with a HID report descriptor, but supports full resolution and full control of the "wheel" functions. > It is detected as "WALTOP International Corp. Slim Tablet", product ID > 0032 (which means it is currently mapped to the usbBambooFun). From > "outside" it is Genius G-pen F350, but I guess there may be other > companies selling it with different name, so let's call it "Slim Tablet".. It is called "Slim Tablet 5.8 inch". I have submitted changes for this and two other tablets (500 and 501) to the usb.ids database but they're yet to be accepted. > Since somebody here was trying to ask Waltop about some information > concerning their product ID numbers but didn't get any answer, it may be > good idea to update the settings for each model when it becomes somehow > available (in case Waltop won't ever cooperate..). For example, name for > the model 0032 can be changed to something like usbSlim and resolution to > +- 2000x2000 dpi as it is 5x3 inches tablet with resolution 1x6000 > points (but surprisingly, even though the resolution for usbBambooFun is > set to 2540x2540, I didn't notice any issues). Regarding the settings. What about using "input_absinfo" "resolution" field? I can try adding support for it to the generic HID driver - it could take it from the report descriptor. It could also be used in the Wacom kernel driver. I understand it won't get into the distributions soon, but maybe we can leave the settings as a fallback, when the kernel doesn't provide it. Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] xf86-input-wacom and dumb tablets
On 09/04/2010 09:21 PM, Chris Bagwell wrote: > Here is some initial things to consider. First up, the typical way of > detecting in userspace what type the input device is is by looking at > what events it declares it supports. You'll see this even in > xf86-input-evdev init logic. Sure, I've seen it in many places. > What input devices do the waltop kernel drivers create? For example, > is there one for pen and one for eraser? Or does "dumb" mean they > only support one type of stylus-tool? First, I'm not talking only about Waltop devices here. I've also added support for 4 UC-Logic models - these are the "dumbest" so far. I'm also looking forward to fixing one Kye device. Currently, UC-Logic tablets create two event devices at most: one for the pen, one for the mouse (if any). The mouse reports relative events and is handled perfectly by the evdev driver. The pen reports ABS_X/Y/PRESSURE and BTN_TOUCH/STYLUS/STYLUS2. There is no BTN_TOOL_STYLUS. The Waltop tablets using my driver could have several event devices: a pen, a pseudo-mouse, having only scroll wheels, and a pair of keyboards reporting other things controlled by wheels on the tablet frame. The pen has the usual ABS_X/Y/PRESSURE and BTN_TOUCH/STYLUS/STYLUS2 and there is BTN_TOOL_STYLUS. Neither UC-Logic nor Waltop tablets I've seen have any other tools. > How are the buttons on the tablet reported? Are they on their own > input device? Hopefully so because that would closely match how > xf86-input-wacom wants to see them and solves an issue with which > stylus tool owns the button reports. I'm not sure if you mean the same or different buttons by "the buttons on the tablet" and the buttons which the stylus tool owns and what they all exactly are, but hopefully I have explained the situation sufficiently above. > Without defining BTN_TOOL_PEN, BTN_TOOL_RUBBER, and BTN_TOOL_FINGER > (for pen, eraser, and buttons respectively) in kernel for each input > device, at best, xf86-input-wacom would have to assume they were all > PENs and user would be forced to config files to resolve this. It seems X.org configuration code matches even BTN_TOOL_PEN-less devices with MatchIsTablet, but I'll have to verify it. If it is true, xf86-input-wacom could maybe ship a configuration with an InputClass matching only the pen event device and leave the rest to evdev. > Once that basic issue is solved, the additional changes needed to > xf86-input-wacom are probably pretty small. Could you say that the basic issue is solved from what I've written above? Because I'm not sure I understood everything right. Also, from what I've seen in the code, I came to the conclusion that MSC_SERIAL is necessary for selecting a channel. Am I wrong? Plus, it seems BTN_TOOL_PEN is necessary too, but there is some additional check for "_source" option in wcmIsAValidType which I don't yet understand, but which allows the device to not have it. Could you please explain in short what does it do and what "_source" option exactly is? Thank you very much :) Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] xf86-input-wacom and Waltop tablets
On 09/04/2010 08:04 PM, Favux ... wrote: > In case you didn't find it here is a link to what I think is some of > Timo's preliminary Waltop work: > http://users.tkk.fi/~tjaalton/foo/waltop.diff Thanks, Dave :) Though, I'm not sure Waltop devices should be added to the Wacom kernel driver. I think a separate Waltop driver would be simpler and will make Wacom driver cleaner and to the point. If nobody objects I'd like to investigate it. I'll try to use the generic HID driver as much as possible. Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] xf86-input-wacom and Waltop tablets
Hello everyone, I see you have some code for Waltop tablets in xf86-input-wacom, taken from the manufacturer's driver (which is in turn based on the Wacom driver). However, the kernel part of this driver didn't get it into the kernel. Although, as Peter Hutterer says, Timo Aaltonen did something regarding this. Unaware of Timo's work, I have recently added kernel support [1] for 5 (3 if you discount version differences) Waltop models. However, it is aimed for xf86-input-evdev support and thus most of them use HID_QUIRK_MULTI_INPUT to route all the report IDs to separate event devices digestible by this driver. I'm not sure if that would harm xf86-input-wacom or not, though. Still, I would like to make the Waltop tablets supported by xf86-input-wacom too. I'm prepared to either take over or help with Timo's work or tune both my kernel driver and xf86-input-wacom to compatibility. I have periodical (although short) access to the models I have supported and I think I could find a few more. What would you like me do? Thank you for your attention. Sincerely, Nick [1] http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;f=drivers/hid/hid-waltop.c;hb=refs/heads/for-next -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] xf86-input-wacom and dumb tablets
Hello everyone, I'm interrested in adding support for more tablets to xf86-input-wacom. That is I wan't to do patches. However, many tablets are quite dumb, compared to Wacom ones, but they still could benefit from many software features the driver has, like rotation, pressure curves, etc. My question is how much catering to "dumbness" are you prepared to tolerate in the code? I now have 4 tablet models, which don't report "In Range" for their stylus, thus they don't send BTN_TOOL_STYLUS. Then, none of the tablets I work on send MSC_SERIAL. Will you accept patches dealing with such things? I was aiming for xf86-input-evdev (with some patches), when I was fixing the kernel support for these tablets, however, having xf86-input-wacom support them would be really great. Thank you. Sincerely, Nick -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
