All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: "João Paulo Rechi Vita" <jprvita@gmail.com>
Cc: "Corentin Chary" <corentin.chary@gmail.com>,
	"Darren Hart" <dvhart@infradead.org>,
	"Andy Shevchenko" <andy@infradead.org>,
	acpi4asus-user <acpi4asus-user@lists.sourceforge.net>,
	"Platform Driver" <platform-driver-x86@vger.kernel.org>,
	"Bastien Nocera" <hadess@hadess.net>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	linux-input <linux-input@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	linux@endlessm.com,
	"João Paulo Rechi Vita" <jprvita@endlessm.com>
Subject: Re: [PATCH 0/3] Fix display off hotkey on Asus machines
Date: Fri, 2 Nov 2018 21:35:22 +0200	[thread overview]
Message-ID: <CAHp75VdzYf_CXiBzVrOUw+R5ZA8O-+_PGJ-Cv-q7QTXpvG0dVA@mail.gmail.com> (raw)
In-Reply-To: <20181101002128.28884-1-jprvita@endlessm.com>

On Thu, Nov 1, 2018 at 2:21 AM João Paulo Rechi Vita <jprvita@gmail.com> wrote:
>
> Asus laptops have a hotkey function on the F7 key to turn the display
> backlight OFF, labeled with a screen with a X inside, as shown on
> https://dlcdnimgs.asus.com/websites/global/products/Xep1ZcSY8dyWXK11/images/keyboard.png
>
> This hotkey worked on very few Asus models, where the EC acts on the
> backlight and input events are generated only to notify userspace of the
> backlight status. On these machines the first hotkey press turns the
> display backlight OFF and notifies the OS with 0x34, which asus-nb-wmi
> forwards to userspace as KEY_DISPLAY_OFF, and a second press turns it
> back ON and notifies the OS with 0x33, which asus-nb-wmi forwards to
> userspace as KEY_DISPLAYTOGGLE. No other keys turn the display backlight
> back ON, but their input is forwarded normally to the application under
> focus.
>
> But for the majority of models, the EC actually does not act on the
> backlight and we simply get a 0x33 notification every time the key is
> pressed, or alternating values of 0x33 / 0x34. We have confirmed this
> behavior on the following models: E203NAS, GL553VE, X441NC, X441UVK,
> X541UVK, X555DG, X555UB, X555UQ, X560UD, X570ZD and X705FD, and the DSDT
> on these machines and the working one (only confirmed on N552VW) is the
> same for the query involved here.
>
> After trying to get information from Asus for quite some time on how
> this works on Windows, we finally recently got a contact that was able
> to give us a definitive answer and a specification for this feature.
> According this contact the 0x33 / 0x34 is an old behavior and all newer
> machines should only be notifying the OS with 0x35 instead, as newer ECs
> don't control the backlight anymore. When a 0x35 notification is
> received the OS should act on the display backlight. From the spec
> (machine-translated from Chinese):
>
>   1.4 Fn+F7
>   Function introduction
>
>   After the user presses Fn + F7, the screen will be closed through the
>   Windows API. The user will immediately open the screen with the mouse
>   and keyboard.
>   The API used can be found in the Sample URL:
>   https://code.msdn.microsoft.com/windowsdesktop/Coalescable-Timer-Sample-d9da954c
>   BIOS implementation
>   Increase Notify code
>   LCD On: 0x33 (display OSD)
>   LCD Off: 0x34 (display OSD)
>   LCD Switch: 0x35 (using API switch)
>
> The behavior on Windows with the ATKACPI driver from Asus installed
> matches what is described above, with the hotkey turning OFF the
> backlight of all connected displays with a fading effect, and any cursor
> input or key press turning the backlight back ON. The key press or
> cursor input is passed through to the application under focus or under
> the cursor.
>
> With this information from the spec, a simple analysis of the DSDT
> (pasted on the first commit of this series) shows that in order to have
> the firmware notify the OS with 0x35 and have the OS act on the
> backlight, we need to call WMNB(ASUS_WMI_DEVID_BACKLIGHT==0x00050011, 2)
> on the _WDG device. Then we can simply map that scan code to the
> appropriate key code in the driver.
>
> In include/uapi/linux/input-event-codes.h KEY_DISPLAY_OFF is defined as
> "display device to off state", but it is not actually handled by
> userspace on a GNOME+Xorg stack. There are also KEY_SCREENSAVER and
> KEY_SCREENLOCK / KEY_COFFEE. The former seems to be ignored by userspace
> as well (and its value is higher than 255 so it can't be handled by Xorg
> IIUC), and the later is mapped to XF86ScreenSaver by Xorg and triggers
> the lock screen action on GNOME. KEY_SCREENLOCK seems to be what closest
> matches the behavior described above in a Xorg world. I am not sure if
> any of this changes with Wayland, so any clarifications in that regard
> would be greatly appreciated.
>

Pushed to my review and testing queue, thanks!

> João Paulo Rechi Vita (3):
>   asus-wmi: Tell the EC the OS will handle the display off hotkey
>   asus-nb-wmi: Map 0x35 to KEY_SCREENLOCK
>   asus-nb-wmi: Drop mapping of 0x33 and 0x34 scan codes
>
>  drivers/platform/x86/asus-nb-wmi.c | 3 +--
>  drivers/platform/x86/asus-wmi.c    | 3 ++-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> --
> 2.19.1
>


-- 
With Best Regards,
Andy Shevchenko

      parent reply	other threads:[~2018-11-02 19:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01  0:21 [PATCH 0/3] Fix display off hotkey on Asus machines João Paulo Rechi Vita
2018-11-01  0:21 ` [PATCH 1/3] asus-wmi: Tell the EC the OS will handle the display off hotkey João Paulo Rechi Vita
2018-11-01  0:21 ` [PATCH 2/3] asus-nb-wmi: Map 0x35 to KEY_SCREENLOCK João Paulo Rechi Vita
2018-11-01  0:21 ` [PATCH 3/3] asus-nb-wmi: Drop mapping of 0x33 and 0x34 scan codes João Paulo Rechi Vita
2018-11-02 19:35 ` Andy Shevchenko [this message]

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=CAHp75VdzYf_CXiBzVrOUw+R5ZA8O-+_PGJ-Cv-q7QTXpvG0dVA@mail.gmail.com \
    --to=andy.shevchenko@gmail.com \
    --cc=acpi4asus-user@lists.sourceforge.net \
    --cc=andy@infradead.org \
    --cc=corentin.chary@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dvhart@infradead.org \
    --cc=hadess@hadess.net \
    --cc=jprvita@endlessm.com \
    --cc=jprvita@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@endlessm.com \
    --cc=platform-driver-x86@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.