Re: [Linuxwacom-devel] [PATCH 1/1] Add support for the DTI-520

2012-05-17 Thread Chris Bagwell
On Thu, May 17, 2012 at 6:38 PM, Adam Nielsen  wrote:
>>> just wondering if the DTI-520 gives you serial numbers for the styli or if
>>> this device uses generic serials.
>>
>> DTI-520 is a protocol 4 (V4) device. It does not support serial number
>> and tool IDs.
>
> What does "protocol 4" refer to?  Do you know why the USB communication
> protocol used on this tablet is completely different to all other Wacom 
> tablets?

This page will give you the scoop on "protocol 4".

http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Wacom_Protocol_Overview

Chris

--
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 libwacom] test: remove special-case for DTI-520

2012-05-17 Thread Peter Hutterer
We don't need to special-case the device, this device may be used with a pen
that includes an eraser. Removing the special case means we expect all
currently known devices to have at lest one stylus, the code from
4a7a7f16564869b3af6701aa943e5c88927f451b tests those styli for additional
eraser.

Quote Ping Cheng, 17 May 2012,
linuxwacom-devel, Thread: Add support for the DTI-520
"DTI-520 is a protocol 4 (V4) device. It does not support serial number
and tool IDs. [...] This is the same as Graphires. Even if the pen included
in the box does not have eraser, user may use a pen with eraser."

Signed-off-by: Peter Hutterer 
---
Changes to v1:
- expect 1 stylus only, let other code test the erasers

 test/tablet-validity.c |   14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/test/tablet-validity.c b/test/tablet-validity.c
index 8f33cb5..38fd0ef 100644
--- a/test/tablet-validity.c
+++ b/test/tablet-validity.c
@@ -59,7 +59,6 @@ static void verify_tablet(WacomDeviceDatabase *db, 
WacomDevice *device)
 {
const char *name;
const int *styli;
-   unsigned int product;
int nstyli, i;
 
name = libwacom_get_name(device);
@@ -85,18 +84,7 @@ static void verify_tablet(WacomDeviceDatabase *db, 
WacomDevice *device)
 
styli = libwacom_get_supported_styli(device, &nstyli);
assert(styli != NULL);
-   assert(nstyli > 0);
-
-   product = libwacom_get_vendor_id(device) << 16 | 
libwacom_get_product_id(device);
-   switch(product) {
-   /* Devices known not have erasers. */
-   case 0x056a003a: /* DTI520*/
-   assert(nstyli == 1);
-   break;
-   default:
-   assert(nstyli > 1);
-   break;
-   }
+   assert(nstyli >= 1);
 
switch(libwacom_get_class(device)) {
case WCLASS_BAMBOO:
-- 
1.7.10.1


--
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 libwacom] test: remove special-case for DTI-520

2012-05-17 Thread Bastien Nocera
Em Fri, 2012-05-18 às 09:37 +1000, Peter Hutterer escreveu:
> We don't need to special-case the device, this device may be used with a pen
> that includes an eraser. Removing the special case means we expect all
> currently known devices to have at least two styli defined.

That's a wrong expectation. You should test whether they all have at
least one stylus defined, and for the stylus that claim to have an
eraser tip to have it defined and listed.

That'll stop broken definitions like this:
http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/libwacom;a=commit;h=e65080cd10ee9e5fca50d517bad2d1dd877d2b78

So should be:
assert(nstyli >= 1);

> Quote Ping Cheng, 17 May 2012,
> linuxwacom-devel, Thread: Add support for the DTI-520
> "DTI-520 is a protocol 4 (V4) device. It does not support serial number
> and tool IDs. [...] This is the same as Graphires. Even if the pen included
> in the box does not have eraser, user may use a pen with eraser."
> 
> Signed-off-by: Peter Hutterer 
> ---
> Fixes make check regression introduced with 8227f3f6 and 4a7a7f16
> 
>  test/tablet-validity.c |   14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/test/tablet-validity.c b/test/tablet-validity.c
> index 8f33cb5..c8510e9 100644
> --- a/test/tablet-validity.c
> +++ b/test/tablet-validity.c
> @@ -59,7 +59,6 @@ static void verify_tablet(WacomDeviceDatabase *db, 
> WacomDevice *device)
>  {
>   const char *name;
>   const int *styli;
> - unsigned int product;
>   int nstyli, i;
>  
>   name = libwacom_get_name(device);
> @@ -85,18 +84,7 @@ static void verify_tablet(WacomDeviceDatabase *db, 
> WacomDevice *device)
>  
>   styli = libwacom_get_supported_styli(device, &nstyli);
>   assert(styli != NULL);
> - assert(nstyli > 0);
> -
> - product = libwacom_get_vendor_id(device) << 16 | 
> libwacom_get_product_id(device);
> - switch(product) {
> - /* Devices known not have erasers. */
> - case 0x056a003a: /* DTI520*/
> - assert(nstyli == 1);
> - break;
> - default:
> - assert(nstyli > 1);
> - break;
> - }
> + assert(nstyli > 1);
>  
>   switch(libwacom_get_class(device)) {
>   case WCLASS_BAMBOO:



--
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] Add support for the DTI-520

2012-05-17 Thread Ping Cheng
On Thu, May 17, 2012 at 4:38 PM, Adam Nielsen  wrote:
>>> just wondering if the DTI-520 gives you serial numbers for the styli or
>>> if
>>> this device uses generic serials.
>>
>>
>> DTI-520 is a protocol 4 (V4) device. It does not support serial number
>> and tool IDs.
>
>
> What does "protocol 4" refer to?  Do you know why the USB communication
> protocol used on this tablet is completely different to all other Wacom
> tablets?

We basically support two versions of Wacom pen protocols here, V4 and
V5. V5 devices are Intuos and Cintiq V5 series, which report tool IDs
and serial numbers. All the other pen devices are V4, such as
Graphire, Bamboo, and DTI/DTF/ISDV4...

>
>> Does your eraser (physically) react to pressure, i.e., does your
>> eraser tip move when you press? If not, your pen does not have an
>> eraser
>
> No it definitely doesn't move, so I guess it's not an eraser then!

Your tool most likely does not have an eraser. Most DTI/DTF tools do
not have eraser out of box.

Ping

--
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] Add support for the DTI-520

2012-05-17 Thread Favux ...
The amount of movement as the eraser (what would be the rubber)
depresses into the stylus barrel varies by stylus model.  With one
stylus I have it slides in a noticeable distance but my BambooPT
stylus' eraser hardly slides in.  But it does wiggle a bit.

Guess it depends on how the transducer is set up.

--
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] Add support for the DTI-520

