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