do you get a kernel device for this one? If so, please get an evemu-record description from it (with a short interaction with the tablet please)

Sorry, will get that soon. But in the mean time, I do have a confirmed working 'driver' provided by the manufacturer, which I believe may be even more useful.

The driver was linked on this forum post - http://forum.huiontablet.com/discussion/22/can-dwh69-work-on-linux/p1 but I understand as a random dropbox link not everyone would want to download it. It contains an 'idc' (for android) file, and instruction file which I replicate below, and `huiontablet.c` which I've uploaded to pastebin here - http://pastebin.com/ykCYrryL

The current Arch 4.7.2 kernel could not compile with the provided c file, producing the following error:-

drivers/hid/huiontablet.c: In function ‘usb_mouse_irq’:
drivers/hid/huiontablet.c:100:3: error: implicit declaration of function ‘err’ [-Werror=implicit-function-declaration]
err ("can't resubmit intr, %s-%s/input0, status %d",
^~~

Simple fix, I just removed the call to 'err' and substituted printk (which was commented out there, I believe 'err' is used in Android).

Note, I've cleaned up some chinese from the instructions file.

1 huiontablet.c [kernel]/drivers/hid
  Copy huiontablet.c to [kernel]/drivers/hid
  
2 Makefile
  Open Makefile ,before the end of file ,you can write
  
obj-$(CONFIG_HID_HUIONTABLET)	+= huiontablet.o

3 Kconfig "drivers/hid/usbhid/Kconfig"
  Open Kconfig,after "drivers/hid/usbhid/Kconfig" (about Line 60),add
  
config HID_HUIONTABLET
	tristate "Huion tablet"	
	depends on INPUT
	---help---
	Support for Huion tablet.

4 hid-ids.h
  Open hid-ids.h,before endif(about Line 675),add
#define USB_VENDOR_ID_HUIONTABLET 0x256C
#define USB_DEVICE_ID_HUIONTABLET 0x0005
#define USB_DEVICE_ID_HUIONTABLET2 0x006E

5 [kernel]/drivers/hid/usbhid hid-quirks.c
  Enter the folder [kernel]/drivers/hid/usbhid,open hid-quirks.c,in hid_blacklist struct,before { 0, 0 }£¬add
        { USB_VENDOR_ID_HUIONTABLET,USB_DEVICE_ID_HUIONTABLET, HID_QUIRK_IGNORE},
        { USB_VENDOR_ID_HUIONTABLET,USB_DEVICE_ID_HUIONTABLET2, HID_QUIRK_IGNORE},

about Line 90

6 make menuconfig
Device Drivers-> HID Devices-> Huion tablet 
  open console and enter the kernel folder,
  make menuconfig
select Device Drivers-> HID Devices-> Huion tablet 
  

Warning:This guide is according to Linux version 3.0,you can modify according to the actual circumstance


7 Aodroid ROM Vendor_256c_Product_006e.idc /system/usr/idc
(https://source.android.com/devices/tech/input/input-device-configuration-files.html)
After update the kernel of the Android device,you may find the cursor can not be rotated if the Android device was rotated.Please put the file Vendor_256c_Product_006e.idc to folder /system/usr/idc/
(refer to https://source.android.com/devices/tech/input/input-device-configuration-files.html)

(In reply to Peter Hutterer from comment #1)
> do you get a kernel device for this one? If so, please get an evemu-record
> description from it (with a short interaction with the tablet please)

Please let me know if this is still necessary based on my latest reply.

First: the driver you linked to cannot be upstreamed. it is of unknown origin and the very top says Copyright (c) 2013 Tan Huang,Shenzhen Huion. No license information is provided, so full copyright must be assumed and thus this driver is incompatible with the GPL.

Because of that I didn't read past the copyright bit, unless it is marked as GPL looking at the driver will taint anyone and open them to copyright infringement penalties. IANAL but stuff like this needs to be handled very carefully.

If you can get Eugina from the forum to contact me, then we can work upstreaming this driver properly.

(In reply to ngoonee from comment #3)
> Please let me know if this is still necessary based on my latest reply.

Yes please. Let's see what the current kernel does.

Okay, will provide as much information as I can. For reference, I'm using this tablet in wireless mode (there's a dongle provided which plugs to USB). Based on my experiments with the provided non open-source driver, there should be no kernel-facing difference.

Firstly I'm just going to follow the instructions given in http://digimend.github.io/support/howto/trbl/diagnostics/

This is the output of sudo usbhid-dump -ed -m 256c:006e - http://pastebin.com/1cNAZCn2

The following tests are the outputs of sudo usbhid-dump -es -m 256c:006e
This is the border-crossing top, right, bottom, left - http://pastebin.com/zBmz5edA
This is the pen pressure test - http://pastebin.com/gyNx9XYr
This is the pen-button test - http://pastebin.com/QZZnkFxw
Frame button test - this device has 8 capacitive buttons - http://pastebin.com/vvfP3Pes

This is the evemu-record for the following actions:-
Crossing the top/right/bottom/left border
Pressing the pen hard to modify pressure reading
Pressing the pen's two additional buttons once each
Line 6570 onwards - pressing each of buttons 1-8 on the tablet

http://pastebin.com/4gFdWXfd

For the record, I have 5 /dev/input/event/** devices, named
PenTablet {Pen,Mouse,Keyboard,Consumer Control, System Control} but only the PenTablet Pen device outputs anything for evemu-record.

Also for the record, using evdev means I can use the tablet with appropriate pressure, but the 8 buttons at the side do not give any response (even to xev). But of course I'm interest in libinput with this bug report.

please attach all the pastebin things as bugzilla attachments here, pastebin has a habit of making things disappear right when developers find the time to look at them.

Created attachment 126502 [details]
Descriptors

Output of sudo usbhid-dump -ed -m 256c:006e

Created attachment 126503 [details]
Border-crossing test

Output of sudo usbhid-dump -es -m 256c:006e
Did the border-crossing test in following order:- top, right, bottom, left

Created attachment 126504 [details]
Pen pressure test

Output of sudo usbhid-dump -es -m 256c:006e
Pen pressure test (press till max pressure and then release)

Created attachment 126505 [details]
Pen button test

Output of sudo usbhid-dump -es -m 256c:006e
Pen button test (button 2 and then button 3, with button 2 being closer to nib)

Created attachment 126506 [details]
Frame buttons test

Output of sudo usbhid-dump -es -m 256c:006e
Frame buttons test (8 buttons, left-to-right then top-to-bottom

Created attachment 126507 [details]
Evemu-record output

This is the evemu-record for the following actions:-
Crossing the top/right/bottom/left border
Pressing the pen hard to modify pressure reading
Pressing the pen's two additional buttons once each
Line 6570 onwards - pressing each of buttons 1-8 on the tablet

(In reply to ngoonee from comment #13)
> Created attachment 126507 [details]
> Evemu-record output

this one seems to work provided I add a BTN_TOOL_PEN 1 to the first event. The main question is: is this event not sent when you get into proximity?

run evemu-record | grep BTN_TOOL_PEN and see if you can spot the pattern. it should be sent whenever the tool gets into detectable proximity and set to 0 whenever it goes out of proximity.

(In reply to Peter Hutterer from comment #14)
> (In reply to ngoonee from comment #13)
> > Created attachment 126507 [details]
> > Evemu-record output
> 
> this one seems to work provided I add a BTN_TOOL_PEN 1 to the first event.
> The main question is: is this event not sent when you get into proximity?
> 
> run evemu-record | grep BTN_TOOL_PEN and see if you can spot the pattern. it
> should be sent whenever the tool gets into detectable proximity and set to 0
> whenever it goes out of proximity.

So here's the behaviour I observe:-

1. Bringing pen in and out of proximity gives no output.

2. Pressing buttons gives no output.

3. Pressing buttons WHILE PEN IS IN PROXIMITY gives output.

Seems like the buttons are being treated similarly to the buttons on the pen. This applies for all 8 buttons.

(In reply to ngoonee from comment #15)
> So here's the behaviour I observe:-
> 
> 1. Bringing pen in and out of proximity gives no output.
> 
> 2. Pressing buttons gives no output.
> 
> 3. Pressing buttons WHILE PEN IS IN PROXIMITY gives output.

so to verify: you get a BTN_TOOL_PEN only when you press buttons while in proximity? if so, what's the behaviour there? when is BTN_TOOL_PEN set and when isn't it?

(In reply to Peter Hutterer from comment #16)
> (In reply to ngoonee from comment #15)
> > So here's the behaviour I observe:-
> > 
> > 1. Bringing pen in and out of proximity gives no output.
> > 
> > 2. Pressing buttons gives no output.
> > 
> > 3. Pressing buttons WHILE PEN IS IN PROXIMITY gives output.
> 
> so to verify: you get a BTN_TOOL_PEN only when you press buttons while in
> proximity? if so, what's the behaviour there? when is BTN_TOOL_PEN set and
> when isn't it?

Sorry, didn't realise to test that. Oddly enough, when pressing the button I get BTN_TOOL_PEN set to 0 and then immediately set to 1. This happens again when releasing the button.

This is the full output (without the grep) with me holding the pen in proximity BUT UNMOVING and then pressing (first two reports) and releasing (last two reports)

E: 12.986116 0001 0140 0000     # EV_KEY / BTN_TOOL_PEN         0
E: 12.986116 0003 0000 0257     # EV_ABS / ABS_X                257
E: 12.986116 0003 0001 0001     # EV_ABS / ABS_Y                1
E: 12.986116 0000 0000 0000     # ------------ SYN_REPORT (0) ---------- +622ms
E: 12.988118 0001 0140 0001     # EV_KEY / BTN_TOOL_PEN         1
E: 12.988118 0003 0000 9159     # EV_ABS / ABS_X                9159
E: 12.988118 0003 0001 4600     # EV_ABS / ABS_Y                4600
E: 12.988118 0000 0000 0000     # ------------ SYN_REPORT (0) ---------- +2ms
E: 13.734112 0001 0140 0000     # EV_KEY / BTN_TOOL_PEN         0
E: 13.734112 0003 0000 0257     # EV_ABS / ABS_X                257
E: 13.734112 0003 0001 0000     # EV_ABS / ABS_Y                0
E: 13.734112 0000 0000 0000     # ------------ SYN_REPORT (0) ---------- +746ms
E: 13.736114 0001 0140 0001     # EV_KEY / BTN_TOOL_PEN         1
E: 13.736114 0003 0000 9159     # EV_ABS / ABS_X                9159
E: 13.736114 0003 0001 4600     # EV_ABS / ABS_Y                4600
E: 13.736114 0000 0000 0000     # ------------ SYN_REPORT (0) ---------- +2ms

punting to benjamin, this needs a kernel-level fix

(In reply to Peter Hutterer from comment #18)
> punting to benjamin, this needs a kernel-level fix

I must confess I am a little bit lost here.

Could you:
- install hid-uclogic from DIGImend (or grab https://github.com/DIGImend/digimend-kernel-drivers/blob/master/hid-uclogic.c) as it contains changes that have just been submitted upstream
- make sure the out-of-the-tree is loaded and in used (in doubt, provide the dmesg)
- redo a full test of entering in proximity, pressing the tip, releasing the pressure still keeping the pen in proximity, getting out of proximity while:
  * having evemu-record recording the PEN tool
  * having hid-recorder[1] recording the raw HID events *at the same time*



[1] http://bentiss.github.io/hid-replay-docs/ (sorry it's easier for me to debug with my own tool rather than the ones from DIGIMend)

(In reply to Benjamin Tissoires from comment #19)
> (In reply to Peter Hutterer from comment #18)
> > punting to benjamin, this needs a kernel-level fix
> 
> I must confess I am a little bit lost here.
> 
> Could you:
> - install hid-uclogic from DIGImend (or grab
> https://github.com/DIGImend/digimend-kernel-drivers/blob/master/hid-uclogic.
> c) as it contains changes that have just been submitted upstream
> - make sure the out-of-the-tree is loaded and in used (in doubt, provide the
> dmesg)
> - redo a full test of entering in proximity, pressing the tip, releasing the
> pressure still keeping the pen in proximity, getting out of proximity while:
>   * having evemu-record recording the PEN tool
>   * having hid-recorder[1] recording the raw HID events *at the same time*
> 
> 
> 
> [1] http://bentiss.github.io/hid-replay-docs/ (sorry it's easier for me to
> debug with my own tool rather than the ones from DIGIMend)

Unfortunately I've tried that before but the driver can't build on 4.7.3 in ARCH. Here's the error:-

sudo make
[sudo] password for ngoonee:
make -C /lib/modules/4.7.3-2-ARCH/build SUBDIRS=/home/data/Downloads/digimend-kernel-drivers-6 modules
make[1]: Entering directory '/usr/lib/modules/4.7.3-2-ARCH/build'
  CC [M]  /home/data/Downloads/digimend-kernel-drivers-6/hid-uclogic.o
/home/data/Downloads/digimend-kernel-drivers-6/hid-uclogic.c:1101:22: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .input_configured = uclogic_input_configured,
                      ^~~~~~~~~~~~~~~~~~~~~~~~
/home/data/Downloads/digimend-kernel-drivers-6/hid-uclogic.c:1101:22: note: (near initialization for ‘uclogic_driver.input_configured’)
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:296: /home/data/Downloads/digimend-kernel-drivers-6/hid-uclogic.o] Error 1
make[1]: *** [Makefile:1457: _module_/home/data/Downloads/digimend-kernel-drivers-6] Error 2
make[1]: Leaving directory '/usr/lib/modules/4.7.3-2-ARCH/build'
make: *** [Makefile:9: modules] Error 2

I have no problems compiling latest git kernel though, if these are already committed there.

So I'm just going to do the test first (without latest digimend, see above comment) with hid-uclogic from 4.7.2, here's the dmesg showing the driver.

[ 7432.847468] usb 3-2: new full-speed USB device number 5 using xhci_hcd
[ 7433.593578] input: PenTablet Pen as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.0/0003:256C:006E.0005/input/input25
[ 7433.593734] uclogic 0003:256C:006E.0005: input,hidraw4: USB HID v1.11 Device [PenTablet] on usb-0000:00:14.0-2/input0
[ 7433.593954] input: PenTablet Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.1/0003:256C:006E.0006/input/input26
[ 7433.594114] uclogic 0003:256C:006E.0006: input,hiddev0,hidraw5: USB HID v1.11 Mouse [PenTablet] on usb-0000:00:14.0-2/input1
[ 7433.600782] input: PenTablet Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.2/0003:256C:006E.0007/input/input28
[ 7433.697659] input: PenTablet Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.2/0003:256C:006E.0007/input/input29
[ 7433.697874] input: PenTablet System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.2/0003:256C:006E.0007/input/input30
[ 7433.698065] uclogic 0003:256C:006E.0007: input,hidraw6: USB HID v1.0b Keyboard [PenTablet] on usb-0000:00:14.0-2/input2

For the record, my test consisted of:-

1. Bringing pen into proximity
2. Pressing pen in to full pressure
3. Release pen but keeping it in proximity
4. Pressing the pen's buttons (nearer-to-nib followed by further-from-nib
5. Taking pen away from proximity
6. Pressing the 8 frame capacitive buttons (pen not in proximity)
7. Bringing pen into proximity and pressing the 8 frame capacitive buttons again
8. Taking pen away from proximity

Created attachment 126529 [details]
Evemu-record output - matching with hid-recorder

Created attachment 126530 [details]
hid-recorder output - matching with evemu-record

(In reply to ngoonee from comment #20)
> sudo make
> [sudo] password for ngoonee:
> make -C /lib/modules/4.7.3-2-ARCH/build
> SUBDIRS=/home/data/Downloads/digimend-kernel-drivers-6 modules
> make[1]: Entering directory '/usr/lib/modules/4.7.3-2-ARCH/build'
>   CC [M]  /home/data/Downloads/digimend-kernel-drivers-6/hid-uclogic.o
> /home/data/Downloads/digimend-kernel-drivers-6/hid-uclogic.c:1101:22: error:
> initialization from incompatible pointer type
> [-Werror=incompatible-pointer-types]
>   .input_configured = uclogic_input_configured,
>                       ^~~~~~~~~~~~~~~~~~~~~~~~
> /home/data/Downloads/digimend-kernel-drivers-6/hid-uclogic.c:1101:22: note:
> (near initialization for ‘uclogic_driver.input_configured’)
> cc1: some warnings being treated as errors

Hmm, weird, I would have expected "#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 4, 0)" to be working.

You should be able to replace the #if statement above with "#if 0" and this should hopefully be OK.


(In reply to ngoonee from comment #21)
> I have no problems compiling latest git kernel though, if these are already
> committed there.

They are submitted, but not yet committed. The patch you need is https://patchwork.kernel.org/patch/9332241/ but I am not sure if you need the 4 before of this one or not


(In reply to ngoonee from comment #24)
> Created attachment 126530 [details]
> hid-recorder output - matching with evemu-record

Thanks for the log. The good news is that as soon as you will be able to apply the patch above, you should have working buttons. This device doesn't have fallback mechanism for the buttons and doesn't send keystrokes when you press those (which was the case for other Huions).

When the patch will be applied, this will also remove the spurious BTN_TOOL_PEN 0/1 when you press the buttons, as they will be properly parsed and the state will be normal.

The last worrying thing (but I think it's already known) is that the InRange bit is always set, meaning that there won't be any out of proximity events.

(In reply to Benjamin Tissoires from comment #25)
> 
> Hmm, weird, I would have expected "#if LINUX_VERSION_CODE <
> KERNEL_VERSION(4, 4, 0)" to be working.
> 
> You should be able to replace the #if statement above with "#if 0" and this
> should hopefully be OK.

There's no #if LINUX_VERSION_CODE anywhere in the digimend-kernel-drivers-6 files, though, so I'm not sure what you're referring to.
> 
> 
> (In reply to ngoonee from comment #21)
> > I have no problems compiling latest git kernel though, if these are already
> > committed there.
> 
> They are submitted, but not yet committed. The patch you need is
> https://patchwork.kernel.org/patch/9332241/ but I am not sure if you need
> the 4 before of this one or not

Thanks, applied to 4.7.3 (applies cleanly) and compiled.
> 
> 
> (In reply to ngoonee from comment #24)
> > Created attachment 126530 [details]
> > hid-recorder output - matching with evemu-record
> 
> Thanks for the log. The good news is that as soon as you will be able to
> apply the patch above, you should have working buttons. This device doesn't
> have fallback mechanism for the buttons and doesn't send keystrokes when you
> press those (which was the case for other Huions).
> 
> When the patch will be applied, this will also remove the spurious
> BTN_TOOL_PEN 0/1 when you press the buttons, as they will be properly parsed
> and the state will be normal.
> 
> The last worrying thing (but I think it's already known) is that the InRange
> bit is always set, meaning that there won't be any out of proximity events.

Installing the patched kernel (and uninstalling xf86-input-evdev) means the device stops working (in other words, doesn't work with xf86-input-libinput).

(In reply to ngoonee from comment #26)
> Installing the patched kernel (and uninstalling xf86-input-evdev) means the
> device stops working (in other words, doesn't work with xf86-input-libinput).

use libinput-debug-events first to make sure it works, no need to remove evdev or restart X

(In reply to ngoonee from comment #26)
> There's no #if LINUX_VERSION_CODE anywhere in the digimend-kernel-drivers-6
> files, though, so I'm not sure what you're referring to.

File hid-uclogic.c, line 750:
https://github.com/DIGImend/digimend-kernel-drivers/blob/master/hid-uclogic.c#L750

> Installing the patched kernel (and uninstalling xf86-input-evdev) means the
> device stops working (in other words, doesn't work with xf86-input-libinput).

Please provide a dmesg, and the evemu-record of the patched kernel for both the pen node and the pad node (which should now be present).

(in addition to the libinput-debug-events logs requested by Peter)

(In reply to Peter Hutterer from comment #27)
> (In reply to ngoonee from comment #26)
> > Installing the patched kernel (and uninstalling xf86-input-evdev) means the
> > device stops working (in other words, doesn't work with xf86-input-libinput).
> 
> use libinput-debug-events first to make sure it works, no need to remove
> evdev or restart X

libinput error: libinput bug: Device 'PenTablet Keyboard' does not meet tablet criteria. Ignoring this device.
libinput error: libinput bug: Device 'PenTablet System Control' does not meet tablet criteria. Ignoring this device.
libinput error: libinput bug: Device 'PenTablet Consumer Control' does not meet tablet criteria. Ignoring this device.
libinput error: libinput bug: Device 'PenTablet Mouse' does not meet tablet criteria. Ignoring this device.
event16 DEVICE_ADDED     PenTablet Pad                     seat0 default group10 cap:P buttons:8 strips:0 rings:0 mode groups:1
event15 DEVICE_ADDED     PenTablet Pen                     seat0 default group10 cap:T  size 229.30/143.31mm

I assume this means the patch applies successfully at least?

Once again for the record this is the actions I'm recording:-

1. Bringing pen into proximity
2. Pressing pen in to full pressure
3. Release pen but keeping it in proximity
4. Pressing the pen's buttons (nearer-to-nib followed by further-from-nib
5. Taking pen away from proximity
6. Pressing the 8 frame capacitive buttons (pen not in proximity)
7. Bringing pen into proximity and pressing the 8 frame capacitive buttons again
8. Taking pen away from proximity

Created attachment 126577 [details]
evemu-record output for Pen device

Created attachment 126578 [details]
evemu-record output for Pad device

Created attachment 126579 [details]
libinput-debug-events

thanks for the logs.

That looks good to me. Buttons are handled in their own device, and the pen is not interfering. I'll let Peter check if there are some libinput errors

(In reply to Benjamin Tissoires from comment #34)
> thanks for the logs.
> 
> That looks good to me. Buttons are handled in their own device, and the pen
> is not interfering. I'll let Peter check if there are some libinput errors

You're welcome. Did notice at various points in other testing (not logged here) that you're right about the proximity never going 'off'. At some point (and I couldn't reliably reproduce) this meant my mouse button was stuck 'down', and until I unplugged the tablet I could not click on anything with my 'real' mouse.

(In reply to Benjamin Tissoires from comment #28)
> (In reply to ngoonee from comment #26)
> > There's no #if LINUX_VERSION_CODE anywhere in the digimend-kernel-drivers-6
> > files, though, so I'm not sure what you're referring to.
> 
> File hid-uclogic.c, line 750:
> https://github.com/DIGImend/digimend-kernel-drivers/blob/master/hid-uclogic.
> c#L750

Right, I'm not sure why I assumed -6 was the latest. Cloned the repo and now it builds (no changes needed). Much easier than recompiling the kernel, and same effect from my testing (according to what has been requested so far in this bug report).

Based on https://github.com/DIGImend/digimend-kernel-drivers/issues/10 I figured that it really should be possible to use this tablet with libwacom, and simply adding a 'PenTablet' MatchProduct to my xorg.conf (specifically I edited /etc/X11/xorg.conf.d/70-wacom.conf) means xsetwacom picks up my tablet. I can rebind buttons, but have not tried restricting to a single monitor (I'll do that when I regain access to my external monitor during the work week). Initial signs are promising.

The lack of proximity out of range event has a pretty annoying sideeffect that I can't scroll in gimp/inkscape as the button4/5 events don't seem to do anything.

(In reply to ngoonee from comment #29)
> libinput error: libinput bug: Device 'PenTablet Keyboard' does not meet
> tablet criteria. Ignoring this device.

This message means that the device has ID_INPUT_TABLET assigned but it shouldn't. That's a udev issue, not sure why this happens though. Do you have a manual override or something? same for th eothers

> libinput error: libinput bug: Device 'PenTablet System Control' does not
> meet tablet criteria. Ignoring this device.
> libinput error: libinput bug: Device 'PenTablet Consumer Control' does not
> meet tablet criteria. Ignoring this device.
> libinput error: libinput bug: Device 'PenTablet Mouse' does not meet tablet
> criteria. Ignoring this device.
> event16 DEVICE_ADDED     PenTablet Pad                     seat0 default
> group10 cap:P buttons:8 strips:0 rings:0 mode groups:1
> event15 DEVICE_ADDED     PenTablet Pen                     seat0 default
> group10 cap:T  size 229.30/143.31mm
> 
> I assume this means the patch applies successfully at least?

yes, P and T are Pad and Tablet capabilities. and from the evemu output at least I can tell that the event sequence looks correct. libinput spits out a whole bunch of tablet events too.
I recommend grabbing libinput from git and building with gtk+-3 devel headers installed. that way you can run make and sudo ./tools/event-gui to test if the tablet responds correctly.


(In reply to ngoonee from comment #37)
> Based on https://github.com/DIGImend/digimend-kernel-drivers/issues/10 I
> figured that it really should be possible to use this tablet with libwacom,

libwacom is merely a descriptive library. it's used by GNOME but only to display the config item. It doesn't decide if the tablet works otherwise.

> and simply adding a 'PenTablet' MatchProduct to my xorg.conf (specifically I
> edited /etc/X11/xorg.conf.d/70-wacom.conf) means xsetwacom picks up my
> tablet. 

if xsetwacom detects the device you assigned the wacom driver, not libinput. change the Driver line to "libinput".

> The lack of proximity out of range event has a pretty annoying sideeffect
> that I can't scroll in gimp/inkscape as the button4/5 events don't seem to
> do anything.


from the libinput output I get here you get proximity events. there's a tip up, followed by axis events (though it doesn't move much) so proximity works. the stylus buttons come in while the tip is up, so everything appears to work?

(In reply to Peter Hutterer from comment #38)
> (In reply to ngoonee from comment #29)
> > libinput error: libinput bug: Device 'PenTablet Keyboard' does not meet
> > tablet criteria. Ignoring this device.
> 
> This message means that the device has ID_INPUT_TABLET assigned but it
> shouldn't. That's a udev issue, not sure why this happens though. Do you
> have a manual override or something? same for th eothers

Nope, at least not that I've set myself. And this being Arch, unlikely to have much non-upstream defaults anyway.
> > I assume this means the patch applies successfully at least?
> 
> yes, P and T are Pad and Tablet capabilities. and from the evemu output at
> least I can tell that the event sequence looks correct. libinput spits out a
> whole bunch of tablet events too.
> I recommend grabbing libinput from git and building with gtk+-3 devel
> headers installed. that way you can run make and sudo ./tools/event-gui to
> test if the tablet responds correctly.

Will get round to that soon.
> 
> if xsetwacom detects the device you assigned the wacom driver, not libinput.
> change the Driver line to "libinput".
> 
> > The lack of proximity out of range event has a pretty annoying sideeffect
> > that I can't scroll in gimp/inkscape as the button4/5 events don't seem to
> > do anything.
> 
> 
> from the libinput output I get here you get proximity events. there's a tip
> up, followed by axis events (though it doesn't move much) so proximity
> works. the stylus buttons come in while the tip is up, so everything appears
> to work?

So I tested with Driver line to libinput (and restarted, otherwise it kept using libwacom), and the stylus itself works but I lose the frame buttons as compared to when I was using 'wacom'. Doesn't even show up in xev.

Behaviour in gimp/inkscape is unchanged compared to wacom. I can scroll fine (using my mouse) until I first draw something, after which no scrolling will work until I unplug the tablet.

sorry, was travelling. What's the most recent evemu-record output so I can start reproducing things here?

Ping?

Latest evemu-record for following actions:-
Crossing the right/bottom/left/top border
Pressing the pen hard to modify pressure reading
Pressing the pen's two additional buttons once each
pressing each of buttons 1-8 on the tablet
pressing each of buttons 1-8 on the tablet with pen in proximity

This is with latest digimend and libinput drivers selected (rather than libwacom). Separate evemu-record for pen and pad attached.

Created attachment 127610 [details]
evemu-record output for Pen device

Created attachment 127611 [details]
evemu-record output for Pad device

Sorry for the delay, IRL busy-ness. Thanks for looking into this!

(In reply to ngoonee from comment #43)
> Created attachment 127610 [details]
> evemu-record output for Pen device

It's still missing the BTN_TOOL_PEN when the pen gets into proximity. so looks like the same issue is still present.

Hi,

Same problem on Debian.

Under X sessions, the Huion tablet, identified like "256c:006e", works very well (not yet tried "shortcuts").

'xinput list' command returns this:

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ USB Optical Mouse                       	id=11	[slave  pointer  (2)]
⎜   ↳ PenTablet  Pen                          	id=12	[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)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Logitech Logitech USB Keyboard          	id=9	[slave  keyboard (3)]
    ↳ Logitech Logitech USB Keyboard          	id=10	[slave  keyboard (3)]

While under Wayland, xinput returns this:

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer:13                     	id=6	[slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:13            	id=7	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ xwayland-keyboard:13                    	id=8	[slave  keyboard (3)]

Is it normal that, even the Mouse and the Keybord are not identified correctly?

Thanks

xinput on Wayland runs through Xwayland. And Xwayland doesn't see all input devices because it only sees what's on the wayland protocol and that works differently. So running xinput under wayland is almost always pointless.

see also https://who-t.blogspot.com.au/2016/12/the-future-of-xinput-xmodmap-setxkbmap.html


ngoonee, please do the following: reboot the machine without touching the tablet. then start evemu-record. *now* use the tablet for a single sequence and attach the output. I'm wondering whether the BTN_TOOL_PEN is never sent or just sent once on the very first event. That's why it's important that the tablet does not generate any events until you have evemu running

I'm actually fairly confused now, apologies for that.

Should I be using the patch from commit 19 for this test?

Should I be rebooting with the device plugged in or plug it in after boot?

If the latter, I guess I should start evemu-record before plugging it in?

(In reply to ngoonee from comment #49)
> I'm actually fairly confused now, apologies for that.

no worries, sorry about not being clear
 
> Should I be using the patch from commit 19 for this test?

yes please, given that it's needed anyway

> Should I be rebooting with the device plugged in or plug it in after boot?

shouldn't matter, but safer to plug it in after boot (less chance of accidental events)

> If the latter, I guess I should start evemu-record before plugging it in?

that won't work because evemu-record needs the device node which won't exist until it's plugged in.

@ Peter Hutterer

Thanks for the informations.

Should I open a new bug report ? Since it works for me under Xorg, but not under Wayland/Xwayland.

Finally, I am able to "see" the tablet through libinput-list-devices and libinput-debug-events, but unable to use it under Gnome3/Wayland nor Weston/Wayland.

Muslim: Weston doesn't have tablet support yet, so that's expected. GNOME should have it in the latest version, but unless you're on F25, don't expect it to work. IIRC the Huion tablets re-use product ids, so let's file a separate bug for yours because this bug is about one that doesn't work in libinput at all. But if you say it works under X then it's highly likely that it works fine anyway (unless you have the wacom driver hooked up to it). But either way, separate bug please, thanks.

Created attachment 128460 [details]
evemu-record output for Pen device - immediately after boot

Looks like you're right. It shows BTN_TOOL_PEN in this situation.

yep, I guess this is the same issue as fixed for touchpads with 5552a6f145b9cb9d8e00f2fdf25e0acb75fe6c72. The tablet code is a bit quirkier here but that should still be fixable.

@Peter Hutterer

Thanks to your post, https://who-t.blogspot.com.au/2016/12/the-future-of-xinput-xmodmap-setxkbmap.html, I did some tests.

And after some search, I find this:

https://plus.google.com/117863863653209681821/posts/7w9USq3fPZ9

Now, I think the problem comes from Gnome3 or libgtk-3, as Mypaint used to work until updates of Gnome3 and libgtk3.

For information, I use Debian Sid, and Gnome version is 3.22.

Anyway, thanks for all, and sorry for the inconvenience!

give this one a try please:
https://github.com/whot/libinput/tree/wip/huion-dwh69-fdo97771

Note that you need to set the hwdb entry (see the last commit) so that the udev property shows up on your device, otherwise it won't apply.

Okay gave that a try. Not sure if my hwdb is a) correct and b) taking effect, but no difference in behavior that I can see. This is what I put in /etc/udev/hwdb.d/70-HuionDWH69.hwdb

libinput:input:b003v256cp006e*
 LIBINPUT_MODEL_HUION_TABLET_NO_PROXIMITY_OUT=reserved

this should be just 1, not "reserved", otherwise it won't get picked up. a sudo udevadm test /sys/class/input/eventX should tell you whether the property is picked up correctly by udev. and for the above to work, you need to uppercase the hex, so it's b003v256Cp006E*. Those are the ones I can immediately spot, but why didn't you just use the example that's already in there (and matches by name)?

(In reply to Peter Hutterer from comment #58)
> this should be just 1, not "reserved", otherwise it won't get picked up. a
> sudo udevadm test /sys/class/input/eventX should tell you whether the
> property is picked up correctly by udev. and for the above to work, you need
> to uppercase the hex, so it's b003v256Cp006E*. Those are the ones I can
> immediately spot, but why didn't you just use the example that's already in
> there (and matches by name)?

Ah, because... I'm stupid I guess.

Anyway I'm now using that, udevadm test shows the property was picked up, but behaviour seems unchanged in that my evemu-record only shows BTN_TOOL_PEN once. Would the evemu-record help or is there some other info which is needed?

Something which may or may not be interesting, under evemu-record the id for the Pentablet Pen is 17
Available devices:
/dev/input/event0:      AT Translated Set 2 keyboard
/dev/input/event1:      Asus WMI hotkeys
/dev/input/event2:      Lid Switch
/dev/input/event3:      Sleep Button
/dev/input/event4:      Power Button
/dev/input/event5:      Asus Wireless Radio Control
/dev/input/event6:      HDA Digital PCBeep
/dev/input/event7:      HDA Intel PCH Mic
/dev/input/event8:      HDA Intel PCH Headphone
/dev/input/event9:      Video Bus
/dev/input/event10:     Video Bus
/dev/input/event11:     PC Speaker
/dev/input/event12:     NOVATEK USB Keyboard
/dev/input/event13:     NOVATEK USB Keyboard
/dev/input/event14:     PixArt USB Optical Mouse
/dev/input/event15:     ETPS/2 Elantech Touchpad
/dev/input/event16:     ASUS USB2.0 Webcam
/dev/input/event17:     PenTablet Pen
/dev/input/event18:     PenTablet Pad
/dev/input/event19:     PenTablet Mouse
/dev/input/event20:     PenTablet Keyboard
/dev/input/event21:     PenTablet Consumer Control
/dev/input/event22:     PenTablet System Control

But my xinput --list shows something else.

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ ETPS/2 Elantech Touchpad                  id=13   [slave  pointer  (2)]
⎜   ↳ PixArt USB Optical Mouse                  id=15   [slave  pointer  (2)]
⎜   ↳ PenTablet Pad                             id=17   [slave  pointer  (2)]
⎜   ↳ PenTablet Pen Pen (0)                     id=20   [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)]
    ↳ Asus Wireless Radio Control               id=7    [slave  keyboard (3)]
    ↳ Video Bus                                 id=8    [slave  keyboard (3)]
    ↳ Video Bus                                 id=9    [slave  keyboard (3)]
    ↳ Sleep Button                              id=10   [slave  keyboard (3)]
    ↳ Asus WMI hotkeys                          id=11   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=12   [slave  keyboard (3)]
    ↳ ASUS USB2.0 Webcam                        id=14   [slave  keyboard (3)]
    ↳ PenTablet Pen                             id=16   [slave  keyboard (3)]
    ↳ NOVATEK USB Keyboard                      id=18   [slave  keyboard (3)]
    ↳ NOVATEK USB Keyboard                      id=19   [slave  keyboard (3)]

(In reply to ngoonee from comment #59)
> Anyway I'm now using that, udevadm test shows the property was picked up,
> but behaviour seems unchanged in that my evemu-record only shows
> BTN_TOOL_PEN once. Would the evemu-record help or is there some other info
> which is needed?

once it's picked up correctly, you need to restart X or the compositor. Or reboot, that's easiest. Then check it's still there with udevadm info /sys/... and it should work now.

the different ids are expected, one is kernel event node number, the other one is X device ID, they're two different things.

(In reply to Peter Hutterer from comment #60)
> 
> once it's picked up correctly, you need to restart X or the compositor. Or
> reboot, that's easiest. Then check it's still there with udevadm info
> /sys/... and it should work now.
> 
> the different ids are expected, one is kernel event node number, the other
> one is X device ID, they're two different things.

I've done the reboot, it's still there as checked by udevadm info /sys..., but evemu-record only ever shows BTN_TOOL_PEN once =(

oh, right. that's not actually fixed, the bit that has changed is that libinput now knows how to handle this situation - it syncs the BTN_TOOL_PEN on start. So don't worry about evemu-record, check whether the tablet behaves correctly now.

(In reply to Peter Hutterer from comment #62)
> oh, right. that's not actually fixed, the bit that has changed is that
> libinput now knows how to handle this situation - it syncs the BTN_TOOL_PEN
> on start. So don't worry about evemu-record, check whether the tablet
> behaves correctly now.

Still seeing the same behavior in that having the tablet plugged in seems to affect mouse scrolling behavior in gimp and inkscape both. Otherwise working fine (and the buttons now work on libinput where they didn't before).

if you just run libinput-debug-events does the output look sane?

ping?

closing, please re-open when the required information is available