HUION Giano 1409 Digitizer not recognizing "click"

[roiredxsoto]

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

[roiredxsoto]

plain "listusb"

[roiredxsoto]

Session "syslog"

[waddlesplash]

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

[roiredxsoto]

USB-HID-0/7

[roiredxsoto]

USB-HID 1/7

[roiredxsoto]

USB-HID 2/7

[roiredxsoto]

USB-HID 3/7

[roiredxsoto]

USB-HID 4/7

[roiredxsoto]

USB-HID 5/7

[roiredxsoto]

USB-HID 6/7

[roiredxsoto]

USB-HID 7/7

[roiredxsoto]

Updated "listusb" as of 20190622

[lt_henry]

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?

[waddlesplash]

Yes, it probably should, at least for now.

[lt_henry]

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.

[lt_henry]

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

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

[roiredxsoto]

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

[lt_henry]

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.

[mmlr]

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?

[mmlr]

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?

[lt_henry]

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.

[roiredxsoto]

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

[X512]

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

This can be related to #15710.

[waddlesplash]

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

[roiredxsoto]

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

[waddlesplash]

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

[roiredxsoto]

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

[waddlesplash]

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

[X512]

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.

[roiredxsoto]

Good day,

Well, finally got some time. I first 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.

[roiredxsoto]

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

[roiredxsoto]

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

[roiredxsoto]

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

[waddlesplash]

Ah, it looks like an XHCI issue perhaps then.

[roiredxsoto]

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

[lt_henry]

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.

[lt_henry]

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.

[roiredxsoto]

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

[lt_henry]

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.

[roiredxsoto]

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.

[roiredxsoto]

Syslog prior to crash

[diver]

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

[roiredxsoto]

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

[roiredxsoto]

Good day,

With
Haiku raven 1 hrev55181+62 Oct 13 2021 07:38: x86_64 x86_64 Haiku

It seems that the click is recognized. I can click and drag, draw, select... haven't tested all the buttons on the digitizer nor the buttons on the pen, but the basic click that wasn't working at the begining works now.

I presume this one can be closed now?

Thanks a lot!\\ Regards,
RR

[waddlesplash]

Thanks for testing!