2012-05-17 Thread Adam Nielsen
>> just wondering if the DTI-520 gives you serial numbers for the styli or if
>> this device uses generic serials.
>
> DTI-520 is a protocol 4 (V4) device. It does not support serial number
> and tool IDs.

What does "protocol 4" refer to?  Do you know why the USB communication 
protocol used on this tablet is completely different to all other Wacom tablets?

> Does your eraser (physically) react to pressure, i.e., does your
> eraser tip move when you press? If not, your pen does not have an
> eraser.

No it definitely doesn't move, so I guess it's not an eraser then!

Thanks,
Adam.


--
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 libwacom] test: remove special-case for DTI-520

2012-05-17 Thread Peter Hutterer
We don't need to special-case the device, this device may be used with a pen
that includes an eraser. Removing the special case means we expect all
currently known devices to have at least two styli defined.

Quote Ping Cheng, 17 May 2012,
linuxwacom-devel, Thread: Add support for the DTI-520
"DTI-520 is a protocol 4 (V4) device. It does not support serial number
and tool IDs. [...] This is the same as Graphires. Even if the pen included
in the box does not have eraser, user may use a pen with eraser."

Signed-off-by: Peter Hutterer 
---
Fixes make check regression introduced with 8227f3f6 and 4a7a7f16

 test/tablet-validity.c |   14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/test/tablet-validity.c b/test/tablet-validity.c
