lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aMG9L2566Hh6b0Kf@ewhac.org>
Date: Wed, 10 Sep 2025 11:02:23 -0700
From: "Leo L. Schwab" <ewhac@...ac.org>
To: Hans de Goede <hansg@...nel.org>
Cc: Kate Hsuan <hpa@...hat.com>, Jiri Kosina <jikos@...nel.org>,
	Benjamin Tissoires <bentiss@...nel.org>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] HID: lg-g15 - Add support for Logitech G13.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