linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tero Kristo <tero.kristo@linux.intel.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Jiri Kosina <jikos@kernel.org>
Cc: linux-input@vger.kernel.org, benjamin.tissoires@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] HID: input: Add support for USI style events
Date: Fri, 7 Oct 2022 14:25:47 +0300	[thread overview]
Message-ID: <6d820385-6118-4d90-6ffe-a9df20febe75@linux.intel.com> (raw)
In-Reply-To: <YzcyUgLbZ2pVJSMO@google.com>


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.
>

      reply	other threads:[~2022-10-07 11:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12 10:35 [PATCH] HID: input: Add support for USI style events Tero Kristo
2022-08-25  9:41 ` Jiri Kosina
2022-09-30  9:09   ` Jiri Kosina
2022-09-30 18:15     ` Dmitry Torokhov
2022-10-07 11:25       ` Tero Kristo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d820385-6118-4d90-6ffe-a9df20febe75@linux.intel.com \
    --to=tero.kristo@linux.intel.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).