Nouveau - Aug 2022 - [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper

Hi Daniel,

On 7/21/22 23:30, Daniel Dadap wrote:
> 
> On 7/21/22 16:24, Daniel Dadap wrote:
>>
>> On 7/12/22 14:38, Hans de Goede wrote:
>>> ATM on x86 laptops where we want userspace to use the acpi_video
backlight
>>> device we often register both the GPU's native backlight device
and
>>> acpi_video's firmware acpi_video# backlight device. This relies
on
>>> userspace preferring firmware type backlight devices over native
ones, but
>>> registering 2 backlight devices for a single display really is
undesirable.
>>>
>>> On x86 laptops where the native GPU backlight device should be
used,
>>> the registering of other backlight devices is avoided by their
drivers
>>> using acpi_video_get_backlight_type() and only registering their
backlight
>>> if the return value matches their type.
>>>
>>> acpi_video_get_backlight_type() uses
>>> backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a
native
>>> driver is available and will never return native if this returns
>>> false. This means that the GPU's native backlight registering
code
>>> cannot just call acpi_video_get_backlight_type() to determine if it
>>> should register its backlight, since
acpi_video_get_backlight_type() will
>>> never return native until the native backlight has already
registered.
>>>
>>> To fix this add a new internal native function parameter to
>>> acpi_video_get_backlight_type(), which when set to true will make
>>> acpi_video_get_backlight_type() behave as if a native backlight has
>>> already been registered.
>>>
>>> And add a new acpi_video_backlight_use_native() helper, which sets
this
>>> to true, for use in native GPU backlight code.
>>>
>>> Changes in v2:
>>> - Replace adding a native parameter to
acpi_video_get_backlight_type() with
>>> ?? adding a new acpi_video_backlight_use_native() helper.
>>>
>>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>>> ---
>>> ? drivers/acpi/video_detect.c | 24 ++++++++++++++++++++----
>>> ? include/acpi/video.h??????? |? 5 +++++
>>> ? 2 files changed, 25 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/acpi/video_detect.c
b/drivers/acpi/video_detect.c
>>> index becc198e4c22..4346c990022d 100644
>>> --- a/drivers/acpi/video_detect.c
>>> +++ b/drivers/acpi/video_detect.c
>>> @@ -17,8 +17,9 @@
>>> ?? * Otherwise vendor specific drivers like thinkpad_acpi,
asus-laptop,
>>> ?? * sony_acpi,... can take care about backlight brightness.
>>> ?? *
>>> - * Backlight drivers can use acpi_video_get_backlight_type() to
determine
>>> - * which driver should handle the backlight.
>>> + * Backlight drivers can use acpi_video_get_backlight_type() to
determine which
>>> + * driver should handle the backlight. RAW/GPU-driver backlight
drivers must
>>> + * use the acpi_video_backlight_use_native() helper for this.
>>> ?? *
>>> ?? * If CONFIG_ACPI_VIDEO is neither set as "compiled in"
(y) nor as a module (m)
>>> ?? * this file will not be compiled and
acpi_video_get_backlight_type() will
>>> @@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct
notifier_block *nb,
>>> ?? * Arguably the native on win8 check should be done first, but
that would
>>> ?? * be a behavior change, which may causes issues.
>>> ?? */
>>> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>> +static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
>>> ? {
>>> ????? static DEFINE_MUTEX(init_mutex);
>>> +??? static bool native_available;
>>> ????? static bool init_done;
>>> ????? static long video_caps;
>>> ? @@ -570,6 +572,8 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(void)
>>> ????????????? backlight_notifier_registered = true;
>>> ????????? init_done = true;
>>> ????? }
>>> +??? if (native)
>>> +??????? native_available = true;
>>> ????? mutex_unlock(&init_mutex);
>>> ? ????? if (acpi_backlight_cmdline != acpi_backlight_undef)
>>> @@ -581,13 +585,25 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(void)
>>> ????? if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
>>> ????????? return acpi_backlight_vendor;
>>> ? -??? if (acpi_osi_is_win8() &&
backlight_device_get_by_type(BACKLIGHT_RAW))
>>> +??? if (acpi_osi_is_win8() &&
>>> +??????? (native_available ||
backlight_device_get_by_type(BACKLIGHT_RAW)))
>>> ????????? return acpi_backlight_native;
>>> ? ????? return acpi_backlight_video;
>>
>>
>> So I ran into a minor problem when testing the NVIDIA proprietary
driver against this change set, after checking acpi_video_backlight_use_native()
before registering the NVIDIA proprietary driver's backlight handler.
Namely, for the case where a user installs the NVIDIA proprietary driver after
the video.ko has already registered its backlight handler, we end up with both
the firmware and native handlers registered simultaneously, since the ACPI video
driver no longer unregisters its backlight handler. In this state, desktop
environments end up preferring the registered but non-functional firmware
handler from video.ko. (Manually twiddling the sysfs interface for the native
NVIDIA handler works fine.) When rebooting the system after installing the
NVIDIA proprietary driver, it is able to register its native handler before the
delayed work to register the ACPI video backlight handler fires, so we end up
with only one (native) handler, and userspace is happy.
>>
>> Maybe this will be moot later on, when the existing sysfs interface is
deprecated, and it probably isn't a huge deal, since a reboot fixes things
(I imagine installing an in-tree DRM/KMS driver on an already running kernel
isn't really a thing, which is why this isn't a problem with the in-tree
drivers), but would it make sense to unregister the ACPI video backlight handler
here before returning acpi_backlight_native? That way, we'll briefly end up
with zero backlight handlers rather than briefly ending up with two of them. Not
sure if that's really any better, though.
>>
> 
> Thinking about this a little more, maybe it's better not to overly
complicate things, and just assert that users of the NVIDIA proprietary driver
will need to reboot after installation in order to get the backlight working, at
least until we get further along in this effort and the backlight interface
transitions to the DRM connector property you have proposed.
Right, this series stops unregistering the acpi_video# /sys/class/backlight
devices because the idea is to never register them in the first place.

Registering them in the first place causes 2 problems:

1. It causes userspace to see udev events for the register + unregister
and by the time the systemd backlight level save/restore helper runs
from udev the unregister has already happened and it logs ugly errors.
More in general this kinda racy behavior just is ugly.

2. On some hw merely registering the backlight device, which I think
at least tries to retrieve the current level through ACPI, is causing
issues. So now we have DMI quirks to force the native backlight on
some devices, even though the heuristics also say native eventually,
just to avoid the race. Avoiding the add + remove dance allows
us to drop a bunch of quirks and likely also fixes issues on other
devices which we don't yet know need the quirk.


So this patch-set changes the acpi_video.c code to no longer register
the acpi_video# backlight devices at init time *at all*. Instead native
drivers are supposed to now call acpi_video_register_backlight()
when they have found an internal panel. But to avoid this causing
the acpi_video# backlight devices to not show up at all in some
cases (e.g. native kms drivers blacklisted) the acpi_video code
also calls acpi_video_register_backlight() itself after 8 seconds.

I believe this is what you are hitting, the 8 seconds have passed
before the nvidia driver calls acpi_video_backlight_use_native(),
so the acpi_video# backlight devices have registered (and no longer
go away).

