Re: [Linuxwacom-devel] Issues with DTI-520

2012-04-10 Thread RubyKat 
On Wed, Apr 11, 2012 at 03:12:41PM +1000, Adam Nielsen wrote:
> >Was this patch ever submitted?  I've just bought a second-hand Wacom DTI-520
> >myself
> >and I would really like for it to be supported.  PLEASE?
> 
> I haven't submitted it yet as there were a few unknowns related to
> tool IDs and I haven't got any other tools to test with.
> 
> If you're able to compile the driver I'd be happy to post the patch
> so you can test it out.

Thanks for the prompt response!  No, I'm not really set up for compiling
drivers here.  If work on the patch is stalled, would it be better to
submit it anyway?  Since mostly-working is better than not working at
all, and if the code was in the repo, someone else might be able to
improve it.

K.A.
-- 
 _--_|\| Kathryn Andersen 
/  \   | 
\_.--.*/   | 
  v| 
---| Melbourne -> Victoria -> Australia -> Southern Hemisphere
Maranatha! |-> Earth -> Sol -> Milky Way Galaxy -> Universe

--
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] Issues with DTI-520

2012-04-10 Thread Adam Nielsen 
> Thanks for the prompt response!  No, I'm not really set up for compiling
> drivers here.  If work on the patch is stalled, would it be better to
> submit it anyway?  Since mostly-working is better than not working at
> all, and if the code was in the repo, someone else might be able to
> improve it.

You're probably right.  Ok, I'll prepare a patch and see if it can be included.

Cheers,
Adam.


--
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] Issues with DTI-520

2012-04-10 Thread Adam Nielsen 
> Was this patch ever submitted?  I've just bought a second-hand Wacom DTI-520
> myself
> and I would really like for it to be supported.  PLEASE?

I haven't submitted it yet as there were a few unknowns related to tool IDs 
and I haven't got any other tools to test with.

If you're able to compile the driver I'd be happy to post the patch so you can 
test it out.

Cheers,
Adam.



--
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] Issues with DTI-520

2012-04-10 Thread RubyKat 


Adam Nielsen" wrote:
> Well it looks like it's all working now.  I'll tidy it up and send you a
> patch 
> - do you have a preferred repository for me to base the patch on?

> Thanks again for all your help Chris!

Was this patch ever submitted?  I've just bought a second-hand Wacom DTI-520
myself
and I would really like for it to be supported.  PLEASE?

K. Andersen
-- 
View this message in context: 
http://old.nabble.com/Issues-with-DTI-520-tp33305258p33666160.html
Sent from the linuxwacom-devel mailing list archive at Nabble.com.


--
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] Issues with DTI-520

2012-02-25 Thread Adam Nielsen 
>> Yet "xinput test" doesn't display any events for the stylus interface.  Any
>> ideas what I could be doing wrong?
>
> Only seeing this small sample, Its probably the proximity value thats
> not working.  When px=0, the driver will not post X/Y events to X
> server.

Aha, indeed that was the problem.  I had forgotten to make the state of 
BTN_TOOL_PEN reflect the proximity value.

Well it looks like it's all working now.  I'll tidy it up and send you a patch 
- do you have a preferred repository for me to base the patch on?

Thanks again for all your help Chris!

Cheers,
Adam.


--
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] Issues with DTI-520

2012-02-19 Thread Chris Bagwell 
On Sun, Feb 19, 2012 at 2:33 AM, Adam Nielsen  wrote:
>
> So far everything works fine in evdev, but I am still having problems
> getting the X driver to pick up the device.
>
> Currently the interface with the buttons works (the L and R buttons on the
> tablet work as left and right mouse buttons) however the stylus interface is
> still being ignored.
>
> I got the logging working with 'xinput set-prop device_name "Wacom Debug
> Levels" 10 10' from your other e-mail and the correct events are logged:
>
> [ 26093.031] (II) Wacom DTI520UB/L stylus (10:wcmReady): 1 numbers of data
> [ 26093.031] (II) /dev/input/event13 (10:wcmReadPacket): fd=75
> [ 26093.031] (II) /dev/input/event13 (1:wcmReadPacket): pos=0 remaining=256
> [ 26093.031] (II) /dev/input/event13 (10:wcmReadPacket): buffer has 72 bytes
> [ 26093.031] (II) /dev/input/event13 (10:usbParseEvent):
> [ 26093.031] (II) /dev/input/event13 (10:usbParseEvent):
> [ 26093.031] (II) /dev/input/event13 (10:usbParseEvent):
> [ 26093.031] (II) /dev/input/event13 (6:usbDispatchEvents): 3 events
> received
> [ 26093.031] (II) /dev/input/event13 (10:wcmEvent): channel = 0
> [ 26093.031] (II) /dev/input/event13 (10:wcmEvent): c=0 i=0 t=0 s=1 x=3806
> y=2352 b=0 p=0 rz=0 tx=0 ty=0 aw=0 aw2=0 rw=0 t=0 px=0 st=0 cs=0
> [ 26093.031] (II) Wacom DTI520UB/L stylus (10:wcmReady): 0 numbers of data
> [ 26093.031] (II) Wacom DTI520UB/L stylus (10:wcmDevReadInput): Read (1)
>
> Yet "xinput test" doesn't display any events for the stylus interface.  Any
> ideas what I could be doing wrong?

Only seeing this small sample, Its probably the proximity value thats
not working.  When px=0, the driver will not post X/Y events to X
server.

Also, the device type is set to 0 ("t=0"). Events are discarded when
no device_type is set.

What version of xf86-input-wacom are you running?  You may need to
upgrade for it to work with whats sometimes called "generic" tablets.
I think you need at least version 0.11 for that support.

Or you can modify your kernel side code a little to not be "generic".

>
> I am configuring the device like this in wacom_setup_input_capabilities():
>
>        case WACOM_DTI:
>                __clear_bit(ABS_MISC, input_dev->absbit);
>                switch (features->device_type) {
>                case BTN_TOOL_PEN:
>                        __set_bit(BTN_TOOL_PEN, input_dev->keybit);
>                        __set_bit(BTN_STYLUS, input_dev->keybit);
>                        __set_bit(BTN_STYLUS2, input_dev->keybit);
>
>                        __set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
>                        break;

That all looks good.  The ABS_MISC that your turning off is what
xf86-input-wacom used to key off of to set device_type on its side.
You can delete that line and then start sending it; using
wacom_dtu_irq() as a guide on how to do that.

But it also shouldn't be needed in newer X input drivers.

Chris

--
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] Issues with DTI-520

2012-02-19 Thread Adam Nielsen 
> wacom_features is not shared exactly.  Each interface has its own
> features but its value is initialized from a common value.
>
> What you need to do is figure out a way to touch up the values that do
> not make sense for a given interface.  Normally, this is done in
> wacom_parse_hid() but in your case it probably needs to be done
> somewhere else (I'll help figure that out with you soon but for now
> just hardcode it in wacom_probe() somehow).

Ahh ok, I think I misunderstood why the code was failing when I tweaked the 
wacom_features for the other interface.  I have now done as you suggested and 
it seems to work well.

> True, put you can check USB interface # in wacom_probe() and override
> pkglen there.  Then you can base your settings in
> wacom_setup_input_capabilities() based on pktlen.

Yes, this works well.

> FYI: I realize this all looks kinda ugly.  I'm working on some ideas
> on how to clean this up.  As long as you get this working, I'll help
> clean it up.

So far everything works fine in evdev, but I am still having problems getting 
the X driver to pick up the device.

Currently the interface with the buttons works (the L and R buttons on the 
tablet work as left and right mouse buttons) however the stylus interface is 
still being ignored.

