Re: [PATCH v6 0/3] HID: generic: add LampArray support via hid-lamparray helper

[Cristian Mazzotta <cmmazzo@icloud.com>]

On 16.09.26 16:48, Aaron Erhardt wrote:
> Add a new hid-lamparray helper module and integrate it with the hid-generic
> driver.

Thanks for picking these up!

I do have two corrections on patch 3 however, and both were mine
originally, so my bad:

 - The measurement in the commit message and in the comment above
   lamparray_suspend() is wrong. It should be 12.35 W with lamps lit and
   3.14 W blanked, which is 9.21 W or about 75% of s2idle draw, not
   2.84 W / 77%. The 2.84 W was an earlier test on a local branch that
   includes full multi-zone support. It's worth noting in the comment that
   the 3.14 W still includes the lid zone, which single-zone control
   cannot reach on this device.

 - The kerneldoc for lamparray_suspend() still says it "writes zeroes to
   the rgb values only, keeping the brightness", but the call is now
   lamparray_hw_set_state(ldev, 0, 0, 0, 0). The code is fine, but the doc
   should follow it.

On your question about the default state: I think the lights "look like
they don't work" can be a real conclusion, but the cause is the intensity
default rather than the brightness default.

With led_init_state NULL, last_r/g/b stay zero, register_led copies
them into subleds[].intensity, and brightness_set reads r/g/b back out
of subled_info[].intensity. So every brightness write sends
(0, 0, 0, brightness), which is black at any brightness. The
zero-brightness quirk does not change this since it only forces RGB to
zero when brightness is already zero.

The LED class device is therefore inert rather than just dark;
systemd-backlight restoring a saved brightness, or a DE slider, or
UPower, all write brightness and see nothing happen. This is because
nothing in that stack writes multi_intensity first.

Defaulting to autonomous mode would not fix that. It would replace an
inert knob with an ignored one: the cached RGB and brightness would
describe nothing the hardware is doing, and a DE would have to
discover and write use_leds_uapi to make the node real. That is
driver-specific knowledge that desktop environments are unlikely to
carry.

On a second look, I would suggest keeping brightness at LED_OFF, but
defaulting the intensities to max_r/max_g/max_b. The device is still
dark at probe, autonomous mode is still disabled so the cached state
matches the hardware, and the first brightness write from existing
userspace lights it up. Combined with the quirk you added for Armin's
device, it stays dark even on firmware that ignores the intensity channel.

One hardware data point, since discoverability came up: on the Acer
Predator PT14-52T the keyboard brightness keys are handled entirely in
the EC and never reach the LED class device, so they cannot be relied
on to show the user that anything is controllable.

On multi-collection, I don't see myself getting to it soon. I might work
on it during fall or winter break of my university, however I cannot
guarantee it, so please do not consider it blocked on me. The ENE
controller exposes two LampArrayAttributesReport collections and
lamparray_parse_update_report() only keeps the last.

I have a local branch which includes working multi-collection support.
It's based off of Tim's v4, and it's what I referred to in the original
v4 thread; I'd be happy to send over my branch as a reference, though
porting it to v6 is not trivial.