This is not only a problem when installing the nvidia binary driver
for the first time. It can also be a problem if the binary driver
is not in the initrd and leaving the initrd takes longer then
8 seconds, say because of a diskcrypt password. So I believe that
this really can be a problem with the nvidia binary driver.

But I think this is easy to fix. We could make the 8 second
delay configurable by replacing the ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY
define with a module-parameter; and we could make "0" as value mean
that acpi_video.c will never call acpi_video_register_backlight()
itself.

Since the various (also counting distor packaging) nvidia binary
driver installers already all modify the kernel commandline to
blacklist nouveau, then the installers can just also pass this
parameter and then acpi_video.c will never register the acpi_video#.

This does mean that the nvidia binary driver then must call
acpi_video_register_backlight() when an internal panel is found.

Note the current patches to amdgpu/nouveau skip the calling of
acpi_video_register_backlight() when
the acpi_video_backlight_use_native() call returns true and they
have registered their own backlight. But calling it always is ok
*as long as the driver is driving the laptops internal panel* !

acpi_video_register_backlight() contains:

       if (acpi_video_get_backlight_type() != acpi_backlight_video)
                return 0;

So calling it when a native backlight has already been registered
is a no-op.

Please let me know if the proposed solution works for you and
if you want me to make ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY a
module-option for the next version.

