Hi guys,
We have some new laptops with Intel new Intel WiskyLake CPU come
in and they all have the same problem. They all have the so-called
"Modern Standby" feature which is s2idle in Linux.
The problem is the built-in keyboard no longer wake up the system
after it goes to s2idle. Only the power button can wake up. It's
different from the other laptops with old Intel CPUs (CoffeeLake,
KaybeLake...etc). We found the difference is that the EC (embedded
controller) no longer signals SCI event when in s2idle.
Confirmed with ASUS EC engineer, he also admits that the EC code
for signaling SCI event in modern standby has been removed on
WiskyLake models. Because the built-in PS2 keyboard can still wake up
the system on WisksyLake+Windows10 RS4 combination without EC
intervention.
Based on this information, we suspect that maybe the built-in
keyboard wakeup on Windows 10 RS4 in enabled by default (although we
don't know how to prove that). It's easy to simply do
'device_set_wakeup_enable' and 'enable_irq_wake' for the i8042
keyboard port to wake up the system without EC, but it's nasty.
Any suggestion about how to achieve the keyboard wake up function
on these new laptops in a generic way? Thanks
Chris
On Friday, August 3, 2018 10:04:09 AM CEST Chris Chiu wrote:
> Hi guys,
> We have some new laptops with Intel new Intel WiskyLake CPU come
> in and they all have the same problem. They all have the so-called
> "Modern Standby" feature which is s2idle in Linux.
>
> The problem is the built-in keyboard no longer wake up the system
> after it goes to s2idle. Only the power button can wake up. It's
> different from the other laptops with old Intel CPUs (CoffeeLake,
> KaybeLake...etc). We found the difference is that the EC (embedded
> controller) no longer signals SCI event when in s2idle.
>
> Confirmed with ASUS EC engineer, he also admits that the EC code
> for signaling SCI event in modern standby has been removed on
> WiskyLake models. Because the built-in PS2 keyboard can still wake up
> the system on WisksyLake+Windows10 RS4 combination without EC
> intervention.
>
> Based on this information, we suspect that maybe the built-in
> keyboard wakeup on Windows 10 RS4 in enabled by default (although we
> don't know how to prove that). It's easy to simply do
> 'device_set_wakeup_enable' and 'enable_irq_wake' for the i8042
> keyboard port to wake up the system without EC, but it's nasty.
>
> Any suggestion about how to achieve the keyboard wake up function
> on these new laptops in a generic way? Thanks
What about echoing "enabled" to the keyboard's power/wakeup file in sysfs?
On Mon, Aug 6, 2018 at 5:37 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Friday, August 3, 2018 10:04:09 AM CEST Chris Chiu wrote:
>> Hi guys,
>> We have some new laptops with Intel new Intel WiskyLake CPU come
>> in and they all have the same problem. They all have the so-called
>> "Modern Standby" feature which is s2idle in Linux.
>>
>> The problem is the built-in keyboard no longer wake up the system
>> after it goes to s2idle. Only the power button can wake up. It's
>> different from the other laptops with old Intel CPUs (CoffeeLake,
>> KaybeLake...etc). We found the difference is that the EC (embedded
>> controller) no longer signals SCI event when in s2idle.
>>
>> Confirmed with ASUS EC engineer, he also admits that the EC code
>> for signaling SCI event in modern standby has been removed on
>> WiskyLake models. Because the built-in PS2 keyboard can still wake up
>> the system on WisksyLake+Windows10 RS4 combination without EC
>> intervention.
>>
>> Based on this information, we suspect that maybe the built-in
>> keyboard wakeup on Windows 10 RS4 in enabled by default (although we
>> don't know how to prove that). It's easy to simply do
>> 'device_set_wakeup_enable' and 'enable_irq_wake' for the i8042
>> keyboard port to wake up the system without EC, but it's nasty.
>>
>> Any suggestion about how to achieve the keyboard wake up function
>> on these new laptops in a generic way? Thanks
>
> What about echoing "enabled" to the keyboard's power/wakeup file in sysfs?
>
'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get the
keyboard wake up the system as expected. We considered to work out a DMI
based quirk for this. But based on the information that EC would not signal SCI
event for WiskyLake models, we'd like to know if there's any generic solution?
Maybe a 'udev' rule to identify WiskyLake NoteBook then enable the keyboard
wake up?
Chris
On Monday, August 6, 2018 1:07:25 PM CEST Chris Chiu wrote:
> On Mon, Aug 6, 2018 at 5:37 PM, Rafael J. Wysocki <[email protected]> wrote:
> > On Friday, August 3, 2018 10:04:09 AM CEST Chris Chiu wrote:
> >> Hi guys,
> >> We have some new laptops with Intel new Intel WiskyLake CPU come
> >> in and they all have the same problem. They all have the so-called
> >> "Modern Standby" feature which is s2idle in Linux.
> >>
> >> The problem is the built-in keyboard no longer wake up the system
> >> after it goes to s2idle. Only the power button can wake up. It's
> >> different from the other laptops with old Intel CPUs (CoffeeLake,
> >> KaybeLake...etc). We found the difference is that the EC (embedded
> >> controller) no longer signals SCI event when in s2idle.
> >>
> >> Confirmed with ASUS EC engineer, he also admits that the EC code
> >> for signaling SCI event in modern standby has been removed on
> >> WiskyLake models. Because the built-in PS2 keyboard can still wake up
> >> the system on WisksyLake+Windows10 RS4 combination without EC
> >> intervention.
> >>
> >> Based on this information, we suspect that maybe the built-in
> >> keyboard wakeup on Windows 10 RS4 in enabled by default (although we
> >> don't know how to prove that). It's easy to simply do
> >> 'device_set_wakeup_enable' and 'enable_irq_wake' for the i8042
> >> keyboard port to wake up the system without EC, but it's nasty.
> >>
> >> Any suggestion about how to achieve the keyboard wake up function
> >> on these new laptops in a generic way? Thanks
> >
> > What about echoing "enabled" to the keyboard's power/wakeup file in sysfs?
> >
>
> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get the
> keyboard wake up the system as expected. We considered to work out a DMI
> based quirk for this. But based on the information that EC would not signal SCI
> event for WiskyLake models, we'd like to know if there's any generic solution?
> Maybe a 'udev' rule to identify WiskyLake NoteBook then enable the keyboard
> wake up?
A udev rule sounds like a good idea to me.
On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki <[email protected]> wrote:
>> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get the
>> keyboard wake up the system as expected. We considered to work out a DMI
>> based quirk for this. But based on the information that EC would not signal SCI
>> event for WiskyLake models, we'd like to know if there's any generic solution?
>> Maybe a 'udev' rule to identify WiskyLake NoteBook then enable the keyboard
>> wake up?
>
> A udev rule sounds like a good idea to me.
What would the udev rule look like though?
Match for Intel CPU generation (WhiskyLake) and laptop chassis type
and then enable i8042 wakeups? While that seems like the most accurate
reflection of the situation which we are seeing across multiple
vendors, it doesn't feel right and seems unlikely to be accepted by
systemd upstream.
In previous designs, pressing a key while the system was in S3 sleep
would cause a SCI interrupt due to the firing of the EC GPE, which
effectively meant that keyboard wakeups were on by default and could
not be disabled. Also USB keyboards have wakeups on by default (see
usbhid_start()). Just these new platforms have this
unfortunate/accidental behaviour change...
Would it make sense to turn i8042 wakeups on by default on the kernel
side? I don't know if any particular conditions are applied, but that
would appear to be the default Win10 behaviour here.
Daniel
On Fri, Aug 17, 2018 at 4:29 AM Daniel Drake <[email protected]> wrote:
>
> On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki <[email protected]> wrote:
> >> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get the
> >> keyboard wake up the system as expected. We considered to work out a DMI
> >> based quirk for this. But based on the information that EC would not signal SCI
> >> event for WiskyLake models, we'd like to know if there's any generic solution?
> >> Maybe a 'udev' rule to identify WiskyLake NoteBook then enable the keyboard
> >> wake up?
> >
> > A udev rule sounds like a good idea to me.
>
> What would the udev rule look like though?
>
> Match for Intel CPU generation (WhiskyLake) and laptop chassis type
> and then enable i8042 wakeups? While that seems like the most accurate
> reflection of the situation which we are seeing across multiple
> vendors, it doesn't feel right and seems unlikely to be accepted by
> systemd upstream.
>
> In previous designs, pressing a key while the system was in S3 sleep
> would cause a SCI interrupt due to the firing of the EC GPE, which
> effectively meant that keyboard wakeups were on by default and could
> not be disabled. Also USB keyboards have wakeups on by default (see
> usbhid_start()). Just these new platforms have this
> unfortunate/accidental behaviour change...
>
> Would it make sense to turn i8042 wakeups on by default on the kernel
> side? I don't know if any particular conditions are applied, but that
> would appear to be the default Win10 behaviour here.
Yes, it would, but that might prevent some systems from suspending at
all in theory if there are keyboard interrupts on them occurring
during system-wide suspend, for example.
Otherwise, it would just be a matter of calling device_wakeup_enable()
at init time for the keyboard port (as long as you know which one of
them is the keyboard).