public inbox for linux-input@vger.kernel.org
 help / color / mirror / Atom feed
From: Denis Benato <benato.denis96@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>,
	linux-input@vger.kernel.org,
	Denis Benato <denis.benato@linux.dev>,
	rust-for-linux@vger.kernel.org
Subject: hid-asus: integration of some rust code
Date: Thu, 8 Jan 2026 14:36:35 +0100	[thread overview]
Message-ID: <3e36262d-8eed-443c-afdd-beef2f8be5e9@gmail.com> (raw)

Hi all,

These past months I have been considering moving some userspace code to the kernel.

The userspace code is past of asusd and manages a feature of ASUS laptop called anime matrix:
a series of leds forming a display on the back.

The code in question was written by the previous maintainer of that application when
the kernel was not accepting any rust code, and now that it does I think it's about time
to port this well-tested feature where it belongs since it's talking directly to the hardware.


For context hid-asus must remain loaded and attached to the device as this new code
needs to manage just a subset of what is supported by the device, using the same hid_device*.

My (main) questions are the following:
- is this something that is acceptable?
- is this possible, and if yes what is the best way?
- is a mixed C/rust driver something that is accepted or does it break some rule?
- technically is this something that today the kernel has infrastructure for?

Specifically to Jiri: since you are the maintainer of hid-asus do you have any
objections in doing this?

Thanks to everyone who will respond and help me out.

Please feel free to add more considerations and answers questions I haven't
made since I'm sure there will be more anyway once I start working to this.

Best regards,
Denis B.


                 reply	other threads:[~2026-01-08 13:36 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=3e36262d-8eed-443c-afdd-beef2f8be5e9@gmail.com \
    --to=benato.denis96@gmail.com \
    --cc=denis.benato@linux.dev \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rust-for-linux@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