Sorry, I don't know how to edit the original post (an accidental shoot) to complete it.
Xorg wacom driver is loaded (correctly, I suppose) and Xinput seems happy about it (see attached logs)
But no event is generated and xinput test is totally void.
I attach the complete journal of the operations (boot, disconnect and reconnect) and a wireshark trace starting at the last device insertion and including some random pen activities.
Apologies for the delay in responding. Could you please try using the evemu-record tool to capture the kernel events sent from this device? The package containing that program varies, but may be called "evemu-utils".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dont't warry and thank you for finding the time to analyze the case.
Sure I can run evemu-record, but not immediately as the board is in a school. Please be patient, I'll send you the report ASAP.
Do you want a parallel whireshark/evemu trace?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If possible, instead of getting a parallel trace from Wireshark, a parallel trace from hid-recorder (see https://bentiss.github.io/hid-replay-docs/) would be more valuable. That is, assuming the Waltop kernel driver uses HID (if you don't see the Waltop device as an option when using hid-recorder, probably not).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally succeeded in collecting the requested reports
The strange thing (in my ignorance) is that evemu doesen't receive any event.
Hid, at the contrary, gets everything.
I made a rectangular trace around the board and a cross in the middle.
Tell me if I could help in any way
Thanks for the output -- it definitely clears things up. It looks like the device has an incorrect HID descriptor. This prevents the "hid-generic" kernel driver from interpreting the data, which is why evemu-record didn't log any events.
Since your tablet doesn't use the "wacom" kernel driver, its not something we can fix. You'll want to contact the Digimend project at https://digimend.github.io/ which produces a driver that works around these incorrect descriptors. It doesn't look like they support this particular device yet, so you'll want to provide a copy of the "evemu" and "hid" files you attached above so they can see exactly what's wrong with the descriptor.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK thank you
Just a last question to let me go further. Can you please explain what's wrong in the hid descriptor (or how can I find this answer by myself), and why the wacom driver is anyway loaded (who fools it)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure, no problem :) I've included a translation of the HID descriptor at the bottom of this reply.
The data captured in the "hid" log indicates that reports with ID 2 were being sent by the hardware. Looking at the descriptor, report ID 2 can described in basic terms as "a fixed one-byte header of 0x02, then seven 8-bit fields of unknown data, and finally two 8-bit fields that contain altitude and azimuth." Not only is the "unknown data" completely unhelpful to the kernel driver, but the descriptor says to expect 10 bytes of data but the "hid" log shows that only 8 bytes of data are actually being sent by the hardware.
Looking at the other reports described, report ID 16 is fully-described and only 8 bytes long, but it doesn't look like it describes the data that was logged. In particular, the highest three bits of the first byte are supposed to be constant, but that's not the case. Also, the lowest bit of the first byte aren't likely to be the tip switch since it changes state far too often in the logged data.
As for why our X11 driver is being loaded, that's because our driver recognizes that your device is a tablet (more specifically, our X11 driver will bind to any device with "WALTOP" in the name). This descriptor issue isn't something we can fix in the X11 driver, however -- its a problem that has to be fixed in the kernel. We do maintain the "wacom" kernel driver for Wacom tablets, but its the Digimend project that maintains the kernel driver for non-Wacom tablets. They're more experienced in understanding how to decode the hardware data from non-Wacom hardware. Once their kernel driver is updated to support this device, our X11 driver should be able to work properly.
I really thank you very much!
A good explanation is much better then hours spent snorkeling through the code or the RFCs
I contacted Digimend, but I also want to try by myself (I developed several kernel drivers but none in the hid zone)
Thank you again
Claudio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Best of luck. I'd recommend installing "hidrd" if you're going to try making edits to the descriptor yourself. Its able to convert the binary to a few different human-readable formats, and is even able to do the reverse trick if you use its "xml" format for editing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I don't know how to edit the original post (an accidental shoot) to complete it.
Xorg wacom driver is loaded (correctly, I suppose) and Xinput seems happy about it (see attached logs)
But no event is generated and xinput test is totally void.
I attach the complete journal of the operations (boot, disconnect and reconnect) and a wireshark trace starting at the last device insertion and including some random pen activities.
Thank you in advance
Claudio
Last edit: Claudio Laurita 2017-11-19
Apologies for the delay in responding. Could you please try using the
evemu-recordtool to capture the kernel events sent from this device? The package containing that program varies, but may be called "evemu-utils".Dont't warry and thank you for finding the time to analyze the case.
Sure I can run evemu-record, but not immediately as the board is in a school. Please be patient, I'll send you the report ASAP.
Do you want a parallel whireshark/evemu trace?
If possible, instead of getting a parallel trace from Wireshark, a parallel trace from
hid-recorder(see https://bentiss.github.io/hid-replay-docs/) would be more valuable. That is, assuming the Waltop kernel driver uses HID (if you don't see the Waltop device as an option when using hid-recorder, probably not).Finally succeeded in collecting the requested reports
The strange thing (in my ignorance) is that evemu doesen't receive any event.
Hid, at the contrary, gets everything.
I made a rectangular trace around the board and a cross in the middle.
Tell me if I could help in any way
Thanks for the output -- it definitely clears things up. It looks like the device has an incorrect HID descriptor. This prevents the "hid-generic" kernel driver from interpreting the data, which is why
evemu-recorddidn't log any events.Since your tablet doesn't use the "wacom" kernel driver, its not something we can fix. You'll want to contact the Digimend project at https://digimend.github.io/ which produces a driver that works around these incorrect descriptors. It doesn't look like they support this particular device yet, so you'll want to provide a copy of the "evemu" and "hid" files you attached above so they can see exactly what's wrong with the descriptor.
OK thank you
Just a last question to let me go further. Can you please explain what's wrong in the hid descriptor (or how can I find this answer by myself), and why the wacom driver is anyway loaded (who fools it)?
Sure, no problem :) I've included a translation of the HID descriptor at the bottom of this reply.
The data captured in the "hid" log indicates that reports with ID 2 were being sent by the hardware. Looking at the descriptor, report ID 2 can described in basic terms as "a fixed one-byte header of 0x02, then seven 8-bit fields of unknown data, and finally two 8-bit fields that contain altitude and azimuth." Not only is the "unknown data" completely unhelpful to the kernel driver, but the descriptor says to expect 10 bytes of data but the "hid" log shows that only 8 bytes of data are actually being sent by the hardware.
Looking at the other reports described, report ID 16 is fully-described and only 8 bytes long, but it doesn't look like it describes the data that was logged. In particular, the highest three bits of the first byte are supposed to be constant, but that's not the case. Also, the lowest bit of the first byte aren't likely to be the tip switch since it changes state far too often in the logged data.
As for why our X11 driver is being loaded, that's because our driver recognizes that your device is a tablet (more specifically, our X11 driver will bind to any device with "WALTOP" in the name). This descriptor issue isn't something we can fix in the X11 driver, however -- its a problem that has to be fixed in the kernel. We do maintain the "wacom" kernel driver for Wacom tablets, but its the Digimend project that maintains the kernel driver for non-Wacom tablets. They're more experienced in understanding how to decode the hardware data from non-Wacom hardware. Once their kernel driver is updated to support this device, our X11 driver should be able to work properly.
Last edit: Jason Gerecke 2018-01-31
I really thank you very much!
A good explanation is much better then hours spent snorkeling through the code or the RFCs
I contacted Digimend, but I also want to try by myself (I developed several kernel drivers but none in the hid zone)
Thank you again
Claudio
Best of luck. I'd recommend installing "hidrd" if you're going to try making edits to the descriptor yourself. Its able to convert the binary to a few different human-readable formats, and is even able to do the reverse trick if you use its "xml" format for editing.