forked from luck/tmp_suning_uos_patched
1b7f37e127
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 <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
37 lines
1.1 KiB
C
37 lines
1.1 KiB
C
#ifndef __ACPI_VIDEO_H
|
|
#define __ACPI_VIDEO_H
|
|
|
|
#include <linux/errno.h> /* for ENODEV */
|
|
|
|
struct acpi_device;
|
|
|
|
#define ACPI_VIDEO_CLASS "video"
|
|
|
|
#define ACPI_VIDEO_DISPLAY_CRT 1
|
|
#define ACPI_VIDEO_DISPLAY_TV 2
|
|
#define ACPI_VIDEO_DISPLAY_DVI 3
|
|
#define ACPI_VIDEO_DISPLAY_LCD 4
|
|
|
|
#define ACPI_VIDEO_DISPLAY_LEGACY_MONITOR 0x0100
|
|
#define ACPI_VIDEO_DISPLAY_LEGACY_PANEL 0x0110
|
|
#define ACPI_VIDEO_DISPLAY_LEGACY_TV 0x0200
|
|
|
|
#if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE)
|
|
extern int acpi_video_register(void);
|
|
extern void acpi_video_unregister(void);
|
|
extern void acpi_video_unregister_backlight(void);
|
|
extern int acpi_video_get_edid(struct acpi_device *device, int type,
|
|
int device_id, void **edid);
|
|
#else
|
|
static inline int acpi_video_register(void) { return 0; }
|
|
static inline void acpi_video_unregister(void) { return; }
|
|
static inline void acpi_video_unregister_backlight(void) { return; }
|
|
static inline int acpi_video_get_edid(struct acpi_device *device, int type,
|
|
int device_id, void **edid)
|
|
{
|
|
return -ENODEV;
|
|
}
|
|
#endif
|
|
|
|
#endif
|