diff options
author | Jason Gerecke <jason.gerecke@wacom.com> | 2024-12-11 00:00:58 +0300 |
---|---|---|
committer | Jiri Kosina <jkosina@suse.com> | 2025-01-09 11:58:28 +0300 |
commit | 4f4ab4bcd5de770b3ed0e00a6dfeac548b2c8340 (patch) | |
tree | 49e8305b465dca976960d7f239fbde175cfec477 /tools/perf/scripts/python/task-analyzer.py | |
parent | 2a770b49b1bf00fca5473cb386eaf36d21d17d4b (diff) | |
download | linux-4f4ab4bcd5de770b3ed0e00a6dfeac548b2c8340.tar.xz |
HID: wacom: Improve behavior of non-standard LED brightness values
Assigning a non-standard brightness value to an LED can cause the value
to slowly drift downward over time as the effects of integer division
accumulate. Each time that an LED is triggered, a series of set and get
calls occur. For example, if we assume a tablet with max_hlv = 100, then
when brightness is set to "200" through sysfs, the hlv value written to
hardware will be `200*100/255 = 78`. If the LED trigger is later activated,
the hlv value will be used to determine the brightness: `78*255/100 = 198`.
This lower brightness then used to set the brightness of the next LED.
However, `198*100/255 = 77`, so the next LED ends up slightly dimmer.
Each subsequent trigger activation will cause the brightness to continue
drifting down until we reach a point where the result of integer divsion
does not introduce any new error.
This commit corrects the issue by being more careful about how we handle
scaling between the two ranges (0..max_{h,l}lv) and (0..LED_FULL).
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/task-analyzer.py')
0 files changed, 0 insertions, 0 deletions