summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/task-analyzer.py
diff options
context:
space:
mode:
authorJason Gerecke <jason.gerecke@wacom.com>2024-12-11 00:00:58 +0300
committerJiri Kosina <jkosina@suse.com>2025-01-09 11:58:28 +0300
commit4f4ab4bcd5de770b3ed0e00a6dfeac548b2c8340 (patch)
tree49e8305b465dca976960d7f239fbde175cfec477 /tools/perf/scripts/python/task-analyzer.py
parent2a770b49b1bf00fca5473cb386eaf36d21d17d4b (diff)
downloadlinux-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