index 8f33cb5..c8510e9 100644
--- a/test/tablet-validity.c
+++ b/test/tablet-validity.c
@@ -59,7 +59,6 @@ static void verify_tablet(WacomDeviceDatabase *db, 
WacomDevice *device)
 {
const char *name;
const int *styli;
-   unsigned int product;
int nstyli, i;
 
name = libwacom_get_name(device);
@@ -85,18 +84,7 @@ static void verify_tablet(WacomDeviceDatabase *db, 
WacomDevice *device)
 
styli = libwacom_get_supported_styli(device, &nstyli);
assert(styli != NULL);
-   assert(nstyli > 0);
-
-   product = libwacom_get_vendor_id(device) << 16 | 
libwacom_get_product_id(device);
-   switch(product) {
-   /* Devices known not have erasers. */
-   case 0x056a003a: /* DTI520*/
-   assert(nstyli == 1);
-   break;
-   default:
-   assert(nstyli > 1);
-   break;
-   }
+   assert(nstyli > 1);
 
switch(libwacom_get_class(device)) {
case WCLASS_BAMBOO:
-- 
1.7.10.1


--
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] Add support for the DTI-520

2012-05-17 Thread Ping Cheng
On Thu, May 17, 2012 at 4:05 PM, Adam Nielsen  wrote:
> Hi Peter,
>
>> just wondering if the DTI-520 gives you serial numbers for the styli or if
>> this device uses generic serials.
>>  From what I can tell from the tech specs, this devices does not have an
>> eraser, right?
>
> Unfortunately I've got no way of knowing, as I only have one stylus to test
> with and don't have access to any others.  It appears to have an eraser on it
> but it doesn't do anything (no USB data when it is used.)  But I can't confirm
> whether it's a limitation of the tablet or if it's not actually an eraser on
> the stylus.

Does your eraser (physically) react to pressure, i.e., does your
eraser tip move when you press? If not, your pen does not have an
eraser.

Ping

>
> There are only two things I haven't been able to ascertain about the USB
> protocol for the tablet.  One is why there are two proximity values (one is
> set when the stylus gets close, and the other one is set when it gets really
> close) so I'm not sure whether one is actually some sort of tool ID.  The
> other is that when the stylus gets in range, the very first set of coordinates
> (and only the first set) are way off (huge negative values) and they're always
> the same, which I suspect could be a tool ID or possibly a short serial 
> number.
>
> But alas, without access to other styli I'm afraid I can't test any further!
>
> Cheers,
> Adam.
>
>
> --
> 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

--
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] Add support for the DTI-520

2012-05-17 Thread Ping Cheng
On Thu, May 17, 2012 at 3:55 PM, Peter Hutterer
 wrote:
> Adam,
>
> just wondering if the DTI-520 gives you serial numbers for the styli or if
> this device uses generic serials.

DTI-520 is a protocol 4 (V4) device. It does not support serial number
and tool IDs.

> >From what I can tell from the tech specs, this devices does not have an
> eraser, right?

This is the same as Graphires. Even if the pen included in the box
does not have eraser, user may use a pen with eraser.

Ping

>
> Cheers,
>  Peter
>
> On Wed, Apr 11, 2012 at 04:13:08PM +1000, Adam Nielsen wrote:
>> Add support for the DTI-520
>>
>> Signed-off-by: Adam Nielsen 
>> ---
>>  src/wcmUSB.c            |    1 +
>>  src/wcmValidateDevice.c |    1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/src/wcmUSB.c b/src/wcmUSB.c
>> index f62fd5b..142325b 100644
>> --- a/src/wcmUSB.c
>> +++ b/src/wcmUSB.c
>> @@ -223,6 +223,7 @@ static struct
>>       { WACOM_VENDOR_ID, 0x37,  2,  2, &usbCintiq     }, /* PL700 */
>>       { WACOM_VENDOR_ID, 0x38,  2,  2, &usbCintiq     }, /* PL510 */
>>       { WACOM_VENDOR_ID, 0x39,  2,  2, &usbCintiq     }, /* PL710 */
>> +     { WACOM_VENDOR_ID, 0x3A,  2,  2, &usbCintiq     }, /* DTI520 */
>>       { WACOM_VENDOR_ID, 0xC0,  2,  2, &usbCintiq     }, /* DTF720 */
>>       { WACOM_VENDOR_ID, 0xC2,  2,  2, &usbCintiq     }, /* DTF720a 
>> */
>>       { WACOM_VENDOR_ID, 0xC4,  2,  2, &usbCintiq     }, /* DTF521 */
>> diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
>> index 4d7c791..53c38c3 100644
>> --- a/src/wcmValidateDevice.c
>> +++ b/src/wcmValidateDevice.c
>> @@ -240,6 +240,7 @@ int wcmDeviceTypeKeys(InputInfoPtr pInfo)
>>               case 0x37:  /* PL700 */
>>               case 0x38:  /* PL510 */
>>               case 0x39:  /* PL710 */
>> +             case 0x3A:  /* DTI520 */
>>               case 0xC0:  /* DTF720 */
>>               case 0xC2:  /* DTF720a */
>>               case 0xC4:  /* DTF521 */
>> --
>> 1.7.10
>
> --
> 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

