Been fussing over this for awhile, but found my problem seems unique compared to others, so no instructions have been helpful.
I purchased an H610 graphics tablet, running it on my Ubuntu 15.10 machine, and with the right GIMP configuration it works, with pressure sensitivity. But the fact that the hotkeys aren't working is bothering me, and it only got more confusing as I tried investigating it.
lsusb; edited because I have a hub installed, so only copying relevant one since there are 20 results. The lack of name for the listing is not an accident; the device only shows up by its ID#. I verified with unplugging/plugging to make sure that was the correct one.
Bus 001 Device 007: ID 256c:006e
xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB Receiver id=9 [slave pointer (2)]
⎜ ↳ Logitech K360 id=10 [slave pointer (2)]
⎜ ↳ 10594 Pad id=11 [slave pointer (2)]
⎜ ↳ 10594 Pen id=12 [slave pointer (2)]
⎜ ↳ 10594 Mouse id=13 [slave pointer (2)]
⎜ ↳ 10594 Consumer Control id=15 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Logitech USB Receiver id=8 [slave keyboard (3)]
↳ 10594 Keyboard id=14 [slave keyboard (3)]
↳ 10594 System Control id=16 [slave keyboard (3)]
↳ Logitech Logitech USB Headset id=17 [slave keyboard (3)]
Which is disconcerting because I have found 10594 is a number for the exact model of H610, which means it's reading the tablet 6 times within the xinput list, and is something I have not seen in the many tablet configuration guides/asks I've read.
So far in my attempts, I've installed DIGImend, which added the "10594 Pad" input which makes the buttons respond with completely incorrect, and even obstructive functions as the undo button is the hotkey to close a window.
On another Ubuntu computer I successfully broke pressure sensitivity while trying to set up Wizardpen and messing with the xorg configuration files, and reverting the file back to default did not fix it.
That one doesn't matter anymore; computer was breaking down and since been disposed of.
Also found it is using evdev for input when I ran xinput --list-props
Device '10594 Pad':
Device Enabled (151): 1
Coordinate Transformation Matrix (153): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (281): 0
Device Accel Constant Deceleration (282): 1.000000
Device Accel Adaptive Deceleration (283): 1.000000
Device Accel Velocity Scaling (284): 10.000000
Device Product ID (268): 9580, 110
Device Node (269): "/dev/input/event7"
Evdev Axis Inversion (285): 0, 0
Evdev Axis Calibration (286): <no items>
Evdev Axes Swap (287): 0
Axis Labels (288): "Abs X" (311), "Abs Y" (312), "Abs Misc" (313)
Button Labels (289): "Button 0" (272), "Button 1" (303), "Button 2" (304), "Button Wheel Up" (157), "Button Wheel Down" (158), "Button Horiz Wheel Left" (159), "Button Horiz Wheel Right" (160), "Button 3" (305), "Button 4" (306), "Button 5" (307), "Button 6" (308), "Button 7" (309), "Button 8" (310)
Evdev Scrolling Distance (290): 0, 0, 0
Evdev Middle Button Emulation (291): 0
Evdev Middle Button Timeout (292): 50
Evdev Third Button Emulation (293): 0
Evdev Third Button Emulation Timeout (294): 1000
Evdev Third Button Emulation Button (295): 3
Evdev Third Button Emulation Threshold (296): 20
Evdev Wheel Emulation (297): 0
Evdev Wheel Emulation Axes (298): 0, 0, 4, 5
Evdev Wheel Emulation Inertia (299): 10
Evdev Wheel Emulation Timeout (300): 200
Evdev Wheel Emulation Button (301): 4
Evdev Drag Lock Buttons (302): 0
.. though not sure if that matters. I've just been fussing over it so much, looking at methods of configuration, reading guides and other help requests, and mostly just got myself confused, outside my range of skills, burnt out, and on the verge of just saying it's good enough that the pressure sensitivity and pen works.
This is kinda my last-ditch try here; seeing if anyone can make sense of this.
An update here. I have messed with it on and off over the months. With newer Ubuntu distros, its behavior changed slightly, but the problems persisted. But I do have a slight update that may explain it a bit better.
Maybe I'm gonna get lucky and someone will be able to identify what the heck is going on.
From what I have figured out: By default, tablet drivers read it as having all possible tablet functions, though it should only have Pen and Keyboard. So it shows up 5 times, all controlled by evdev.
Installing Digimend makes a change: Pen is detected as Wacom in the following reset, then that too goes away after another reset, at which point neither xinput nor xsetwacom can detect anything. Inspecting the syslog, while I can't understand all that's there, I can understand it's reading the tablet (10594) being present.
May 27 07:22:09 Garnet kernel: [12090.086359] usb 3-1: Product: 10594
May 27 07:22:10 Garnet mtp-probe: checking bus 3, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1"
May 27 07:22:10 Garnet mtp-probe: bus: 3, device: 5 was not an MTP device
May 27 07:22:10 Garnet kernel: [12090.404882] input: 10594 Pen as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:256C:006E.0003/input/input7
May 27 07:22:10 Garnet kernel: [12090.404998] uclogic 0003:256C:006E.0003: input,hidraw2: USB HID v1.11 Device [10594] on usb-0000:00:14.0-1/input0
May 27 07:22:10 Garnet kernel: [12090.405199] input: 10594 Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.1/0003:256C:006E.0004/input/input8
May 27 07:22:10 Garnet kernel: [12090.405331] uclogic 0003:256C:006E.0004: input,hiddev0,hidraw3: USB HID v1.11 Mouse [10594] on usb-0000:00:14.0-1/input1
May 27 07:22:10 Garnet kernel: [12090.405882] input: 10594 Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.2/0003:256C:006E.0005/input/input10
May 27 07:22:10 Garnet kernel: [12090.513450] input: 10594 Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.2/0003:256C:006E.0005/input/input11
May 27 07:22:10 Garnet kernel: [12090.513579] input: 10594 System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.2/0003:256C:006E.0005/input/input12
May 27 07:22:10 Garnet kernel: [12090.513769] uclogic 0003:256C:006E.0005: input,hidraw4: USB HID v1.11 Keyboard [10594] on usb-0000:00:14.0-1/input2
May 27 07:22:13 Garnet /usr/lib/snapd/snapd[4416]: daemon.go:170: DEBUG: uid=1000;@ GET /v2/snaps?sources=local 67.924µs 200
May 27 07:38:04 Garnet kernel: [ 56.311313] usb 3-1: Product: 10594
May 27 07:38:04 Garnet mtp-probe: checking bus 3, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1"
May 27 07:38:04 Garnet mtp-probe: bus: 3, device: 5 was not an MTP device
May 27 07:38:04 Garnet kernel: [ 56.454322] uclogic 0003:256C:006E.0003: hidraw2: USB HID v1.11 Keypad [10594] on usb-0000:00:14.0-1/input0
May 27 07:38:04 Garnet kernel: [ 56.454643] uclogic 0003:256C:006E.0004: hiddev0,hidraw3: USB HID v1.11 Mouse [10594] on usb-0000:00:14.0-1/input1
May 27 07:38:04 Garnet kernel: [ 56.455162] uclogic 0003:256C:006E.0005: hidraw4: USB HID v1.11 Keyboard [10594] on usb-0000:00:14.0-1/input2
hidraw2: USB HID v1.11 Keypad [10594] on usb-0000:00:14.0-1/input0
May 27 07:41:33 Garnet kernel: [ 8.330450] uclogic 0003:256C:006E.0002: hiddev0,hidraw3: USB HID v1.11 Mouse [10594] on usb-0000:00:14.0-1/input1
May 27 07:41:33 Garnet kernel: [ 8.330924] uclogic 0003:256C:006E.0003: hidraw4: USB HID v1.11 Keyboard [10594] on usb-0000:00:14.0-1/input2
So.. I guess the uclogic module is properly grabbing the tablet, but somewhere in the process of getting it to the wacom profile it fails?
Is the problem something stupid, like the fact that inside the tablet itself it's labelled as "10594" and so despite being the Huion H610, it's not being read properly due to a different product ID? I did try changing some of the recommended Huion configuration files to it, fruitlessly, a few times during my messing with it.
Either way, while I understand it all a bit better, the darn thing still doesn't work, and has been nothing but compulsively driving me to get the buttons work, and supplying me with endless frustration.