From: "Gary Guo" <gary@garyguo.net>
To: "Rahul Rameshbabu" <sergeantsagara@protonmail.com>,
"Gary Guo" <gary@garyguo.net>
Cc: <linux-input@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<rust-for-linux@vger.kernel.org>, <a.hindborg@kernel.org>,
<alex.gaynor@gmail.com>, <aliceryhl@google.com>,
<benjamin.tissoires@redhat.com>, <benno.lossin@proton.me>,
<bjorn3_gh@protonmail.com>, <boqun.feng@gmail.com>,
<dakr@kernel.org>, <db48x@db48x.net>, <jikos@kernel.org>,
<ojeda@kernel.org>, <peter.hutterer@who-t.net>,
<tmgross@umich.edu>
Subject: Re: [PATCH v6 1/2] rust: core abstractions for HID drivers
Date: Sun, 01 Mar 2026 13:17:40 +0000 [thread overview]
Message-ID: <DGRH3T072LM3.3LTULCM4FPU99@garyguo.net> (raw)
In-Reply-To: <87o6l8kpud.fsf@protonmail.com>
On Sun Mar 1, 2026 at 6:48 AM GMT, Rahul Rameshbabu wrote:
> On Fri, 27 Feb, 2026 15:27:59 +0000 "Gary Guo" <gary@garyguo.net> wrote:
>> On Sun Feb 22, 2026 at 9:56 PM GMT, Rahul Rameshbabu wrote:
>>> These abstractions enable the development of HID drivers in Rust by binding
>>> with the HID core C API. They provide Rust types that map to the
>>> equivalents in C. In this initial draft, only hid_device and hid_device_id
>>> are provided direct Rust type equivalents. hid_driver is specially wrapped
>>> with a custom Driver type. The module_hid_driver! macro provides analogous
>>> functionality to its C equivalent. Only the .report_fixup callback is
>>> binded to Rust so far.
>>>
>>> Future work for these abstractions would include more bindings for common
>>> HID-related types, such as hid_field, hid_report_enum, and hid_report as
>>> well as more bus callbacks. Providing Rust equivalents to useful core HID
>>> functions will also be necessary for HID driver development in Rust.
>>>
>>> Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
[snip]
>>> +pub trait Driver: Send {
>>> + /// The type holding information about each device id supported by the driver.
>>> + // TODO: Use `associated_type_defaults` once stabilized:
>>> + //
>>> + // ```
>>> + // type IdInfo: 'static = ();
>>> + // ```
>>> + type IdInfo: 'static;
>>> +
>>> + /// The table of device ids supported by the driver.
>>> + const ID_TABLE: IdTable<Self::IdInfo>;
>>> +
>>> + /// Called before report descriptor parsing. Can be used to mutate the
>>> + /// report descriptor before the core HID logic processes the descriptor.
>>> + /// Useful for problematic report descriptors that prevent HID devices from
>>> + /// functioning correctly.
>>> + ///
>>> + /// Optional to implement.
>>> + fn report_fixup<'a, 'b: 'a>(_hdev: &Device<device::Core>, _rdesc: &'b mut [u8]) -> &'a [u8] {
>>
>> I think this can just use a single lifetime?
>>
>
> I think the problem is when a driver decides to replace the _rdesc with
> a static lifetime report descriptor declared in the device driver. My
> example driver does not do this, but this is another common pattern in C
> HID drivers. This is why two separate lifetimes were required.
>
Lifetime on references are covariant, so it is okay to convert `&'static [u8]`
to `&'b mut [u8]`.
Best,
Gary
next prev parent reply other threads:[~2026-03-01 13:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-22 21:56 [PATCH v6 0/2] Initial work for Rust abstraction for HID device driver development Rahul Rameshbabu
2026-02-22 21:56 ` [PATCH v6 1/2] rust: core abstractions for HID drivers Rahul Rameshbabu
2026-02-22 23:39 ` Terry Junge
2026-02-23 2:47 ` Rahul Rameshbabu
2026-02-27 15:27 ` Gary Guo
2026-03-01 6:48 ` Rahul Rameshbabu
2026-03-01 12:30 ` Alice Ryhl
2026-03-01 13:17 ` Gary Guo [this message]
2026-02-22 21:56 ` [PATCH v6 2/2] rust: hid: Glorious PC Gaming Race Model O and O- mice reference driver Rahul Rameshbabu
2026-02-23 2:38 ` Greg KH
2026-02-23 2:52 ` Rahul Rameshbabu
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=DGRH3T072LM3.3LTULCM4FPU99@garyguo.net \
--to=gary@garyguo.net \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benjamin.tissoires@redhat.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=db48x@db48x.net \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=peter.hutterer@who-t.net \
--cc=rust-for-linux@vger.kernel.org \
--cc=sergeantsagara@protonmail.com \
--cc=tmgross@umich.edu \
/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