I got the logging working with 'xinput set-prop device_name "Wacom Debug 
Levels" 10 10' from your other e-mail and the correct events are logged:

[ 26093.031] (II) Wacom DTI520UB/L stylus (10:wcmReady): 1 numbers of data
[ 26093.031] (II) /dev/input/event13 (10:wcmReadPacket): fd=75
[ 26093.031] (II) /dev/input/event13 (1:wcmReadPacket): pos=0 remaining=256
[ 26093.031] (II) /dev/input/event13 (10:wcmReadPacket): buffer has 72 bytes
[ 26093.031] (II) /dev/input/event13 (10:usbParseEvent):
[ 26093.031] (II) /dev/input/event13 (10:usbParseEvent):
[ 26093.031] (II) /dev/input/event13 (10:usbParseEvent):
[ 26093.031] (II) /dev/input/event13 (6:usbDispatchEvents): 3 events received
[ 26093.031] (II) /dev/input/event13 (10:wcmEvent): channel = 0
[ 26093.031] (II) /dev/input/event13 (10:wcmEvent): c=0 i=0 t=0 s=1 x=3806 
y=2352 b=0 p=0 rz=0 tx=0 ty=0 aw=0 aw2=0 rw=0 t=0 px=0 st=0 cs=0
[ 26093.031] (II) Wacom DTI520UB/L stylus (10:wcmReady): 0 numbers of data
[ 26093.031] (II) Wacom DTI520UB/L stylus (10:wcmDevReadInput): Read (1)

Yet "xinput test" doesn't display any events for the stylus interface.  Any 
ideas what I could be doing wrong?

$ xsetwacom --list devices
Wacom DTI520UB/L stylus id: 13  type: STYLUS
Wacom DTI520UB/L padid: 14  type: PAD

$ xinput list-props 13
Device 'Wacom DTI520UB/L stylus':
 Device Enabled (121):   1
 Coordinate Transformation Matrix (123): 1.00, 0.00, 0.00, 
0.00, 1.00, 0.00, 0.00, 0.00, 1.00
 Device Accel Profile (245): 0
 Device Accel Constant Deceleration (246):   1.00
 Device Accel Adaptive Deceleration (247):   1.00
 Device Accel Velocity Scaling (248):10.00
 Device Node (620):  "/dev/input/event13"
 Wacom Tablet Area (621):0, 0, 6282, 4762
 Wacom Rotation (622):   0
 Wacom Pressurecurve (623):  0, 0, 100, 100
 Wacom Serial IDs (624): 58, 0, 2, 0
 Wacom Serial ID binding (625):  0
 Wacom Pressure Threshold (626): 27
 Wacom Sample and Suppress (627):2, 4
 Wacom Enable Touch (628):   0
 Wacom Hover Click (629):1
 Wacom Enable Touch Gesture (630):   0
 Wacom Touch Gesture Parameters (631):   0, 0, 250
 Wacom Tool Type (632):  "STYLUS" (441)
 Wacom Button Actions (633): "None" (0), "None" (0), "None" (0), 
"None" (0), "None" (0), "None" (0), "None" (0)
 Device Product ID (634):1386, 58
 Wacom Debug Levels (635):   0, 0

I am configuring the device like this in wacom_setup_input_capabilities():

case WACOM_DTI:
__clear_bit(ABS_MISC, input_dev->absbit);
switch (features->device_type) {
case BTN_TOOL_PEN:
__set_bit(BTN_TOOL_PEN, input_dev->keybit);
__set_bit(BTN_STYLUS, input_dev->keybit);
__set_bit(BTN_STYLUS2, input_dev->keybit);

__set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
break;

case 0:
__set_bit(BTN_BACK, input_dev->keybit);
__set_bit(BTN_FORWARD, input_dev->keybit);
__set_bit(BTN_LEFT, input_dev->keybit);
__set_bit(BTN_RIGHT, input_dev->keybit);
__set_bit(BTN_EXTRA, input_dev->keybit);
__set_bit(BTN_0, input_dev->keybit);
__set_bit(BTN_1, input_dev->keybit);
__set_bit(BTN_2, input_dev->keybit);

Re: [Linuxwacom-devel] Issues with DTI-520

2012-02-18 Thread Chris Bagwell 
On Sat, Feb 18, 2012 at 7:32 PM, Adam Nielsen  wrote:
> Hi Chris,
>
> A couple more questions...
>
>
>>> This worked quite well.  I do however get two identical devices appearing
>>> (both tablets with buttons) rather than one tablet and one set of buttons
>>> as
>>> I think would be more logical.  Not sure how to address this though.
>>
>>
>> Its wacom_setup_input_capabilities() job to declare and not declare
>> correct events for each interface.  Right now, all devices have an X/Y
>> so you'll have a new case of button only.
>>
>> For temporary hack, I'd check for pktlen or interface # in that
>> function to hide what you need.  For other multi-interface cases, 1
>> interface is a stylus tablet and 1 interface is a touchpad so we 1st
>> set and then check device_type to see what events to hide.
>
>
> I'm a bit stuck on this.  As far as I can tell,
> wacom_setup_input_capabilities() is called once for each interface (so one
> call for the stylus and one for the buttons) but the wacom_features
> structure seems to be shared between them both.  This means that I can't
> check pktlen as it will be the same for both interfaces.

wacom_features is not shared exactly.  Each interface has its own
features but its value is initialized from a common value.

What you need to do is figure out a way to touch up the values that do
not make sense for a given interface.  Normally, this is done in
wacom_parse_hid() but in your case it probably needs to be done
somewhere else (I'll help figure that out with you soon but for now
just hardcode it in wacom_probe() somehow).


>
> Likewise I can't check the USB interface number, as that doesn't seem to be
> passed to wacom_setup_input_capabilities().

True, put you can check USB interface # in wacom_probe() and override
pkglen there.  Then you can base your settings in
wacom_setup_input_capabilities() based on pktlen.

FYI: I realize this all looks kinda ugly.  I'm working on some ideas
on how to clean this up.  As long as you get this working, I'll help
clean it up.

>
> Am I misunderstanding this, or is there another way I can work out what
> interface I'm accessing inside wacom_setup_input_capabilities()?
>
>
>> We kinda need a new device type that says Pad-only.  Probably a fixed
>> value of 0 to mean !Pen and !Touch will be good enough for now.
>
>
> I'm not quite sure what you mean by this.  I have a few ideas but none of
> them worked out due to the shared wacom_features so I think I misunderstand.

Maybe this will be helpful to understand what I'm thinking.  I'm
working on support for a wireless module that has 3 USB interfaces:  A
monitor interface (so you can detect when wireless tablet is
connected), a pen interface, and a touch interface.  To help out, I
gave the device type a unique name (BAMBOO_WIRELESS) and then I set
device_type to either 0, STYLUS, or DOUPLETAP (touch) depending on
interface #.  I also set pktlen when needed based on interface #.

http://www.spinics.net/lists/linux-input/msg19345.html

Between device_type and pkglen, I can tell what interface I'm running
on without looking at interface # any more.

Chris

>
> Thanks,
> Adam.
>

--
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] Issues with DTI-520

2012-02-18 Thread Adam Nielsen 
Hi Chris,

A couple more questions...

>> This worked quite well.  I do however get two identical devices appearing
>> (both tablets with buttons) rather than one tablet and one set of buttons as
>> I think would be more logical.  Not sure how to address this though.
>
> Its wacom_setup_input_capabilities() job to declare and not declare
> correct events for each interface.  Right now, all devices have an X/Y
> so you'll have a new case of button only.
>
> For temporary hack, I'd check for pktlen or interface # in that
> function to hide what you need.  For other multi-interface cases, 1
> interface is a stylus tablet and 1 interface is a touchpad so we 1st
> set and then check device_type to see what events to hide.

