Suspend via button pressing and third-party apps on RM2 problems

[Witos]

Describe the bug
There as some issue related to suspend mode.

Issue no 1
** To Reproduce **

1. Open KORader / Xochitl
2. Wait for suspend.
3. Press Power button
4. KOReader / Xochitl is in the suspend mode
5. It's hard to wake it up, since pressing button causes suspend from oxide
6. Pressing power button multiple times sometimes help

Issue no 2
To Reproduce

1. Press Power button
2. Press Power button again
3. The device is not resumed.

Expected behavior
This has about 30% reproduction rate.
The device should be resumed
Screenshots
If applicable, add screenshots to help explain your problem.

Version Information:

• Device: RM2
• OS: 2.5
• Version 2.1.x

Additional context
Add any other context about the problem here.

[Eeems]

Could this be #97?

[Eeems]

@Witos Can you confirm that issue 2 is resolved in the v2.1 release?

[Witos]

@Eeems , no change - it didn't help.

[Eeems]

That's very odd. So it's not the same problem I was having with slow resume on the rM1, as that would eventually wake up and was due to wifi pinging blocking the main thread.

[ships]

@Eeems , when 2.1 arrives in Stable i will update and grab some system logs.

[Eeems]

Should be the next merge window, so next week.

[sternj]

If this is the same issue I'm having, systmecl restart tarnish also is a stopgap resolution

[Eeems]

This was reported before the lockscreen was added I believe.

[sternj]

Is this a lockscreen issue? I'm not running into it on system restart, just on button press after suspend

[Eeems]

Is this a lockscreen issue? I'm not running into it on system restart, just on button press after suspend

No, this seems unrelated from initial information.

[sternj]

Should I create a new issue with what I'm observing and put the logs there? I'm on testing right now so I have 2.1

[Eeems]

Should I create a new issue with what I'm observing and put the logs there? I'm on testing right now so I have 2.1

Is what you are seeing different than #142?

[ships]

I am getting much surprising behavior around sleep and restart, such as splash screens largely not appearing ever since transitioning to oxide as main launcher, and poweroff resetting Oxide's sleep configuration. Been assuming it is all part of this issue.

[sternj]

Yes-- rather than just not being able to interact with the screen, no icons appear

[Eeems]

Yes-- rather than just not being able to interact with the screen, no icons appear

And you have a pin set on the lockscreen?

I am getting much surprising behavior around sleep and restart, such as splash screens largely not appearing ever since transitioning to oxide as main launcher, and poweroff resetting Oxide's sleep configuration. Been assuming it is all part of this issue.

On v2.1?

[sternj]

No pin set on the lockscreen-- apologies for burying the lede a bit there, I just know there were previous issues with pinless things, hence why I asked

[Eeems]

No pin set on the lockscreen-- apologies for burying the lede a bit there, I just know there were previous issues with pinless things, hence why I asked

So that would be #142, which is documented in the release notes with the recommended work around (Set a pin).

[jdkruzr]

I have these same issues. There are also sometimes visual artifacts in the form of parts of the screen persisting when the device sleeps while Xochitl is running. If I press the power button to sleep the device while Xochitl is foregrounded, it sleeps, but will then not wake back up without me holding power to shut it off and then powering it back on.

[Eeems]

I have these same issues. There are also sometimes visual artifacts in the form of parts of the screen persisting when the device sleeps while Xochitl is running. If I press the power button to sleep the device while Xochitl is foregrounded, it sleeps, but will then not wake back up without me holding power to shut it off and then powering it back on.

What version of Oxide?

[jdkruzr]

it was the latest one from the release page -- I don't know how to get the version number; will e.g. "oxide --version" do that?

[Eeems]

Unfortunately no. The only way to get the version information is to use a toltec package and check opkg list-installed. Or to know what it was that you installed.

[jdkruzr]

ok, I see you just built 2.1.2 a few days ago -- I am 90% sure I had 2.1.1 installed. (am currently in the process of getting rid of all the 2.1.1 related files so I can install 2.1.2 via opkg to see if things are fixed)

[jdkruzr]

Same issues, specifically that when you come back from sleep, if it has been at least a few seconds, the screen stays on "reMarkable is sleeping." If you hit the power button again it does the black/white flash screen refresh to go back to sleeping mode, so something is happening when you try to "wake" it. It does not appear to turn its wifi back on when you "faux wake" it like this, though. I know this mostly because I cannot connect back to ssh.

Additionally I'm having a problem where ssh is unresponsive unless I tap the screen, when it starts responding again with whatever tried to last get it to do, but it is immediately unresponsive again unless I tap the screen again.

