Open dannytaylor opened 7 years ago
A bit more info: Forgot to mention I'm on Arch, kernel 4.8.13-1
Comparing usbhid-dump stream to my H610 I can see some specific things I would have to change for the G10T, but I'm not sure how to go about getting the driver to load for it in the first place. I'm thinking I have to change something in uclogic_enable_tablet
to get valid tablet parameters.
I've attached the dmesg output of plugging in the H610 then plugging in the G10T. dmesg.txt
And the output of $ sudo cat /sys/kernel/debug/usb/devices
for the 2 devices. Different revision # and # of interfaces are probably causing a lot of trouble.
usb-debug.txt
Hi @dannytaylor! First, thanks for trying to make it work yourself!
Now, from what I see Huion is once again abusing USB spec and reuses the VID/PID pair, but now it goes further and does that with a completely different, incompatible model. Otherwise so far it seems a great product and one worth making drivers for.
I see from the report descriptor that it is not actually representing real device capabilities and sets the logical extents at 32767, squishing the horizontal resolution and stretching the vertical resolution. This is likely done for compatibility with the dumb Windows generic HID driver. The actual logical extents should be 50800x31750, if the company description is to be believed.
From here, you have two options, or two work stages, if you'd like. First is to make the driver work with the default, basic interface with impaired resolution, and the hard-coded key combinations from the buttons. The second, is to reverse-engineer the tablet protocol used to enable the fully functional mode, that the Windows driver uses, getting the full resolution and likely abstract, easily re-mappable buttons. I can't say anything about the touchpad protocol at this moment, though.
For any of the options/stages you'd need a way to tell this tablet apart from other tablets with the same VID/PID. Reverse-engineering the protocol will likely give us a way. Otherwise you might want to look at the device and interface descriptors for possible ways to identify this tablet.
After that, for the first option/stage you'll simply need to take the original report descriptor, amend it a little, and make the driver supply it to the kernel. Sure, resolution won't be as good, and buttons will likely need some messing with, but the tablet will work more-or-less.
For the second option/stage you will need Windows running natively or in a VM. You'll need to capture USB traffic with Wireshark (either running on Windows, or on Linux which hosts the VM), and look into patterns and try to figure out what happens there, reproduce some of the USB communication under Linux and try to find the sequence that switches the tablet into the fully-functional mode, and also a response which lets us identify the tablet, those are likely to be the same thing.
Your choice now. I'll be able to help you a little with both of these. For the start I would also like to see the lsusb -v
output for the tablet.
Thanks for the info! Here's the output of lsusb -v for the tablet.
I'll have to do some more reading up on using Wireshark, but on connecting the tablet with the Windows VM up I can see a String Descriptor response from the tablet with a bString of HUION_T161_160923
and another response of HUION Animation Technology Co.,ltd
.
I'll try and compare the Wireshark output to my H610 and see what useful info I can find.
(for any Linux users with this tablet)
After a couple false starts, I've made a (very) rough workaround to get the all of the functionality of the tablet working in Linux.
It reads the USB data then tells a virtual device to mimic the tablet inputs. It's not really ideal, but so far it seems to work as well as it does on Windows. Maybe it could be useful for someone smarter than me to write a proper driver.
Unfortunately I haven't gotten the switch to flip the tablet into fully functional mode working in the script. To have it this script work you have to connect and disconnect the tablet in a Windows VM with the manufacturer's driver installed. Full-function will persist on reboot, but not on replugging the wireless adapter. I've tried emulating the USB traffic that I've gotten from the Wireshark log via the Windows VM, but no luck so far.
I'll probably work on getting the script to work in non full-functioning mode with the impaired resolution next.
I'm a bit out of my depth troubleshooting this, hoping someone has dealt with a similar issue. This is a newer product from Huion with a touchpad, but I'm not too concerned about getting the touchpad working. I also have a Huion H610 which is working without issue (thanks!).
It uses the same manufacturer and device IDs as other Huion tablets
But it doesn't show up with any identifying information using uclogic-tools or at all in
xinput --list
Output of
$sudo usbhid-dump -a3:19 -es
looks correct for coordinates and pressure as far as I can tell. Though there are 2 interfaces from the descriptor dump and all the inputs (including touchpad) show up on the second003:019:001
interface.I replaced the code in
hid-uclogic.c
in__u8 uclogic_tablet_rdesc_template[]
with the output from$ sudo usbhid-dump -a3:19 -i1 | grep -v : | xxd -p -r | hidrd-convert -o code
but that did not seem to be the solution.I'll keep working on this, but any help or things to try are appreciated.
I've attached the the hidrd-convert'd usbhid dumps for both interfaces and the dmesg from reconnecting the tablet. usbhid-dump_code_0.txt usbhid-dump_code_1.txt dmesg.txt usbhid-dump_buttons.txt usbhid-dump_pen_coords.txt usbhid-dump_pen_pressure.txt