| Age | Commit message (Collapse) | Author |
|---|
|
./scripts/get_abi.pl is warning about duplicated symbol
definition:
Warning: /sys/class/backlight/<backlight>/l1_daylight_max is defined 2 times: ./Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870:4 ./Documentation/ABI/testing/sysfs-class-backlight-adp8860:12
What happens is that 3 drivers use the same pattern to report
max and dim setting for different ambient light zones.
It should be noticed that the adp8870 doc was missing an
entry for l1_daylight_dim, which was fixed on this patch.
While the ambient light zone is device-specific, the sysfs
definition is actually common. So, unify them at:
Documentation/ABI/testing/sysfs-class-backlight
and use as the contact point, the e-mail reported by
get_maintainers.pl for the subsystem.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/c13c6ebd03cd04a0d15d89018f8d529918fc0a73.1621413933.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
Both adp8860 and adp8870 define some extensions to the
backlight class. This causes warnings:
Warning: /sys/class/backlight/<backlight>/ambient_light_level is defined 2 times: /sys/class/backlight/<backlight>/ambient_light_level:8 /sys/class/backlight/<backlight>/ambient_light_level:30
Warning: /sys/class/backlight/<backlight>/ambient_light_zone is defined 2 times: /sys/class/backlight/<backlight>/ambient_light_zone:18 /sys/class/backlight/<backlight>/ambient_light_zone:40
As ABI definitions shouldn't be duplicated.
Unfortunately, the ABI is dependent on the specific device
features. As such, ambient_light_level range is somewhat
different among the supported devices.
The ambient_light_zone is even worse: the meanings of each
preset are different, and there's no ABI to retrieve
the supported types nor their meanins. Unfortunately,
it is too late to fix it without causing regressions,
as this has been used since Kernel v2.6.35.
Rewrite those ABI documentation using the current documentation
as a reference, and double-checking at the datasheets:
https://www.analog.com/media/en/technical-documentation/data-sheets/ADP8870.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/ADP8860.pdf
in order to properly document the differences between those two
drivers.
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/342195ad5a819d9bcfcebc133c77ab69b4211672.1604042072.git.mchehab+huawei@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Backlight brightness curves can have different shapes. The two main
types are linear and non-linear curves. The human eye doesn't
perceive linearly increasing/decreasing brightness as linear (see
also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED
linearly to human eye"), hence many backlights use non-linear (often
logarithmic) brightness curves. The type of curve currently is opaque
to userspace, so userspace often uses more or less reliable heuristics
(like the number of brightness levels) to decide whether to treat a
backlight device as linear or non-linear.
Export the type of the brightness curve via the new sysfs attribute
'scale'. The value of the attribute can be 'linear', 'non-linear' or
'unknown'. For devices that don't provide information about the scale
of their brightness curve the value of the 'scale' attribute is 'unknown'.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
Mauro Carvalho Chehab
Matthias Kaehlcke