--
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] Add support for the DTI-520

2012-05-17 Thread Peter Hutterer
On Fri, May 18, 2012 at 09:05:14AM +1000, Adam Nielsen wrote:
> Hi Peter,
> 
> >just wondering if the DTI-520 gives you serial numbers for the styli or if
> >this device uses generic serials.
> > From what I can tell from the tech specs, this devices does not have an
> >eraser, right?
> 
> Unfortunately I've got no way of knowing, as I only have one stylus
> to test with and don't have access to any others.  It appears to
> have an eraser on it but it doesn't do anything (no USB data when it
> is used.)  But I can't confirm whether it's a limitation of the
> tablet or if it's not actually an eraser on the stylus.

> There are only two things I haven't been able to ascertain about the
> USB protocol for the tablet.  One is why there are two proximity
> values (one is set when the stylus gets close, and the other one is
> set when it gets really close) so I'm not sure whether one is
> actually some sort of tool ID.  The other is that when the stylus
> gets in range, the very first set of coordinates (and only the first
> set) are way off (huge negative values) and they're always the same,
> which I suspect could be a tool ID or possibly a short serial
> number.
> 
> But alas, without access to other styli I'm afraid I can't test any further!

Thanks. Ping/Jason - can you chime in here?

Cheers,
  Peter

--
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] Add support for the DTI-520

2012-05-17 Thread Adam Nielsen
Hi Peter,

> just wondering if the DTI-520 gives you serial numbers for the styli or if
> this device uses generic serials.
>  From what I can tell from the tech specs, this devices does not have an
> eraser, right?

Unfortunately I've got no way of knowing, as I only have one stylus to test 
with and don't have access to any others.  It appears to have an eraser on it 
but it doesn't do anything (no USB data when it is used.)  But I can't confirm 
whether it's a limitation of the tablet or if it's not actually an eraser on 
the stylus.

There are only two things I haven't been able to ascertain about the USB 
protocol for the tablet.  One is why there are two proximity values (one is 
set when the stylus gets close, and the other one is set when it gets really 
close) so I'm not sure whether one is actually some sort of tool ID.  The 
other is that when the stylus gets in range, the very first set of coordinates 
(and only the first set) are way off (huge negative values) and they're always 
the same, which I suspect could be a tool ID or possibly a short serial number.

But alas, without access to other styli I'm afraid I can't test any further!

Cheers,
Adam.


--
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] Add support for the DTI-520

2012-05-17 Thread Peter Hutterer
Adam,

just wondering if the DTI-520 gives you serial numbers for the styli or if
this device uses generic serials.
>From what I can tell from the tech specs, this devices does not have an
eraser, right?

Cheers,
  Peter

