linux-kernel - Re: [PATCH] HID: input: Add support for USI style events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6d820385-6118-4d90-6ffe-a9df20febe75@linux.intel.com>
Date:   Fri, 7 Oct 2022 14:25:47 +0300
From:   Tero Kristo <tero.kristo@...ux.intel.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Jiri Kosina <jikos@...nel.org>
Cc:     linux-input@...r.kernel.org, benjamin.tissoires@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] HID: input: Add support for USI style events

On 30/09/2022 21:15, Dmitry Torokhov wrote:
> On Fri, Sep 30, 2022 at 11:09:12AM +0200, Jiri Kosina wrote:
>> On Thu, 25 Aug 2022, Jiri Kosina wrote:
>>
>>>> Add support for Universal Stylus Interface (USI) style events to the HID
>>>> input layers. The events are mapped as follows:
>>>>
>>>> type	id	event
>>>> ----	--	-----
>>>> MSC(4)	6	Pen ID
>>>> MSC(4)	7	Pen Color
>>>> MSC(4)	8	Pen Line Style Ink
>>>> MSC(4)	9	Pen Line Style Pencil
>>>> MSC(4)	0xa	Pen Line Style Highlighter
>>>> MSC(4)	0xb	Pen Line Style Chisel Marker
>>>> MSC(4)	0xc	Pen Line Style Brush
>>>> MSC(4)	0xd	Pen No Preferred Line Style
>>>> ABS(3)	0x1c	Pen Line Width
>>>>
>>>> All the listed MSC events are new, the ABS one is mapped to an existing
>>>> event.
>>> Dmitry, could you please Ack the MSC_PEN_* additions?
>> Dmitry, friendly ping on this one.
> Very sorry, I meant to answer and forgot...
>
> We need good descriptions of what exactly these events are, and when and
> how userspace should expect/use them.
>
> In general, I am wary of MISC_* namespace as it needs to be sent in
> every packet as we do not retain state and do not give userspace way of
> querying it, unlike ABS_* or KEY_* or number of other events.

Hmm ok, do you have a counter proposal for this? Should all of them move 
to some other namespace? I have been using Benjamin's HID-BPF support to 
handle the quirks of the USI support so far, and the events are passed 
via that interface also, allowing for writing of the parameters too.

However, it would seem like it would be good to pass the details via the 
input event route also, if the user does not want to tap to the HID-BPF 
for whatever reason, and the pens do work as is, except for the new 
parameters.

>
> Also, what do we do with multiple pens used at once? Maybe we do not
> have such devices now, but multitouch devices did not exist in the
> beginning either, and now are ubiquitous.

Multiple pen support is expected to happen somewhere in future, the spec 
sort of supports it already but the controllers really don't (and I am 
not quite sure how flexible the controller interface is for multiple pen 
support either.) Should we use ABS_MT_* for the new params?

-Tero

>
> Thanks.
>