I have a laptop running Slackware64 15.0, which, previous to upgrading
to 5.15.27, required me to press a keyboard key after opening the lid
to awaken it (after it was suspended to RAM).

After upgrading to 5.15.27 (the dirty pipe saga of 2022), the laptop
now awakens just by opening the lid. (I consider this to be A Good
Thing.)

However, it also awakens (with the lid still closed) if I unplug the
AC power. (I consider this to be A Bad Thing.)

I've hunted around a bit, but don't see any obvious reasons for this.
(I define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
/proc/acpi/wakeup is the same in both 5.15.19 and .27.

This happened with both Slackware64 15.0 and with Artix, so I'm
leaning in the "something specific with kernel" direction, as opposed
to "something peculiar of my distro".

FWIW, it is an HP Envy x360 with a Ryzen 4700U.

Has anyone here seen this on their hardware? I'd like it NOT to
wakeup when the AC power is disconnected, and if anyone has some
ideas, I'd be happy to hear it.

Thanks.
Jim

On Mon, 04 Apr 2022 21:17:57 -0300, Jim Diamond wrote:
> I've hunted around a bit, but don't see any obvious reasons for this. (I
> define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
> /proc/acpi/wakeup is the same in both 5.15.19 and .27.

If you are willing to do the work, it might be easier to diff only
between the two kernel versions where this change happened, for example
between 5.15.23 and 5.15.24.

The quickest way to find where the change happened is to do a binary
search for that point. Now you know that 5.15.19 work as before and
5.15.27 works at after. What about the version in the middle in between?
That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
know if the next step is to search between 5.15.19 and 5.15.23 or between
5.15.23 and 5.15.27.

regards Henrik

On 4/5/22 07:45, Henrik Carlqvist wrote:
> If you are willing to do the work, it might be easier to diff only
> between the two kernel versions where this change happened, for
> example between 5.15.23 and 5.15.24.
>
> The quickest way to find where the change happened is to do a
> binary search for that point. Now you know that 5.15.19 work as
> before and 5.15.27 works at after. What about the version in the
> middle in between? That would be 5.15.23. Once you have tested with
> kernel 5.15.23 you will know if the next step is to search between
> 5.15.19 and 5.15.23 or between 5.15.23 and 5.15.27.

The handling of events by buttons is done on elogin daemon.
The elogin daemon interacts with acpi daemon. I suggest to check the
log to see which events are detected at boot time.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

Jim Diamond <JimDiamond@ns.sympatico.ca> wrote:
> I have a laptop running Slackware64 15.0, which, previous to upgrading
> to 5.15.27, required me to press a keyboard key after opening the lid
> to awaken it (after it was suspended to RAM).
>
> After upgrading to 5.15.27 (the dirty pipe saga of 2022), the laptop
> now awakens just by opening the lid. (I consider this to be A Good
> Thing.)
>
> However, it also awakens (with the lid still closed) if I unplug the
> AC power. (I consider this to be A Bad Thing.)
>
> I've hunted around a bit, but don't see any obvious reasons for this.
> (I define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
> /proc/acpi/wakeup is the same in both 5.15.19 and .27.
>
> This happened with both Slackware64 15.0 and with Artix, so I'm
> leaning in the "something specific with kernel" direction, as opposed
> to "something peculiar of my distro".
>
> FWIW, it is an HP Envy x360 with a Ryzen 4700U.
>
> Has anyone here seen this on their hardware? I'd like it NOT to
> wakeup when the AC power is disconnected, and if anyone has some
> ideas, I'd be happy to hear it.
>
> Thanks. Jim

You might be able to add a file in /etc/acpi/events/ so that it
ignores that AC power connected/disconnected event. I'd tried but
failed to do a similar thing on a yoga-style laptop -- disable the
keyboard when folded to yoga-style, and re-enable it when folded back.
So, first modify the acpi/acpi_handler.sh to log every single event
it ever sees. Then plug/unplug the AC power and check the logs.
If you're actually trapping those events, then you should likely be
able to add some events/ scripts to handle them however you prefer.
(But, like I said, I failed to accomplish all that.)
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 4/5/22 12:52, John Forkosh wrote:

> You might be able to add a file in /etc/acpi/events/ so that it
> ignores that AC power connected/disconnected event. I'd tried but
> failed to do a similar thing on a yoga-style laptop -- disable the
> keyboard when folded to yoga-style, and re-enable it when folded
> back. So, first modify the acpi/acpi_handler.sh to log every single
> event it ever sees. Then plug/unplug the AC power and check the
> logs. If you're actually trapping those events, then you should
> likely be able to add some events/ scripts to handle them however you
> prefer. (But, like I said, I failed to accomplish all that.)

That may work on 14.2 and lower versions. The elogind daemon intercepts
the events before they get to the acp handler.

In 15.0 had to change the file /etc/elogind/logind.conf to ignore 'halt'
and 'suspend' events.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

On 2022-04-05 at 07:52 ADT, John Forkosh <forkosh@panix.com> wrote:
> Jim Diamond <JimDiamond@ns.sympatico.ca> wrote:
>> I have a laptop running Slackware64 15.0, which, previous to upgrading
>> to 5.15.27, required me to press a keyboard key after opening the lid
>> to awaken it (after it was suspended to RAM).
>>
>> After upgrading to 5.15.27 (the dirty pipe saga of 2022), the laptop
>> now awakens just by opening the lid. (I consider this to be A Good
>> Thing.)
>>
>> However, it also awakens (with the lid still closed) if I unplug the
>> AC power. (I consider this to be A Bad Thing.)
>>
>> I've hunted around a bit, but don't see any obvious reasons for this.
>> (I define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
>> /proc/acpi/wakeup is the same in both 5.15.19 and .27.
>>
>> This happened with both Slackware64 15.0 and with Artix, so I'm
>> leaning in the "something specific with kernel" direction, as opposed
>> to "something peculiar of my distro".
>>
>> FWIW, it is an HP Envy x360 with a Ryzen 4700U.
>>
>> Has anyone here seen this on their hardware? I'd like it NOT to
>> wakeup when the AC power is disconnected, and if anyone has some
>> ideas, I'd be happy to hear it.
>>
>> Thanks. Jim
>
> You might be able to add a file in /etc/acpi/events/ so that it
> ignores that AC power connected/disconnected event. I'd tried but
> failed to do a similar thing on a yoga-style laptop -- disable the
> keyboard when folded to yoga-style, and re-enable it when folded back.
> So, first modify the acpi/acpi_handler.sh to log every single event
> it ever sees. Then plug/unplug the AC power and check the logs.
> If you're actually trapping those events, then you should likely be
> able to add some events/ scripts to handle them however you prefer.
> (But, like I said, I failed to accomplish all that.)

Hi John,

thanks for the thoughts. I think that for acpi_handler.sh to do
anything, the laptop has to be "awake". So, by the time that
acpi_handler.sh is called, the thing I don't want to happen has
already happened.

I did contemplate handling the "wakeup" there by checking to see if
the lid is closed, and, if so, put the laptop back to sleep, but I was
hoping to prevent the wakeup in the first place.

Cheers.
Jim

On 2022-04-05 at 10:46 ADT, Giovanni <lsodgf0@home.net.it> wrote:
> On 4/5/22 12:52, John Forkosh wrote:
>
>> You might be able to add a file in /etc/acpi/events/ so that it
>> ignores that AC power connected/disconnected event. I'd tried but
>> failed to do a similar thing on a yoga-style laptop -- disable the
>> keyboard when folded to yoga-style, and re-enable it when folded
>> back. So, first modify the acpi/acpi_handler.sh to log every single
>> event it ever sees. Then plug/unplug the AC power and check the
>> logs. If you're actually trapping those events, then you should
>> likely be able to add some events/ scripts to handle them however you
>> prefer. (But, like I said, I failed to accomplish all that.)
>
> That may work on 14.2 and lower versions. The elogind daemon intercepts
> the events before they get to the acp handler.
>
> In 15.0 had to change the file /etc/elogind/logind.conf to ignore 'halt'
> and 'suspend' events.

Hi Giovanni,

as I mentioned to John, I was hoping to avoid it waking up in the
first place, which I assume (*cough*) is because of some change in how
"hardware events" are handled.

I did change a couple of entries in /etc/elogind/logind.conf when I
initially installed 15.0, but that file hasn't been changed since well
before 5.15.27 was installed.

Jim

On 2022-04-05 at 02:45 ADT, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> On Mon, 04 Apr 2022 21:17:57 -0300, Jim Diamond wrote:
>> I've hunted around a bit, but don't see any obvious reasons for this. (I
>> define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
>> /proc/acpi/wakeup is the same in both 5.15.19 and .27.
>
> If you are willing to do the work, it might be easier to diff only
> between the two kernel versions where this change happened, for example
> between 5.15.23 and 5.15.24.
>
> The quickest way to find where the change happened is to do a binary
> search for that point. Now you know that 5.15.19 work as before and
> 5.15.27 works at after. What about the version in the middle in between?
> That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
> know if the next step is to search between 5.15.19 and 5.15.23 or between
> 5.15.23 and 5.15.27.

Hi Henrik,

thanks for your thoughts. I was hoping not to dig through the source
code (to say nothing of doing a binary search with kernel compiles at
each stage), but I may end up doing that.

I don't know how many people are reading this newsgroup these days,
but I am somewhat intrigued if I am the only person having this issue.
I had previously posted this to alt.os.linux since it is not
slackware-specific (it also happens to me with the artix system I was
using while waiting for 15.0 to appear). However, sadly that group is
mostly full of spam these days.

Cheers.

Jim

On 2022-04-05 at 05:36 ADT, Giovanni <lsodgf0@home.net.it> wrote:
> On 4/5/22 07:45, Henrik Carlqvist wrote:
>> If you are willing to do the work, it might be easier to diff only
>> between the two kernel versions where this change happened, for
>> example between 5.15.23 and 5.15.24.
>>
>> The quickest way to find where the change happened is to do a
>> binary search for that point. Now you know that 5.15.19 work as
>> before and 5.15.27 works at after. What about the version in the
>> middle in between? That would be 5.15.23. Once you have tested with
>> kernel 5.15.23 you will know if the next step is to search between
>> 5.15.19 and 5.15.23 or between 5.15.23 and 5.15.27.
>
> The handling of events by buttons is done on elogin daemon.
> The elogin daemon interacts with acpi daemon. I suggest to check the
> log to see which events are detected at boot time.

Giovanni,

I'm not sure which log you are referring to, but in /var/log the only
file I see with "elogind" is /var/log/message. At boot time there are
lines like this

Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event3 (Power Button)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event1 (Power Button)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event2 (Lid Switch)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event0 (AT Translated Set 2 keyboard)
Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event8 (HP WMI hotkeys)

but this is the same set of devices for both .19 and .27.

Were you thinking of some other log information?

Jim

On 4/7/22 02:40, Jim Diamond wrote:

> Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event3 (Power Button)
> Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event1 (Power Button)
> Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event2 (Lid Switch)
> Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event0 (AT Translated Set 2 keyboard)
> Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event8 (HP WMI hotkeys)
>
> but this is the same set of devices for both .19 and .27.
>
> Were you thinking of some other log information?
>
> Jim

No, that's the log which shows that the buttons are trapped by
elogin-daemon and that led me to think of problems in elogind. But also
this package didn't change.

Kernel change-logs show modifications in the area, with several
references to 'suspend'.
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.25
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.26
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.27

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

On 4/6/2022 8:08 PM, Jim Diamond wrote:
> On 2022-04-05 at 02:45 ADT, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>> On Mon, 04 Apr 2022 21:17:57 -0300, Jim Diamond wrote:
>>> I've hunted around a bit, but don't see any obvious reasons for this. (I
>>> define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
>>> /proc/acpi/wakeup is the same in both 5.15.19 and .27.
>>
>> If you are willing to do the work, it might be easier to diff only
>> between the two kernel versions where this change happened, for example
>> between 5.15.23 and 5.15.24.
>>
>> The quickest way to find where the change happened is to do a binary
>> search for that point. Now you know that 5.15.19 work as before and
>> 5.15.27 works at after. What about the version in the middle in between?
>> That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
>> know if the next step is to search between 5.15.19 and 5.15.23 or between
>> 5.15.23 and 5.15.27.
>
> Hi Henrik,
>
> thanks for your thoughts. I was hoping not to dig through the source
> code (to say nothing of doing a binary search with kernel compiles at
> each stage), but I may end up doing that.
>
> I don't know how many people are reading this newsgroup these days,
> but I am somewhat intrigued if I am the only person having this issue.
> I had previously posted this to alt.os.linux since it is not
> slackware-specific (it also happens to me with the artix system I was
> using while waiting for 15.0 to appear). However, sadly that group is
> mostly full of spam these days.
>
> Cheers.
>
> Jim

I did some testing on my laptop running Slackware 15.0 with 5.15.27.

Suspend to RAM
- Awakens on opening the case
- Does nothing on removing/attaching power

Suspend to disk
- Awakens on opening the case
- Does nothing on removing/attaching power

On 4/7/2022 2:25 PM, User wrote:
> On 4/6/2022 8:08 PM, Jim Diamond wrote:
>> On 2022-04-05 at 02:45 ADT, Henrik Carlqvist
>> <Henrik.Carlqvist@deadspam.com> wrote:
>>> On Mon, 04 Apr 2022 21:17:57 -0300, Jim Diamond wrote:
>>>> I've hunted around a bit, but don't see any obvious reasons for
>>>> this. (I
>>>> define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
>>>> /proc/acpi/wakeup is the same in both 5.15.19 and .27.
>>>
>>> If you are willing to do the work, it might be easier to diff only
>>> between the two kernel versions where this change happened, for example
>>> between 5.15.23 and 5.15.24.
>>>
>>> The quickest way to find where the change happened is to  do a binary
>>> search for that point. Now you know that 5.15.19 work as before and
>>> 5.15.27 works at after. What about the version in the middle in between?
>>> That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
>>> know if the next step is to search between 5.15.19 and 5.15.23 or
>>> between
>>> 5.15.23 and 5.15.27.
>>
>> Hi Henrik,
>>
>> thanks for your thoughts.  I was hoping not to dig through the source
>> code (to say nothing of doing a binary search with kernel compiles at
>> each stage), but I may end up doing that.
>>
>> I don't know how many people are reading this newsgroup these days,
>> but I am somewhat intrigued if I am the only person having this issue.
>> I had previously posted this to alt.os.linux since it is not
>> slackware-specific (it also happens to me with the artix system I was
>> using while waiting for 15.0 to appear).  However, sadly that group is
>> mostly full of spam these days.
>>
>> Cheers.
>>
>>                                  Jim
>
> I did some testing on my laptop running Slackware 15.0 with 5.15.27.
>
> Suspend to RAM
> - Awakens on opening the case
> - Does nothing on removing/attaching power
>
> Suspend to disk
> - Awakens on opening the case
> - Does nothing on removing/attaching power

Screen Saver Mode
- Awakens on opening the case
- Awakens on removing/attaching power

On 2022-04-07 at 15:25 ADT, User <user@example.net> wrote:
> On 4/6/2022 8:08 PM, Jim Diamond wrote:
>> On 2022-04-05 at 02:45 ADT, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>>> On Mon, 04 Apr 2022 21:17:57 -0300, Jim Diamond wrote:
>>>> I've hunted around a bit, but don't see any obvious reasons for this. (I
>>>> define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
>>>> /proc/acpi/wakeup is the same in both 5.15.19 and .27.
>>>
>>> If you are willing to do the work, it might be easier to diff only
>>> between the two kernel versions where this change happened, for example
>>> between 5.15.23 and 5.15.24.
>>>
>>> The quickest way to find where the change happened is to do a binary
>>> search for that point. Now you know that 5.15.19 work as before and
>>> 5.15.27 works at after. What about the version in the middle in between?
>>> That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
>>> know if the next step is to search between 5.15.19 and 5.15.23 or between
>>> 5.15.23 and 5.15.27.

<snip>

>> I don't know how many people are reading this newsgroup these days,
>> but I am somewhat intrigued if I am the only person having this issue.
>> I had previously posted this to alt.os.linux since it is not
>> slackware-specific (it also happens to me with the artix system I was
>> using while waiting for 15.0 to appear). However, sadly that group is
>> mostly full of spam these days.

>
> I did some testing on my laptop running Slackware 15.0 with 5.15.27.
>
> Suspend to RAM
> - Awakens on opening the case
> - Does nothing on removing/attaching power

Thanks for the report. Can you tell me what sort of processor you
have? (In short, AMD or Intel? And further, the model number if you
don't mind.)

Cheers.
Jim

On 2022-04-07 at 09:40 ADT, Giovanni <lsodgf0@home.net.it> wrote:
> On 4/7/22 02:40, Jim Diamond wrote:
>
>> Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event3 (Power Button)
>> Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event1 (Power Button)
>> Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event2 (Lid Switch)
>> Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event0 (AT Translated Set 2 keyboard)
>> Mar 9 18:09:15 x360 elogind-daemon[1300]: Watching system buttons on /dev/input/event8 (HP WMI hotkeys)
>>
>> but this is the same set of devices for both .19 and .27.
>>
>> Were you thinking of some other log information?
>>
> No, that's the log which shows that the buttons are trapped by
> elogin-daemon and that led me to think of problems in elogind. But also
> this package didn't change.
>
> Kernel change-logs show modifications in the area, with several
> references to 'suspend'.
> https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.25
> https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.26
> https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.27

Giovanni,

thanks for those links. There are some suspend comments in other
changelogs as well, but the 5.15.25 does talk about a problem with the
AC adapter on another HP system.

So maybe .24 or .25 would be the place to start compiling kernels, as
Henrik suggested.

Cheers.
Jim

On 2022-04-04 at 21:17 ADT, Jim Diamond <JimDiamond@ns.sympatico.ca> wrote:
> I have a laptop running Slackware64 15.0, which, previous to upgrading
> to 5.15.27, required me to press a keyboard key after opening the lid
> to awaken it (after it was suspended to RAM).
>
> After upgrading to 5.15.27 (the dirty pipe saga of 2022), the laptop
> now awakens just by opening the lid. (I consider this to be A Good
> Thing.)
>
> However, it also awakens (with the lid still closed) if I unplug the
> AC power. (I consider this to be A Bad Thing.)

Just in case anyone cares, here is the "answer" (with thanks to Henrik
and Giovanni):

In 5.15.24 drivers/acpi/x86/s2idle.c has this code:

/*
* Some Intel based LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U don't
* use intel-hid or intel-vbtn but require the EC GPE to be enabled while
* suspended for certain wakeup devices to work, so mark it as wakeup-capable.
*
* Only enable on !AMD as enabling this universally causes problems for a number
* of AMD based systems.
*/
if (!acpi_s2idle_vendor_amd())
acpi_ec_mark_gpe_for_wake();

and in 5.15.25, notwithstanding the warning in the comment, it has
been changed to

/*
* Some LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U, require the
* EC GPE to be enabled while suspended for certain wakeup devices to
* work, so mark it as wakeup-capable.
*/
acpi_ec_mark_gpe_for_wake();

This causes the system to wake up on a variety of EC (embedded
controller) events, including opening the lid and unplugging or
plugging in the AC power. (Tested by re-compiling 5.15.25 with the
s2idle.c code from 5.15.24 and testing with that modified kernel.)

Jim

On Sat, 09 Apr 2022 17:56:08 -0300, Jim Diamond wrote:
> In 5.15.24 drivers/acpi/x86/s2idle.c has this code:
>
> /*
> * Some Intel based LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U
> don't * use intel-hid or intel-vbtn but require the EC GPE to be
> enabled while * suspended for certain wakeup devices to work, so
> mark it as wakeup-capable. *
> * Only enable on !AMD as enabling this universally causes problems
> for a number * of AMD based systems.
> */
> if (!acpi_s2idle_vendor_amd())
> acpi_ec_mark_gpe_for_wake();
>
> and in 5.15.25, notwithstanding the warning in the comment, it has been
> changed to
>
> /*
> * Some LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U, require
> the * EC GPE to be enabled while suspended for certain wakeup
> devices to * work, so mark it as wakeup-capable.
> */
> acpi_ec_mark_gpe_for_wake();
>
> This causes the system to wake up on a variety of EC (embedded
> controller) events, including opening the lid and unplugging or plugging
> in the AC power. (Tested by re-compiling 5.15.25 with the s2idle.c code
> from 5.15.24 and testing with that modified kernel.)
>
> Jim

Nice work! So who made this change and why? Some digging with git gives:

git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux
git checkout v5.15.25
cd drivers/acpi/x86/
git diff v5.15.24 s2idle.c

The above command shows that the only difference between 5.15.25 and
5.15.24 in s2idle.c are those lines that you have identified. So if you
prefer the behavior of 5.15.24 you can safely use that file as you did.

git blame s2idle.c

Shows that the change was made by Mario Limonciello who has an email
address indicating that he is working at AMD. The commit was
0044583276952 and it was made 2022-01-28.

git log s2idle.c

Gives a rather long explanation to why the AMD check was removed.

The information retreived by these git command lines could also be
retrieved by pointing and clicking in "gitk --all".

So your next step will probably be to consider wether your local fix is
good enough for now or if you want to discuss this with Mario to also get
it fixed in a better way in future releases.

regards Henrik

On 4/8/2022 5:37 PM, Jim Diamond wrote:
> On 2022-04-07 at 15:25 ADT, User <user@example.net> wrote:
>> On 4/6/2022 8:08 PM, Jim Diamond wrote:
>>> On 2022-04-05 at 02:45 ADT, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>>>> On Mon, 04 Apr 2022 21:17:57 -0300, Jim Diamond wrote:
>>>>> I've hunted around a bit, but don't see any obvious reasons for this. (I
>>>>> define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
>>>>> /proc/acpi/wakeup is the same in both 5.15.19 and .27.
>>>>
>>>> If you are willing to do the work, it might be easier to diff only
>>>> between the two kernel versions where this change happened, for example
>>>> between 5.15.23 and 5.15.24.
>>>>
>>>> The quickest way to find where the change happened is to do a binary
>>>> search for that point. Now you know that 5.15.19 work as before and
>>>> 5.15.27 works at after. What about the version in the middle in between?
>>>> That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
>>>> know if the next step is to search between 5.15.19 and 5.15.23 or between
>>>> 5.15.23 and 5.15.27.
>
> <snip>
>
>>> I don't know how many people are reading this newsgroup these days,
>>> but I am somewhat intrigued if I am the only person having this issue.
>>> I had previously posted this to alt.os.linux since it is not
>>> slackware-specific (it also happens to me with the artix system I was
>>> using while waiting for 15.0 to appear). However, sadly that group is
>>> mostly full of spam these days.
>
>>
>> I did some testing on my laptop running Slackware 15.0 with 5.15.27.
>>
>> Suspend to RAM
>> - Awakens on opening the case
>> - Does nothing on removing/attaching power
>
> Thanks for the report. Can you tell me what sort of processor you
> have? (In short, AMD or Intel? And further, the model number if you
> don't mind.)
>
> Cheers.
> Jim

Its a 10th Gen Intel

On 2022-04-10 at 07:56 ADT, User <user@example.net> wrote:
> On 4/8/2022 5:37 PM, Jim Diamond wrote:
>> On 2022-04-07 at 15:25 ADT, User <user@example.net> wrote:
>>> On 4/6/2022 8:08 PM, Jim Diamond wrote:
>>>> On 2022-04-05 at 02:45 ADT, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>>>>> On Mon, 04 Apr 2022 21:17:57 -0300, Jim Diamond wrote:
>>>>>> I've hunted around a bit, but don't see any obvious reasons for this. (I
>>>>>> define "diffing the code of 5.15.19 with 5.15.27" as "not obvious".)
>>>>>> /proc/acpi/wakeup is the same in both 5.15.19 and .27.
>>>>>
>>>>> If you are willing to do the work, it might be easier to diff only
>>>>> between the two kernel versions where this change happened, for example
>>>>> between 5.15.23 and 5.15.24.
>>>>>
>>>>> The quickest way to find where the change happened is to do a binary
>>>>> search for that point. Now you know that 5.15.19 work as before and
>>>>> 5.15.27 works at after. What about the version in the middle in between?
>>>>> That would be 5.15.23. Once you have tested with kernel 5.15.23 you will
>>>>> know if the next step is to search between 5.15.19 and 5.15.23 or between
>>>>> 5.15.23 and 5.15.27.
>>
>> <snip>
>>
>>>> I don't know how many people are reading this newsgroup these days,
>>>> but I am somewhat intrigued if I am the only person having this issue.
>>>> I had previously posted this to alt.os.linux since it is not
>>>> slackware-specific (it also happens to me with the artix system I was
>>>> using while waiting for 15.0 to appear). However, sadly that group is
>>>> mostly full of spam these days.
>>
>>>
>>> I did some testing on my laptop running Slackware 15.0 with 5.15.27.
>>>
>>> Suspend to RAM
>>> - Awakens on opening the case
>>> - Does nothing on removing/attaching power
>>
>> Thanks for the report. Can you tell me what sort of processor you
>> have? (In short, AMD or Intel? And further, the model number if you
>> don't mind.)
>>
>> Cheers.

> Its a 10th Gen Intel

Thanks. Not a surprise, now that I know it is an issue with how some
AMD systems handle AC power events.

Jim

On 2022-04-09 at 22:10 ADT, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> On Sat, 09 Apr 2022 17:56:08 -0300, Jim Diamond wrote:
>> In 5.15.24 drivers/acpi/x86/s2idle.c has this code:
>>
>> /*
>> * Some Intel based LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U
>> don't * use intel-hid or intel-vbtn but require the EC GPE to be
>> enabled while * suspended for certain wakeup devices to work, so
>> mark it as wakeup-capable. *
>> * Only enable on !AMD as enabling this universally causes problems
>> for a number * of AMD based systems.
>> */
>> if (!acpi_s2idle_vendor_amd())
>> acpi_ec_mark_gpe_for_wake();
>>
>> and in 5.15.25, notwithstanding the warning in the comment, it has been
>> changed to
>>
>> /*
>> * Some LPS0 systems, like ASUS Zenbook UX430UNR/i7-8550U, require
>> the * EC GPE to be enabled while suspended for certain wakeup
>> devices to * work, so mark it as wakeup-capable.
>> */
>> acpi_ec_mark_gpe_for_wake();
>>
>> This causes the system to wake up on a variety of EC (embedded
>> controller) events, including opening the lid and unplugging or plugging
>> in the AC power. (Tested by re-compiling 5.15.25 with the s2idle.c code
>> from 5.15.24 and testing with that modified kernel.)
>>

> Nice work! So who made this change and why? Some digging with git gives:
>
> git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> cd linux
> git checkout v5.15.25
> cd drivers/acpi/x86/
> git diff v5.15.24 s2idle.c
>
> The above command shows that the only difference between 5.15.25 and
> 5.15.24 in s2idle.c are those lines that you have identified. So if you
> prefer the behavior of 5.15.24 you can safely use that file as you did.

And it lingers on, that change is also in 5.17.2.

> git blame s2idle.c
>
> Shows that the change was made by Mario Limonciello who has an email
> address indicating that he is working at AMD. The commit was
> 0044583276952 and it was made 2022-01-28.

> git log s2idle.c
>
> Gives a rather long explanation to why the AMD check was removed.

And for people who aren't git-compliant, the ChangeLog Giovanni
mentioned (https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.25)
can be perused.

> The information retreived by these git command lines could also be
> retrieved by pointing and clicking in "gitk --all".

> So your next step will probably be to consider wether your local fix is
> good enough for now or if you want to discuss this with Mario to also get
> it fixed in a better way in future releases.

It is good enough for me, and I was considering whether I should file
a kernel bug report or not. It is sort of surprising that I seem to
be the only one looking for answers about this. Surely there are many
other Linux users using laptops identical or similar to mine. Maybe
they are all OK with AC events waking up their laptop.

But since Mario has an AMD address as you note, I might try him first.

Cheers.
Jim