public inbox for linux-input@vger.kernel.org
 help / color / mirror / Atom feed
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


  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