On Sun, Feb 12, 2012 at 5:53 AM, Adam Nielsen <a.niel...@shikadi.net> 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 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!
>
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 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;
>
> }
>
Oh, I see now. HID report was declaring buttons 1-5 using 5 bits
followed by 3 trash bits then buttons 6-10 using more 5 bits and 3
more trash bits. The statefullness of HID reports can be very
confusing.
>> 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
