* 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 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.