| Summary: | kernel: Huion DWH69 missing BTN_TOOL_PEN events | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | ngoonee |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | benjamin.tissoires, peter.hutterer |
| Version: | 1.4.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Descriptors
Border-crossing test Pen pressure test Pen button test Frame buttons test Evemu-record output Evemu-record output - matching with hid-recorder hid-recorder output - matching with evemu-record evemu-record output for Pen device evemu-record output for Pad device libinput-debug-events evemu-record output for Pen device evemu-record output for Pad device evemu-record output for Pen device - immediately after boot |
||
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 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
The hardware is working (tested on a Windows install). It is detected as PenTablet on my Arch install but does not show up on xinput. The below is the output of lsusb -v -d 256c:006e (which is the right vendor/product ID, shared among all/almost all Huion devices I think). Please let me know if this should go to digimend instead (which, as I understand, is shutting down soon). Bus 003 Device 010: ID 256c:006e Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x256c idProduct 0x006e bcdDevice 0.00 iManufacturer 5 (error) iProduct 6 PenTablet iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 84 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 480mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 179 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 244 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.0b bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 92 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 8 can't get debug descriptor: Resource temporarily unavailable D