linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tero Kristo <tero.kristo@linux.intel.com>
To: Hyungwoo Yang <hyungwoo.yang@gmail.com>,
	linux-input@vger.kernel.org, benjamin.tissoires@redhat.com,
	jikos@kernel.org, mika.westerberg@linux.intel.com
Cc: linux-kernel@vger.kernel.org, dmitry.torokhov@gmail.com,
	peter.hutterer@who-t.net
Subject: Re: [RFCv2 0/8] USI stylus support series
Date: Tue, 30 Nov 2021 16:41:47 +0200	[thread overview]
Message-ID: <447d53c6-280d-da3d-fb04-3fd161aa28f4@linux.intel.com> (raw)
In-Reply-To: <1bcb6a07-c1c2-c8c6-a0a7-4eace372dd5e@gmail.com>

Hi Hyungwoo,

On 30/11/2021 08:36, Hyungwoo Yang wrote:
> Hi Tero,
>
>
> I have a question. As you know, USI provides a room for vendors to 
> differentiate their stylus. If a vendor wants to add reach features to 
> differentiate their stylus. Do you think the vendor needs to come up 
> with like HID-USI-<vendor>.c to configure the corresponding 
> usages(vendor-defined data) ? or we should use other approach ? like 
> register callbacks via HID-core ?

I think this depends quite a bit on what kind of features we are talking 
about. Looking at this series, we have:

- hid-core changes to add new event codes / add support for these

- bfp modifications to support caching and write feature for the new 
event codes (technically they can be written already via /dev/hidraw 
directly, but the interface is bit clumsy, so we improve it with BFP)

So, depending on the feature you want to add, you can take either way, 
but probably hacking with BPF is going to be easiest. Vendor could even 
write their own BPF tool. Also, please note that the location of 
samples/bpf/hid_usi* is not going to remain, there will most likely be 
an external repository where the new HID related BPF tools are going to 
maintained, Benjamin had some thoughts about that already.

-Tero


>
> -Hyungwoo
>
> On 11/26/21 5:01 AM, Tero Kristo wrote:
>> Hi,
>>
>> This series is an update based on comments from Benjamin. What is done
>> is this series is to ditch the separate hid-driver for USI, and add the
>> generic support to core layers. This part basically brings the support
>> for providing USI events, without programmability (patches 1-6).
>>
>> Additionally, a HID-BPF based sample is provided which can be used to
>> program / query pen parameters in comparison to the old driver level
>> implementation (patches 7-8, patch #8 is an incremental change on top of
>> patch #7 which just converts the fifo to socket so that the client can
>> also get results back from the server.)
>>
>> The whole series is based on top of Benjamin's hid-bpf support work, and
>> I've pushed a branch at [1] with a series that works and brings in
>> the dependency. There are also a few separate patches in this series to
>> fix the problems I found from Benjamin's initial work for hid-bpf; I
>> wasn't able to get things working without those. The branch is also
>> based on top of 5.16-rc2 which required some extra changes to the
>> patches from Benjamin.
>>
>> -Tero
>>
>> [1] https://github.com/t-kristo/linux/tree/usi-5.16-rfc-v2-bpf
>>
>>
>>
>>

  reply	other threads:[~2021-11-30 14:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26 13:01 [RFCv2 0/8] USI stylus support series Tero Kristo
2021-11-26 13:01 ` [RFCv2 1/8] HID: Add map_msc() to avoid boilerplate code Tero Kristo
2021-11-26 13:01 ` [RFCv2 2/8] HID: hid-input: Add suffix also for HID_DG_PEN Tero Kristo
2021-11-26 13:01 ` [RFCv2 3/8] HID: core: Add support for USI style events Tero Kristo
2021-11-26 13:01 ` [RFCv2 4/8] HID: input: Make hidinput_find_field() static Tero Kristo
2021-11-26 13:01 ` [RFCv2 5/8] HID: core: map USI pen style reports directly Tero Kristo
2021-11-26 13:01 ` [RFCv2 6/8] HID: debug: Add USI usages Tero Kristo
2021-11-26 13:01 ` [RFCv2 7/8] samples: hid: add new hid-usi sample Tero Kristo
2021-11-26 13:01 ` [RFCv2 8/8] samples: hid: convert USI sample to use unix socket for comms Tero Kristo
2021-11-30  6:36 ` [RFCv2 0/8] USI stylus support series Hyungwoo Yang
2021-11-30 14:41   ` Tero Kristo [this message]
2021-11-30 14:44 ` Benjamin Tissoires
2021-11-30 16:13   ` Tero Kristo
2021-12-08 14:56     ` Benjamin Tissoires
2021-12-09  8:55       ` Tero Kristo
2021-12-09 13:53         ` Benjamin Tissoires
2021-12-10  8:50           ` Tero Kristo

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=447d53c6-280d-da3d-fb04-3fd161aa28f4@linux.intel.com \
    --to=tero.kristo@linux.intel.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hyungwoo.yang@gmail.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=peter.hutterer@who-t.net \
    /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).