The Toshiba Portege R700 needs disable_backlight_sysfs_if=1, just like
the Toshiba Portege R830. Add a quirk for this.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=21012
Cc: 4.2+ <stable@vger.kernel.org> # 4.2+
Tested-by: NEmma Reisz <emmareisz@outlook.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

acpi_video_handles_brightness_key_presses() may use an uninitialized mutex.
The error has been reported by lockdep: DEBUG_LOCKS_WARN_ON(l->magic != l).
The function assumes that the video driver has been registered before being
called. As explained in the comment of acpi_video_init(), the registration
of the video class may be defered and thus may not take place in the init
function of the module.

Use completion mechanisms to make sure that
acpi_video_handles_brightness_key_presses() wait for the completion of
acpi_video_register() before using the mutex.
Also get rid of register_count since task completion can replace it.
Signed-off-by: NAdrien Schildknecht <adrien+dev@schischi.me>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The Dell Vostro V131 has an especially broken acpi-video implementation.

The backlight control bits work, but when the brightness is changed via
the acpi-video interface the backlight flickers annoyingly before settling
at the new brightness, switching to using the native interface fixes the
flickering so add a quirk for this (the vendor interface has the same
problem).

Brightness keypresses reported through the acpi-video-bus are also broken,
they get reported one event delayed, so if you press the brightness-up
hotkey on the keyboard nothing happens, then if you press brightness-down,
the previous brightness-up event gets reported. Since the keypresses are
also reported via wmi (if active) and via atkbd (when wmi is not active)
add a quirk to simply filter out the delayed (broken) events.
Reported-and-tested-by: NMichał Kępień <kernel@kempniu.pl>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add a module option to disable the reporting of keypresses, in some buggy
firmware implementatinon, the reported events are wrong. E.g. they lag
reality by one event in the case triggering the writing of this patch.

In this case it is better to not forward these wrong events to userspace
(esp.) when there is another source of the same events which is not buggy.

Note this is only intended to work around implementations which send
events which are plain wrong. In some cases we get double events, e.g.
from both acpi-video and the atkbd driver, in this case acpi-video is
considered the canonical source, and the events from the other source
should be filtered (using e.g. /lib/udev/hwdb.d/60-keyboard.hwdb).
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Several drivers want to know if the acpi-video is generating key-presses
for brightness change hotkeys to avoid sending double key-events to
userspace for these. Currently these driver use this construct for this:

	if (acpi_video_get_backlight_type() == acpi_backlight_vendor)
		report_brightness_key_event();

This indirect way of detecting if acpi-video is active does not make the
code easier to understand, and in some cases it is wrong because just
because the preferred type != vendor does not mean that acpi-video is
actually listening for brightness events, e.g. there may be no acpi-video
bus on the system at all.

This commit adds a acpi_video_handles_brightness_key_presses() helper
function, making the code needing this functionality both easier to read
and more correct.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The firmware of ESPRIMO Mobile M9410 has two video output devices that
have _BCM control method, one is the type of "External Digital Monitor"
while the other is the type of "Internal/Integrated Digital Flat Panel".
Only the 2nd video output device's _BCM control method works, but
since we have created two and the 1st one got picked up by user space,
the backlight functionality is broken. To solve this problem, only
register backlight interface for "Internal/Integrated Digital Flat Panel"
type video output device on this laptop.

Another problem of this laptop is that the IDs listed by the _DOD method
doesn't have bit 31 set, which means it doesn't follow the format
specified by ACPI spec. But the value indicates that it actually follows
that format so I've added a DMI quirk and a module level parameter to
force use the device_id_scheme so that we can get the video output
device's type to do the decision if we should register backlight
interface.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=104121Suggested-by: NHans de Goede <hdegoede@redhat.com>
Reported-and-tested-by: NChristian Scharl <zahlsum-kernelbugs@yahoo.de>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is no need to carry potentially outdated Free Software Foundation
mailing address in file headers since the COPYING file includes it.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

acpi_video_unregister_backlight() is now only used by video_detect.c
which is part of the same acpi_video module as video.c, make
acpi_video_unregister_backlight() private to this module.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It is possible for a native backlight driver to load while
acpi_video_register is running, which may lead to
acpi_video_unregister_backlight being called while acpi_video_register
is running and the 2 racing against eachother.

The register_count variable protects against this, but not in a thread
safe manner, this commit adds locking to make this thread safe.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When builtin there is no guarantee in which order module_init functions
are run, so acpi_video_register() may get called from the i915 driver
(if it is also builtin) before acpi_video_init() gets called, resulting
in the dmi quirks not yet being parsed.

