Hi Peter, everyone,
On 6/24/20 10:06 AM, Peter Hutterer wrote:
> On Wed, Jun 17, 2020 at 02:39:47PM -0700, Harry Cutts wrote:
>> Hi Kernel input people,
>>
>> On Chrome OS, we've observed a couple of graphics tablets getting
>> INPUT_PROP_DIRECT set despite them being traditional digitizers
>> without screens. The two tablets we've seen this for are the Huion
>> H610PRO (VID:PID 256c:006d) and the UGTABLET 10 inch PenTablet
>> (28bd:0905). Reverting "HID: input: Set INPUT_PROP_-property for
>> HID_UP_DIGITIZERS" (8473a93d1ba5385f63a128a285702ccc1d3ae2cc) fixes
>> the Huinon, at least. (We didn't get a chance to test it with the
>> UGTABLET.) Do we know if this is a shortcoming of that patch, are
>> those tablets just describing themselves incorrectly in their HID
>> descriptors? (in which case I guess we'd just have to add quirks for
>> them)
>
> fwiw, both huion and ugtablet are ones i know are regularly giving me
> troubles in libinput because what they say they do and what they do isn't in
> sync. HUION also re-uses usbids. 006d is a relatively new one I think, we
> have at least 7 different devices with 0256c:006e in libwacom and need to
> match on the name there, but with the Huion HS610 even that breaks - it uses
> the same vid/pid *and* name of other devices despite having different
> properties [1]. HS610, HS64 and your H610PRO all seem to use 000d, so...
> yay?
>
> I've CC'd Nikolai, he has much more kernel-level experience with these
> devices than I do.
These days, you can't rely on pretty much anything to identify an exact
non-Wacom graphics tablet model. With Huion's I sometimes rely on the special
string descriptor containing tablet parameters in binary, retrieving which has
side effects (switching proprietary mode on).
The only reliable way to deal with them is to only consider their reported
parameters, and not try to derive anything else from any
supposedly-identifying properties.
Regarding the original topic of this thread, it's not clear from the source
code what INPUT_PROP_DIRECT exactly means, but I see that it is synonymous
with the "Pen" (0x02) application collection usage, about which HUT 1.12 [1]
16.1 Digitizer Devices says:
A digitizer with an integrated display that allows use of a stylus. The
system must ensure that the sensed stylus position and the display
representations of that position are the same.
I also see that all replacement graphics tablet report descriptors I
contributed to the kernel use it, and that is incorrect. Shame on me.
The proper fix thus would be to replace the 0x02 usage with 0x01 in
replacement report descriptors, before application collection item, for all
(non-display) graphics tablets. 0x01, according to HUT 1.12 would mean:
A device that measures absolute spatial position, typically in two or more
dimensions. This is a generic usage; several specialized types of
digitizers are distinguished by their attributes.
That would get INPUT_PROP_POINTER assigned to them instead.
However, this might get a bit tricky as it's not always easy to find out which
exact models are display models, and then there's Huion display models, e.g.:
https://www.huion.com/pen_display/KamvasPro/kamvas-pro-24.html
which likely have the aforementioned identification issues too.
Finally, of course, we have models which don't have replacement report
descriptors we control, but which have 0x02 usage instead of 0x01 in their
firmware (I must have copied that from somewhere after all). OTOH, those
usually don't work (well) out-of-box, so probably not a big deal.
What's the practical implication of having INPUT_PROP_POINTER instead of
INPUT_PROP_DIRECT for a display-equipped graphics tablet?
Nick
[1]: Universal Serial Bus HID Usage Tables (HUT) 1.12
https://www.usb.org/sites/default/files/hut1_12.pdf
