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 002d0000 >> aabbxxxx yyyypppz > > 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 https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel