Re: X450LCP lost abillity to turn the screen off

[Marcos Paulo de Souza]

Hi JoÃo,

On 2/13/19 7:46 PM, Marcos Paulo de Souza wrote:
> Hello JoÃo,
>
> On 2/12/19 2:30 PM, JoÃo Paulo Rechi Vita wrote:
> > On Mon, Feb 11, 2019 at 6:31 PM Marcos Paulo de Souza
> > <marcos.souza.org@xxxxxxxxx> wrote:
> > > Hello JoÃo,
> > >
> > > On 2/11/19 5:14 PM, JoÃo Paulo Rechi Vita wrote:
> > > > Hello Marcos,
> > > >
> > > > On Sun, Feb 10, 2019 at 5:05 PM Marcos Paulo de Souza
> > > > <marcos.souza.org@xxxxxxxxx> wrote:
> > > > > On 2/10/19 9:45 PM, Andy Shevchenko wrote:
> > > > > > On Sun, Feb 10, 2019 at 9:24 PM Marcos Paulo de Souza
> > > > > > <marcos.souza.org@xxxxxxxxx> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Since 5.0.0-rc4 I vefiried that my ASUS laptop
> > > > > >
> > > > > > Can you be more specific, what model, BIOS version, etc (also would be
> > > > > > nice to have dmi strings from it, I guess dmidecode tool would help).
> > > > >
> > > > > dmidecode attached.
> > > > >
> > > > > > > cannot turn the screen of
> > > > > > > anymore. There were several commits in 5.0 merge window touching this
> > > > > > > functionality like:
> > > > > > >
> > > > > > >    71b12beaf12f platform/x86: asus-nb-wmi: Drop mapping of 0x33 and 0x34 scan codes
> > > > > > >    b3f2f3799a97 platform/x86: asus-nb-wmi: Map 0x35 to KEY_SCREENLOCK
> > > > > > >    78f3ac76d9e5 platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey
> > > > > >
> > > > > > Can you bisect or just try to revert one-by-one from above and see
> > > > > > which one is a culprit?
> > > > >
> > > > > I already did some primary analysis, and it seems the commit 3f2f3799a97
> > > > > maps the x035 (which is Alt+f7 in my laptop) to SCREENLOCK, which is
> > > > > wrong because alt+f7 should be Screen Toggle. I will try to revert this
> > > > > commit, or remap to KEY_DISPLAYTOGGLE or KEY_DISPLAY_OFF, and test if it
> > > > > works.
> > > >
> > > > User-space does not act on KEY_DISPLAYTOGGLE / KEY_DISPLAY_OFF, these
> > > > values should be used when the hardware is turning the screen
> > > > back-light ON and OFF. According to Asus BIOS engineers, the
> > > > back-light used to be driven by the hardware, but they have changed to
> > > > the this new approach of telling the OS to drive the back-light for a
> > > > while now (no specific dates or BIOS / windows driver versions were
> > > > shared). They we actually surprised when we told the that some
> > > > machines still have a working implementation (and selected by default
> > > > unless told otherwise) of the old behavior, which sounds like it is
> > > > the case for the machine you have at hand.
> > > >
> > > > The new behavior, as defined in their spec is to only notify the OS of
> > > > the keypress with 0x35, and have the OS "close" the screen, with the
> > > > screen being "opened" on mouse or keyboard activity. This closely
> > > > matches the screen lock behavior on Linux platforms, so we are mapping
> > > > it to KEY_SCREENLOCK in the kernel, and it then gets mapped to
> > > > XF86ScreenSaver by xkeyboard-config, and finally gnome-settings-daemon
> > > > uses it as a lock screen shortcut (look for "screensaver" in
> > > > plugins/media-keys/shortcuts-list.h on the gnome-settings-daemon
> > > > repository).
> > >
> > > Interesting.
> > >
> > > > > But yes, I'll do my best to track the problem ASAP at my side. Please
> > > > > let me know if I can provide any additional information.
> > > >
> > > > You can check what is being sent by the kernel with evtest, and what
> > > > is being sent by X with "xinput test <device id>" (and you can find
> > > > the device id with "xinput list"). And you can re-map it without
> > > > having to rebuild the kernel using udev's hwdb. But simply re-mapping
> > > > should not change anything, since userspace does not act on
> > > > KEY_DISPLAYTOGGLE / KEY_DISPLAY_OFF. If you want to switch back to the
> > > > old behavior you need to revert "78f3ac76d9e5 platform/x86: asus-wmi:
> > > > Tell the EC the OS will handle the display off hotkey".
> > >
> > > I tried reverting the patch and only recompiling/reinstalling the
> > > platform/x86 modules, but the problem still happens. My next step will
> > > be testing agains't 4.20, since my machine was working with 4.12, so I
> > > might try the major releases first.
> >
> > So maybe your desktop environment (KDE) acts on KEY_DISPLAYTOGGLE /
> > KEY_DISPLAY_OFF and this is the only reason why this was working in
> > the first place? It would be sad to find out different DEs behave
> > differently in this situation, but IMO
> > include/uapi/linux/input-event-codes.h is not super clear about
> > whether userspace should act on these values or they are just intended
> > to notify userspace of a change so desktop notifications (like an OSD)
> > can be shown. If that is the case you will need to revert all 3
> > commits you listed earlier. Also, make sure to check with evtest which
> > values are being sent by the kernel to make sure the correct code is
> > being executed.
>
> I think you found the issue. Tried GNOME in the same machine, with the
> same kernel, and it works. I can revert those 3 commits and try again
> with a different DE, if you think it would help.

Let me elaborate it better:
* When using KDE, pressing Alt+F7, KDE only locks the screen
* When using GNOME, pressing Alt+F7, GNOME locks the screen and turns 
the screen off.

I hope it explains better what happened.

Thanks.

> Thanks.
>
> > > > That being said, I believe it would be more productive to figure out
> > > > why your userspace stack is not reacting to 0x35 / XF86ScreenSaver and
> > > > fix that. Which window manager / graphical desktop environment are you
> > > > using?
> > >
> > > Well, I'm using KDE Plasma 5 Desktop Environment (20170319-lp150.7.1) of
> > > openSUSE Leap 15.0.
> > >
> > > > As a final note, from your dmidecode output I see you are on BIOS
> > > > version X450LCP.207, and there is version 208 available for download
> > > > on Asus website. I'm curious to know if it changes the old behavior
> > > > (with the patches you listed reverted), but I'm not responsible if a
> > > > BIOS update breaks your machine in any way, so just do it if you this
> > > > is something you are comfortable with and understand and assume all
> > > > the risks yourself. We have been reporting machines with the old
> > > > behavior back to Asus, but I don't know what they are doing with that
> > > > information, if anything. I'm adding your machine with the old BIOS
> > > > version to the list, so if you test the new BIOS let me know so I can
> > > > add that as well. But please don't feel any pressure to update the
> > > > BIOS if this is something you would not do otherwise.
> > >
> > > For now I would like to skip this upgrade, since it is nothing that I
> > > can play with now (I use this machine at work). I really hope that Asus
> > > could join fwupd, making such upgrades easier to apply on Linux machines.
> >
> > Absolutely, don't worry about the BIOS update.
> >
> > > Let me know if I can provide more info. I may have news in the next day
> > > about testing other kernels...
> >
> > Thanks for your feedback.
> >
> > --
> > JoÃo Paulo Rechi Vita