44af5b4...
by
Hans de Goede <email address hidden>
ACPI: video: Add backlight=native DMI quirk for HP EliteBook 8460p
The HP EliteBook 8460p predates Windows 8, so it defaults to using
acpi_video# for backlight control.
Starting with the 6.1.y kernels the native radeon_bl0 backlight is hidden
in this case instead of relying on userspace preferring acpi_video# over
native backlight devices.
It turns out that for the acpi_video# interface to work on
the HP EliteBook 8460p, the brightness needs to be set at least once
through the native interface, which now no longer is done breaking
backlight control.
The native interface however always works without problems, so add
a quirk to use native backlight on the EliteBook 8460p to fix this.
Fixes: fb1836c91317 ("ACPI: video: Prefer native over vendor")
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2161428
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(backported picked from commit 9dcb34234b8235144c96103266317da33321077e)
AceLan: fixed the conflict with the non-exist quirks.
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
9ac2c9d...
by
Hans de Goede <email address hidden>
ACPI: video: Add backlight=native DMI quirk for Asus U46E
The Asus U46E backlight tables have a set of interesting problems:
1. Its ACPI tables do make _OSI ("Windows 2012") checks, so
acpi_osi_is_win8() should return true.
But the tables have 2 sets of _OSI calls, one from the usual global
_INI method setting a global OSYS variable and a second set of _OSI
calls from a MSOS method and the MSOS method is the only one calling
_OSI ("Windows 2012").
The MSOS method only gets called in the following cases:
1. From some Asus specific WMI methods
2. From _DOD, which only runs after acpi_video_get_backlight_type()
has already been called by the i915 driver
3. From other ACPI video bus methods which never run (see below)
4. From some EC query callbacks
So when i915 calls acpi_video_get_backlight_type() MSOS has never run
and acpi_osi_is_win8() returns false, so acpi_video_get_backlight_type()
returns acpi_video as the desired backlight type, which causes
the intel_backlight device to not register.
2. _DOD effectively does this:
Return (Package (0x01) { 0x0400 })
causing acpi_video_device_in_dod() to return false, which causes
the acpi_video backlight device to not register.
Leaving the user with no backlight device at all. Note that before 6.1.y
the i915 driver would register the intel_backlight device unconditionally
and since that then was the only backlight device userspace would use that.
Add a backlight=native DMI quirk for this special laptop to restore
the old (and working) behavior of the intel_backlight device registering.
Fixes: fb1836c91317 ("ACPI: video: Prefer native over vendor")
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(backported picked from commit e6b3086fddc0065a5ffb947d4d29dd0e6efc327b)
AceLan: fixed the conflict with the non-exist quirks.
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
eab814b...
by
Hans de Goede <email address hidden>
Some apple laptop models have an ACPI device with a HID of APP000B
and that device has an IO resource (so it does not describe the new
unsupported MMIO based gmux type), but there actually is no gmux
in the laptop at all.
The gmux_probe() function of the actual apple-gmux driver has code
to detect this, this code has been factored out into a new
apple_gmux_detect() helper in apple-gmux.h.
Use this new function to fix acpi_video_get_backlight_type() wrongly
returning apple_gmux as type on the following laptops:
The patches adding NVidia-WMI-EC and Apple GMUX backlight detection
support to acpi_video_get_backlight_type(), forgot to update
acpi_video_parse_cmdline() to allow manually selecting these from
the commandline.
Add support for these to acpi_video_parse_cmdline().
Fixes: fe7aebb40d42 ("ACPI: video: Add Nvidia WMI EC brightness control detection (v3)")
Fixes: 21245df307cb ("ACPI: video: Add Apple GMUX brightness control detection")
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit 420a1116aef0e8e12c305508f45ce73e5ae30a09)
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
5c8e49c...
by
Hans de Goede <email address hidden>
The apple-gmux driver only binds to old GMUX devices which have an
IORESOURCE_IO resource (using inb()/outb()) rather then memory-mapped
IO (IORESOURCE_MEM).
T2 MacBooks use the new style GMUX devices (with IORESOURCE_MEM access),
so these are not supported by the apple-gmux driver. This is not a problem
since they have working ACPI video backlight support.
But the apple_gmux_present() helper only checks if an ACPI device with
the "APP000B" HID is present, causing acpi_video_get_backlight_type()
to return acpi_backlight_apple_gmux disabling the acpi_video backlight
device.
Add a new apple_gmux_backlight_present() helper which checks that
the "APP000B" device actually is an old GMUX device with an IORESOURCE_IO
resource.
This fixes the acpi_video0 backlight no longer registering on T2 MacBooks.
Once this lands this patch should be reverted so that
acpi_video_get_backlight_type() also prefers the gmux on new style GMUX
MacBooks, but for now this is necessary to avoid regressing backlight
control on T2 Macs.
Fixes: 21245df307cb ("ACPI: video: Add Apple GMUX brightness control detection")
Reported-and-tested-by: Aditya Garg <email address hidden>
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit 3cf3b7f012f3ea8bdc56196e367cf07c10424855)
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
5292bba...
by
Hans de Goede <email address hidden>
When available prefer native backlight control over vendor backlight
control.
Testing has shown that there are quite a few laptop models which rely
on native backlight control (they don't have ACPI video bus backlight
control) and on which acpi_osi_is_win8() returns false.
Currently __acpi_video_get_backlight_type() returns vendor on these
laptops, leading to an empty /sys/class/backlight.
As a workaround for this acpi_video_backlight_use_native() has been
temporarily changed to always return true.
This re-introduces the problem of having multiple backlight
devices under /sys/class/backlight for a single panel.
Change __acpi_video_get_backlight_type() to prefer native over vendor
when available. So that it returns native on these models.
And change acpi_video_backlight_use_native() back to only return
true when __acpi_video_get_backlight_type() returns native.
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit fb1836c91317e0770950260dfa91eb9b2170cb27)
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
ae7c8b5...
by
Hans de Goede <email address hidden>
Simplify __acpi_video_get_backlight_type() removing a nested if which
makes the flow harder to follow.
This also results in having only 1 exit point with
return acpi_backlight_native instead of 2.
Note this drops the (video_caps & ACPI_VIDEO_BACKLIGHT) check from
the if (acpi_osi_is_win8() && native_available) return native path.
Windows 8's hardware certification requirements include that there must
be ACPI video bus backlight control, so the ACPI_VIDEO_BACKLIGHT check
is redundant.
Signed-off-by: Hans de Goede <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit a5df42521f328b45c9d89c13740e747be08ac66e)
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
3379c4d...
by
Hans de Goede <email address hidden>
ACPI: video: Add backlight=native DMI quirk for Dell G15 5515
The Dell G15 5515 has the WMI interface (and WMI call returns) expected
by the nvidia-wmi-ec-backlight interface. But the backlight class device
registered by the nvidia-wmi-ec-backlight driver does not actually work.
The amdgpu_bl0 native GPU backlight class device does actually work,
add a backlight=native DMI quirk for this.
Reported-by: Iris <email address hidden>
Reviewed-by: Daniel Dadap <email address hidden>
Signed-off-by: Hans de Goede <email address hidden>
---
Changes in v2:
- Add a comment that this needs to be revisited when dynamic-mux
support gets added (suggested by: Daniel Dadap)
(cherry picked from commit f46acc1efd4b5846de9fa05f966e504f328f34a6)
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
d09ee54...
by
Hans de Goede <email address hidden>
ACPI: video: Make acpi_video_backlight_use_native() always return true
Testing has shown that there are quite a few laptop models which rely
on native backlight control and which do not support ACPI video bus
backlight control, causing __acpi_video_get_backlight_type() to return
vendor. Known Windows laptop models affected by this are:
Acer Aspire 1640
HP Compaq nc6120
IBM ThinkPad X40
System76 Starling Star1
and the following MacBook models are affected too:
Apple MacBook 2.1
Apple MacBook 4.1
Apple MacBook Pro 7.1
the list of affected Windows laptop models is likely just the top of
the iceberg. So for now lets undo the change to not register native
backlight class devices when __acpi_video_get_backlight_type() != native.
Since as part of the backlight-detect refactor the detection code now
relies on the GPU drivers calling acpi_video_backlight_use_native() to
learn that native backlight support is available we cannot just remove
the acpi_video_backlight_use_native() calls from the GPU drivers.
Instead modify acpi_video_backlight_use_native() to always return true
for now. This is meant as a temporary work-around, which will be removed
again when the heuristics from __acpi_video_get_backlight_type() have
been improved so that they will return native on affected models.
Reported-by: Matthew Garrett <email address hidden>
Reported-by: John Warriner <email address hidden>
Reported-by: Scott Ostrander <email address hidden>
Reported-by: Matthias Rampke <email address hidden>
Reported-by: Milan Hodoscek <email address hidden>
Signed-off-by: Hans de Goede <email address hidden>
(cherry picked from commit 454d61a56d5e4c8cd9905f81d475d23f86f370af)
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
2d2a287...
by
Hans de Goede <email address hidden>
2 improvements for the Chromebook handling in
acpi_video_get_backlight_type():
1. Also check for the "GOOG000C" ACPI HID used on some models
2. Move the Chromebook check to above the ACPI-video check normally
Chromebooks don't have ACPI video backlight support, but when
flashed with upstream coreboot builds they may have ACPI video
backlight support, but native should still be used/preferred then.
Suggested-by: Mr. Chromebox <email address hidden>
Signed-off-by: Hans de Goede <email address hidden>
(cherry picked from commit 59dc2a7e7c6a0d4a2a2c4dafea874af484fc0592)
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
