From: Daniel Drake <email@example.com> To: Yurii Pavlovskyi <firstname.lastname@example.org> Cc: Corentin Chary <email@example.com>, Darren Hart <firstname.lastname@example.org>, Andy Shevchenko <email@example.com>, acpi4asus-user <firstname.lastname@example.org>, Platform Driver <email@example.com>, Linux Kernel <firstname.lastname@example.org>, Endless Linux Upstreaming Team <email@example.com> Subject: Re: [PATCH v2 05/11] platform/x86: asus-wmi: Support queued WMI event codes Date: Fri, 12 Apr 2019 15:48:17 +0800 [thread overview] Message-ID: <CAD8Lp47yHMt-zYd02s3AgBDNQvRA5=Ccp4id8nTVHnQOtT+4_Q@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Thu, Apr 11, 2019 at 1:44 PM Yurii Pavlovskyi <email@example.com> wrote: > Event codes are expected to be polled from a queue on at least some > models. Maybe avoid the word "poll" since it suggests something else (at least to me). > The fix flushes the old key codes out of the queue on load and after > receiving event the queue is read until either ..FFFF or 1 is encountered. > > It might be considered a minor issue and no normal user would likely to > observe this (there is little reason unloading the driver), but it does > significantly frustrate a developer who is unlucky enough to encounter > this. > > Introduce functionality for flushing and processing queued codes, which is > enabled via quirk flag for ASUS7000. It might be considered if it is > reasonable to enable it everywhere (might introduce regressions) or always > try to flush the queue on module load and try to detect if this quirk is > present in the future. > > This patch limits the effect to the specific hardware defined by ASUS7000 > device that is used for driver detection by vendor driver of Fx505. The > fallback is also implemented in case initial flush fails. Which vendor driver are you referring to here? Researching more: In our database of 144 Asus models, 142 of them have GANQ. Of those 142, 9 of them return One in the empty-queue case. The other 133 match your FX505GM device exactly. So it seems valid to interpret both 0xffff and 0x1 as queue-end markers. The 2 devices that do not have GANQ are not laptops. They also do not have the _UID "ATK" WMI device, they only have "ASUSWMI" and their WMI _WED method does not use a queue. There are a few more units that have both ASUSWMI and ATK devices, and the ASUSWMI device appears to never be queued. Another observation is that the ASUSWMI device works with notify code 0xD2, and the ATK device works with 0xFF. Nailing this down a bit further, I found a DSDT for EEEPC X101H: that one only has ASUSWMI and it is also not queued. So I think you should make this queue behaviour applied more generically, but either avoid it when the WMI device _UID is not "ATK" (as discussed in the DCTS/DSTS thread), or avoid it when the notify code is not 0xFF. Thanks Daniel
next prev parent reply other threads:[~2019-04-12 7:48 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-10 20:11 [PATCH 00/11] asus-wmi: Support of ASUS TUF Gaming series laptops Yurii Pavlovskyi 2019-04-10 20:20 ` [PATCH 01/11] platform/x86: asus-wmi: Fix hwmon device cleanup Yurii Pavlovskyi 2019-04-11 8:21 ` Daniel Drake 2019-04-12 17:49 ` Yurii Pavlovskyi 2019-04-10 20:26 ` [PATCH 02/11] platform/x86: asus-wmi: Fix preserving keyboard, backlight intensity on load Yurii Pavlovskyi 2019-04-10 20:27 ` [PATCH 03/11] platform/x86: asus-wmi: Increase input buffer size of WMI methods Yurii Pavlovskyi 2019-04-10 20:28 ` [PATCH 04/11] platform/x86: asus-wmi: Add quirk to force DSTS WMI method detection Yurii Pavlovskyi 2019-04-11 5:42 ` [PATCH v2 " Yurii Pavlovskyi 2019-04-11 10:55 ` [PATCH " Daniel Drake 2019-04-12 20:04 ` Yurii Pavlovskyi 2019-04-10 20:29 ` [PATCH 05/11] platform/x86: asus-wmi: Support queued WMI event codes Yurii Pavlovskyi 2019-04-11 5:44 ` [PATCH v2 " Yurii Pavlovskyi 2019-04-12 7:48 ` Daniel Drake [this message] 2019-04-12 20:32 ` Yurii Pavlovskyi 2019-04-10 20:30 ` [PATCH 06/11] platform/x86: asus-nb-wmi: Add microphone mute key code Yurii Pavlovskyi 2019-04-11 5:44 ` [PATCH v2 " Yurii Pavlovskyi 2019-04-10 20:31 ` [PATCH 07/11] platform/x86: asus-wmi: Organize code into sections Yurii Pavlovskyi 2019-04-11 5:45 ` [PATCH v2 " Yurii Pavlovskyi 2019-04-10 20:32 ` [PATCH 08/11] platform/x86: asus-wmi: Enhance detection of thermal data Yurii Pavlovskyi 2019-04-11 5:45 ` [PATCH v2 " Yurii Pavlovskyi 2019-04-10 20:33 ` [PATCH 09/11] platform/x86: asus-wmi: Control RGB keyboard backlight Yurii Pavlovskyi 2019-04-11 5:46 ` [PATCH v2 " Yurii Pavlovskyi 2019-04-10 20:34 ` [PATCH 10/11] platform/x86: asus-wmi: Switch fan boost mode Yurii Pavlovskyi 2019-04-11 5:47 ` [PATCH v2 " Yurii Pavlovskyi 2019-04-12 8:03 ` Daniel Drake 2019-04-12 20:50 ` Yurii Pavlovskyi 2019-04-10 20:36 ` [PATCH 11/11] platform/x86: asus-wmi: Do not disable keyboard backlight on unload Yurii Pavlovskyi 2019-04-11 5:48 ` [PATCH v2 " Yurii Pavlovskyi 2019-04-11 5:38 ` [PATCH 00/11] asus-wmi: Support of ASUS TUF Gaming series laptops Yurii Pavlovskyi
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='CAD8Lp47yHMt-zYd02s3AgBDNQvRA5=Ccp4id8nTVHnQOtT+4_Q@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2 05/11] platform/x86: asus-wmi: Support queued WMI event codes' \ /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
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).