Opened 3 years ago

Last modified 2 months ago

#14592 new bug

HUION Giano 1409 Digitizer not recognizing "click"

Reported by: roiredxsoto Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Drivers/Input/USB-HID Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Good day,

I was testing a HUION Giano 1409 on Haiku x64

~> uname -a
Haiku Cygnvs 1 hrev52379 Oct  1 2018 14:59:14 x86_64 x86_64 Haiku

This is a cheap wireles digitizer A4+ size. Works in linux (not the tablet buttons), but pressure sensitivity and all the important things. I plugged to my Home Haiku Box, AMD A8, to check if have same issues I have at work with the Wacom on Ryzen and:

  • The wireless tablet is recognized as Tablet (no buttons worked, as expected, and I don't expect them to work, as they don't work on Linux neither)
  • The Pen can move the cursor around the screen without any issues nor glitches
  • But, no click recorded, meaning can't use the pen to select anything in the Tracker, or any app, neither to draw anything in Krita.
  • Therefore, no pressure sensitivity

Attached are the relevant files. Thanks and Regards, RR

Attachments (16)

20181004-listusb.txt (931 bytes ) - added by roiredxsoto 3 years ago.
plain "listusb"
20181004-syslog (387.0 KB ) - added by roiredxsoto 3 years ago.
Session "syslog"
usb_hid_report_descriptor_045e_07a5_0.bin (75 bytes ) - added by roiredxsoto 22 months ago.
USB-HID-0/7
usb_hid_report_descriptor_045e_07a5_1.bin (223 bytes ) - added by roiredxsoto 22 months ago.
USB-HID 1/7
usb_hid_report_descriptor_045e_07a5_2.bin (296 bytes ) - added by roiredxsoto 22 months ago.
USB-HID 2/7
usb_hid_report_descriptor_045e_0780_0.bin (60 bytes ) - added by roiredxsoto 22 months ago.
USB-HID 3/7
usb_hid_report_descriptor_045e_0780_1.bin (86 bytes ) - added by roiredxsoto 22 months ago.
USB-HID 4/7
usb_hid_report_descriptor_256c_006e_0.bin (183 bytes ) - added by roiredxsoto 22 months ago.
USB-HID 5/7
usb_hid_report_descriptor_256c_006e_1.bin (244 bytes ) - added by roiredxsoto 22 months ago.
USB-HID 6/7
usb_hid_report_descriptor_256c_006e_2.bin (92 bytes ) - added by roiredxsoto 22 months ago.
USB-HID 7/7
20190622-listusb.txt (680 bytes ) - added by roiredxsoto 22 months ago.
Updated "listusb" as of 20190622
IMG_20200720_191938215.jpg (3.2 MB ) - added by roiredxsoto 9 months ago.
Pciture of KDL when pluging in the Huion to the USB2 port
IMG_20200724_173255024.jpg (686.6 KB ) - added by roiredxsoto 9 months ago.
Picture of KDL after entering from desktop and pluging in the usb wire, and performing "syslog | tail 25"
IMG_20200724_173608799.jpg (726.6 KB ) - added by roiredxsoto 9 months ago.
Terminal output performing "tail -f /boot/system/var/log/syslog", after pluging the USB wire, entering non recoverable KDL
IMG_20200724_173644276.jpg (516.0 KB ) - added by roiredxsoto 9 months ago.
KDL picture corresponding to the "tail -f /boot/system/var/log/syslog" trip to KDL after pluging the USB wire
syslog.old (512.0 KB ) - added by roiredxsoto 2 months ago.
Syslog prior to crash

Change History (43)

by roiredxsoto, 3 years ago

Attachment: 20181004-listusb.txt added

plain "listusb"

by roiredxsoto, 3 years ago

Attachment: 20181004-syslog added

Session "syslog"

comment:1 by waddlesplash, 2 years ago

Component: Drivers/USBDrivers/Input/USB-HID
Owner: changed from mmlr to nobody

Please also attach USB-HID report descriptors, from /tmp.

by roiredxsoto, 22 months ago

USB-HID-0/7

by roiredxsoto, 22 months ago

USB-HID 1/7

by roiredxsoto, 22 months ago

USB-HID 2/7

by roiredxsoto, 22 months ago

USB-HID 3/7

by roiredxsoto, 22 months ago

USB-HID 4/7

by roiredxsoto, 22 months ago

USB-HID 5/7

by roiredxsoto, 22 months ago

USB-HID 6/7

by roiredxsoto, 22 months ago

USB-HID 7/7

by roiredxsoto, 22 months ago

Attachment: 20190622-listusb.txt added

Updated "listusb" as of 20190622

comment:2 by lt_henry, 11 months ago

Didnt have time to parse all descriptors, but Im sure are crap. I have a digitizer with same problem. What happens to mine (waltop) is no button is reported to input_server because... it has not buttons in the report descriptor and TabletProtocolHandler looks for a Pen Tip item but nothing is done with that.

Should Tip produce left-click events?

comment:3 by waddlesplash, 11 months ago

