* X450LCP lost abillity to turn the screen off
@ 2019-02-10 19:24 Marcos Paulo de Souza
2019-02-10 23:45 ` Andy Shevchenko
0 siblings, 1 reply; 9+ messages in thread
From: Marcos Paulo de Souza @ 2019-02-10 19:24 UTC (permalink / raw)
To: linux-kernel; +Cc: jprvita, andriy.shevchenko, platform-driver-x86
Hi,
Since 5.0.0-rc4 I vefiried that my ASUS laptop 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
I didn't have time to track it down, and my previous working kernel was 4.12
(default in openSUSE Leap 15), but I hope I will be able to test older kernels this week.
--
Thanks,
Marcos
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X450LCP lost abillity to turn the screen off
2019-02-10 19:24 X450LCP lost abillity to turn the screen off Marcos Paulo de Souza
@ 2019-02-10 23:45 ` Andy Shevchenko
2019-02-11 1:06 ` Marcos Paulo de Souza
0 siblings, 1 reply; 9+ messages in thread
From: Andy Shevchenko @ 2019-02-10 23:45 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Linux Kernel Mailing List, João Paulo Rechi Vita,
Andy Shevchenko, Platform Driver
On Sun, Feb 10, 2019 at 9:24 PM Marcos Paulo de Souza
<marcos.souza.org@gmail.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).
> 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 didn't have time to track it down, and my previous working kernel was 4.12
> (default in openSUSE Leap 15), but I hope I will be able to test older kernels this week.
>
> --
> Thanks,
> Marcos
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X450LCP lost abillity to turn the screen off
2019-02-10 23:45 ` Andy Shevchenko
@ 2019-02-11 1:06 ` Marcos Paulo de Souza
2019-02-11 19:14 ` João Paulo Rechi Vita
0 siblings, 1 reply; 9+ messages in thread
From: Marcos Paulo de Souza @ 2019-02-11 1:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linux Kernel Mailing List, João Paulo Rechi Vita,
Andy Shevchenko, Platform Driver
[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]
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@gmail.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.
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.
>
>
>> I didn't have time to track it down, and my previous working kernel was 4.12
>> (default in openSUSE Leap 15), but I hope I will be able to test older kernels this week.
>>
>> --
>> Thanks,
>> Marcos
>
>
>
[-- Attachment #2: dmidecode.txt --]
[-- Type: text/plain, Size: 10039 bytes --]
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
24 structures occupying 1683 bytes.
Table at 0x000EBF30.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: X450LCP.207
Release Date: 04/11/2014
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 6144 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
Smart battery is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: X450LCP
Version: 1.0
Serial Number: E6N0B2019875248
UUID: 00011CF9-09FF-1D12-679B-10C37BC1F9B8
Wake-up Type: Power Switch
SKU Number: ASUS-NotebookSKU
Family: X
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: X450LCP
Version: 1.0
Serial Number: BSN12345678901234567
Asset Tag: ATN12345678901234567
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: MIDDLE
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
Manufacturer: ASUSTeK COMPUTER INC.
Type: Notebook
Lock: Not Present
Version: 1.0
Serial Number: E6N0B2019875248
Asset Tag: No Asset Tag
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0
SKU Number: To be filled by O.E.M.
Handle 0x0004, DMI type 10, 26 bytes
On Board Device 1 Information
Type: Video
Status: Enabled
Description: VGA
On Board Device 2 Information
Type: Ethernet
Status: Enabled
Description: GLAN
On Board Device 3 Information
Type: Ethernet
Status: Enabled
Description: WLAN
On Board Device 4 Information
Type: Sound
Status: Enabled
Description: Audio CODEC
On Board Device 5 Information
Type: SATA Controller
Status: Enabled
Description: SATA Controller
On Board Device 6 Information
Type: Other
Status: Enabled
Description: USB 2.0 Controller
On Board Device 7 Information
Type: Other
Status: Enabled
Description: USB 3.0 Controller
On Board Device 8 Information
Type: Other
Status: Enabled
Description: SMBus Controller
On Board Device 9 Information
Type: Other
Status: Enabled
Description: Card Reader
On Board Device 10 Information
Type: Other
Status: Enabled
Description: Cmos Camera
On Board Device 11 Information
Type: Other
Status: Enabled
Description: Bluetooth
Handle 0x0005, DMI type 11, 5 bytes
OEM Strings
String 1: gQsyTcBQszb-t
String 2: cLKGwFe5CEb4O
String 3: vHP0ScB5R6pYY
String 4: 90NB03A2-M01750
String 5:
String 6:
String 7:
String 8:
String 9:
String 10:
Handle 0x0006, DMI type 12, 5 bytes
System Configuration Options
Option 1: DSN: 2 F4PINATG
Option 2: DSN:8B9F1CB73C01
Option 3: DSN:10C37BC1F9B8
Option 4: SMI:00B2CA
Handle 0x0007, DMI type 32, 20 bytes
System Boot Information
Status: No errors detected
Handle 0x0008, DMI type 4, 42 bytes
Processor Information
Socket Designation: SOCKET 0
Type: Central Processor
Family: Core i7
Manufacturer: Intel
ID: 51 06 04 00 FF FB EB BF
Signature: Type 0, Family 6, Model 69, Stepping 1
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Multi-threading)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz
Voltage: 1.2 V
External Clock: 100 MHz
Max Speed: 3800 MHz
Current Speed: 1800 MHz
Status: Populated, Enabled
Upgrade: Socket rPGA988B
L1 Cache Handle: 0x000A
L2 Cache Handle: 0x0009
L3 Cache Handle: 0x000B
Serial Number: Not Specified
Asset Tag: Fill By OEM
Part Number: Fill By OEM
Core Count: 2
Core Enabled: 2
Thread Count: 4
Characteristics:
64-bit capable
Handle 0x0009, DMI type 7, 19 bytes
Cache Information
Socket Designation: CPU Internal L2
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 512 kB
Maximum Size: 512 kB
Supported SRAM Types:
Unknown
Installed SRAM Type: Unknown
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 8-way Set-associative
Handle 0x000A, DMI type 7, 19 bytes
Cache Information
Socket Designation: CPU Internal L1
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 128 kB
Maximum Size: 128 kB
Supported SRAM Types:
Unknown
Installed SRAM Type: Unknown
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Other
Associativity: 8-way Set-associative
Handle 0x000B, DMI type 7, 19 bytes
Cache Information
Socket Designation: CPU Internal L3
Configuration: Enabled, Not Socketed, Level 3
Operational Mode: Write Back
Location: Internal
Installed Size: 4096 kB
Maximum Size: 4096 kB
Supported SRAM Types:
Unknown
Installed SRAM Type: Unknown
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 16-way Set-associative
Handle 0x000C, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 32 GB
Error Information Handle: Not Provided
Number Of Devices: 4
Handle 0x000D, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x000C
Error Information Handle: Not Provided
Total Width: 8 bits
Data Width: 8 bits
Size: 4096 MB
Form Factor: DIMM
Set: None
Locator: ChannelA-DIMM0
Bank Locator: BANK 0
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MT/s
Manufacturer: 0114
Serial Number: 0157EC3E
Asset Tag: 9876543210
Part Number: SH564128FJ8NWRNSQR
Rank: 1
Configured Clock Speed: 1600 MT/s
Handle 0x000E, DMI type 20, 35 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x000FFFFFFFF
Range Size: 4 GB
Physical Device Handle: 0x000D
Memory Array Mapped Address Handle: 0x0013
Partition Row Position: Unknown
Interleave Position: Unknown
Interleaved Data Depth: Unknown
Handle 0x000F, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x000C
Error Information Handle: Not Provided
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: DIMM
Set: None
Locator: ChannelA-DIMM1
Bank Locator: BANK 1
Type: Unknown
Type Detail: None
Speed: Unknown
Manufacturer: [Empty]
Serial Number: [Empty]
Asset Tag: 9876543210
Part Number: [Empty]
Rank: Unknown
Configured Clock Speed: Unknown
Handle 0x0010, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x000C
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: SODIMM
Set: None
Locator: ChannelB-DIMM0
Bank Locator: BANK 2
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MT/s
Manufacturer: 0114
Serial Number: 00000000
Asset Tag: 9876543210
Part Number:
Rank: 1
Configured Clock Speed: 1600 MT/s
Handle 0x0011, DMI type 20, 35 bytes
Memory Device Mapped Address
Starting Address: 0x00100000000
Ending Address: 0x001FFFFFFFF
Range Size: 4 GB
Physical Device Handle: 0x0010
Memory Array Mapped Address Handle: 0x0013
Partition Row Position: Unknown
Interleave Position: Unknown
Interleaved Data Depth: Unknown
Handle 0x0012, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x000C
Error Information Handle: Not Provided
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: DIMM
Set: None
Locator: ChannelB-DIMM1
Bank Locator: BANK 3
Type: Unknown
Type Detail: None
Speed: Unknown
Manufacturer: [Empty]
Serial Number: [Empty]
Asset Tag: 9876543210
Part Number: [Empty]
Rank: Unknown
Configured Clock Speed: Unknown
Handle 0x0013, DMI type 19, 31 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x001FFFFFFFF
Range Size: 8 GB
Physical Array Handle: 0x000C
Partition Width: 4
Handle 0x0019, DMI type 136, 6 bytes
OEM-specific Type
Header and Data:
88 06 19 00 00 00
Handle 0x001A, DMI type 131, 64 bytes
OEM-specific Type
Header and Data:
83 40 1A 00 31 00 00 00 00 00 00 00 00 00 00 00
F8 00 43 9C 00 00 00 00 01 20 00 00 05 00 09 00
F0 05 03 00 00 00 00 00 C8 00 FF FF 00 00 00 00
00 00 00 00 66 00 00 00 76 50 72 6F 00 00 00 00
Handle 0x001B, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Long
Installable Languages: 1
en|US|iso8859-1
Currently Installed Language: en|US|iso8859-1
Handle 0x001C, DMI type 127, 4 bytes
End Of Table
[-- Attachment #3: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 1817 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X450LCP lost abillity to turn the screen off
2019-02-11 1:06 ` Marcos Paulo de Souza
@ 2019-02-11 19:14 ` João Paulo Rechi Vita
2019-02-12 2:31 ` Marcos Paulo de Souza
0 siblings, 1 reply; 9+ messages in thread
From: João Paulo Rechi Vita @ 2019-02-11 19:14 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Andy Shevchenko, Linux Kernel Mailing List, Andy Shevchenko,
Platform Driver, Linux Upstreaming Team,
João Paulo Rechi Vita
Hello Marcos,
On Sun, Feb 10, 2019 at 5:05 PM Marcos Paulo de Souza
<marcos.souza.org@gmail.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@gmail.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).
> 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".
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?
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.
Best regards,
--
João Paulo Rechi Vita
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X450LCP lost abillity to turn the screen off
2019-02-11 19:14 ` João Paulo Rechi Vita
@ 2019-02-12 2:31 ` Marcos Paulo de Souza
2019-02-12 10:30 ` Andy Shevchenko
2019-02-12 16:30 ` João Paulo Rechi Vita
0 siblings, 2 replies; 9+ messages in thread
From: Marcos Paulo de Souza @ 2019-02-12 2:31 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: Andy Shevchenko, Linux Kernel Mailing List, Andy Shevchenko,
Platform Driver, Linux Upstreaming Team,
João Paulo Rechi Vita
[-- Attachment #1: Type: text/plain, Size: 5261 bytes --]
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@gmail.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@gmail.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.
>
> 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.
Let me know if I can provide more info. I may have news in the next day
about testing other kernels...
Thanks,
Marcos
>
> Best regards,
>
> --
> João Paulo Rechi Vita
>
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 1817 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X450LCP lost abillity to turn the screen off
2019-02-12 2:31 ` Marcos Paulo de Souza
@ 2019-02-12 10:30 ` Andy Shevchenko
2019-02-12 16:30 ` João Paulo Rechi Vita
1 sibling, 0 replies; 9+ messages in thread
From: Andy Shevchenko @ 2019-02-12 10:30 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: João Paulo Rechi Vita, Linux Kernel Mailing List,
Andy Shevchenko, Platform Driver, Linux Upstreaming Team,
João Paulo Rechi Vita
On Tue, Feb 12, 2019 at 4:31 AM Marcos Paulo de Souza
<marcos.souza.org@gmail.com> wrote:
> 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@gmail.com> wrote:
> > 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.
When you are going to try older releases, it would be nice to see if
LTS kernels (v4.14.y, v4.19.y from Linux stable tree [1]) behave
differently
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X450LCP lost abillity to turn the screen off
2019-02-12 2:31 ` Marcos Paulo de Souza
2019-02-12 10:30 ` Andy Shevchenko
@ 2019-02-12 16:30 ` João Paulo Rechi Vita
2019-02-13 21:46 ` Marcos Paulo de Souza
1 sibling, 1 reply; 9+ messages in thread
From: João Paulo Rechi Vita @ 2019-02-12 16:30 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Andy Shevchenko, Linux Kernel Mailing List, Andy Shevchenko,
Platform Driver, Linux Upstreaming Team,
João Paulo Rechi Vita
On Mon, Feb 11, 2019 at 6:31 PM Marcos Paulo de Souza
<marcos.souza.org@gmail.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@gmail.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@gmail.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.
> >
> > 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X450LCP lost abillity to turn the screen off
2019-02-12 16:30 ` João Paulo Rechi Vita
@ 2019-02-13 21:46 ` Marcos Paulo de Souza
2019-02-23 3:49 ` Marcos Paulo de Souza
0 siblings, 1 reply; 9+ messages in thread
From: Marcos Paulo de Souza @ 2019-02-13 21:46 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: Andy Shevchenko, Linux Kernel Mailing List, Andy Shevchenko,
Platform Driver, Linux Upstreaming Team,
João Paulo Rechi Vita
[-- Attachment #1: Type: text/plain, Size: 6630 bytes --]
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@gmail.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@gmail.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@gmail.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.
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
>
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 1817 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X450LCP lost abillity to turn the screen off
2019-02-13 21:46 ` Marcos Paulo de Souza
@ 2019-02-23 3:49 ` Marcos Paulo de Souza
0 siblings, 0 replies; 9+ messages in thread
From: Marcos Paulo de Souza @ 2019-02-23 3:49 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: Andy Shevchenko, Linux Kernel Mailing List, Andy Shevchenko,
Platform Driver, Linux Upstreaming Team,
João Paulo Rechi Vita
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@gmail.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@gmail.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@gmail.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
>>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-02-23 3:49 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-10 19:24 X450LCP lost abillity to turn the screen off Marcos Paulo de Souza
2019-02-10 23:45 ` Andy Shevchenko
2019-02-11 1:06 ` Marcos Paulo de Souza
2019-02-11 19:14 ` João Paulo Rechi Vita
2019-02-12 2:31 ` Marcos Paulo de Souza
2019-02-12 10:30 ` Andy Shevchenko
2019-02-12 16:30 ` João Paulo Rechi Vita
2019-02-13 21:46 ` Marcos Paulo de Souza
2019-02-23 3:49 ` Marcos Paulo de Souza
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).