lkml.org 
[lkml]   [2019]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 24/63] Documentation: ACPI: move video_extension.txt to firmware-guide/acpi and convert to reST
On Wed, Apr 24, 2019 at 11:56:47AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Apr 2019 00:28:53 +0800
> Changbin Du <changbin.du@gmail.com> escreveu:
>
> > This converts the plain text documentation to reStructuredText format and
> > add it to Sphinx TOC tree. No essential content change.
> >
> > Signed-off-by: Changbin Du <changbin.du@gmail.com>
> > ---
> > Documentation/firmware-guide/acpi/index.rst | 1 +
> > .../acpi/video_extension.rst} | 63 ++++++++++---------
> > 2 files changed, 36 insertions(+), 28 deletions(-)
> > rename Documentation/{acpi/video_extension.txt => firmware-guide/acpi/video_extension.rst} (79%)
> >
> > diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst
> > index 0e60f4b7129a..ae609eec4679 100644
> > --- a/Documentation/firmware-guide/acpi/index.rst
> > +++ b/Documentation/firmware-guide/acpi/index.rst
> > @@ -23,3 +23,4 @@ ACPI Support
> > i2c-muxes
> > acpi-lid
> > lpit
> > + video_extension
> > diff --git a/Documentation/acpi/video_extension.txt b/Documentation/firmware-guide/acpi/video_extension.rst
> > similarity index 79%
> > rename from Documentation/acpi/video_extension.txt
> > rename to Documentation/firmware-guide/acpi/video_extension.rst
> > index 79bf6a4921be..06f7e3230b6e 100644
> > --- a/Documentation/acpi/video_extension.txt
> > +++ b/Documentation/firmware-guide/acpi/video_extension.rst
> > @@ -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
> > +1. 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
>
> Hmm... you didn't touch on this part of the document:
>
> And what ACPI video driver does is:
> 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
>
> You should touch it. My suggestion here is:
>
> And what ACPI video driver does is:
>
> 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
>
Thanks, done.

> > @@ -32,26 +36,26 @@ 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)
> > -{
> > - Return (Package (0x0C)
> > + Method (_BCL, 0, NotSerialized)
> > {
> > - 0x64,
> > - 0x32,
> > - 0x0A,
> > - 0x14,
> > - 0x1E,
> > - 0x28,
> > - 0x32,
> > - 0x3C,
> > - 0x46,
> > - 0x50,
> > - 0x5A,
> > - 0x64
> > - })
> > -}
> > + Return (Package (0x0C)
> > + {
> > + 0x64,
> > + 0x32,
> > + 0x0A,
> > + 0x14,
> > + 0x1E,
> > + 0x28,
> > + 0x32,
> > + 0x3C,
> > + 0x46,
> > + 0x50,
> > + 0x5A,
> > + 0x64
> > + })
> > + }
> >
> > The first two levels are for when laptop are on AC or on battery and are
> > not used by Linux currently. The remaining 10 levels are supported levels
> > @@ -62,13 +66,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
> > +2. 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
> > @@ -82,7 +88,7 @@ ii) For some laptops, the press of the hotkey will not generate the
> > about the event. The event value is defined in the ACPI spec. ACPI
> > video driver will generate an key type input event according to the
> > notify value it received and send the event to user space through the
> > - input device it created:
> > + input device it created::
> >
> > event keycode
> > 0x86 KEY_BRIGHTNESSUP
>
> Perhaps making this as a table would work better:
>
> input device it created:
>
> ===== ===================
> event keycode
> ===== ===================
> 0x86 KEY_BRIGHTNESSUP
> 0x87 KEY_BRIGHTNESSDOWN
> etc.
> ===== ===================
>
>
Done.

> > @@ -94,13 +100,14 @@ 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
> > +3. 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.
>
>
>
> Thanks,
> Mauro

--
Cheers,
Changbin Du

\
 
 \ /
  Last update: 2019-04-24 19:47    [W:0.134 / U:3.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site