[Eeems]

Additionally I'm having a problem where ssh is unresponsive unless I tap the screen, when it starts responding again with whatever tried to last get it to do, but it is immediately unresponsive again unless I tap the screen again.

SSH over wifi or USB?

Same issues, specifically that when you come back from sleep, if it has been at least a few seconds, the screen stays on "reMarkable is sleeping." If you hit the power button again it does the black/white flash screen refresh to go back to sleeping mode, so something is happening when you try to "wake" it. It does not appear to turn its wifi back on when you "faux wake" it like this, though. I know this mostly because I cannot connect back to ssh.

:( I can't replicate this on my device, so I'm not really sure what is happening. I'll try doing a reinstall again later to see if I can replicate it. Otherwise I'll need some help from someone who can replicate and debug it. Perhaps @Witos?

[ships]

I have gotten this behavior once since upgrading to 2.1 (more identifiable with @jdkruzr 's comments than the OP). If it comes up again i'll grab system logs.

[jdkruzr]

I have gotten this behavior once since upgrading to 2.1 (more identifiable with @jdkruzr 's comments than the OP). If it comes up again i'll grab system logs.

which system logs would be useful, do you think? I'd like to give it a shot after the next revision (am using remux for now).

@Eeems this was over WiFi.

[Eeems]

which system logs would be useful, do you think? I'd like to give it a shot after the next revision (am using remux for now).

journalctl -u tarnish

[Witos]

Ad. Issue no. 1

I had suspend option turned off via koreader settings. I discovered that it was triggered anyway - I don't know whether I used the setting wrong or there is a bug in koreader. Regardless - turning autosuspend plugin via koreader's "Plugin management" menu solved the problem.

[Eeems]

Time to open an issue with KOReader?

[primalmotion]

I had the same problem, only with KOReader it seems. I fixed the issue by remapping the button like so:

cat /opt/koreader/settings/event_map.lua
return {
    [116] = "noop",
 }

[regfi]

I had the same problem, only with KOReader it seems. I fixed the issue by remapping the button like so:

cat /opt/koreader/settings/event_map.lua
return {
    [116] = "noop",
 }

It works for me, the problem confused me a lot. By the way, for KOReader version 2021.07, the "event_map.lua" located at "/opt/koreader/frontend/device/remarkable/event_map.lua"

[not-a-doctor-stromberg]

I love you all, having a work around for this is (no exaggeration) the best thing that's ever happened to anyone i'll stand by it. thank you!

[qubist]

I had suspend option turned off via koreader settings. I discovered that it was triggered anyway - I don't know whether I used the setting wrong or there is a bug in koreader. Regardless - turning autosuspend plugin via koreader's "Plugin management" menu solved the problem.

Time to open an issue with KOReader?

Just found this thread. But I think I opened this issue a few days ago! koreader/koreader#8891

@Witos could you please elaborate on how you fixed this issue in KOReader with plugins?

Edit: answered my own question. From the top menu, tap the wrench and screwdriver icon. From page 2, tap "More tools", then "Plugin management". Then un-check "Auto suspend". Navigate back to the main menu. Click the hamburger icon in the top menu, tap "Exit" then tap "Exit". Re-open KOReader and this setting should be applied. Unfortunately this didn't resolve the issue for me. (I'm going to try the eventmap way now.)

[qubist]

Could this be related to this code in KOReader?
https://github.com/koreader/koreader/blob/3e78847c46d54e497fc3b1fce0febd96d0d2f65c/frontend/device/remarkable/device.lua#L185-L195

I notice the resume() function is empty..

Also some other devices have an intoScreensaver() function and an outOfScreensaver() function.

[Eeems]

Part of it is because Oxide handles its own automatic suspend, as well as suspending when the power button is pressed. It doesn't make sense to have applications that Oxide is running to also handle power, which is where the issue is. That said the main issue here is that the power button is not supposed to pass events to other applications. This works on the rM1, but on the rM2 the driver for the button is still passing events even though the interface is grabbed.

[qubist]

Thanks for the explanation! Sounds like an issue that can be fixed within Oxide, as well as on KOReader's side (which I've started: koreader/koreader#8900)

[Eeems]

It's actually not an issue that can be fixed within Oxide that I'm aware of. It's a bug with the evdev device handling input on the rM2.

[Witos]

Yes, in case of rm2 applications that are handling the power button by itself (oxide, koreader, xochitl and other) are conflicting.

[Eeems]

The compositor handles this with input handling now.