Message-ID: <90a2d017-3e37-4a62-a55a-caf15416e188@gmail.com>
Date:   Sat, 23 Feb 2019 00:49:29 -0300
From:   Marcos Paulo de Souza <marcos.souza.org@...il.com>
To:     João Paulo Rechi Vita <jprvita@...lessm.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Upstreaming Team <linux@...lessm.com>,
        João Paulo Rechi Vita <jprvita@...il.com>
Subject: Re: X450LCP lost abillity to turn the screen off

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@...il.com> 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@...il.com> 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@...il.com> 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
>>

Powered by blists - more mailing lists