linux-kernel - [PATCH v4 0/2] HP: wmi: added support for 4 zone keyboard rgb

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-next>] [day] [month] [year] [list]

Message-ID: <20240719100011.16656-1-carlosmiguelferreira.2003@gmail.com>
Date: Fri, 19 Jul 2024 10:59:44 +0100
From: Carlos Ferreira <carlosmiguelferreira.2003@...il.com>
To: hdegoede@...hat.com,
	ilpo.jarvinen@...ux.intel.com
Cc: mustafa.eskieksi@...il.com,
	platform-driver-x86@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Carlos Ferreira <carlosmiguelferreira.2003@...il.com>
Subject: [PATCH v4 0/2] HP: wmi: added support for 4 zone keyboard rgb

Hi,
This driver now supports brightness control and an initial version of mode
control (all brightness values to 0 means off and otherwise its on).

About this mode control, it presents some limitations and problems.
The first problems i noticed happens when setting the keyboard to
off mode with software and on with hardware.

Example: If i have 2 zones with brightness != 0 and use sw to turn the
keyboard off, when turning it back on with the Fn + key combo, only the
last zone that received brightness 0 will be back and not both of them
as i would expect given that was effectively the state before the user
decided to turn it off (this is what happens on Win).

The other problem is a bit worse, and it happens because of the small time
frame in between me pressing the Fn + Key combo and fourzone_set_state()
actually running. If a userspace program sets a brightness/color value
to a zone in this interval, the driver will reach an inconsistent state,
making it pretty much useless as it happens frequently. According to my
tests, setting a color every 0.2s or even slower is enough to trigger this.
It could easily happen with software generated effects.

Both of this problems would be solved using a proper system to control
modes instead of trying to encode them in brightness values.

As far as i know, the multicolor LED API does not have this (maybe it should).
If it really doesn't have mode support, then creating a sysfs entry/attribute
in "/sys/devices/platform/hp-wmi/leds" would allow for proper mode control
and the mc LED API would also function as expected.

About the Kconfig file, i had to use "select" instead of "depends"
because i was running into a dependency cycle issue.

Changes in v4:
 - Added support for brightness control
 - Added initial support for on/off mode control
 - Changed from KEY_KBDILLUMTOGGLE to led_classdev_notify_brightness_hw_changed()
 - Changed from a single rgb subled to 3 subleds (R, G, B)
 - Added the LED_RETAIN_AT_SHUTDOWN flag to better mimic the Windows behaviour
 - Added the dependency on LEDS_CLASS_MULTICOLOR
 - Included some documentation for the LED API
Changes in v3:
 - Moved to the multicolor led api
 - Mapped the wmi backlight toggle event to KEY_KBDILLUMTOGGLE
 - Some other minor changes
Changes in v2:
 - Rearranged code to remove forward declarations
 - Changed from sprintf() to sysfs_emit()
 - Fixed some identation and coding style problems
 - Switched from manual bit manipulation to GENMASK(x, y) + FIELD_PREP(XX, )
 - #define'ed magic constants

Carlos Ferreira (2):
  HP: wmi: added support for 4 zone keyboard rgb
  HP: wmi: Add documentation for the LED API naming scheme

 Documentation/leds/leds-class.rst |  40 +++++
 drivers/platform/x86/hp/Kconfig   |   1 +
 drivers/platform/x86/hp/hp-wmi.c  | 282 +++++++++++++++++++++++++++++-
 3 files changed, 314 insertions(+), 9 deletions(-)

-- 
2.45.2