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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
