Opened 21 months ago

Last modified 3 weeks 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 (11)

20181004-listusb.txt (931 bytes ) - added by roiredxsoto 21 months ago.
plain "listusb"
20181004-syslog (387.0 KB ) - added by roiredxsoto 21 months ago.
Session "syslog"
usb_hid_report_descriptor_045e_07a5_0.bin (75 bytes ) - added by roiredxsoto 13 months ago.
USB-HID-0/7
usb_hid_report_descriptor_045e_07a5_1.bin (223 bytes ) - added by roiredxsoto 13 months ago.
USB-HID 1/7
usb_hid_report_descriptor_045e_07a5_2.bin (296 bytes ) - added by roiredxsoto 13 months ago.
USB-HID 2/7
usb_hid_report_descriptor_045e_0780_0.bin (60 bytes ) - added by roiredxsoto 13 months ago.
USB-HID 3/7
usb_hid_report_descriptor_045e_0780_1.bin (86 bytes ) - added by roiredxsoto 13 months ago.
USB-HID 4/7
usb_hid_report_descriptor_256c_006e_0.bin (183 bytes ) - added by roiredxsoto 13 months ago.
USB-HID 5/7
usb_hid_report_descriptor_256c_006e_1.bin (244 bytes ) - added by roiredxsoto 13 months ago.
USB-HID 6/7
usb_hid_report_descriptor_256c_006e_2.bin (92 bytes ) - added by roiredxsoto 13 months ago.
USB-HID 7/7
20190622-listusb.txt (680 bytes ) - added by roiredxsoto 13 months ago.
Updated "listusb" as of 20190622

Download all attachments as: .zip

Change History (21)

by roiredxsoto, 21 months ago

Attachment: 20181004-listusb.txt added

plain "listusb"

by roiredxsoto, 21 months ago

Attachment: 20181004-syslog added

Session "syslog"

comment:1 by waddlesplash, 17 months ago

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

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

by roiredxsoto, 13 months ago

USB-HID-0/7

by roiredxsoto, 13 months ago

USB-HID 1/7

by roiredxsoto, 13 months ago

USB-HID 2/7

by roiredxsoto, 13 months ago

USB-HID 3/7

by roiredxsoto, 13 months ago

USB-HID 4/7

by roiredxsoto, 13 months ago

USB-HID 5/7

by roiredxsoto, 13 months ago

USB-HID 6/7

by roiredxsoto, 13 months ago

USB-HID 7/7

by roiredxsoto, 13 months ago

Attachment: 20190622-listusb.txt added

Updated "listusb" as of 20190622

comment:2 by lt_henry, 2 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, 2 months ago

Yes, it probably should, at least for now.

comment:4 by lt_henry, 2 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, 2 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, 3 weeks ago

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

comment:7 by lt_henry, 3 weeks 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, 3 weeks 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 3 weeks ago by mmlr (previous) (diff)

comment:9 by mmlr, 3 weeks 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, 3 weeks 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.

Note: See TracTickets for help on using tickets.