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: <ZwlC750GojkprUKg@duo.ucw.cz>
Date: Fri, 11 Oct 2024 17:23:27 +0200
From: Pavel Machek <pavel@....cz>
To: Benjamin Tissoires <bentiss@...nel.org>
Cc: Werner Sembach <wse@...edocomputers.com>, Armin Wolf <W_Armin@....de>,
	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

Hi!

> > > There is a slight difference between mouse support and LEDs on your
> > > keyboard. The former is actually required to bring up the machine and to
> > > use it, the latter is nice to have.
> > 
> > But that's not the difference that matters. Linux is not microkernel,
> > and is trying to provide hardware abstractions. (Except for printers,
> > I guess that's because printers are often network devices).
> > 
> > Besides, mouse was not required to bring up a machine "back then".
> > 
> > Besides,
> > 
> > 1) using those keyboards in dark room without backlight is hard,
> > because their labels are translucent and not having enough contrast.
> > 
> > 2) rainbow effects make people ill.
> 
> And I agree with you here. And that's also why I agree with Werner's
> plan: have a minimum support in kernel for that with the already
> supported LED class, which is supported by UPower and others, and let
> the ones who want the fancy effects be in charge of their mess.

But the patch being proposed does not match the this description,
right?

And for hardware I seen, "minimum driver" you describe would be
already 90% of the full driver. (We can just use fbdev interface...)

Anyway, lets do it. I have rgb keyboard, you have few, and we have
Tuxedocomputers with machines where driver can't live in userspace.
If you have working driver, lets see it. I have posted my copy, but I
hae problem where keyboard functionality stops working when its
loaded. Can you help?

Then we can see how much of the driver is required for basic
functionality. I suspect it will be fairly easy to turn it into "full"
driver at that point.

> > Note how we have drivers for audio, LEDs, cameras, dunno, iio sensors,
> > none of that is required to bring system up.
> > 
> > We need driver for the WMI stuff in kernel. And that point it should
> > be pretty clear proper driver/subsystem should be done.
> 
> Yes, and again, I never said we need to provide WMI to userspace.

Good.

> What I want is:
> - provide a minimum support on Linux using already existing APIs (LED
>   class)
> - allow crazy people to do their thing if they want to have a rainbow
>   initiated by every key press
> - ensure the minimum support of the LED class is not messed up when
>   people start using the HID LampArray API.
> 
> HID LampArray is a ratified standard by a few hardware makers already[0]
> (Acer, Asus, HP, Logitech, Razer, SteelSeries and Twinkly apparently).

I have yet to see HID LampArray device.

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)