Regards,

Hans


p.s.

I think that eventually I might even try to make the new
module-param default to 0 / default to not having acpi_video.c
do the registering itself ever and see how that goes...



>>> ? }
>>> +
>>> +enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>> +{
>>> +??? return __acpi_video_get_backlight_type(false);
>>> +}
>>> ? EXPORT_SYMBOL(acpi_video_get_backlight_type);
>>> ? +bool acpi_video_backlight_use_native(void)
>>> +{
>>> +??? return __acpi_video_get_backlight_type(true) ==
acpi_backlight_native;
>>> +}
>>> +EXPORT_SYMBOL(acpi_video_backlight_use_native);
>>> +
>>> ? /*
>>> ?? * Set the preferred backlight interface type based on DMI info.
>>> ?? * This function allows DMI blacklists to be implemented by
external
>>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>>> index db8548ff03ce..4705e339c252 100644
>>> --- a/include/acpi/video.h
>>> +++ b/include/acpi/video.h
>>> @@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
>>> ? extern int acpi_video_get_edid(struct acpi_device *device, int
type,
>>> ???????????????????? int device_id, void **edid);
>>> ? extern enum acpi_backlight_type
acpi_video_get_backlight_type(void);
>>> +extern bool acpi_video_backlight_use_native(void);
>>> ? extern void acpi_video_set_dmi_backlight_type(enum
acpi_backlight_type type);
>>> ? /*
>>> ?? * Note: The value returned by
acpi_video_handles_brightness_key_presses()
>>> @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type
acpi_video_get_backlight_type(void)
>>> ? {
>>> ????? return acpi_backlight_vendor;
>>> ? }
>>> +static inline bool acpi_video_backlight_use_native(void)
>>> +{
>>> +??? return true;
>>> +}
>>> ? static inline void acpi_video_set_dmi_backlight_type(enum
acpi_backlight_type type)
>>> ? {
>>> ? }
>

On 8/2/22 06:31, Hans de Goede wrote:
> Hi Daniel,
>
> On 7/21/22 23:30, Daniel Dadap wrote:
>> On 7/21/22 16:24, Daniel Dadap wrote:
>>> On 7/12/22 14:38, Hans de Goede wrote:
>>>> ATM on x86 laptops where we want userspace to use the
acpi_video backlight
>>>> device we often register both the GPU's native backlight
device and
>>>> acpi_video's firmware acpi_video# backlight device. This
relies on
>>>> userspace preferring firmware type backlight devices over
native ones, but
>>>> registering 2 backlight devices for a single display really is
undesirable.
>>>>
>>>> On x86 laptops where the native GPU backlight device should be
used,
>>>> the registering of other backlight devices is avoided by their
drivers
>>>> using acpi_video_get_backlight_type() and only registering
their backlight
>>>> if the return value matches their type.
>>>>
>>>> acpi_video_get_backlight_type() uses
>>>> backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a
native
>>>> driver is available and will never return native if this
returns
>>>> false. This means that the GPU's native backlight
registering code
>>>> cannot just call acpi_video_get_backlight_type() to determine
if it
>>>> should register its backlight, since
acpi_video_get_backlight_type() will
>>>> never return native until the native backlight has already
registered.
>>>>
>>>> To fix this add a new internal native function parameter to
>>>> acpi_video_get_backlight_type(), which when set to true will
make
>>>> acpi_video_get_backlight_type() behave as if a native backlight
has
>>>> already been registered.
>>>>
>>>> And add a new acpi_video_backlight_use_native() helper, which
sets this
>>>> to true, for use in native GPU backlight code.
>>>>
>>>> Changes in v2:
>>>> - Replace adding a native parameter to
acpi_video_get_backlight_type() with
>>>>  ?? adding a new acpi_video_backlight_use_native() helper.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>>>> ---
>>>>  ? drivers/acpi/video_detect.c | 24 ++++++++++++++++++++----
>>>>  ? include/acpi/video.h??????? |? 5 +++++
>>>>  ? 2 files changed, 25 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/video_detect.c
b/drivers/acpi/video_detect.c
>>>> index becc198e4c22..4346c990022d 100644
>>>> --- a/drivers/acpi/video_detect.c
>>>> +++ b/drivers/acpi/video_detect.c
>>>> @@ -17,8 +17,9 @@
>>>>  ?? * Otherwise vendor specific drivers like thinkpad_acpi,
asus-laptop,
>>>>  ?? * sony_acpi,... can take care about backlight brightness.
>>>>  ?? *
>>>> - * Backlight drivers can use acpi_video_get_backlight_type()
to determine
>>>> - * which driver should handle the backlight.
>>>> + * Backlight drivers can use acpi_video_get_backlight_type()
to determine which
>>>> + * driver should handle the backlight. RAW/GPU-driver
backlight drivers must
>>>> + * use the acpi_video_backlight_use_native() helper for this.
>>>>  ?? *
>>>>  ?? * If CONFIG_ACPI_VIDEO is neither set as "compiled
in" (y) nor as a module (m)
>>>>  ?? * this file will not be compiled and
acpi_video_get_backlight_type() will
>>>> @@ -548,9 +549,10 @@ static int
acpi_video_backlight_notify(struct notifier_block *nb,
>>>>  ?? * Arguably the native on win8 check should be done first,
but that would
>>>>  ?? * be a behavior change, which may causes issues.
>>>>  ?? */
>>>> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>> +static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
>>>>  ? {
>>>>  ????? static DEFINE_MUTEX(init_mutex);
>>>> +??? static bool native_available;
>>>>  ????? static bool init_done;
>>>>  ????? static long video_caps;
>>>>  ? @@ -570,6 +572,8 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(void)
>>>>  ????????????? backlight_notifier_registered = true;
>>>>  ????????? init_done = true;
>>>>  ????? }
>>>> +??? if (native)
>>>> +??????? native_available = true;
>>>>  ????? mutex_unlock(&init_mutex);
>>>>  ? ????? if (acpi_backlight_cmdline != acpi_backlight_undef)
>>>> @@ -581,13 +585,25 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(void)
>>>>  ????? if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
>>>>  ????????? return acpi_backlight_vendor;
>>>>  ? -??? if (acpi_osi_is_win8() &&
backlight_device_get_by_type(BACKLIGHT_RAW))
>>>> +??? if (acpi_osi_is_win8() &&
>>>> +??????? (native_available ||
backlight_device_get_by_type(BACKLIGHT_RAW)))
>>>>  ????????? return acpi_backlight_native;
>>>>  ? ????? return acpi_backlight_video;
>>>
>>> So I ran into a minor problem when testing the NVIDIA proprietary
driver against this change set, after checking acpi_video_backlight_use_native()
before registering the NVIDIA proprietary driver's backlight handler.
Namely, for the case where a user installs the NVIDIA proprietary driver after
the video.ko has already registered its backlight handler, we end up with both
the firmware and native handlers registered simultaneously, since the ACPI video
driver no longer unregisters its backlight handler. In this state, desktop
environments end up preferring the registered but non-functional firmware
handler from video.ko. (Manually twiddling the sysfs interface for the native
NVIDIA handler works fine.) When rebooting the system after installing the
NVIDIA proprietary driver, it is able to register its native handler before the
delayed work to register the ACPI video backlight handler fires, so we end up
with only one (native) handler, and userspace is happy.
>>>
>>> Maybe this will be moot later on, when the existing sysfs interface
is deprecated, and it probably isn't a huge deal, since a reboot fixes
things (I imagine installing an in-tree DRM/KMS driver on an already running
kernel isn't really a thing, which is why this isn't a problem with the
in-tree drivers), but would it make sense to unregister the ACPI video backlight
handler here before returning acpi_backlight_native? That way, we'll briefly
end up with zero backlight handlers rather than briefly ending up with two of
them. Not sure if that's really any better, though.
>>>
>> Thinking about this a little more, maybe it's better not to overly
complicate things, and just assert that users of the NVIDIA proprietary driver
will need to reboot after installation in order to get the backlight working, at
least until we get further along in this effort and the backlight interface
transitions to the DRM connector property you have proposed.
> Right, this series stops unregistering the acpi_video# /sys/class/backlight
> devices because the idea is to never register them in the first place.
>
> Registering them in the first place causes 2 problems:
>
> 1. It causes userspace to see udev events for the register + unregister
> and by the time the systemd backlight level save/restore helper runs
> from udev the unregister has already happened and it logs ugly errors.
> More in general this kinda racy behavior just is ugly.
>
> 2. On some hw merely registering the backlight device, which I think
> at least tries to retrieve the current level through ACPI, is causing
> issues. So now we have DMI quirks to force the native backlight on
> some devices, even though the heuristics also say native eventually,
> just to avoid the race. Avoiding the add + remove dance allows
> us to drop a bunch of quirks and likely also fixes issues on other
> devices which we don't yet know need the quirk.

