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: <Zxk2vD5FHA2w2jTL@duo.ucw.cz>
Date: Wed, 23 Oct 2024 19:47:40 +0200
From: Pavel Machek <pavel@....cz>
To: Werner Sembach <wse@...edocomputers.com>
Cc: Armin Wolf <W_Armin@....de>, Hans de Goede <hdegoede@...hat.com>,
	Benjamin Tissoires <bentiss@...nel.org>,
	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!

> > > > > Personally I really like the idea to just emulate a HID LampArray device
> > > > > for this instead or rolling our own API.  I believe there need to be
> > > > > strong arguments to go with some alternative NIH API and I have not
> > > > > heard such arguments yet.
> > > > If you don't want "some alternative API", we already have perfectly
> > > > working API for 2D arrays of LEDs. I believe I mentioned it before
> > > > :-). Senzrohssre.
> > > We may have to support 3D arrays of LEDs, so using a simple framebuffer
> > > would likely cause trouble.
> > Do you have pointer for device that is 3D?
> 
> The example from the spec is a keyboard with lightbars on the side, the we
> actually sell notebooks with similar led configurations (mostly on the front
> and not on the side). Example is the Sirius I implemented which has a not
> yet implemented lightbar on the front.

I also have lightbar on the keyboard. Put it is still close-enough to
2D. As would be bars on side or bar in front.

> > OpenRGB manages to map keyboard into plane... so what I'd propose is
> > this:
> > 
> > Framebuffer
> > Information for each pixel:
> > 	    present ? (displays with missing pixels are pretty common)
> > 	    list of keys related to this pixel
> > 	    width, height, length (if we know them)
> > 
> > Pixels map to keys M:N.
> 
> How would iso-enter be mapped here?

I guess it depends on number of LEDs under the enter. I have one LED
under it, so it would be one pixel.

> How would the q-key be mapped relative the the 1-key? (they are exactly
> halve a key offset)

That would have to be decided. I remember this from openrgb:

https://www.gamingonlinux.com/2022/01/openrgb-gets-greately-expanded-hardware-support-in-the-07-release/

and that's one option.

> ~,1,2
> tab,missing pixel,q

I'd go with this one. OpenRGB does it on one screenshot, but there are
other screenshots. Advantage is that if someone does TAB with two
LEDs, we'll have place for it.

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)