linux-kernel - Re: [PATCH v5 0/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] [day] [month] [year] [list]

Message-ID: <Z9SaYi5sKOeKTvRA@duo.ucw.cz>
Date: Fri, 14 Mar 2025 22:06:42 +0100
From: Pavel Machek <pavel@....cz>
To: Werner Sembach <wse@...edocomputers.com>
Cc: Armin Wolf <W_Armin@....de>, hdegoede@...hat.com,
	ilpo.jarvinen@...ux.intel.com, bentiss@...nel.org,
	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, cs@...edo.de,
	platform-driver-x86@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH v5 0/1] platform/x86/tuxedo: Add virtual LampArray for
 TUXEDO NB04 devices

Hi!

> > Comments from previous review were not addressed.
> > 
> > Most importantly, this is not a way to do kernel interface. We want
> > reasonable interface that can be documented and modified as needed. We
> > want to pass /dev/input to userspace, not raw HID. This is not ok.
> 
> There are already 2 endless discussions about this:
> 
> https://lore.kernel.org/all/1fb08a74-62c7-4d0c-ba5d-648e23082dcb@tuxedocomputers.com/
> 
> https://lore.kernel.org/all/73c36418-34d6-46cf-9f10-6ca5e569274f@tuxedocomputers.com/
> 
> And a shorter one before that:
> 
> https://lore.kernel.org/all/30cbbf20-08cf-a69b-4f58-359a9802e86f@tuxedocomputers.com/
> 
> The brief:
> 
> - LampArray is a standard that will hit the Linux world anyway.

Maybe. Still have to see device implementing that. LampArray will
still need /sys/class/leds for compatibility. LampArray still does not
solve effects. More importantly, it is not okay to say "kernel
interface is specified by that crazy document from 3rd party".

> - The alternative proposal via a led matrix does not even really fit
> keyboards, and does not at all fit all other device types.

We are solving keyboards, not the other device types. The other devices
can likely be handled by existing /sys/class/leds interfaces.

> Hans and Benjamin already agree with me that LampArray is the way to go.
> 
> So after over 2 years can I please have a final decision on how to implement this?

For final decisions, you'd have to talk to Linus.

(And sorry for the delay, btw).

If you want to move this forward, place a driver in
drivers/leds/keyboard. Implement /sys/class/leds interface, but make
sure interface is clearly separated from the code talking to the
firmware. Then we can review that, perhaps merge, so users will have
something, and decide what interface to use for per-key control.

LampArray is no-go. Other options are open.

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)