#14592 closed bug (fixed)
HUION Giano 1409 Digitizer not recognizing "click"
Reported by: | roiredxsoto | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta4 |
Component: | Drivers/Input/HID/USB | 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)
Change History (46)
by , 6 years ago
Attachment: | 20181004-listusb.txt added |
---|
comment:1 by , 6 years ago
Component: | Drivers/USB → Drivers/Input/USB-HID |
---|---|
Owner: | changed from | to
Please also attach USB-HID report descriptors, from /tmp.
comment:2 by , 5 years 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:4 by , 5 years 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 , 5 years ago
Ok, I've submitted a patch... (my first patch since svn, sorry if I messed up)
comment:7 by , 5 years 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 , 5 years 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?
comment:9 by , 5 years 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 , 5 years 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 , 4 years ago
Attachment: | IMG_20200720_191938215.jpg added |
---|
Pciture of KDL when pluging in the Huion to the USB2 port
comment:11 by , 4 years ago
Pciture of KDL when pluging in the Huion to the USB2 port
This can be related to #15710.
comment:12 by , 4 years ago
Seems strange, because the fix to #15710 should probably have fixed this also...
comment:13 by , 4 years 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
comment:14 by , 4 years ago
Please run "syslog | tail 25" at the KDL prompt and post a picture of that.
comment:15 by , 4 years 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 , 4 years ago
Try entering KDL manually once before plugging the new device in, and see if you can type and exit then.
comment:17 by , 4 years 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 , 4 years 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
by , 4 years 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 , 4 years 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 , 4 years 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:20 by , 4 years 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 , 4 years 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 , 4 years 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 , 4 years 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
comment:24 by , 4 years 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 , 4 years 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.
comment:26 by , 4 years ago
Can you try entering KDL using /bin/kernel_debugger and exiting it once before plugging back the digitizer?
comment:27 by , 4 years 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
comment:28 by , 3 years ago
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
comment:29 by , 3 years ago
Milestone: | Unscheduled → R1/beta4 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
plain "listusb"