On Sat, Feb 11, 2012 at 8:42 PM, Adam Nielsen <a.niel...@shikadi.net> 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 0cee0000 02401780 0ce60000 02401784 0ce70000
> 02401789 0ce30000
> 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:
>
> ffff880229ce40c0 304567392 C Ii:025:01 0 8 = 024008f5 002d0000
> ffff880229ce40c0 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 just the data and examining it:
>
> 024008f5 002d0000
> aabbxxxx yyyypppz
>
> 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.
Ok. You've got what looks like new packet format. Its similar to a
lot of others but putting stylus button presses in z is a first;
usually those are in your bb. You'll need to add a new WACOM_BTI or
similar ID in wacom_wac.h and write custom packet parser to handle
this different. Since PTU is working closest, you can copy&paste its
behaviour. If possible, I'd try to start with TABLETPC2FG because
they have basically same packet format for pen but also have 2 input
interfaces which is closer to yours (be warned though in
wacom_query_tablet_data(), there is a TABLETPC2FG check and your HW
needs to do the else() block. Its required to turn off MOUSE mode.).
I think TABLETPC2FG would work for you if you change following line in
wacom_tpc_pen():
bool prox = data[1] & 0x20;
to
bool prox = data[1] & 0x80;
Bits 0x80 and 0x40 seem to be related to how close proximity you are.
Other than that, I think rest function aligns to PTU.
>
> 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 0000
> S Ii:025:02 -115 8 <
> C Ii:025:02 -75 6 = 04000404 0000
> S Ii:025:02 -115 8 <
> C Ii:025:02 -75 6 = 04000104 0000
> S Ii:025:02 -115 8 <
> C Ii:025:02 -75 6 = 04000804 0000
> S Ii:025:02 -115 8 <
> C Ii:025:02 -75 6 = 04001004 0000
>
> 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 press (of any button) that the USB data arrives.
I'm guessing its related to your USB hardware to receive 8 bytes
instead of 6. What we do for 2 interfaces with different packet
lengths is set features->pktlen at run time for the second interface.
None of the current code will work easily for you, I think. In
wacom_probe(), you can use this if() to detect its the 2nd interface
and hardcode packet size to only 6 (for now... now sure clean way to
do this):
if (intf->cur_altsetting->desc.bInterfaceNumber == 1) {
>
> The other buttons are:
>
> 04100004 0000 # Left Ctrl (the 'zoom' modifier)
> 04040004 0000 # L
> 04010004 0000 # Up (zoom in)
> 04020004 0000 # Down (zoom out)
> 04080004 0000 # R
> 04100004 0000 # Right Ctrl
>
> Actually now I think I have to change the buffer length to six to get this
> to work - I pressed a couple of buttons at the same time and the values
> moved to the end of those fields...I think the second 04 in byte 3 is the
> start of the next event. I'm not sure how to set the digitizer events to be
> eight bytes but the buttons to be only six.
>
> At any rate, it looks like those second button codes take up five bits, so I
> guess they're the first ones you mentioned.
>
>
>> Good luck. Hope you find one thats same. Its always much easier than
>> writing yet another packet parsing routing.
>
>
> Are you familiar enough with the protocols to know whether this is similar
> to any others?
Yep. And feel free to keep asking question. Hopefully we can get a
working driver out of this.
>
> Thanks again,
> 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