Yes, those sound like good reasons to avoid registering the ACPI video 
backlight driver wherever possible.

> So this patch-set changes the acpi_video.c code to no longer register
> the acpi_video# backlight devices at init time *at all*. Instead native
> drivers are supposed to now call acpi_video_register_backlight()
> when they have found an internal panel. But to avoid this causing
> the acpi_video# backlight devices to not show up at all in some
> cases (e.g. native kms drivers blacklisted) the acpi_video code
> also calls acpi_video_register_backlight() itself after 8 seconds.
>
> I believe this is what you are hitting, the 8 seconds have passed
> before the nvidia driver calls acpi_video_backlight_use_native(),
> so the acpi_video# backlight devices have registered (and no longer
> go away).
>
> This is not only a problem when installing the nvidia binary driver
> for the first time. It can also be a problem if the binary driver
> is not in the initrd and leaving the initrd takes longer then
> 8 seconds, say because of a diskcrypt password. So I believe that
> this really can be a problem with the nvidia binary driver.

Hmm. I hadn't considered the case of the binary driver being absent from 
the initrd, and the possibility of the transition out of the initrd 
happening after the timeout. Yes, this is a bigger problem than the 
"only after first installing the driver" scenario I ran into.

> But I think this is easy to fix. We could make the 8 second
> delay configurable by replacing the ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY
> define with a module-parameter; and we could make "0" as value
mean
> that acpi_video.c will never call acpi_video_register_backlight()
> itself.
>
> Since the various (also counting distor packaging) nvidia binary
> driver installers already all modify the kernel commandline to
> blacklist nouveau, then the installers can just also pass this
> parameter and then acpi_video.c will never register the acpi_video#.

