From: Hans de Goede <hdegoede@redhat.com>
To: Darren Hart <dvhart@infradead.org>
Cc: Ben Skeggs <bskeggs@redhat.com>,
platform-driver-x86@vger.kernel.org,
dri-devel@lists.freedesktop.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Aaron Lu <aaron.lu@intel.com>,
linux-acpi@vger.kernel.org, Hans de Goede <hdegoede@redhat.com>,
Corentin Chary <corentin.chary@gmail.com>,
acpi4asus-user@lists.sourceforge.net
Subject: [PATCH 2/3] asus-wmi: Use acpi_video_unregister_backlight instead of acpi_video_unregister
Date: Mon, 1 Jun 2015 11:25:07 +0200 [thread overview]
Message-ID: <1433150708-8498-3-git-send-email-hdegoede@redhat.com> (raw)
In-Reply-To: <1433150708-8498-1-git-send-email-hdegoede@redhat.com>
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) and a wmi_backlight_power quirk, 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) asus-wmi.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) asus-wmi.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: Corentin Chary <corentin.chary@gmail.com>
Cc: acpi4asus-user@lists.sourceforge.net
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/asus-wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 7543a56..945145d 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1777,7 +1777,7 @@ static int asus_wmi_add(struct platform_device *pdev)
acpi_video_dmi_promote_vendor();
if (!acpi_video_backlight_support()) {
pr_info("Disabling ACPI video driver\n");
- acpi_video_unregister();
+ acpi_video_unregister_backlight();
err = asus_wmi_backlight_init(asus);
if (err && err != -ENODEV)
goto fail_backlight;
--
2.4.2
next prev parent reply other threads:[~2015-06-01 9:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 9:25 [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers Hans de Goede
2015-06-01 9:25 ` [PATCH 1/3] apple_gmux: Use acpi_video_unregister_backlight instead of acpi_video_unregister Hans de Goede
2015-06-01 9:25 ` Hans de Goede [this message]
2015-06-04 14:42 ` [PATCH 2/3] asus-wmi: " Corentin Chary
2015-06-01 9:25 ` [PATCH 3/3] samsung-laptop: " Hans de Goede
2015-06-04 14:43 ` Corentin Chary
2015-06-01 17:41 ` [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers Darren Hart
2015-06-01 17:58 ` Hans de Goede
2015-06-02 9:59 ` Jani Nikula
2015-06-02 10:14 ` Hans de Goede
2015-06-02 14:33 ` Aaron Lu
2015-06-03 0:31 ` Aaron Lu
2015-06-02 14:28 ` Aaron Lu
2015-06-03 3:46 ` Darren Hart
2015-06-08 4:54 ` Darren Hart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1433150708-8498-3-git-send-email-hdegoede@redhat.com \
--to=hdegoede@redhat.com \
--cc=aaron.lu@intel.com \
--cc=acpi4asus-user@lists.sourceforge.net \
--cc=bskeggs@redhat.com \
--cc=corentin.chary@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dvhart@infradead.org \
--cc=linux-acpi@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).