linux-stable.git/include/acpi/video.h, branch linux-4.5.y

ACPI / video: Document acpi_video_handles_brightness_key_presses() a bit

2016-01-15T21:09:07+00:00

Document that acpi_video_handles_brightness_key_presses()'s return value
may change over time and should not be cached.

Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki

ACPI / video: Add a acpi_video_handles_brightness_key_presses() helper

2016-01-01T02:14:51+00:00

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: Hans de Goede 
Signed-off-by: Rafael J. Wysocki

ACPI: Eliminate CONFIG_.*{, _MODULE} #ifdef in favor of IS_ENABLED()

2015-09-15T01:05:45+00:00

This commit removes all CONFIG_.*{,_MODULE} in ACPI code, replacing it
with IS_ENABLED().

Signed-off-by: Sudeep Holla 
Signed-off-by: Rafael J. Wysocki

ACPI / video: Inline acpi_video_set_dmi_backlight_type

2015-06-24T17:59:28+00:00

... and kill this:

  In file included from drivers/gpu/drm/radeon/radeon_acpi.c:29:0:
  include/acpi/video.h:46:13: warning: ‘acpi_video_set_dmi_backlight_type’ defined but not used [-Wunused-function]
   static void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
               ^

Signed-off-by: Borislav Petkov 
Signed-off-by: Rafael J. Wysocki

ACPI / video: Make acpi_video_unregister_backlight() private

2015-06-18T23:12:50+00:00

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: Hans de Goede 
Acked-by: Darren Hart 
Signed-off-by: Rafael J. Wysocki

ACPI / video: Port to new backlight interface selection API

2015-06-18T23:10:59+00:00

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: Hans de Goede 
Acked-by: Darren Hart 
Signed-off-by: Rafael J. Wysocki

acpi-video-detect: Rewrite backlight interface selection logic

2015-06-18T23:10:44+00:00

Currently we have 2 kernel commandline options + dmi-quirks in 3 places all
interacting (in interesting ways) to select which which backlight interface
to use. On the commandline we've acpi_backlight=[video|vendor] and
video.use_native_backlight=[0|1]. DMI quirks we have in
acpi/video-detect.c, acpi/video.c and drivers/platform/x86/*.c .

This commit is the first step to cleaning this up, replacing the 2 cmdline
options with just acpi_backlight=[video|vendor|native|none], and adds a
new API to video_detect.c to reflect this.

Follow up commits will also move other related code, like unregistering the
acpi_video backlight interface if it was registered before other drivers
which take priority over it are loaded, to video_detect.c where this
logic really belongs.

Signed-off-by: Hans de Goede 
Acked-by: Darren Hart 
Signed-off-by: Rafael J. Wysocki

ACPI / i915: ignore firmware requests for backlight change

2014-07-07T21:38:05+00:00

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=77091
Reported-and-tested-by: Igor Gnatenko 
Reported-and-tested-by: Anton Gubarkov 
Signed-off-by: Aaron Lu 
Acked-by: Jani Nikula 
Signed-off-by: Rafael J. Wysocki

ACPI / video: Add an acpi_video_unregister_backlight function

2014-05-20T11:41:42+00:00

Add an acpi_video_unregister_backlight function, which only unregisters
the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
driver need this as they don't want the acpi_video# backlight device, but do
need the acpi-video driver for hotkey handling.

Chances are that this new acpi_video_unregister_backlight() is actually
what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor
drivers which want to disable the acpi_video# backlight device, make 2 calls:

acpi_video_dmi_promote_vendor();
acpi_video_unregister();

The intention here is to make things independent of when acpi_video_register()
gets called. As acpi_video_register() will get called on acpi-video load time
on non intel gfx machines, while it gets called on i915 load time on intel
gfx machines.

This leads to the following 2 interesting scenarios:

 a) intel gfx:
  1) acpi-video module gets loaded (as it is a dependency of acpi_vendor
     and i915)
  2) acpi-video does NOT call acpi_video_register()
  3) acpi_vendor loads (lets assume it loads before i915), calls
     acpi_video_dmi_promote_vendor(); which sets
     ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
  4) calls acpi_video_unregister -> not registered, nop
  5) i915 loads, calls acpi_video_register
  6) acpi_video_register registers the acpi_notifier for the hotkeys,
     does NOT register a backlight device because of
     ACPI_VIDEO_BACKLIGHT_DMI_VENDOR

 b) non intel gfx
  1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
  2) acpi-video calls acpi_video_register()
  3) acpi_video_register registers the acpi_notifier for the hotkeys,
     and a backlight device
  4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
  5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier
     for the hotkeys AND the backlight device

So here we have possibly the same acpi_vendor module, making the same calls,
but with different results, in one cases acpi-video does handle hotkeys,
in the other it does not.

Note that the a) scenario turns into b) if we assume the i915 module loads
before the vendor_acpi module, so we also have different behavior depending
on module loading order!

So as said I believe that quite a few existing acpi_vendor modules really
always want the behavior of a), hence this patch adds a new
acpi_video_unregister_backlight() which gives the behavior of a) independent
of module loading order.

Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki

Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8"

2013-07-26T12:59:20+00:00

We attempted to address a regression introduced by commit a57f7f9
(ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
ACPI video backlight support doesn't work on a number of systems,
because the relevant AML methods in the ACPI tables in their BIOSes
become useless after the BIOS has been told that the OS is compatible
with Windows 8.  That problem is tracked by the bug entry at:

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

Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware
expects Windows 8) introduced for this purpose essentially prevented
the ACPI backlight support from being used if the BIOS had been told
that the OS was compatible with Windows 8 and the i915 driver was
loaded, in which case the backlight would always be handled by i915.
Unfortunately, however, that turned out to cause problems with
backlight to appear on multiple systems with symptoms indicating that
i915 was unable to control the backlight on those systems as
expected.

For this reason, revert commit 8c5bd7a, but leave the function
acpi_video_backlight_quirks() introduced by it, because another
commit on top of it uses that function.

References: https://lkml.org/lkml/2013/7/21/119
References: https://lkml.org/lkml/2013/7/22/261
References: https://lkml.org/lkml/2013/7/23/429
References: https://lkml.org/lkml/2013/7/23/459
References: https://lkml.org/lkml/2013/7/23/81
References: https://lkml.org/lkml/2013/7/24/27
Reported-and-tested-by: James Hogan 
Reported-and-tested-by: Kamal Mostafa 
Reported-and-tested-by: Jörg Otte 
Reported-and-tested-by: Steven Newbury 
Reported-by: Martin Steigerwald 
Reported-by: Kalle Valo 
Tested-by: Joerg Platte 
Signed-off-by: Rafael J. Wysocki