I'm a bit stuck on this.  As far as I can tell, 
wacom_setup_input_capabilities() is called once for each interface (so one 
call for the stylus and one for the buttons) but the wacom_features structure 
seems to be shared between them both.  This means that I can't check pktlen as 
it will be the same for both interfaces.

Likewise I can't check the USB interface number, as that doesn't seem to be 
passed to wacom_setup_input_capabilities().

Am I misunderstanding this, or is there another way I can work out what 
interface I'm accessing inside wacom_setup_input_capabilities()?

> We kinda need a new device type that says Pad-only.  Probably a fixed
> value of 0 to mean !Pen and !Touch will be good enough for now.

I'm not quite sure what you mean by this.  I have a few ideas but none of them 
worked out due to the shared wacom_features so I think I misunderstand.

Thanks,
Adam.


--
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] Issues with DTI-520

2012-02-13 Thread Chris Bagwell 
On Mon, Feb 13, 2012 at 4:26 AM, Adam Nielsen  wrote:
>>> Unfortunately once I reached this point the X driver stopped working.  It
>>> detects the device but "xinput test" doesn't report any output.  I'm a bit
>>> stumped at this because I haven't changed anything in the X driver and the
>>> events are all being reported correctly by the kernel.
>>
>> Can you send output from "xinput list" and snippet of your
>> /var/log/Xorg.0.log were each wacom input is detected?  It woud also
>> be helpful to see the initial output of evtest for your stylus device
>> where it prints out the supported capabilities.
>
> Ok, here's what it all looks like:
>

> ⎜   ↳ Wacom DTI520UB/L stylus                   id=12   [slave  pointer  (2)]
> ⎜   ↳ Wacom DTI520UB/L pad                      id=13   [slave  pointer  (2)]
> ⎜   ↳ Wacom DTI520UB/L stylus                   id=15   [slave  pointer  (2)]
> ⎜   ↳ Wacom DTI520UB/L pad                      id=16   [slave  pointer  (2)]

>
> (as a side note, any idea why some things appear in this list twice?)

Once you update the capabilities in kernel driver to hide the unneeded
events per interface, the duplicates will go away here as well.

>
> [196927.474] (II) config/udev: Adding input device Wacom DTI520UB/L 
> (/dev/input/mouse2)
> [196927.474] (II) No input driver specified, ignoring this device.
> [196927.474] (II) This device may have been added with another device file.
> [196927.475] (II) config/udev: Adding input device Wacom DTI520UB/L 
> (/dev/input/mouse1)
> [196927.475] (II) No input driver specified, ignoring this device.
> [196927.475] (II) This device may have been added with another device file.
> [196927.477] (II) config/udev: Adding input device Wacom DTI520UB/L 
> (/dev/input/event13)
> [196927.477] (**) Wacom DTI520UB/L: Applying InputClass "Wacom class"
> [196927.477] (**) Wacom DTI520UB/L: Applying InputClass "evdev tablet 
> catchall"
> [196927.477] (**) Wacom DTI520UB/L: Applying InputClass "Wacom class"
> [196927.477] (II) Using input driver 'wacom' for 'Wacom DTI520UB/L'
> [196927.477] (II) Loading /usr/lib/xorg/modules/input/wacom_drv.so
> [196927.477] (**) Wacom DTI520UB/L: always reports core events
> [196927.477] (**) Option "Device" "/dev/input/event13"
> [196927.477] (II) Wacom DTI520UB/L: type not specified, assuming 'stylus'.
> [196927.477] (II) Wacom DTI520UB/L: other types will be automatically added.
> [196927.477] (--) Wacom DTI520UB/L stylus: using pressure threshold of 27 for 
> button 1
> [196927.477] (--) Wacom DTI520UB/L stylus: Wacom USB PL/Cintiq tablet 
> maxX=6282 maxY=4762 maxZ=511 resX=2 resY=2  tilt=disabled
> [196927.477] (II) Wacom DTI520UB/L stylus: hotplugging dependent devices.
> [196927.477] (EE) Wacom DTI520UB/L stylus: Invalid type 'eraser' for this 
> device.
> [196927.477] (EE) Wacom DTI520UB/L stylus: Invalid type 'cursor' for this 
> device.
> [196927.477] (EE) Wacom DTI520UB/L stylus: Invalid type 'touch' for this 
> device.
> [196927.477] (II) Wacom DTI520UB/L stylus: hotplugging completed.
> [196927.513] (**) Option "config_info" 
> "udev:/sys/devices/pci:00/:00:1a.7/usb1/1-6/1-6.4/1-6.4:1.0/input/input102/event13"
> [196927.513] (II) XINPUT: Adding extended input device "Wacom DTI520UB/L 
> stylus" (type: STYLUS, id 12)
> [196927.514] (**) Wacom DTI520UB/L stylus: (accel) keeping acceleration 
> scheme 1
> [196927.514] (**) Wacom DTI520UB/L stylus: (accel) acceleration profile 0
> [196927.514] (**) Wacom DTI520UB/L stylus: (accel) acceleration factor: 2.000
> [196927.514] (**) Wacom DTI520UB/L stylus: (accel) acceleration threshold: 4
> [196927.514] (**) Wacom DTI520UB/L pad: Applying InputClass "Wacom class"
> [196927.514] (**) Wacom DTI520UB/L pad: Applying InputClass "evdev tablet 
> catchall"
> [196927.514] (**) Wacom DTI520UB/L pad: Applying InputClass "Wacom class"
> [196927.514] (II) Using input driver 'wacom' for 'Wacom DTI520UB/L pad'
> [196927.514] (II) Loading /usr/lib/xorg/modules/input/wacom_drv.so
> [196927.514] (**) Wacom DTI520UB/L pad: always reports core events
> [196927.514] (**) Option "Device" "/dev/input/event13"
> [196927.514] (**) Option "Type" "pad"
> [196927.514] (--) Wacom DTI520UB/L pad: Wacom USB PL/Cintiq tablet maxX=6282 
> maxY=4762 maxZ=511 resX=2 resY=2  tilt=disabled
> [196927.550] (**) Option "config_info" 
> "udev:/sys/devices/pci:00/:00:1a.7/usb1/1-6/1-6.4/1-6.4:1.0/input/input102/event13"
> [196927.550] (II) XINPUT: Adding extended input device "Wacom DTI520UB/L pad" 
> (type: PAD, id 13)
> [196927.550] (**) Wacom DTI520UB/L pad: (accel) keeping acceleration scheme 1
> [196927.550] (**) Wacom DTI520UB/L pad: (accel) acceleration profile 0
> [196927.550] (**) Wacom DTI520UB/L pad: (accel) acceleration factor: 2.000
> [196927.550] (**) Wacom DTI520UB/L pad: (accel) acceleration threshold: 4
> [196927.551] (II) config/udev: Adding input device Wacom DTI520UB/L 
> (/dev/input/event14)
> [196927.551] (**) Wacom DTI520UB/L: Applying InputClass "Wacom

Re: [Linuxwacom-devel] Issues with DTI-520

2012-02-13 Thread Adam Nielsen 
> Its wacom_setup_input_capabilities() job [...]

Thanks for all the details, I'll take a look at it and post back with my 
progress.

> I think this is a record for how fast someone has gotten a new device
> with so many differences working!

Haha thanks!  Just goes to show what happens when there's someone telling you 
exactly what you need to know :-)  Unfortunately now the weekend is over so 
there probably won't be much movement until next weekend...