On Wed, Apr 11, 2012 at 04:13:08PM +1000, Adam Nielsen wrote:
> Add support for the DTI-520
> 
> Signed-off-by: Adam Nielsen 
> ---
>  src/wcmUSB.c|1 +
>  src/wcmValidateDevice.c |1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/src/wcmUSB.c b/src/wcmUSB.c
> index f62fd5b..142325b 100644
> --- a/src/wcmUSB.c
> +++ b/src/wcmUSB.c
> @@ -223,6 +223,7 @@ static struct
>   { WACOM_VENDOR_ID, 0x37,  2,  2, &usbCintiq }, /* PL700 */
>   { WACOM_VENDOR_ID, 0x38,  2,  2, &usbCintiq }, /* PL510 */
>   { WACOM_VENDOR_ID, 0x39,  2,  2, &usbCintiq }, /* PL710 */
> + { WACOM_VENDOR_ID, 0x3A,  2,  2, &usbCintiq }, /* DTI520 */
>   { WACOM_VENDOR_ID, 0xC0,  2,  2, &usbCintiq }, /* DTF720 */
>   { WACOM_VENDOR_ID, 0xC2,  2,  2, &usbCintiq }, /* DTF720a */
>   { WACOM_VENDOR_ID, 0xC4,  2,  2, &usbCintiq }, /* DTF521 */
> diff --git a/src/wcmValidateDevice.c b/src/wcmValidateDevice.c
> index 4d7c791..53c38c3 100644
> --- a/src/wcmValidateDevice.c
> +++ b/src/wcmValidateDevice.c
> @@ -240,6 +240,7 @@ int wcmDeviceTypeKeys(InputInfoPtr pInfo)
>   case 0x37:  /* PL700 */
>   case 0x38:  /* PL510 */
>   case 0x39:  /* PL710 */
> + case 0x3A:  /* DTI520 */
>   case 0xC0:  /* DTF720 */
>   case 0xC2:  /* DTF720a */
>   case 0xC4:  /* DTF521 */
> -- 
> 1.7.10

--
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] [RFC] LEDs & OLEDs on Intuos4 tablets

2012-05-17 Thread Jim Henderson
On Thu, 17 May 2012 15:43:19 -0500, Favux ... wrote:

> Right, that was Nicholas Hirsch's usbfs solution.  See his
> Tracker:Patches post:
> http://sourceforge.net/tracker/?
func=detail&aid=2878608&group_id=69596&atid=525126
> 
> As you can see Ping included it with linuxwacom-0.8.5-8 for kernels
> 2.6.24 and later.  But then upstream dropped usbfs and the Distros
> followed shortly.  So nothing until Eduard Hasenleithner started
> submitting to linux-input in about March 2011.  That became the current
> sysfs solution.
> He started on the xsetwacom implementation which was picked up by Ping
> and then Jason.

Yeah, that's the one. :)  I was one of a few people who were playing 
around with that one.

Thanks for the history, I've only been following peripherally, but now 
that there is an effort to get something going again, I'm more than happy 
to help out with testing if I can. :)

Jim

-- 
 Jim Henderson
 Please keep on-topic replies on the list so everyone benefits


--
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] [RFC] LEDs & OLEDs on Intuos4 tablets

2012-05-17 Thread Favux ...
On Thu, May 17, 2012 at 3:21 PM, Jim Henderson  wrote:
>
> FWIW, I have the same tablet here, and have been interested in seeing OLED
> support return (there was support once upon a time through the kernel
> driver, but it was overly complicated to use and required root privs and
> a CLI tool to push images to it - it's been a couple of years since it
> was there IIRC).

Right, that was Nicholas Hirsch's usbfs solution.  See his
Tracker:Patches post:
http://sourceforge.net/tracker/?func=detail&aid=2878608&group_id=69596&atid=525126

As you can see Ping included it with linuxwacom-0.8.5-8 for kernels
2.6.24 and later.  But then upstream dropped usbfs and the Distros
followed shortly.  So nothing until Eduard Hasenleithner started
submitting to linux-input in about March 2011.  That became the
current sysfs solution.  He started on the xsetwacom implementation
which was picked up by Ping and then Jason.

Favux

--
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] [RFC] LEDs & OLEDs on Intuos4 tablets

2012-05-17 Thread Jim Henderson
On Thu, 17 May 2012 16:06:57 -0400, Mike Erwin wrote:

> Intuos4 M (PTK-640) over here. Just to clarify, there are 64x32 hardware
> pixels beside each button. The Mac driver uses only 64x30,
> and leaves 2 rows black between each icon.

FWIW, I have the same tablet here, and have been interested in seeing OLED 
support return (there was support once upon a time through the kernel 
driver, but it was overly complicated to use and required root privs and 
a CLI tool to push images to it - it's been a couple of years since it 
was there IIRC).

I'm happy to do testing on any solution that comes out of this.  I'm 
running openSUSE 12.1 on the system my tablet is connected to.

