Huion G10T not detected

[dannytaylor]

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

$ lsusb
Bus 003 Device 019: ID 256c:006e  

But it doesn't show up with any identifying information using uclogic-tools or at all in xinput --list

$ sudo uclogic-probe 3 19 | uclogic-decode
  Manufacturer: TABLET
       Product: Pen Tablet
         Max X: N/A
         Max Y: N/A
  Max pressure: N/A
    Resolution: N/A
Internal model: 
Buttons status: 

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 second 003:019:001 interface.

$ sudo usbhid-dump -a3:19  
003:019:001:DESCRIPTOR         1484972775.746970
 05 0D 09 02 A1 01 85 0A 09 20 A1 00 09 42 09 44
 09 45 09 3C 09 43 09 44 15 00 25 01 75 01 95 06
 81 02 09 32 75 01 95 01 81 02 81 03 05 01 09 30
 09 31 55 0D 65 33 26 FF 7F 35 00 46 00 08 75 10
 95 02 81 02 05 0D 09 30 26 FF 07 75 10 95 01 81
 02 C0 C0

003:019:000:DESCRIPTOR         1484972775.747479
 06 00 FF 09 01 A1 01 85 08 75 58 95 01 09 01 81
 02 C0

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

[dannytaylor]

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

[spbnick]

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.

[dannytaylor]

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.

[dannytaylor]

(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.