>> Unfortunately once I reached this point the X driver stopped working.  It
>> detects the device but "xinput test" doesn't report any output.  I'm a bit
>> stumped at this because I haven't changed anything in the X driver and the
>> events are all being reported correctly by the kernel.
>
> Can you send output from "xinput list" and snippet of your
> /var/log/Xorg.0.log were each wacom input is detected?  It woud also
> be helpful to see the initial output of evtest for your stylus device
> where it prints out the supported capabilities.

Ok, here's what it all looks like:

⎡ Virtual core pointer  id=2[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointerid=4[slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver id=10   [slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver id=11   [slave  pointer  (2)]
⎜   ↳ Wacom DTI520UB/L stylus   id=12   [slave  pointer  (2)]
⎜   ↳ Wacom DTI520UB/L pad  id=13   [slave  pointer  (2)]
⎜   ↳ Wacom DTI520UB/L stylus   id=15   [slave  pointer  (2)]
⎜   ↳ Wacom DTI520UB/L pad  id=16   [slave  pointer  (2)]
⎣ Virtual core keyboard id=3[master keyboard (2)]
↳ Virtual core XTEST keyboard   id=5[slave  keyboard (3)]
↳ Power Button  id=6[slave  keyboard (3)]
↳ Power Button  id=7[slave  keyboard (3)]
↳ G15 Gaming Keyboard   id=8[slave  keyboard (3)]
↳ G15 Gaming Keyboard   id=9[slave  keyboard (3)]
↳ G15 Extra Keysid=14   [slave  keyboard (3)]

(as a side note, any idea why some things appear in this list twice?)

[196927.474] (II) config/udev: Adding input device Wacom DTI520UB/L 
(/dev/input/mouse2)
[196927.474] (II) No input driver specified, ignoring this device.
[196927.474] (II) This device may have been added with another device file.
[196927.475] (II) config/udev: Adding input device Wacom DTI520UB/L 
(/dev/input/mouse1)
[196927.475] (II) No input driver specified, ignoring this device.
[196927.475] (II) This device may have been added with another device file.
[196927.477] (II) config/udev: Adding input device Wacom DTI520UB/L 
(/dev/input/event13)
[196927.477] (**) Wacom DTI520UB/L: Applying InputClass "Wacom class"
[196927.477] (**) Wacom DTI520UB/L: Applying InputClass "evdev tablet catchall"
[196927.477] (**) Wacom DTI520UB/L: Applying InputClass "Wacom class"
[196927.477] (II) Using input driver 'wacom' for 'Wacom DTI520UB/L'
[196927.477] (II) Loading /usr/lib/xorg/modules/input/wacom_drv.so
[196927.477] (**) Wacom DTI520UB/L: always reports core events
[196927.477] (**) Option "Device" "/dev/input/event13"
[196927.477] (II) Wacom DTI520UB/L: type not specified, assuming 'stylus'.
[196927.477] (II) Wacom DTI520UB/L: other types will be automatically added.
[196927.477] (--) Wacom DTI520UB/L stylus: using pressure threshold of 27 for 
button 1
[196927.477] (--) Wacom DTI520UB/L stylus: Wacom USB PL/Cintiq tablet maxX=6282 
maxY=4762 maxZ=511 resX=2 resY=2  tilt=disabled
[196927.477] (II) Wacom DTI520UB/L stylus: hotplugging dependent devices.
[196927.477] (EE) Wacom DTI520UB/L stylus: Invalid type 'eraser' for this 
device.
[196927.477] (EE) Wacom DTI520UB/L stylus: Invalid type 'cursor' for this 
device.
[196927.477] (EE) Wacom DTI520UB/L stylus: Invalid type 'touch' for this device.
[196927.477] (II) Wacom DTI520UB/L stylus: hotplugging completed.
[196927.513] (**) Option "config_info" 
"udev:/sys/devices/pci:00/:00:1a.7/usb1/1-6/1-6.4/1-6.4:1.0/input/input102/event13"
[196927.513] (II) XINPUT: Adding extended input device "Wacom DTI520UB/L 
stylus" (type: STYLUS, id 12)
[196927.514] (**) Wacom DTI520UB/L stylus: (accel) keeping acceleration scheme 1
[196927.514] (**) Wacom DTI520UB/L stylus: (accel) acceleration profile 0
[196927.514] (**) Wacom DTI520UB/L stylus: (accel) acceleration factor: 2.000
[196927.514] (**) Wacom DTI520UB/L stylus: (accel) acceleration threshold: 4
[196927.514] (**) Wacom DTI520UB/L pad: Applying InputClass "Wacom class"
[196927.514] (**) Wacom DTI520UB/L pad: Applying InputClass "evdev tablet 
catchall"
[196927.514] (**) Wacom DTI520UB/L pad: Applying InputClass "Wacom class"
[196927.514] (II) Using input driver 'wacom' for 'Wacom DTI520UB/L pad'
[196927.514] (II) Loading /usr/lib/xorg/modules/input/wacom_drv.so
[19

Re: [Linuxwacom-devel] Issues with DTI-520

2012-02-12 Thread Chris Bagwell 
On Sun, Feb 12, 2012 at 5:53 AM, Adam Nielsen  wrote:
> Well, I seem to have had some success!
>
>> Yes, that is all I mean.  Based on your later info, it means there
>> would be some code that looks like this:
>>
>> if (packet_size == 8&&  data[0] == 2)
>>   // Do pen processing
>> else if (packet_size == 6&&  data[0] == 4)
>>   // Do button processing.
>
>
> This worked quite well.  I do however get two identical devices appearing
> (both tablets with buttons) rather than one tablet and one set of buttons as
> I think would be more logical.  Not sure how to address this though.

Its wacom_setup_input_capabilities() job to declare and not declare
correct events for each interface.  Right now, all devices have an X/Y
so you'll have a new case of button only.

For temporary hack, I'd check for pktlen or interface # in that
function to hide what you need.  For other multi-interface cases, 1
interface is a stylus tablet and 1 interface is a touchpad so we 1st
set and then check device_type to see what events to hide.

We kinda need a new device type that says Pad-only.  Probably a fixed
value of 0 to mean !Pen and !Touch will be good enough for now.

>
>
>> Agree.  Looks like 8 it is.  When 1 USB device has 2 interfaces, each
>> interface can have a different packet length.  In Wacom driver, our
>> convention is to put the pen's packet length in the table your
>> modifying and then set at run time for the other interface.
>
>
> Is there an example of where this is set at runtime?  I used your example:
>
>
>>                if (intf->cur_altsetting->desc.bInterfaceNumber == 1) {
>
>
> And hacked it into wacom_sys.c which worked, but of course only on my PC
> with this one tablet.
>

Yes, check in wacom_parse_hid().  It looks for clues in HID report to
see what interface is and set both pktlen and device_type.  If it
finds no hints then it defaults to a pen device with what ever packet
size is set in structure.

I think this is first device I've seen with a "System Control" usage
so that could probably be used to detect the button interface and
override the pen/pktlen defaults.

>
 Thats all on stylus.  Sometimes they include extra info like max X/Y
 values and resolution but doesn't look like it in this report.  You'll
 have to figure those out at some point and fill them in structures.
>
>
> Done that, and it turns out they match exactly with the DTF521, which I
> guess isn't surprising for a model called DTI520.

:-)

>
>
>> Interesting.  Your USB hub works a little different then mine with
>> over specifying packet size to receive.  I think its related to
>> needing 2 button presses for buttons.
>
>
> Yes, it seems that it waits until the buffer is full before returning data.
> Once I figured out the correct buffer sizes everything became very
> responsive.
>
>>> 024008f5 002d
>>> aabb pppz
>>
>>
>> Ok.  You've got what looks like new packet format.
>
>
> Many thanks for all your pointers!  I have now successfully gotten the
> device to report all its events in evtest.  The X and Y coordinates work
> fine, pressure seems to work too, and all of the buttons work - both the
> stylus buttons and the pushbuttons on the display surface!
>

I think this is a record for how fast someone has gotten a new device
with so many differences working!

> Surprisingly the X and Y values (and also the pressure) are in big-endian
> order.  Suddenly all the weird results I was getting before make a lot more
> sense!
>
>  input_report_key(input, BTN_STYLUS, data[7] & 0x01);
>  input_report_key(input, BTN_STYLUS2, data[7] & 0x02);
>  input_report_abs(input, ABS_X, be16_to_cpup((__be16 *)&data[2]));
>  input_report_abs(input, ABS_Y, be16_to_cpup((__be16 *)&data[4]));
>  pressure = (data[6] << 1) | ((data[7] & 0x80) >> 7);
>  if (pressure < 0)
>    pressure = features->pressure_max + pressure + 1;
>  input_report_abs(input, ABS_PRESSURE, pressure);
>
> Unfortunately once I reached this point the X driver stopped working.  It
> detects the device but "xinput test" doesn't report any output.  I'm a bit
> stumped at this because I haven't changed anything in the X driver and the
> events are all being reported correctly by the kernel.
>
> Looking at the X output, it looks like it is reading the tablet interface as
> a "pad" (only looking for the buttons and there aren't any here) and reading
> the other interface as a tablet (where there is no tablet, only buttons.)  I
> can't see where this is set - any hints?  Maybe I need to better separate
> the two devices, and not report a button/tablet when there isn't one.
>

Can you send output from "xinput list" and snippet of your
/var/log/Xorg.0.log were each wacom input is detected?  It woud also
be helpful to see the initial output of evtest for your stylus device
where it prints out the supported capabilities.

>
 This says the 1st 5 bits in packet map to buttons and have on/off single
 values.

 Above has values between 6 and 10 so are more tha

Re: [Linuxwacom-devel] Issues with DTI-520

2012-02-12 Thread Adam Nielsen 
Well, I seem to have had some success!

> Yes, that is all I mean.  Based on your later info, it means there
> would be some code that looks like this:
>
> if (packet_size == 8&&  data[0] == 2)
>// Do pen processing
> else if (packet_size == 6&&  data[0] == 4)
>// Do button processing.

This worked quite well.  I do however get two identical devices appearing 
(both tablets with buttons) rather than one tablet and one set of buttons as I 
think would be more logical.  Not sure how to address this though.

> Agree.  Looks like 8 it is.  When 1 USB device has 2 interfaces, each
> interface can have a different packet length.  In Wacom driver, our
> convention is to put the pen's packet length in the table your
> modifying and then set at run time for the other interface.

Is there an example of where this is set at runtime?  I used your example:

> if (intf->cur_altsetting->desc.bInterfaceNumber == 1) {

And hacked it into wacom_sys.c which worked, but of course only on my PC with 
this one tablet.

>>> Thats all on stylus.  Sometimes they include extra info like max X/Y
>>> values and resolution but doesn't look like it in this report.  You'll
>>> have to figure those out at some point and fill them in structures.

Done that, and it turns out they match exactly with the DTF521, which I guess 
isn't surprising for a model called DTI520.

> Interesting.  Your USB hub works a little different then mine with
> over specifying packet size to receive.  I think its related to
> needing 2 button presses for buttons.

Yes, it seems that it waits until the buffer is full before returning data. 
Once I figured out the correct buffer sizes everything became very responsive.

>> 024008f5 002d
>> aabb pppz
>
> Ok.  You've got what looks like new packet format.

Many thanks for all your pointers!  I have now successfully gotten the device 
to report all its events in evtest.  The X and Y coordinates work fine, 
pressure seems to work too, and all of the buttons work - both the stylus 
buttons and the pushbuttons on the display surface!

Surprisingly the X and Y values (and also the pressure) are in big-endian 
order.  Suddenly all the weird results I was getting before make a lot more 
sense!

   input_report_key(input, BTN_STYLUS, data[7] & 0x01);
   input_report_key(input, BTN_STYLUS2, data[7] & 0x02);
   input_report_abs(input, ABS_X, be16_to_cpup((__be16 *)&data[2]));
   input_report_abs(input, ABS_Y, be16_to_cpup((__be16 *)&data[4]));
   pressure = (data[6] << 1) | ((data[7] & 0x80) >> 7);
   if (pressure < 0)
 pressure = features->pressure_max + pressure + 1;
   input_report_abs(input, ABS_PRESSURE, pressure);

Unfortunately once I reached this point the X driver stopped working.  It 
detects the device but "xinput test" doesn't report any output.  I'm a bit 
stumped at this because I haven't changed anything in the X driver and the 
events are all being reported correctly by the kernel.

Looking at the X output, it looks like it is reading the tablet interface as a 
"pad" (only looking for the buttons and there aren't any here) and reading the 
other interface as a tablet (where there is no tablet, only buttons.)  I can't 
see where this is set - any hints?  Maybe I need to better separate the two 
devices, and not report a button/tablet when there isn't one.

>>> This says the 1st 5 bits in packet map to buttons and have on/off single
>>> values.
>>>
>>> Above has values between 6 and 10 so are more than 1 bit.  Not sure
>>> what it is but there are 3 of them.  And then 5 of something else and
>>> 3 of another thing follows.

Not sure how that ends up applying to the data the device sends via USB:

if (data[0] == 0x04) {
   input_report_key(input, BTN_BACK,data[1] & 0x01); /* up */
   input_report_key(input, BTN_FORWARD, data[1] & 0x02); /* down */
   input_report_key(input, BTN_LEFT,data[1] & 0x04);
   input_report_key(input, BTN_RIGHT,   data[1] & 0x08);
   input_report_key(input, BTN_EXTRA,   data[1] & 0x10); /* both Ctrls */

   input_report_key(input, BTN_0,   data[2] & 0x02);
   input_report_key(input, BTN_1,   data[2] & 0x04);
   input_report_key(input, BTN_2,   data[2] & 0x01);
   input_report_key(input, BTN_3,   data[2] & 0x08);
   input_report_key(input, BTN_4,   data[2] & 0x10);

   return 1;
}

> Yep.  And feel free to keep asking question.  Hopefully we can get a
> working driver out of this.

Thanks again for your assistance with this.  It looks like I'm getting close 
to a working driver!

Cheers,
Adam.


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

Re: [Linuxwacom-devel] Issues with DTI-520

2012-02-11 Thread Chris Bagwell 
On Sat, Feb 11, 2012 at 8:42 PM, Adam Nielsen  wrote:
>> For the buttons, none of the wacom drivers currently support anything
>> quite like this.  I see in the USB report that the device has 2
>> interfaces.  Normally, we only see this on touchscreens where the
>> second interface reports touch events.
>>
>> In your case, the second interface seems to define those buttons.  I
>> see a set of 5 buttons clearly labeled and then some more bits that
>> aren't obvious how to decode.
>>
>> You'd have to write a custom decoder for those if you want to process
>> them.  In mean time, we may or may not need to detect that interface
>> and disable it (if it crashes for example).
>
>
> When you say 'custom decoder' does that mean just figuring out the protocol,
> and using existing code for reporting button presses?  Or will it require
> adding support for buttons from scratch?

Yes, that is all I mean.  Based on your later info, it means there
would be some code that looks like this:

if (packet_size == 8 && data[0] == 2)
  // Do pen processing
else if (packet_size == 6 && data[0] == 4)
  // Do button processing.

Thats all. Not to bad, coding wise.

>
>
>> This says the packet size is 7 8-bit bytes.  That maps to
>> WACOM_PKGLEN_PENPRTN.  I've seen occasionally where they do not
>> include in this count the 1st byte in packet which is ID.  So the
>> packet len could either be 7 or 8.  I'd try 8 first which maps to
>> WACOM_PKGLEN_GRAPHIRE.
>
>
> As per below, it looks like this is 8.

Agree.  Looks like 8 it is.  When 1 USB device has 2 interfaces, each
interface can have a different packet length.  In Wacom driver, our
convention is to put the pen's packet length in the table your
modifying and then set at run time for the other interface.

>
>
>> Thats all on stylus.  Sometimes they include extra info like max X/Y
>> values and resolution but doesn't look like it in this report.  You'll
>> have to figure those out at some point and fill them in structures.
>
>
> That's fine.  Am I looking at e.g. usbmon to find out the maximum value or
> xinput output, evtest, or somewhere else?

evtest is my preferred for max X/Y.  Just need to draw at borders of
screen and see max values reported.  Resolution is manually computed
based on screen size to max X/Y... but in kernel its stored in metric
and screen size is often in inches so you'll need to convert.
Usually, its some round number like 100 to help you know when you got
it right.

>
>
>> Its kinda a max packet length.  With most peoples USB hubs, its OK to
>> leave it large.  Some USB hubs will return an error if a packet is
>> received with less bytes then requested and on those machines you have
>> to get this value exactly right.
>
>
> Ah, that explains a few things from other USB tinkering I've done...  The
> behaviour hasn't changed with a packet length of 32, so looks like that's
> ok.
>
>
>> All the stylus formats are usually pretty similar but it takes just 1
>> bit in a different location and it will act totally strange.
>
>
> That probably explains the wrapping around of the Y coordinate with PL and
> PTU then.
>
>
 Since PL and PTU didn't work for you, I'd move to some of the other
 similar HW types (screens with digitizers).  Cintiq's are most popular
 and possible values for those are WACOM_24HD, CINTIQ, WACOM_BEE, and
 WACOM_21UX2.
>
>
> Is WACOM_24HD new?  It's not in the code I have.  Otherwise here are my
> results:

Yes, very new.  It will be in Linux 3.3 I think.

>
> CINTIQ: X crash
> WACOM_BEE: X crash
> WACOM_21UX2: no events, long time to load module, errors about no device
> 'pad'
> DTU: no events
>
>
>>> I didn't try DTU because in wacom_setup_input_capabilities() in the
>>> kernel
>>> driver it seems to be handled the same as PL.  Is it treated differently
>>> elsewhere?
>>
>>
>> Yes, there is a wacom_dtu_irq() and the stylus bits are every so
>> slightly different.
>
>
> Ah, will have to look at that.  At any rate PTU definitely works better than
> DTU.
>
>
 And the last option to try is Tablet PC driver.  They use TABLETPC.
>
>
> No luck - no events returned.
>
>
 If no luck with any of those, we'd have to start logging some USB
 packets (using kernels /sys/kernel/debug/usb/usbmon interface) and see
 if we can't figure out the packet format and add a new DTI driver.
>
>
> Here is some usbmon output for the device:
>
> C Ii:025:01 0 32 = 0240177a 0cee 02401780 0ce6 02401784 0ce7
> 02401789 0ce3
> S Ii:025:01 -115 32 <
>
> If the data is in bytes, then it seems to be eight bytes repeated up to the
> 32-byte buffer length.  If I change the buffer length back to 8 I seem to
> get a bunch of clean events:
>
> 880229ce40c0 304567392 C Ii:025:01 0 8 = 024008f5 002d
> 880229ce40c0 304567405 S Ii:025:01 -115 8 <

Interesting.  Your USB hub works a little different then mine with
over specifying packet size to receive.  I think its related to
needing 2 button presses for buttons.

>
> Taking

Re: [Linuxwacom-devel] Issues with DTI-520

2012-02-11 Thread Adam Nielsen 
> For the buttons, none of the wacom drivers currently support anything
> quite like this.  I see in the USB report that the device has 2
> interfaces.  Normally, we only see this on touchscreens where the
> second interface reports touch events.
>
> In your case, the second interface seems to define those buttons.  I
> see a set of 5 buttons clearly labeled and then some more bits that
> aren't obvious how to decode.
>
> You'd have to write a custom decoder for those if you want to process
> them.  In mean time, we may or may not need to detect that interface
> and disable it (if it crashes for example).

When you say 'custom decoder' does that mean just figuring out the protocol, 
and using existing code for reporting button presses?  Or will it require 
adding support for buttons from scratch?

> This says the packet size is 7 8-bit bytes.  That maps to
> WACOM_PKGLEN_PENPRTN.  I've seen occasionally where they do not
> include in this count the 1st byte in packet which is ID.  So the
> packet len could either be 7 or 8.  I'd try 8 first which maps to
> WACOM_PKGLEN_GRAPHIRE.

As per below, it looks like this is 8.

> Thats all on stylus.  Sometimes they include extra info like max X/Y
> values and resolution but doesn't look like it in this report.  You'll
> have to figure those out at some point and fill them in structures.

That's fine.  Am I looking at e.g. usbmon to find out the maximum value or 
xinput output, evtest, or somewhere else?

> Its kinda a max packet length.  With most peoples USB hubs, its OK to
> leave it large.  Some USB hubs will return an error if a packet is
> received with less bytes then requested and on those machines you have
> to get this value exactly right.

Ah, that explains a few things from other USB tinkering I've done...  The 
behaviour hasn't changed with a packet length of 32, so looks like that's ok.

> All the stylus formats are usually pretty similar but it takes just 1
> bit in a different location and it will act totally strange.

That probably explains the wrapping around of the Y coordinate with PL and PTU 
then.

>>> Since PL and PTU didn't work for you, I'd move to some of the other
>>> similar HW types (screens with digitizers).  Cintiq's are most popular
>>> and possible values for those are WACOM_24HD, CINTIQ, WACOM_BEE, and
>>> WACOM_21UX2.

Is WACOM_24HD new?  It's not in the code I have.  Otherwise here are my results:

CINTIQ: X crash
WACOM_BEE: X crash
WACOM_21UX2: no events, long time to load module, errors about no device 'pad'
DTU: no events

>> I didn't try DTU because in wacom_setup_input_capabilities() in the kernel
>> driver it seems to be handled the same as PL.  Is it treated differently
>> elsewhere?
>
> Yes, there is a wacom_dtu_irq() and the stylus bits are every so
> slightly different.

Ah, will have to look at that.  At any rate PTU definitely works better than 
DTU.

>>> And the last option to try is Tablet PC driver.  They use TABLETPC.

No luck - no events returned.

>>> If no luck with any of those, we'd have to start logging some USB
>>> packets (using kernels /sys/kernel/debug/usb/usbmon interface) and see
>>> if we can't figure out the packet format and add a new DTI driver.

Here is some usbmon output for the device:

C Ii:025:01 0 32 = 0240177a 0cee 02401780 0ce6 02401784 0ce7 
02401789 0ce3
S Ii:025:01 -115 32 <

If the data is in bytes, then it seems to be eight bytes repeated up to the 
32-byte buffer length.  If I change the buffer length back to 8 I seem to get 
a bunch of clean events:

880229ce40c0 304567392 C Ii:025:01 0 8 = 024008f5 002d
880229ce40c0 304567405 S Ii:025:01 -115 8 <

Taking just the data and examining it:

024008f5 002d
aabb pppz

x and y are absolute coordinates, p is pressure (0 to ff80).  It looks like 
this is only a 9-bit number.  z is 0 normally, and 1 or 2 if the primary or 
secondary stylus button is pressed.  z is 15-bits long but I can't see what 
the other bits are used for - maybe other tools?

a always seems to be 02 and bb is either 00 when the stylus goes out of range, 
40 when the stylus is at the edge of the screen (outside the LCD part) and c0 
when the stylus is over the LCD part.

Going back to the buttons:

> This says the 1st 5 bits in packet map to buttons and have on/off single
> values.
>
> Above has values between 6 and 10 so are more than 1 bit.  Not sure
> what it is but there are 3 of them.  And then 5 of something else and
> 3 of another thing follows.

Pressing each of the top five buttons, left to right, gives this:

C Ii:025:02 -75 6 = 04000204 
S Ii:025:02 -115 8 <
C Ii:025:02 -75 6 = 04000404 
S Ii:025:02 -115 8 <
C Ii:025:02 -75 6 = 04000104 
S Ii:025:02 -115 8 <
C Ii:025:02 -75 6 = 04000804 
S Ii:025:02 -115 8 <
C Ii:025:02 -75 6 = 04001004 

The weird part is that the buttons have to be pressed twice.  The first button 
press controls which code will be sent as above, but it's not until the second 
button

Re: [Linuxwacom-devel] Issues with DTI-520

2012-02-11 Thread Chris Bagwell 
On Sat, Feb 11, 2012 at 6:23 PM, Adam Nielsen  wrote:
> Hi Chris,
>
> Thanks for the quick response!
>
>
>> Hi, I googled this model and I see its a stand alone screen with built
>> in Wacom digitizer.
>
>
> Yes that's correct.  For the record, it also has a built in USB hub which
> works fine:
>
> Bus 001 Device 021: ID 056a:003b Wacom Co., Ltd
> Device Descriptor:
>  ...
>  bDeviceClass            9 Hub
>  bDeviceSubClass         0 Unused
>  bDeviceProtocol         1 Single TT
>  bMaxPacketSize0        64
>  idVendor           0x056a Wacom Co., Ltd
>  idProduct          0x003b
>  bcdDevice            7.02
>  iManufacturer          10 WACOM
>  iProduct               11 DTI-520 HUB
>  ...
>
> The device also has a number of pushbuttons on its face - five unlabelled
> ones across the top (with a space to insert your own paper label), and six
> along the bottom (L, R, up, down, and two Ctrl.  One Ctrl suggests it shifts
> the up/down keys into zoom in/out.)

Interesting.  I've never heard they did USB hubs before.

For the buttons, none of the wacom drivers currently support anything
quite like this.  I see in the USB report that the device has 2
interfaces.  Normally, we only see this on touchscreens where the
second interface reports touch events.

In your case, the second interface seems to define those buttons.  I
see a set of 5 buttons clearly labeled and then some more bits that
aren't obvious how to decode.

You'd have to write a custom decoder for those if you want to process
them.  In mean time, we may or may not need to detect that interface
and disable it (if it crashes for example).


>
> Here is the output:
>
> Bus 001 Device 022: ID 056a:003a Wacom Co., Ltd
> Device Descriptor:

...

This first section defines a mouse device.  Its default behaviour or
Wacom devices.  If it wasn't for the fact that all Wacom devices are
blacklisted from the hid-core, this screen would most likely already
be working but as an odd mouse (relative mode).

>      iInterface              0
>        HID Device Descriptor:
>          bLength                 9
>          bDescriptorType        33
>          bcdHID               1.10
>          bCountryCode            0 Not supported
>          bNumDescriptors         1
>          bDescriptorType        34 Report
>          wDescriptorLength     110
>          Report Descriptor: (length is 110)
>            Item(Global): Usage Page, data= [ 0x01 ] 1
>                            Generic Desktop Controls
>            Item(Local ): Usage, data= [ 0x02 ] 2
>                            Mouse
>            Item(Main  ): Collection, data= [ 0x01 ] 1
>                            Application
>            Item(Global): Report ID, data= [ 0x01 ] 1
>            Item(Local ): Usage, data= [ 0x01 ] 1
>                            Pointer
>            Item(Main  ): Collection, data= [ 0x00 ] 0
>                            Physical
>            Item(Global): Usage Page, data= [ 0x09 ] 9
>                            Buttons
>            Item(Local ): Usage Minimum, data= [ 0x01 ] 1
>                            Button 1 (Primary)
>            Item(Local ): Usage Maximum, data= [ 0x03 ] 3
>                            Button 3 (Tertiary)
>            Item(Global): Logical Minimum, data= [ 0x00 ] 0
>            Item(Global): Logical Maximum, data= [ 0x01 ] 1
>            Item(Global): Report Count, data= [ 0x03 ] 3
>            Item(Global): Report Size, data= [ 0x01 ] 1
>            Item(Main  ): Input, data= [ 0x02 ] 2
>                            Data Variable Absolute No_Wrap Linear
>                            Preferred_State No_Null_Position Non_Volatile
> Bitfield
>            Item(Global): Report Count, data= [ 0x05 ] 5
>            Item(Main  ): Input, data= [ 0x03 ] 3
>                            Constant Variable Absolute No_Wrap Linear
>                            Preferred_State No_Null_Position Non_Volatile
> Bitfield
>            Item(Global): Usage Page, data= [ 0x01 ] 1
>                            Generic Desktop Controls
>            Item(Local ): Usage, data= [ 0x30 ] 48
>                            Direction-X
>            Item(Local ): Usage, data= [ 0x31 ] 49
>                            Direction-Y
>            Item(Global): Logical Minimum, data= [ 0x81 ] 129
>            Item(Global): Logical Maximum, data= [ 0x7f ] 127
>            Item(Global): Report Size, data= [ 0x08 ] 8
>            Item(Global): Report Count, data= [ 0x02 ] 2
>            Item(Main  ): Input, data= [ 0x06 ] 6
>                            Data Variable Relative No_Wrap Linear
>                            Preferred_State No_Null_Position Non_Volatile
> Bitfield
>            Item(Main  ): End Collection, data=none
>            Item(Main  ): End Collection, data=none

This second defines the report id #2 that contains pen data:

>            Item(Global): Usage Page, data= [ 0x0d ] 13
>                            Digitizer
>            Item(Local ): Usage, data= [ 0x01 ] 1
>                        

Re: [Linuxwacom-devel] Issues with DTI-520

2012-02-11 Thread Adam Nielsen 
Hi Chris,

Thanks for the quick response!

> Hi, I googled this model and I see its a stand alone screen with built
> in Wacom digitizer.

Yes that's correct.  For the record, it also has a built in USB hub which 
works fine:

Bus 001 Device 021: ID 056a:003b Wacom Co., Ltd
Device Descriptor:
   ...
   bDeviceClass9 Hub
   bDeviceSubClass 0 Unused
   bDeviceProtocol 1 Single TT
   bMaxPacketSize064
   idVendor   0x056a Wacom Co., Ltd
   idProduct  0x003b
   bcdDevice7.02
   iManufacturer  10 WACOM
   iProduct   11 DTI-520 HUB
   ...

The device also has a number of pushbuttons on its face - five unlabelled ones 
across the top (with a space to insert your own paper label), and six along 
the bottom (L, R, up, down, and two Ctrl.  One Ctrl suggests it shifts the 
up/down keys into zoom in/out.)

> I'm guessing you chose those initial values because there is a 0x39
> already defined and modelled after it?  In general, that is a good
> approach.  Wacom does tend to group related HW with similar product
> ID's.

Yes that's what I was hoping!

> rmmod wacom
> lsusb -vvv

Here is the output:

Bus 001 Device 022: ID 056a:003a Wacom Co., Ltd
Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   1.10
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize0 8
   idVendor   0x056a Wacom Co., Ltd
   idProduct  0x003a
   bcdDevice1.03
   iManufacturer   1 WACOM
   iProduct2 DTI-520-U
   iSerial 0
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength   59
 bNumInterfaces  2
 bConfigurationValue 1
 iConfiguration  0
 bmAttributes 0xe0
   Self Powered
   Remote Wakeup
 MaxPower0mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber0
   bAlternateSetting   0
   bNumEndpoints   1
   bInterfaceClass 3 Human Interface Device
   bInterfaceSubClass  1 Boot Interface Subclass
   bInterfaceProtocol  2 Mouse
   iInterface  0
 HID Device Descriptor:
   bLength 9
   bDescriptorType33
   bcdHID   1.10
   bCountryCode0 Not supported
   bNumDescriptors 1
   bDescriptorType34 Report
   wDescriptorLength 110
   Report Descriptor: (length is 110)
 Item(Global): Usage Page, data= [ 0x01 ] 1
 Generic Desktop Controls
 Item(Local ): Usage, data= [ 0x02 ] 2
 Mouse
 Item(Main  ): Collection, data= [ 0x01 ] 1
 Application
 Item(Global): Report ID, data= [ 0x01 ] 1
 Item(Local ): Usage, data= [ 0x01 ] 1
 Pointer
 Item(Main  ): Collection, data= [ 0x00 ] 0
 Physical
 Item(Global): Usage Page, data= [ 0x09 ] 9
 Buttons
 Item(Local ): Usage Minimum, data= [ 0x01 ] 1
 Button 1 (Primary)
 Item(Local ): Usage Maximum, data= [ 0x03 ] 3
 Button 3 (Tertiary)
 Item(Global): Logical Minimum, data= [ 0x00 ] 0
 Item(Global): Logical Maximum, data= [ 0x01 ] 1
 Item(Global): Report Count, data= [ 0x03 ] 3
 Item(Global): Report Size, data= [ 0x01 ] 1
 Item(Main  ): Input, data= [ 0x02 ] 2
 Data Variable Absolute No_Wrap Linear
 Preferred_State No_Null_Position Non_Volatile 
Bitfield
 Item(Global): Report Count, data= [ 0x05 ] 5
 Item(Main  ): Input, data= [ 0x03 ] 3
 Constant Variable Absolute No_Wrap Linear
 Preferred_State No_Null_Position Non_Volatile 
Bitfield
 Item(Global): Usage Page, data= [ 0x01 ] 1
 Generic Desktop Controls
 Item(Local ): Usage, data= [ 0x30 ] 48
 Direction-X
 Item(Local ): Usage, data= [ 0x31 ] 49
 Direction-Y
 Item(Global): Logical Minimum, data= [ 0x81 ] 129
 Item(Global): Logical Maximum, data= [ 0x7f ] 127
 Item(Global): Report Size, data= [ 0x08 ] 8
 Item(Global): Report Count, data= [ 0x02 ] 2
 Item(Main  ): Input, data= [ 0x06 ] 6
 Data Variable Relative No_Wrap Linear

Re: [Linuxwacom-devel] Issues with DTI-520

2012-02-11 Thread Chris Bagwell 
On Sat, Feb 11, 2012 at 2:21 AM, Adam Nielsen  wrote:
> Hi all,
>
> I recently got hold of a second-hand DTI-520 and I'd like to get it working
> under Linux.  It seems it is not yet supported, so I am trying to add support
> for it.
>

>
> Some of the code I added to the kernel module is:
>
> static const struct wacom_features wacom_features_0x3A =
>   { "Wacom DTI520UB/L",     WACOM_PKGLEN_GRAPHIRE,   3250, 65600,  2047,
>     0, PL, WACOM_PL_RES, WACOM_PL_RES };
>

Hi, I googled this model and I see its a stand alone screen with built
in Wacom digitizer.

I'm guessing you chose those initial values because there is a 0x39
already defined and modelled after it?  In general, that is a good
approach.  Wacom does tend to group related HW with similar product
ID's.

Here are some additional things you can try:

Run the following commands as root:

rmmod wacom
lsusb -vvv

Find the snippet related to Wacom and send it to list.  In that output
will often be information on packet sizes.  We can use this
information to know what value to set for WACOM_PKGLEN_* without
guessing.  Worst case, set that field to 32 for right now and move to
next step.

The part that has "PL" above is what tells packet format and there are
lots of different packet formats.  Hopefully, this is not a totally
new format.

Since PL and PTU didn't work for you, I'd move to some of the other
similar HW types (screens with digitizers).  Cintiq's are most popular
and possible values for those are WACOM_24HD, CINTIQ, WACOM_BEE, and
WACOM_21UX2.

Probably, your screen is closer to the DTU-* and DTF-* models that are
already supported.  DTU and PTU are valid values for it so I'd
probably try DTU next.

And the last option to try is Tablet PC driver.  They use TABLETPC.

If no luck with any of those, we'd have to start logging some USB
packets (using kernels /sys/kernel/debug/usb/usbmon interface) and see
if we can't figure out the packet format and add a new DTI driver.

Chris

--
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] Issues with DTI-520

2012-02-11 Thread Adam Nielsen 
Hi all,

I recently got hold of a second-hand DTI-520 and I'd like to get it working 
under Linux.  It seems it is not yet supported, so I am trying to add support 
for it.

After adding in USB IDs to the kernel driver and the X11 module it starts 
returning data when I move the stylus around.  The X-coordinates seem fine (0 
to 3208) but for some reason the Y coordinate seems to wrap around as I move 
down the screen.  I'm not sure what's causing this - here is some sample 
output from 'xinput test' as I move the stylus about a third of the way down 
the screen:

motion a[0]=770 a[1]=63458 a[2]=0 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=63874 a[2]=0 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=64322 a[2]=0 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=64770 a[2]=0 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=48834 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=32898 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=16931 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=932 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=1351 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=1801 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=2283 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=2829 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=3406 a[2]=4 a[3]=0 a[4]=0 a[5]=-900

Some of the code I added to the kernel module is:

static const struct wacom_features wacom_features_0x3A =
   { "Wacom DTI520UB/L", WACOM_PKGLEN_GRAPHIRE,   3250, 65600,  2047,
 0, PL, WACOM_PL_RES, WACOM_PL_RES };

This gives me these messages in the Xorg output:

[ 15979.601] [dix] Unknown event type 35. No filter
[ 15979.601] [dix] Unknown event type 35. No filter
[ 15983.121] [dix] Unknown event type 35. No filter
[ 15983.121] [dix] Unknown event type 35. No filter

Two messages each time I touch and remove the stylus from the surface. 
Changing the "PL" type in the above code to "PTU" returns a button press and 
button release event instead, as the stylus touches and leaves the surface. 
I'm guessing this means the PTU type is probably more correct than PL.  I also 
seem to get pressure values coming in with the PTU type as well (in xinput's 
a[2] value), although they seem a bit weird (the values are all < 256 but with 
spatterings of 2048 among them, except it stays at 2048 if I press the stylus 
fairly hard.)

Unfortunately I'm just poking around in the dark here, so I'm not really sure 
where to go next.  Does anyone know how I can proceed with figuring out how to 
get this device working properly?

Many thanks,
Adam.

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