Yes, it probably should, at least for now.

comment:4 by lt_henry, 11 months ago

From USB HID Usage tables document, section 16.4:

"The system typically maps Tip Switch to a primary button in a non-pen context."

And the same for Barrel Switch at secondary button.

I can provide a patch for that, at usb_hid, but i am afraid this was already discussed years ago... Perharps the tablet_movement structure should fit both tips and buttons status and let input server choose.

comment:5 by lt_henry, 11 months ago

Ok, I've submitted a patch... (my first patch since svn, sorry if I messed up)

https://review.haiku-os.org/c/haiku/+/2685

comment:6 by roiredxsoto, 10 months ago

Is this patch merged?, Can I test it already?

comment:7 by lt_henry, 10 months ago

No, it is not. There are some minor style issues but... I guess Michael does not agree with the proposed solution. I can try to solve this using a different strategy but I need some clear instructions to proceed.

comment:8 by mmlr, 10 months ago

I did not disagree with the proposed solution, I merely am not really in a position to judge it. That's why I've just pointed out the style and structural issues and was asking for prior discussion references.

My general concern is that the patch maps the two functions to the buttons 0/1, which shadows any possible other buttons and makes them indistinguisable from them. This means that a user cannot reassign them without also changing the buttons. Reporting them separately might allow that. Whether or not there are any buttons to consider I don't know.

Back then stippi said to do the same thing as in the wacom driver as that is apparently how it is documented in the BeBook. Why does that make it unusable? And isn't assigning tip to button 0 making it a primary button as mentioned already?

Last edited 10 months ago by mmlr (previous) (diff)

comment:9 by mmlr, 10 months ago

Possibly tip and barrel could be reported first if present and the buttons could be shifted up? This would make them all unique at least. Again I do not really know what devices usually come with, do they have buttons at all? Do all have tip/barrel? What is the primary use of these and how do they work on other systems?

comment:10 by lt_henry, 10 months ago

Yeah, the patch is a short-term solution. Reading again USB Usage Tables I see that it recommends mapping to 0/1 buttons in a "non-pen context". Whatever that means.

I also prefer to push all sensor state down to user-space and perform the heuristics there based on context, user settings,... I guess input server must be modified, but I dont have the Haiku architecture knowledge for that. I can try it, however :D

Why does that make it unusable?

Some digitizers dont expose buttons at report descriptor. It is not clear to me if this is usb compliant or not.

And isn't assigning tip to button 0 making it a primary button as mentioned already?

But... where is this done?

Again I do not really know what devices usually come with, do they have buttons at all? Do all have tip/barrel?

I hoped you may know better than me :D From my experience, all I can say is that most of the will expose at least, a tip with pressure but no buttons. But that's based on my personal experience.

What is the primary use of these

Some digitizers have a mice device and a stylus:

https://www.trust.com/es/product/15357-sketch-design-tablet-mouse

and how do they work on other systems?

Linux has tons of quirks for this kind of devices, but doesnt seem to provide a custom report descriptor for mine. I should take a deeper look to Linux source and see how its solved.

by roiredxsoto, 9 months ago

Attachment: IMG_20200720_191938215.jpg added

Pciture of KDL when pluging in the Huion to the USB2 port

comment:11 by X512, 9 months ago

Pciture of KDL when pluging in the Huion to the USB2 port

This can be related to #15710.

comment:12 by waddlesplash, 9 months ago

Seems strange, because the fix to #15710 should probably have fixed this also...

comment:13 by roiredxsoto, 9 months ago

Good day,

It is indeed strange. When pluging in the USB wire causes KDL, with the wireless receiver, no KDL, but no click. So 15710 hasn't fixed this issue yet, at least for this digitizer. Tried both, direct connection to the Haikbox USB 2.0 and through the KVM, both report KDL on plug in.

Actually I was expecting "normal" behaviour through wired connection. Indeed strange.

Regards, RR

Last edited 9 months ago by roiredxsoto (previous) (diff)

comment:14 by waddlesplash, 9 months ago

Please run "syslog | tail 25" at the KDL prompt and post a picture of that.

comment:15 by roiredxsoto, 9 months ago

Good day waddlesplash. Nope, can't run "syslog | tail 25" because when the kdebug> prompt appears, nothing happens. Even if I type, no characters on the screen. Even typing blind and pressing return (tried a couple of times), still nothing happens, screen doesn't change, just stays there until forced shutdown (10sec power button). Sorry.

Regards, RR

comment:16 by waddlesplash, 9 months ago

Try entering KDL manually once before plugging the new device in, and see if you can type and exit then.

comment:17 by X512, 9 months ago

Nope, can't run "syslog | tail 25" because when the kdebug> prompt appears, nothing happens.

You can run tail -f /boot/system/var/log/syslog in Terminal and put Terminal window to bottom of screen.

comment:18 by roiredxsoto, 9 months ago

Good day,