This commit moves the dmi_check_system() call to acpi_video_register(),
so that we can be sure the dmi quirks have always been applied before
probing.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Move the unregistering of the acpi backlight interface on registering of a
native backlight from video.c to video_detect.c where it belongs.

Note this removes support for re-registering the acpi backlight interface
when the native interface goes away. In practice this never happens and
it needlessly complicates the code.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Most of the patch is moving the dmi quirks for forcing use of the
acpi-video / the native backlight interface to video_detect.c.

What remains is a nice cleanup.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This is a preparation patch for the backlight interface selection logic
cleanup, there are 2 reasons to not always build the video_detect code
into the kernel:

1) In order for the video_detect.c to also deal with / select native
backlight interfaces on win8 systems, instead of doing this in video.c
where it does not belong, video_detect.c needs to call into the backlight
class code. Which cannot be done if it is builtin and the blacklight class
is not.

2) Currently all the platform/x86 drivers which have quirks to prefer
the vendor driver over acpi-video call acpi_video_unregister_backlight()
to remove the acpi-video backlight interface, this logic really belongs
in video_detect.c, which will cause video_detect.c to depend on symbols of
video.c and video.c already depends on video_detect.c symbols, so they
really need to be a single module.

Note that this commits make 2 changes so as to maintain 100% kernel
commandline compatibility:

1) The __setup call for the acpi_backlight= handling is moved to
   acpi/util.c as __setup may only be used by code which is alwasy builtin
2) video.c is renamed to acpi_video.c so that it can be combined with
   video_detect.c into video.ko

This commit also makes changes to drivers/platform/x86/Kconfig to ensure
that drivers which use acpi_video_backlight_support() from video_detect.c,
will not be built-in when acpi_video is not built in. This also changes
some "select" uses to "depends on" to avoid dependency loops.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On some systems acpi-video backlight is broken in the sense that it cannot
control the brightness of the backlight, but it must still be called on
resume to power-up the backlight after resume.

This commit allows these systems to work by going through all the usual
backlight control moves, while not registering a sysfs backlight
interface.

This commit also adds a quirk enabling this parameter on Toshiba Portege
R830 systems which are known to be affected by this.

I wish there was a better way to deal with this, but we've been unable to
find one.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=21012
Link: https://bugs.freedesktop.org/show_bug.cgi?id=82634Reported-and-tested-by: NSylvain Pasche <sylvain.pasche@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It seems that the latest generation of MacbookPro needs to use the
native backlight driver, just like most modern laptops do, but it does
not automatically get enabled as the Apple BIOS does not advertise
Windows 8 compatibility. So add a quirk for this.
Reported-by: NChristopher Beland <beland@alum.mit.edu>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The Lenovo Ideapad Z570 (which is an Acer in disguise like some other Ideapads)
has a broken acpi_video interface, this was fixed in commmit a11d342f
("ACPI / video: force vendor backlight on Lenovo Ideapad Z570").

Which stops acpi_video from registering a backlight interface, but this is
only a partial fix, because for people who have the ideapad-laptop module
installed that module will now register a backlight interface, which also
does not work, so we need to use the native intel_backlight interface.

The Lenovo Ideapad 570 is a pre-win8 laptop / too old for the acpi-video code
to automatically prefer the native backlight interface, so add a quirk for it.

This commit also removes the previous incomplete fix.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1187004Tested-by: NBe <be.0@gmx.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The native backlight behavior (so not registering both the acpi-video
and the vendor backlight driver) can be useful on some non win8 machines
too, so change the behavior of the video.use_native_backlight=1 or 0
kernel cmdline option to be: if user has set video.use_native_backlight=1
or 0, use that no matter if it is a win8 system or not. Also, we will
put some known systems into the DMI table to make them either use native
backlight interface or not, and the use_native_backlight_dmi is used to
reflect that.
Original-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Report the actual error code from acpi_bus_register_driver(), it may
help future debugging (typically ENODEV as previously reported, but the
unusual cases are where it may help most).
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

