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

[Armin Wolf <W_Armin@gmx.de>]

Am 22.10.24 um 11:37 schrieb Pavel Machek:

> 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.

Using a virtual HID LampArray already creates two issues:

1. We have to supply device size data (length, width, height), but the driver
cannot know this.

2. It is very difficult to extend the HID LampArray interface, for example
there is no way to read the current LED color from the hardware or switch
between different modes.

A sysfs- and/or ioctl-based interface would allow us to:

1. Threat some data as optional.

2. Extend the interface later should the need arise.

Looking at the tuxedo-drivers code, it seems that the WMI interface also reports:

- preset color
- device type (touchpad, keyboard, ...)
- keyboard type (US/UK)

Making this information available through the HID LampArray protocol would be
difficult (except for the device type information).

>> Agreed on everything Hans said.
>>
>> I'll personnaly fight against any new "illumination" API as long as we
>> don't have committed users. This is the same policy the DRM folks
>>> are
> Well, and I'll personally fight against user<->kernel protocol as
> crazy as HID LampArray is.
>
> OpenRGB is not suitable hardware driver.
> 								Pavel

I agree.

The point is that we need to design a userspace API since we cannot just allow
userspace to access the raw device like with HID devices.

And since we are already forced to come up with a userspace API, then maybe it would
make sense to build a extendable userspace API or else we might end up in the exact
same situation later should another similar driver appear.

Since the HID LampArray is a hardware interface standard, we AFAIK cannot easily extend it.

Also i like to point out that OpenRGB seems to be willing to use this new "illumination" API
as long as the underlying hardware interface is properly documented so that they can implement
support for it under Windows.

I would even volunteer to write the necessary OpenRGB backend since i already contributed to
the project in the past.

Thanks,
Armin Wolf