This sounds like a reasonable compromise, but I worry that it may be 
difficult to determine whether a system definitely doesn't need the ACPI 
video backlight driver. On the other hand, the last system that I recall 
personally seeing that did use the ACPI video backlight driver was a 
little over 10 years ago, so it's possible that there are no systems 
which use that driver which are supported by current versions of the 
NVIDIA proprietary driver. I'll have to do some research to determine 
what types of systems actually used video.ko's backlight driver, unless 
you happen to know already.

> This does mean that the nvidia binary driver then must call
> acpi_video_register_backlight() when an internal panel is found.
>
> Note the current patches to amdgpu/nouveau skip the calling of
> acpi_video_register_backlight() when
> the acpi_video_backlight_use_native() call returns true and they
> have registered their own backlight. But calling it always is ok
> *as long as the driver is driving the laptops internal panel* !
>
> acpi_video_register_backlight() contains:
>
>         if (acpi_video_get_backlight_type() != acpi_backlight_video)
>                  return 0;
>
> So calling it when a native backlight has already been registered
> is a no-op.

The NVIDIA proprietary driver will already know when it has registered 
its own backlight handler, so there probably isn't any need to always 
call it when driving an internal panel. I'll have to double-check to see 
if we have already determined whether a panel is connected before 
registering the backlight handler: I am pretty certain that is the case.

