summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/acpi_video.c
diff options
context:
space:
mode:
authorHans de Goede <hdegoede@redhat.com>2015-12-22 19:09:48 +0100
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-01-01 03:14:51 +0100
commit90b066b15eda028ed44299f01236f8576dd8551d (patch)
tree31f5d270508137734424f5f1474d35bc86976df5 /drivers/acpi/acpi_video.c
parentLinux 4.4-rc7 (diff)
downloadlinux-90b066b15eda028ed44299f01236f8576dd8551d.tar.xz
linux-90b066b15eda028ed44299f01236f8576dd8551d.zip
ACPI / video: Add a acpi_video_handles_brightness_key_presses() helper
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 <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/acpi/acpi_video.c')
-rw-r--r--drivers/acpi/acpi_video.c12
1 files changed, 12 insertions, 0 deletions
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 3405f7a41e25..2a649f3edefb 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2072,6 +2072,18 @@ void acpi_video_unregister_backlight(void)
mutex_unlock(&register_count_mutex);
}
+bool acpi_video_handles_brightness_key_presses(void)
+{
+ bool have_video_busses;
+
+ mutex_lock(&video_list_lock);
+ have_video_busses = !list_empty(&video_bus_head);
+ mutex_unlock(&video_list_lock);
+
+ return have_video_busses;
+}
+EXPORT_SYMBOL(acpi_video_handles_brightness_key_presses);
+
/*
* This is kind of nasty. Hardware using Intel chipsets may require
* the video opregion code to be run first in order to initialise