Documentation: ACPI: move video_extension.txt to firmware-guide/acpi and convert to reST
This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du <changbin.du@gmail.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This commit is contained in:
Changbin Du
Rafael J. Wysocki
parent
7fe19072df
commit
7fb091f806
|
|
@ -23,3 +23,4 @@ ACPI Support
|
|||
i2c-muxes
|
||||
acpi-lid
|
||||
lpit
|
||||
video_extension
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=====================
|
||||
ACPI video extensions
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
=====================
|
||||
|
||||
This driver implement the ACPI Extensions For Display Adapters for
|
||||
integrated graphics devices on motherboard, as specified in ACPI 2.0
|
||||
|
|
@ -8,9 +11,10 @@ defining the video POST device, retrieving EDID information or to
|
|||
setup a video output, etc. Note that this is an ref. implementation
|
||||
only. It may or may not work for your integrated video device.
|
||||
|
||||
The ACPI video driver does 3 things regarding backlight control:
|
||||
The ACPI video driver does 3 things regarding backlight control.
|
||||
|
||||
1 Export a sysfs interface for user space to control backlight level
|
||||
Export a sysfs interface for user space to control backlight level
|
||||
==================================================================
|
||||
|
||||
If the ACPI table has a video device, and acpi_backlight=vendor kernel
|
||||
command line is not present, the driver will register a backlight device
|
||||
|
|
@ -22,17 +26,22 @@ The backlight sysfs interface has a standard definition here:
|
|||
Documentation/ABI/stable/sysfs-class-backlight.
|
||||
|
||||
And what ACPI video driver does is:
|
||||
actual_brightness: on read, control method _BQC will be evaluated to
|
||||
|
||||
actual_brightness:
|
||||
on read, control method _BQC will be evaluated to
|
||||
get the brightness level the firmware thinks it is at;
|
||||
bl_power: not implemented, will set the current brightness instead;
|
||||
brightness: on write, control method _BCM will run to set the requested
|
||||
brightness level;
|
||||
max_brightness: Derived from the _BCL package(see below);
|
||||
type: firmware
|
||||
bl_power:
|
||||
not implemented, will set the current brightness instead;
|
||||
brightness:
|
||||
on write, control method _BCM will run to set the requested brightness level;
|
||||
max_brightness:
|
||||
Derived from the _BCL package(see below);
|
||||
type:
|
||||
firmware
|
||||
|
||||
Note that ACPI video backlight driver will always use index for
|
||||
brightness, actual_brightness and max_brightness. So if we have
|
||||
the following _BCL package:
|
||||
the following _BCL package::
|
||||
|
||||
Method (_BCL, 0, NotSerialized)
|
||||
{
|
||||
|
|
@ -62,13 +71,15 @@ as a "brightness level" indicator. Thus from the user space perspective
|
|||
the range of available brightness levels is from 0 to 9 (max_brightness)
|
||||
inclusive.
|
||||
|
||||
2 Notify user space about hotkey event
|
||||
Notify user space about hotkey event
|
||||
====================================
|
||||
|
||||
There are generally two cases for hotkey event reporting:
|
||||
|
||||
i) For some laptops, when user presses the hotkey, a scancode will be
|
||||
generated and sent to user space through the input device created by
|
||||
the keyboard driver as a key type input event, with proper remap, the
|
||||
following key code will appear to user space:
|
||||
following key code will appear to user space::
|
||||
|
||||
EV_KEY, KEY_BRIGHTNESSUP
|
||||
EV_KEY, KEY_BRIGHTNESSDOWN
|
||||
|
|
@ -84,23 +95,27 @@ ii) For some laptops, the press of the hotkey will not generate the
|
|||
notify value it received and send the event to user space through the
|
||||
input device it created:
|
||||
|
||||
===== ==================
|
||||
event keycode
|
||||
===== ==================
|
||||
0x86 KEY_BRIGHTNESSUP
|
||||
0x87 KEY_BRIGHTNESSDOWN
|
||||
etc.
|
||||
===== ==================
|
||||
|
||||
so this would lead to the same effect as case i) now.
|
||||
|
||||
Once user space tool receives this event, it can modify the backlight
|
||||
level through the sysfs interface.
|
||||
|
||||
3 Change backlight level in the kernel
|
||||
Change backlight level in the kernel
|
||||
====================================
|
||||
|
||||
This works for machines covered by case ii) in Section 2. Once the driver
|
||||
received a notification, it will set the backlight level accordingly. This does
|
||||
not affect the sending of event to user space, they are always sent to user
|
||||
space regardless of whether or not the video module controls the backlight level
|
||||
directly. This behaviour can be controlled through the brightness_switch_enabled
|
||||
module parameter as documented in admin-guide/kernel-parameters.rst. It is recommended to
|
||||
disable this behaviour once a GUI environment starts up and wants to have full
|
||||
control of the backlight level.
|
||||
module parameter as documented in admin-guide/kernel-parameters.rst. It is
|
||||
recommended to disable this behaviour once a GUI environment starts up and
|
||||
wants to have full control of the backlight level.
|
||||
Loading…
Reference in New Issue