On Wed, Sep 10, 2025 at 01:09:10PM +0200, Hans de Goede wrote: > On 10-Sep-25 7:52 AM, Leo L. Schwab wrote: > > On Mon, Sep 08, 2025 at 11:08:29PM +0200, Hans de Goede wrote: > >> There are 2 improvements which I would like to see: > >> > >> 1. When the backlight is turned on through the button, you > >> should pass g15_led->brightness to the notify() call rather > >> then LED_FULL. GNOME will show an OSD with the new brightness > >> value shown as a mini progress bar similar to how it shows > >> speaker volume when doing mute/unmute. This mini progress > >> bar should show the actual brightness being restored, not > >> always full brightness. > >> > > If g15_led->brightness is subsequently changed, should a new > > notify() call also be made with that new brightness, i.e. should > > `hw_brightness_changed` be made to track `brightness`? > > No, hw_brightness_changed only track changes done independently > by the hw. sysfs writes should not call notify(). > Erm... So brightness_hw_changed should only sample g15_led->brightness on first probe? What should happen in this case: * Driver loads, probes G13 backlight's current color, calculates brightness to be 50, sets both `brightness` and `brightness_hw_changed` sysfs values to 50. * User presses toggle key; backlight is now off. `brightness_hw_changed` now set to 0. `brightness` and RGB values remain unchanged. * User writes to `brightness` sysfs value, setting it to 255. This does *not* turn the backlight back on; `hw_brightness_changed` remains unchanged. * User presses toggle key; backlight is back on, showing the original color, but brighter. What should brightness_hw_changed be updated to, if anything? > >> IMHO the best fix would be to use: > >> > >> hid_hw_raw_request(..., HID_INPUT_REPORT, HID_REQ_GET_REPORT); > >> [ ... ] > > > > Will give this a try. > > Got this part working. Schwab