One further potential difficulty that I anticipate is that not all 
dynamic mux systems use the EC backlight driver (or a similar, 
GPU-agnostic driver), and rather have whichever GPU happens to be 
connected at the time be responsible for the backlight. I had initially 
thought that supporting the EC backlight interface was a requirement for 
OEMs to implement dynamic mux support, but I recently learned this is 
not true in all cases. On Windows, this requires coordinating the 
backlight controls of the two GPU drivers across a mux switch, to load 
the state of the switched-away-from GPU and set it on the switched-to 
GPU. I imagine for these systems we may need to do some similar 
save/restore, probably managed by vga-switcheroo, but it would require 
having both GPU drivers register their own native backlight handlers 
(and possibly while one of them is not connected to the panel).

Dynamic mux switching isn't actually supported on Linux, yet, so we 
should be able to kick this particular can a little further down the 
road, but in the meantime we should probably start planning for how best 
to handle this sort of system under the "only one backlight handler per 
panel" model. Maybe the vga-switcheroo handler can register its own 
backlight handler, that then negotiates the actual backlight settings 
between the relevant GPU drivers, possibly through a new vga-switcheroo 
client callback. I'll have to think about this a bit more.

> Please let me know if the proposed solution works for you and
> if you want me to make ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY a
> module-option for the next version.

I do think it should be workable, apart from the concern I mentioned 
above about knowing when to set the module option to disable the ACPI 
video backlight driver. I'll need to get a better understanding of 
exactly which systems actually use that driver.

> Regards,
>
> Hans
>
>
> p.s.
>
> I think that eventually I might even try to make the new
> module-param default to 0 / default to not having acpi_video.c
> do the registering itself ever and see how that goes...
Would the GPU drivers then be responsible for calling
acpi_video_register_backlight() again? My understanding was that part of the
intention here was to make that no longer necessary.
>
>>>>  ? }
>>>> +
>>>> +enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>> +{
>>>> +??? return __acpi_video_get_backlight_type(false);
>>>> +}
>>>>  ? EXPORT_SYMBOL(acpi_video_get_backlight_type);
>>>>  ? +bool acpi_video_backlight_use_native(void)
>>>> +{
>>>> +??? return __acpi_video_get_backlight_type(true) ==
acpi_backlight_native;
>>>> +}
>>>> +EXPORT_SYMBOL(acpi_video_backlight_use_native);
>>>> +
>>>>  ? /*
>>>>  ?? * Set the preferred backlight interface type based on DMI
info.
>>>>  ?? * This function allows DMI blacklists to be implemented by
external
>>>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>>>> index db8548ff03ce..4705e339c252 100644
>>>> --- a/include/acpi/video.h
>>>> +++ b/include/acpi/video.h
>>>> @@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
>>>>  ? extern int acpi_video_get_edid(struct acpi_device *device,
int type,
>>>>  ???????????????????? int device_id, void **edid);
>>>>  ? extern enum acpi_backlight_type
acpi_video_get_backlight_type(void);
>>>> +extern bool acpi_video_backlight_use_native(void);
>>>>  ? extern void acpi_video_set_dmi_backlight_type(enum
acpi_backlight_type type);
>>>>  ? /*
>>>>  ?? * Note: The value returned by
acpi_video_handles_brightness_key_presses()
>>>> @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type
acpi_video_get_backlight_type(void)
>>>>  ? {
>>>>  ????? return acpi_backlight_vendor;
>>>>  ? }
>>>> +static inline bool acpi_video_backlight_use_native(void)
>>>> +{
>>>> +??? return true;
>>>> +}
>>>>  ? static inline void acpi_video_set_dmi_backlight_type(enum
acpi_backlight_type type)
>>>>  ? {
>>>>  ? }