Well, finally got some time. I first did what @waddlesplash said.
1- Entered KDL, exited (went fine),
2- Entered KDL and plugged the USB cable. nothing happened. Exited KDL to desktop without issues. The pen tablet now responds to movement, though not to click. Disconnected the USB wire. Nothing happened.
3- Performed the KDL command @waddlesplash suggested. Pic attached.
4- Launched terminal, typed what @X512 said, and plugged the USB wire, result KDL, non recoverable. Attached pics of Terminal output and KDL.

Any further info required, let me know. Thanks both. Regards, RR

Last edited 9 months ago by roiredxsoto (previous) (diff)

by roiredxsoto, 9 months ago

Attachment: IMG_20200724_173255024.jpg added

Picture of KDL after entering from desktop and pluging in the usb wire, and performing "syslog | tail 25"

by roiredxsoto, 9 months ago

Attachment: IMG_20200724_173608799.jpg added

Terminal output performing "tail -f /boot/system/var/log/syslog", after pluging the USB wire, entering non recoverable KDL

by roiredxsoto, 9 months ago

Attachment: IMG_20200724_173644276.jpg added

KDL picture corresponding to the "tail -f /boot/system/var/log/syslog" trip to KDL after pluging the USB wire

comment:19 by waddlesplash, 9 months ago

Ah, it looks like an XHCI issue perhaps then.

in reply to:  19 comment:20 by roiredxsoto, 8 months ago

Replying to waddlesplash:

Ah, it looks like an XHCI issue perhaps then.

Then should I do anything about it in the BIOS? Any other test I should be doing?

Regards,
RR

comment:21 by lt_henry, 8 months ago

Back to Tip/Barrel and Buttons mapping... suggestions? Without mapping both sensors to left and right buttons, some digitizers wont work with default report descriptor. Maybe, we can provide quirks for them, replacing tip and barrel for buttons.

Imho, pushing down tip and barrel to apps is pointless :D I mean, it would render this tablets useless in desktop, so, I only see three options:

  • Report descriptor quirk (ugly :S )
  • Map buttons at usb_hid (my patch)
  • Map buttons at input server (maybe, with a toggle option elsewhere)

I like the third one. I can start modifiying tablet_movement structure and pushing down to input server and default to left and right click there.

comment:22 by lt_henry, 8 months ago

I see tablet_movement holds a boolean field for eraser mode, perhaps, would be better to replace with a uint32 switches field holding tip, barrel, eraser and other common digitizer switches.

comment:23 by roiredxsoto, 5 months ago

Good day,

This pen digitizer can work in two modes, wired and wireless. I just was carrying out some testing ( hrev54705 )today and found out the following:

Wired mode (tested on the revived Laptop):
1- The digitizer does not get listed on listusb
2- Using the pen on the digitizer results in nothing. No cursor movement, no response.
3- Nonetheless, plugging in and out does not cause KDL

Wireless mode (tested on the revived Laptop):
1- The digitizer gets listed on listusb

256c:006e /dev/bus/usb/7/0/0 "TABLET" "Pen Tablet" ver. 0100

2- The cursor is moving when I move the pen around, but no click yet
3- Nonetheless, plugging in and out does not cause KDL

There is some improvement here, though still not functional.

Please, let me know what can I do to help get this working.
Regards,
RR

Last edited 5 months ago by roiredxsoto (previous) (diff)

in reply to:  6 comment:24 by lt_henry, 3 months ago

Replying to roiredxsoto:

Is this patch merged?, Can I test it already?

There is a fix already available (54918). Can you please try it? It should allow generic digitizers to produce click events.

comment:25 by roiredxsoto, 2 months ago

Good day,

~> uname -a
Haiku Corvus 1 hrev54945 Feb  5 2021 08:46:28 x86_64 x86_64 Haiku

Well, well... Something happened lately, maybe that fix. Today I can use the digitizer plugged into the usb switch, with pressure sensitivity, which is a big improvement.

Nonetheless, there is a problem still, and that it causes system crash, and trip to KDL when plugging in the digitizer to the USB port. If the digitizer is plugged in before booting Haiku, Haiku boots normally and the digitizer is usable, responds to clicks, and even to pressure sensitivity (tested on Krita just right now).

Unplugging the digitizer doesn't affect at all. Can keep using the computer without issues. Plugging back the digitizer to the USB port sends back to KDL. KDL is useless though, as doesn't respond to anything, no keyboard input whatsoever, so there is no way to save a report.

Attached is the Syslog.old before the crashes.

It's a great improvement though. Thanks for your work. Kudos!!!!
Regards,
RR

It's a great improvement though.

by roiredxsoto, 2 months ago

Attachment: syslog.old added

Syslog prior to crash

comment:26 by diver, 2 months ago

Can you try entering KDL using /bin/kernel_debugger and exiting it once before plugging back the digitizer?

comment:27 by roiredxsoto, 2 months ago

Good day @Diver,

If I enter KDL the way you pointed out, pc stays there and there is no way to exit. No keyboard input. Need hard shutdown and power on again.

Regards,
RR

Note: See TracTickets for help on using tickets.