linux_dsm_epyc7002/drivers/platform
Hans de Goede 10bffa65b9 apple_gmux: Use acpi_video_unregister_backlight instead of acpi_video_unregister
acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.

The unregistering of the acpi video bus event listener usually is
undesirable, which by itself is a good reason to switch to
acpi_video_unregister_backlight().

Another problem with using acpi_video_unregister() rather then using
acpi_video_unregister_backlight() is that on systems with an intel video
opregion (most systems) whether or not the acpi video bus event listener
actually gets unregistered depends on module load ordering:

Scenario a:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
   is an intel opregion.
2) intel.ko gets loaded, calls acpi_video_register() which registers both
   the listener and the acpi backlight interface
3) apple-gmux.ko gets loaded, calls acpi_video_unregister() causing both
   the listener and the acpi backlight interface to unregister

Scenario b:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
   is an intel opregion.
2) apple-gmux.ko gets loaded, calls acpi_video_dmi_promote_vendor(),
   calls acpi_video_unregister(), which is a nop since acpi_video_register
   has not yet been called
2) intel.ko gets loaded, calls acpi_video_register() which registers
   the listener, but does not register the acpi backlight interface due to
   the call to the preciding call to acpi_video_dmi_promote_vendor()

*) acpi/video.ko always loads first as both other modules depend on it.

So we end up with or without an acpi video bus event listener depending
on module load ordering, not good.

Switching to using acpi_video_unregister_backlight() means that independ
of ordering we will always have an acpi video bus event listener fixing
this.

Note that this commit means that systems without an intel video opregion,
and systems which were hitting scenario a wrt module load ordering, are
now getting an acpi video bus event listener while before they were not!

On some systems this may cause the brightness hotkeys to start generating
keypresses while before they were not (good), while on other systems this
may cause the brightness hotkeys to generate multiple keypress events for
a single press (not so good). Since on most systems the acpi video bus is
the canonical source for brightness events I believe that the latter case
will needs to be handled on a case by case basis by filtering out the
duplicate keypresses at the other source for them.

Cc: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-19 01:09:11 +02:00
..
chrome platform/chrome: chromeos_laptop - instantiate Atmel at primary address 2015-04-24 22:07:14 -07:00
goldfish goldfish: pipe: fix warnings for 32bit builds 2014-05-16 11:32:51 -07:00
mips MIPS: Loongson-3: Add chipset ACPI platform driver 2015-04-01 17:22:18 +02:00
olpc drivers/platform/olpc/olpc-ec.c: initialise earlier 2013-08-23 09:51:22 -07:00
x86 apple_gmux: Use acpi_video_unregister_backlight instead of acpi_video_unregister 2015-06-19 01:09:11 +02:00
Kconfig MIPS: Loongson-3: Add CPU Hwmon platform driver 2015-04-01 17:22:17 +02:00
Makefile MIPS: Loongson-3: Add CPU Hwmon platform driver 2015-04-01 17:22:17 +02:00