i915.ko depends upon the acpi/video.ko module and so refuses to load if
ACPI is disabled at runtime if for example the BIOS is broken beyond
repair. acpi/video provides an optional service for i915.ko and so we
should just allow the modules to load, but do no nothing in order to let
the machines boot correctly.
Reported-by: NBill Augur <bill-auger@programmer.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Acked-by: NAaron Lu <aaron.lu@intel.com>
[ rjw: Fixed up the new comment in acpi_video_init() ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add video_disable_native_backlight quirk for SAMSUNG 900X3C/900X3D/
900X3E/900X4C/900X4D laptops.

The native intel backlight controls do not work correctly on SAMSUNG
Series 9 (900X3C/900X3D/900X3E/900X4C/900X4D) laptops:
One machine has an completely dimmed (= black) display after boot at the
GDM login screen and brightness controls work only between 0 and 5%
(= no effect).
Another machine has the same brightness control issues if an external
HDMI monitor is or gets connected, although the initial brightness is
ok.
After login to Gnome both machines always work fine.

Tested on both machines.

Link: https://bugs.freedesktop.org/show_bug.cgi?id=87286
Link: https://bugs.debian.org/772440Signed-off-by: NJens Reyer <jens.reyer@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Backlight control through the native intel interface does not work properly
on the Samsung 510R, where as using the acpi_video interface does work, add
a quirk for this.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1186097
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The Samsung 730U3E/740U3E has integrated ATI Radeon graphics, and backlight
control does not work properly when using the native interfaces.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1094948Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The L521X variant of the Dell XPS15 has integrated nvidia graphics, and
backlight control does not work properly when using the native interfaces.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1163574Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Several Samsung laptop models (SAMSUNG 870Z5E/880Z5E/680Z5E and
SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V) do not have a working
native backlight control interface so restore their acpi_videoX
interface.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84221
Link: https://bugzilla.kernel.org/show_bug.cgi?id=84651
For SAMSUNG 870Z5E/880Z5E/680Z5E:
Reported-and-tested-by: NBrent Saner <brent.saner@gmail.com>
Reported-by: NVitaliy Filippov <vitalif@yourcmc.ru>
Reported-by: NLaszlo KREKACS <laszlo.krekacs.list@gmail.com>
For SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V:
Reported-by: NVladimir Perepechin <vovochka13@gmail.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

If the firmware has declared more than 8 video output devices, and the
one that control the internal panel's backlight is listed after the
first 8 output devices, the _DOD will not include it due to the current
i915 operation region implementation. As a result, we will not create a
backlight device for it while we should. Solve this problem by special
case the firmware that has 8+ output devices in that if we see such a
firmware, we do not test if the device is in _DOD list. The creation of
the backlight device will also enable the firmware to emit events on
backlight hotkey press when the acpi_osi= cmdline option is specified on
those affected ASUS laptops.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=70241Reported-and-tested-by: NOleksij Rempel <linux@rempel-privat.de>
Reported-and-tested-by: NDmitry Tunin <hanipouspilot@gmail.com>
Reported-and-tested-by: NJimbo <jaime.91@hotmail.es>
Cc: 3.18+ <stable@vger.kernel.org> # 3.18+
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 0b8db271 ("ACPI / video: check _DOD list when creating
backlight devices") checks if the video device is in the bind devices
list to decide if we should create backlight device for it, that causes
problem for one Dell Latitude E6410, where none of the video output
devices are properly bound due to the way how we did the comparing
between its _ADR and the _DOD's values. Solve this problem by comparing
the lower 12 bits of both the device's _ADR and the _DOD's values instead
of relying on bind result.

Fixes: 0b8db271 ("ACPI / video: check _DOD list when creating backlight devices")
Reported-and-tested-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ASUS K53SM's ACPI table queries _OSI("Windows 2012") in the video
output device's _BCL and _BCM control method instead of the usual _INI
functions of the _SB or PCI host bridge PCI0 devices. This made our
video module thought this is a pre-Win8 system when deciding if we
should register a backlight interface for it and the end result is that
a non-working acpi_video interface is registered and user is unable to
control backlight from GUI. Solve this problem by evaluating _BCL control
method before doing the decision.

Note that for some Thinkpad systems, the _BCL is also required to be
evaluated for the hotkey event to be generated no matter if we will
register an ACPI video backlight interface for it or not. Since the
thinkpad_acpi module will do this anyway we didn't add such a thing in
the video module previously. But now with this change here, the
thinkpad_acpi module is no more necessary for those systems regarding
backlight functionality.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=85051Reported-and-tested-by: NRalf Jung <post+kernel@ralfj.de>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The _DOD method lists which video output device is currently attached so
we should only care about them and ignore others. An user recently
reported that there are two acpi_video interfaces appeared on his system
and one of them doesn't work. From the acpidump, it is found that there
are more than one video output devices that have _BCM control method but
the _DOD lists only one of them. So this patch checks if the video output
device is in the _DOD list and will not create backlight device if it is
not in the list. Also, we consider the broken _DOD case(reflected by the
video->attached_count is 0) and do not change behaviour for those broken
_DOD systems.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84111
Reported-and-tested-by: ntrrgc@gmail.com
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ThinkPad X201s has a working ACPI video backlight interface and is
shipped before Win8; then there is BIOS update that starts to query
_OSI("Windows 2012") and that would make our video module stop creating
backlight interface and caused problem for the user. Add it to the DMI
table to disable native backlight to fix this problem.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691
Link: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Reported-and-tested-by: NYves-Alexis Perez <corsac@debian.org>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

use_native_backlight_dmi defaults to true now, so
video_set_use_native_backlight is a nop.  Drop it.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
[ rjw: Changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Link: https://bugs.freedesktop.org/show_bug.cgi?id=81515Reported-and-tested-by: NHohahiu <rakothedin@gmail.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some laptops have a working acpi_video backlight control, and using native
backlight on these causes a regression where backlight control does not work
when userspace is not handling brightness key events. Disable native_backlight
on these to fix this.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691Reported-and-tested-by: NAndre Müller <andre.muller@web.de>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 751109aa ("ACPI / video: Change the default for
video.use_native_backlight to 1") has changed the default for
use_native_backlight from 0 to 1, but instead of changing
use_native_backlight_dmi to true, and leaving use_native_backlight_param at -1,
it has changed use_native_backlight_param to 1.

This causes acpi_video_use_native_backlight() to always think that a value was
specified through the param, making it impossible to add a dmi based quirk
to force 0 now that the default is 1.

This fixes this by restoring the use_native_backlight_param default to -1, and
instead setting the use_native_backlight_dmi default to true.

Fixes: 751109aa (ACPI / video: Change the default for video.use_native_backlight to 1)
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1123565Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When the windows8 related backlight problems became evident, 2 approaches
were follow in parallel, one was to stop claiming to be windows 8 / 2012,
the other was to tell acpi_video to stop registering a backlight driver.

I've read all the threads and it seems that which approach ended up being
applied to which model laptop was never really a concious decision (AFAIK):

https://bugzilla.kernel.org/show_bug.cgi?id=51231
https://bugzilla.kernel.org/show_bug.cgi?id=60682

So lets move all the models which are only on the win8 blacklist because of
brightness issues to the use_native_backlight list, which is the smaller
hammer to use to solve the backlight issues.

Making this change is esp. attractive now that 3.16 has
video.use_native_brightness=1 by default. If that new default does not get
reverted because of regressions, then we can drop all the models
with a use_native_backlight quirk, greatly reducing the number of models we've
a quirk for.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Link: https://bugzilla.kernel.org/show_bug.cgi?id=60682Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In various scenarious userspace will respond to brightness up/down keypresses
by increasing/decreasing the backlight brightness itself. If the kernel then
also changes the brightness this results in the brightness having changed 2
steps for a single keypress which is undesirable. See e.g. :

https://bugs.launchpad.net/gnome-settings-daemon/+bug/527157
http://askubuntu.com/questions/173921/why-does-my-thinkpad-brightness-control-skip-steps

This commit delays responding to brightness up/down keypresses by 100 ms and
if userspace in that time responds by changing the backlight itself, cancels
the kernels own handling of these keypresses, fixing the 2 steps issue.

Link: http://marc.info/?l=linux-kernel&m=140535721100839&w=2
[hdegoede@redhat.com: Move the delayed_work struct into struct
 acpi_video_device instead of having it as a global]
[hdegoede@redhat.com: Keep brightness_switch_enabled as a boolean and always
 delay the keypress handling]
Tested-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1025690
This is yet another model which needs this quirk.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1025690Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This reverts commit 886129a8 (ACPI / video: change acpi-video
brightness_switch_enabled default to 0) as it is reported to cause
problems to happen.

Fixes: 886129a8 (ACPI / video: change acpi-video brightness_switch_enabled default to 0)
Link: http://marc.info/?l=linux-acpi&m=140534286826819&w=2
Reported by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Fix backlight control for Acer TravelMate B113 Laptop by adding
it to the video_dmi_table.

A workaround before that was to use acpi_osi=Linux or
acpi_backlight=vendor on boot but even then, only the function-
keys worked.

With this change there is no need for boot parameters and DE's
controls work as well.
Signed-off-by: NMartin Kepplinger <martink@posteo.de>
[rjw: Subject]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some Thinkpad laptops' firmware will initiate a backlight level change
request through operation region on the events of AC plug/unplug, but
since we are not using firmware's interface to do the backlight setting
on these affected laptops, we do not want the firmware to use some
arbitrary value from its ASL variable to set the backlight level on
AC plug/unplug either.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=76491
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77091Reported-and-tested-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
Reported-and-tested-by: NAnton Gubarkov <anton.gubarkov@gmail.com>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>