It'd be nice if there was a way to extend the Wacom applet in GNOME 3 to 
support this functionality as well (as well as KDE4 and other DEs; I 
mention G3 because (a) I use it, and (b) there's a wacom config applet in 
the user "system settings" application).

Jim

-- 
 Jim Henderson
 Please keep on-topic replies on the list so everyone benefits


--
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] [RFC] LEDs & OLEDs on Intuos4 tablets

2012-05-17 Thread Mike Erwin
>
> Hmm it's getting more complicated. What model do you have?
> I have Intuos4 WL and looks like OLEDS are 64x32, 1 bit color depths...
>
> --
> Przemo Firszt 
>

Intuos4 M (PTK-640) over here. Just to clarify, there are 64x32
hardware pixels beside each button. The Mac driver uses only 64x30,
and leaves 2 rows black between each icon.

Post #138 on this page shows a nice image on the display, with various
shades of gray:
http://ubuntuforums.org/showthread.php?p=10260362

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

--
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] [RFC] LEDs & OLEDs on Intuos4 tablets

2012-05-17 Thread Przemo Firszt
Dnia 2012-05-17, czw o godzinie 13:57 -0400, Mike Erwin pisze:
> Przemo:
> > Some ideas (I haven't tested Karg/sanette's applet yet):
> > OLEDs are 64x32, "scrambled" in some funny way. I hope that I can make
> > efficient "descrambling" in kernel, so we could feed sysfs with plain and
> > simple 1-bit 64x32 images.
Hi,
> I've only sent images to the OLEDs on MacOS, but 4-bit 64x30 seemed to
> be ideal. When sending 8-bit grayscale (or full color) source images,
> only 16 distinct shades could be seen on the display. 64x32 images
> showed up fine, but were scaled by the driver to fit into a 64x30
> space. This seemed like a software choice, to leave a nice 2px gap
> between icons. Sticking with 30px height would allow image/icon sets
> to be used across platforms, something I care about.
> 
> Attached is the test image I constructed to test OLED limits. It can
> also be downloaded from here:
> 
> http://projects.blender.org/scm/viewvc.php/*checkout*/branches/soc-2010-merwin/experimental/OLED%20test%20icons/gray-ramp.png?revision=30902&root=bf-blender
> 
> I'm interested to hear if the same squishing & banding occur on Linux.

Hmm it's getting more complicated. What model do you have?
I have Intuos4 WL and looks like OLEDS are 64x32, 1 bit color depths...

-- 
Przemo Firszt 


--
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] [RFC] LEDs & OLEDs on Intuos4 tablets

2012-05-17 Thread Mike Erwin
Przemo:
> Some ideas (I haven't tested Karg/sanette's applet yet):
> OLEDs are 64x32, "scrambled" in some funny way. I hope that I can make
> efficient "descrambling" in kernel, so we could feed sysfs with plain and
> simple 1-bit 64x32 images.

I've only sent images to the OLEDs on MacOS, but 4-bit 64x30 seemed to
be ideal. When sending 8-bit grayscale (or full color) source images,
only 16 distinct shades could be seen on the display. 64x32 images
showed up fine, but were scaled by the driver to fit into a 64x30
space. This seemed like a software choice, to leave a nice 2px gap
between icons. Sticking with 30px height would allow image/icon sets
to be used across platforms, something I care about.

Attached is the test image I constructed to test OLED limits. It can
also be downloaded from here:

http://projects.blender.org/scm/viewvc.php/*checkout*/branches/soc-2010-merwin/experimental/OLED%20test%20icons/gray-ramp.png?revision=30902&root=bf-blender

I'm interested to hear if the same squishing & banding occur on Linux.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
<>--
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] [RFC] LEDs & OLEDs on Intuos4 tablets

2012-05-17 Thread Favux ...
As far as I know other than on his blog Christoph has posted two(?)
versions to the LWP mailing-lists.  Or at least linked to them.  The
last was:  http://sourceforge.net/mailarchive/message.php?msg_id=27183872
 I think the one currently on his blog is a several month newer
version.

Sanette has posted his tweaks of the applet only on the Ubuntu forums
thread I linked to earlier.  Three versions total AFAIK.  While he has
posted on the mailing-lists I don't think he's posted the applet.  By
the way sanette is Vu Ngoc San.

