linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Tero Kristo <tero.kristo@linux.intel.com>
Cc: "open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
	Jiri Kosina <jikos@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Peter Hutterer <peter.hutterer@who-t.net>
Subject: Re: [RFCv2 0/8] USI stylus support series
Date: Tue, 30 Nov 2021 15:44:56 +0100	[thread overview]
Message-ID: <CAO-hwJLq6Jnvos=CR_-D6FD-7W56q2eYRVyRMbmE5NFaXLHrng@mail.gmail.com> (raw)
In-Reply-To: <20211126130141.1811848-1-tero.kristo@linux.intel.com>

Hi Tero,

On Fri, Nov 26, 2021 at 2:02 PM Tero Kristo <tero.kristo@linux.intel.com> 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).

That part seems to be almost good for now. I have a few things to check:
- patch2: "HID: hid-input: Add suffix also for HID_DG_PEN" I need to
ensure there are no touchscreens affected by this (there used to be a
mess with some vendors where they would not declare things properly)
- patch5: "HID: core: map USI pen style reports directly" this one
feels plain wrong. I would need to have a look at the report
descriptor but this is too specific in a very generic code

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

After a few more thoughts, I wondered what your input is on this. We
should be able to do the very same with plain hidraw... However, you
added a `hid/raw_event` processing that will still be kept in the
kernel, so maybe bpf would be useful for that at least.

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

Yeah, I also rebased on top of 5.16 shortly after sharing that branch
and got roughly the same last fix (HID: bpf: compile fix for
bpf_hid_foreach_rdesc_item). I am *very* interested in your "HID: bpf:
execute BPF programs in proper context" because that is something that
was bothering me a lot :)

"HID: bpf: add expected_attach_type to bpf prog during detach" is
something I'll need to bring in too

but "HID: bpf: fix file mapping" is actually wrong. I initially wanted
to attach BPF programs to hidraw, but shortly realized that this is
not working because the `hid/rdesc_fixup` kills the hidraw node and so
releases the BPF programs. The way I am now attaching it is to use the
fd associated with the modalias in the sysfs file (for instance: `sudo
./hid_surface_dial /sys/bus/hid/devices/0005:045E:091B.*/modalias`).
This way, the reference to the struct hid_device is kept even if we
disconnect the device and reprobe it.

Thanks again for your work, and I'd be curious to have your thoughts
on hid-bpf and if you think it is better than hidraw/evdev write/new
ioctls for your use case.

Cheers,
Benjamin

>
> -Tero
>
> [1] https://github.com/t-kristo/linux/tree/usi-5.16-rfc-v2-bpf
>
>


  parent reply	other threads:[~2021-11-30 14:45 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
2021-11-30 14:44 ` Benjamin Tissoires [this message]
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='CAO-hwJLq6Jnvos=CR_-D6FD-7W56q2eYRVyRMbmE5NFaXLHrng@mail.gmail.com' \
    --to=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 \
    --cc=mika.westerberg@linux.intel.com \
    --cc=peter.hutterer@who-t.net \
    --cc=tero.kristo@linux.intel.com \
    /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).