Unlock not working on reMarkable 2 #161
Comments
|
Same thing happens to me. It looks to me that going back from suspend the |
|
@solanav You are missing information required in the bug template that I need in order to properly triage this:
@danielebruneo or @solanav could you please also attach logs from the device for when this happens |
|
I will, as soon as I can. |
What version are you using? |
|
Device: RM2
Specifically interesting maybe the "Unable to find current application" part. Also, the ID shown in the "Resuming application" belongs to decay: |
Ah, so #142 fixes this in v2.1.1 onward. Could you give v2.1.2 a try? |
|
@Eeems I do not have the toolchain setup yet. |
You can get the latest packages from the release page: https://github.com/Eeems/oxide/releases |
Thank @Eeems I didn't noticed that. I get Despite the version in the control file is |
|
Make sure to install all the packages at the same time, otherwise dependency checks will fail. |
That worked, thanks.
log for tarnish, this time shows: |
Hmm, perhaps this is a timing issue? Looks like you've encountered #152 which until now nobody but @LinusCDE has replicated that I'm aware of. |
Behavior is quite different from #152. I'll try to make a video if I can. Also... it seems I can get it working smoothly if I disable the decay conf file with: |
Sounds like the only difference is the inverted colours, but other than that it's the same.
Actually, decay should probably hand off to oxide if no pin is set.
While that works, upgrades will undo that. The other option is to set your lockscreenApplication to oxide. |
Used to get this as well. Not sure if it was with pin/no pin on stable/pr. I think this is due to the sleep starting right in a refresh of rm2fb. @raisjn does the shim also (more or less) properly implement the waiting on a "refresh token" to await a refresh1? If yes, then waiting for this would be the solution. |
|
Sorry for the delay. The first time I lock it after rebooting it works perfect. And then it doesn't. Journalctl after refreshing: Doing |
That doesn't actually fix it. You are now running xochitl directly instead of running oxide.
Interesting, I can replicate this. I swear I tested this use case, but I guess I didn't. By the looks of it the lock screen is either crashing or not running properly if no pin is set, and thus it's not properly handing off to the launcher. |
|
By the way, setting oxide as lockscreenApplication often drives to non usable oxide coming back from sleep (i.e can't click on icons) and non working previousApplication gesture. Also, a part from that... there apparently is also that "timing issue" that drives to the sleep screen randomly being half-rendered (inveretd colors, or partially showing what was running, etc). |
Pardon?
Could you open an issue about this? Nobody else has reported that it doesn't work yet.
Yes, this is known already. It's only an issue on the rM2, as it's specific to the rm2fb dependency. |
*decay not decoy :) I meant deleting or renaming the
This could maybe related to the main issue. |
To answer my own questions. rm2fb seems to just stub the functionality. Tested with retris. While it actually waits on the rM 1, on the rM 2 the time is unrealistically tiny. rM 1 (DU/FastMono refreshes): rM 2 (DU/FastMono refreshes): @Eeems do you use this feature on the rM 1 to wait for the E-Ink to finish before actually suspend the device? If yes, this could explain the "inverted sleep screen" on the rM 2 as that would have a race condition to start suspending mid refresh. |
|
https://github.com/Eeems/oxide/blob/master/applications/system-service/screenapi.h#L99-L100 |
Then this would be an issue of rm2fb and not oxide. Maybe open an issue for that. |
|
Hmm, I thought there already was an issue opened I guess not. |
|
currently, rm2fb has only one way communication from clients -> server, there is no method for server to communicate back to client. the proper way to fix this would be to create duplex communication between clients and server and then add a way of notifying clients of their subscribed events (in this case - the update complete event). until its properly fixed, adding a short delay after painting the screen before going to sleep (1 second) will mostly help with the screen not fully updating before the tablet suspends. if that workaround is already in place, then rm2fb will need to be debugged to see why 1 second isn't enough to repaint the screen |
|
Hey, just to confirm, I finally got around to installing 2.1.2 and I'm also experiencing this issue (or #152, I think they're duplicates) on my rM2. Sounds like the issue is already identified, but happy to provide logs/testing if needed. |
|
Yeah, this happened to me too, a couple of days ago. Not being a Linux hacker, I managed to find instructions to swap the launcher back from tarnish to xochitl. Decided to wait until the problem is confirmed as resolved. |
|
With a pin it was working form me also before: #161 (comment) |
|
Here's the log file with the crash in it. From discord: I should note I'm using the physical power button to cycle wake -> sleep -> wake etc. |
|
I found a workaround to this. If you don't want to set a pin and face the unlock problem, you can rename |
That seems to work for me as well. Funnily enough this would be a viable workaround for basically having "No pin" and also the sleep screen working. It works for both having a pin set and having no pin set. |
|
That's not really a great workaround. I would really recommend to just have a simple script that calls |
|
Can anybody confirm that this is still an issue on the latest version? |
|
Yes. If I choose to not set up a pin, the second unlock in an app results in the suspend screen just "flashing" every second time. It works fine with an pin though. Maybe there is a change of the framebuffer missing. Or some timing issue with rm2fb which prevents/discord changes right after an unlock. EDIT: Tested on 2.2.1-2 (testing from toltec which is also the latest release here) |
|
Likely it's just the logic in decay is borked still. Not sure why it works fine for me on my rM1 though. |
|
Maybe look for the differing logic between displaying the decay interface vs restoring the last framebuffer. Either there is some logic error. But if the code differs next to nothing, I would guess a timing issue. Maybe restoring the last framebuffer is a lot faster in comparision and rm2fb fails to properly bridge the fake framebuffer that faster after resuming. Would be weird though as no other app has ever encountered that. |
|
The restore logic works fine as it's handled by tarnish and not by the lockscreen. It's likely just failing to switch back to the previous application properly. Which is the issue it had in the past. Unless you are telling me that you're able to interact with the previous application even though it's not being displayed properly? In which case I'm not sure how restoring the framebuffer ever works when switching applications. I'm explicitly waiting for the draw to finish before resuming the application. |
This seems to be the case indeed. I couldn't trigger any log messages from the last running application (only tarnish noting UP/DOWN/MOVE and swipe messages). |
Describe the bug
After installating oxide on my Remarkable 2, the unlock button locks correctly (showing the lock screen), but when unlocking the screen stays white.
I've tried both with and without pin and the result is the same.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It should be showing the pin input or the screen.
The text was updated successfully, but these errors were encountered: