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

[Aaron Erhardt]

Am 16.09.26 um 18:15 schrieb Cristian Mazzotta:
> 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.

Ack. Will be fixed in v7.

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

I think this is a good idea. In general, the default should probably
either set intensities to max_(r|g|b) or brightness to max_brightness.
This would reduce the amount of writes necessary to see a result and I
agree that probably the brightness knob is most likely to be used by
userspace. Still, I'd like to have some more feedback, especially from
the maintainers before integrating this behavior in v7.

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

I could have a look at your branch, but I think it's better to wait for
this series to be merged before exploring more advanced features. I
can't guarantee that I will work on that actively, especially since I
don't have access to such hardware, but I'm curious to see what changes
you have applied to make it work with v4.