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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

Am 22.10.24 um 21:15 schrieb Pavel Machek:
Hi!

- interface for setting multiple LEDs at once
- interface for setting a range of LEDs at once
How are LEDs ordered? I don't believe range makes much sense.
Range would allow for efficiently changing the color of all LEDs. But i agree
that this can be considered optional and can be added later.
Yep, setting all of them makes sense. We should probably provide
backward-compatible interface for keyboards with single backlight, so
this would likely be LED class.

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.

Another usecase is probably ergonomic keyboards, but I cannot tell you a real world example atm.


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?

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

would it be:
~,1,2
tab,q,w

or:

~,1,2
tab,missing pixel,q

Regards

Werner


Yes, we'll have some number of non-present pixels, but again, I
believe that's not uncommon due to round screens, etc.

(But I'm fine with other interfaces, as long as they are "normal")

Best regards,
								Pavel





[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux