linux-kernel - Re: [PATCH 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a796f0e7-47a8-40fa-a64e-9dd56117bf78@gmx.de>
Date: Mon, 21 Oct 2024 22:26:54 +0200
From: Armin Wolf <W_Armin@....de>
To: Pavel Machek <pavel@....cz>
Cc: Werner Sembach <wse@...edocomputers.com>,
 Benjamin Tissoires <bentiss@...nel.org>, Hans de Goede
 <hdegoede@...hat.com>, Ilpo Järvinen
 <ilpo.jarvinen@...ux.intel.com>, dri-devel@...ts.freedesktop.org,
 jelle@...aa.nl, jikos@...nel.org, lee@...nel.org,
 linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-leds@...r.kernel.org, miguel.ojeda.sandonis@...il.com,
 ojeda@...nel.org, onitake@...il.com, platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO
 NB04 devices

Am 11.10.24 um 17:26 schrieb Pavel Machek:

> Hi!
>
>>> 1.
>>> https://lore.kernel.org/all/6b32fb73-0544-4a68-95ba-e82406a4b188@gmx.de/
>>> -> Should be no problem? Because this is not generally exposing wmi
>>> calls, just mapping two explicitly with sanitized input (whitelisting
>>> basically).
>> It would be OK to expose a selected set of WMI calls to userspace and sanitizing the input of protect potentially buggy firmware from userspace.
>>
> I don't believe this is good idea. Passthrough interfaces where
> userland talks directly to hardware are very tricky.
>
>> Regarding the basic idea of having a virtual HID interface: i would prefer to create a illumination subsystem instead, but i have to agree that we should be doing this
>> only after enough drivers are inside the kernel, so we can design a
>> suitable interface for them. For now, creating a virtual HID
>> interface seems to be good enough.
> I have an RGB keyboard, and would like to get it supported. I already
> have kernel driver for LEDs (which breaks input functionality). I'd
> like to cooperate on "illumination" subsystem.
>
> Best regards,
> 								Pavel

Sorry for taking a bit long to respond.

This "illumination" subsystem would (from my perspective) act like some sort of LED subsystem
for devices with a high count of LEDs, like some RGB keyboards.

This would allow us too:
- provide an abstract interface for userspace applications like OpenRGB
- provide an generic LED subsystem emulation on top of the illumination device (optional)
- support future RGB controllers in a generic way

Advanced features like RGB effects, etc can be added later should the need arise.

I would suggest that we model it after the HID LampArray interface:

- interface for querying:
  - number of LEDs
  - supported colors, etc of those LEDs
  - position of those LEDs if available
  - kind (keyboard, ...)
  - latency, etc
- interface for setting multiple LEDs at once
- interface for setting a range of LEDs at once
- interface for getting the current LED colors

Since sysfs has a "one value per file" rule, i suggest that we use a chardev interface
for querying per-LED data and for setting/getting LED colors.

I do not know if mixing sysfs (for controller attributes like number of LEDs, etc) and IOCTL
(for setting/getting LED colors) is a good idea, any thoughts?

Thanks,
Armin Wolf