The applet isn't on Source Forge, GitHub, or Launchpad etc. as far as
I know.  Given sanette's plea/wish on the last version he posted for a
coder/developer to clean the applet up I doubt he would have any
objections to someone hosting it somewhere.  Have to ask them:

Christoph Karg wa...@kargulus.de

Vu Ngoc San san.vu-n...@laposte.net

Favux

--
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] [RFC] LEDs & OLEDs on Intuos4 tablets

2012-05-17 Thread Bastien Nocera
On Wed, 2012-05-16 at 19:01 +0100, Przemo Firszt wrote:
> Dnia 2012-05-16, śro o godzinie 11:56 -0500, Favux ... pisze:
> > Hi Prezmo,
> > 
> > Peter vetoed the xsetwacom implementation for the Intuos4 OLEDs:
> > http://sourceforge.net/mailarchive/message.php?msg_id=28814445
> > 
> > From this thread:
> > http://sourceforge.net/mailarchive/forum.php?thread_name=CAF8JNhK6%3DvdFtXAYK6iX7UJo6%3DxSduaaUK63d94pGkg5V15s0Q%40mail.gmail.com&forum_name=linuxwacom-devel
> > 
> > Other than the work Bastien mentions on the g-s-d/Wacom Tablet applet
> > there is another applet then has been around a while.  It's by
> > Christoph Karg:  http://braindump.kargulus.de/  And San (sanette) has
> > posted several versions with modifications on the Ubuntu forums, the
> > last:  http://ubuntuforums.org/showpost.php?p=10921962&postcount=214
> > Christoph posted his applet once or twice on linuxwacom-discuss, not
> > sure if San ever did.
> > 
> > Christoph should have give the applet a name, don't you think?
> > 
> > Favux
> Thanks Favux!
> What about libwacom? Could we use it to simplify LED/OLED handling?
> And then g-s-d could use libwacom?

libwacom is all about enumeration and identification. It doesn't poke
the hardware directly, and it probably never should.



--
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] [RFC] LEDs & OLEDs on Intuos4 tablets

2012-05-17 Thread Przemo Firszt

Dnia 16 Maja 2012, 6:47 pm, Śr, Favux ... napisał(a):
[..]
>> Good, you're reading my mind :-)
>> I'd start with something simple (see my other email). What do you mean
>> by "a good algorithm to transform the actions or keyboard combinations
>> into 3 small drawings"? What about letting user define a text that
>> describes the action and convert the text to image? Windows driver is
>> using that method. (I might be missing something simple here as I
>> haven't started to work on OLEDs yet)
>
> Karg/sanette's applet does that.
>
Ok, I know bit more today :-)
Is there any change that the Karg/sanette's applet will be part of
standard ubuntu/fedora/mint/whatever application set? I'd like to see
OLEDS working out-of-the-box on wide range of distros. Using kernel
modules/libwacom/xsetwacom/g-s-d would provide that.

Some ideas (I haven't tested Karg/sanette's applet yet):
OLEDs are 64x32, "scrambled" in some funny way. I hope that I can make
efficient "descrambling" in kernel, so we could feed sysfs with plain and
simple 1-bit 64x32 images.

We could try to squeeze 3 lines of text, 10px height with one pixel break
(3 x 10 + 2 = 32). The font would be 7x10, so the number of characters
would be 24 (8 characters per line, each character 7 pixels wide + 1 px of
break). There are free 7x10 fonts, so we don't have to do it from scratch.

Now the main question: where we should do the rendering?
I think about doing it in libwacom ("descrambling" could also be part of
libwacom if it turns out to be too awkward to do it in kernel).
What are your thoughts? It there a better place for it?

I'm ccing Peter and Ping
-- 
Regards,
Przemo Firszt


--
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/3] HID: wacom: Move Graphire raport header check.

2012-05-17 Thread Przemo Firszt

Dnia 16 Maja 2012, 8:43 pm, Śr, Jiri Kosina napisał(a):
> On Wed, 16 May 2012, Ping Cheng wrote:
> [..]
>> Acked-by: Ping Cheng  for the series.
>
> I have applied the series. Thanks to both of you,
Thanks!
-- 
Regards,
Przemo Firszt


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