[BUG] Video not updating after awaking from screen lock

[Aetf]

Describe the bug
When streaming with Chiaki-ng from my PS5, I left the system for a while and the system entered lock screen (as configured by the KDE desktop).

After unlocking and reentering the system, chiaki-ng stopped updating video frames. The screen was frozen at the last frame. The game is still controllable and from the audio I can hear that my operations still worked, just the frame wasn't updated.

Debug Log

chiaki_session_2024-09-04_23-02-50-873873.log

To Reproduce
Steps to reproduce the behavior:

1. Start streaming
2. Lock screen
3. Unlock screen
4. See error

Expected behavior
Streaming continues to work as normal after unlocking. And chiaki-ng should inhibit sleep/locking while streaming.

Desktop (please complete the following information):

• OS: Archlinux + KDE Wayland
• Version: Linux Aetf-Arch-XPS 6.9.7-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Fri, 28 Jun 2024 04:32:27 +0000 x86_64 GNU/Linux
• KDE Version 6.1
• Device: desktop PC
• chiaki-ng Version: 1.8.1

Additional context

chiaki-ng can only be SIGKILLed after the error.

[Aetf]

I should add that the screen locked even when I'm actively playing. Seems like the controller input isn't considered by KDE as active use. This makes it more important for chiaki-ng to inhibit sleep...

[streetpea]

@Aetf it should already inhibit sleep. See the code here and here… I’ve tested this works on SteamOS using the flatpak build of chiaki-ng. Have you tried the flatpak build to see if this works there?

Also have you tried using ctrl+q after waking up from the Lock Screen to quit Chiaki-ng?

[Aetf]

Interesting. I used the locally compiled version built from a clean chroot (from AUR). From the code, system inhibition is guarded by CHIAKI_HAVE_DBUS. Maybe it's caused by the dbus dependency missing during compilation. Let me play with the PKGBUILD for a bit.

As for ctrl+q, it doesn't work. The mouse did pop out (which was hidden automatically when starting streaming), but the confirmation dialog (when configured to ask) didn't show up. And it's the same when configured to do nothing on disconnect: mouse popped out, can't click anything.

[streetpea]

@Aetf one way to check is download the flatpak from flathub for testing purposes. See if it works on your system. If it does, then you know something is going on with the arch build. If it doesn't then there is something on your system making it not work there while it works on steam deck.

[Aetf]

Just tried the flatpak version. It also doesn't inhibit sleep.

[streetpea]

Can you post the logs running from konsole?

[Aetf]

https://gist.github.com/Aetf/d5c840919501954110aeec3482ee30c3

[streetpea]

@Aetf the log you linked seems fine. Can you post the logs from the konsole if you launch via the konsole?

[Aetf]

running flatpak version from konsole and tried lock screen while streaming. This time it actually works.
So the graphics freezing issue might be due to different dependency version used for compiling.

However I think the sleep inhibit still isn't quite right.

konsole log: https://gist.github.com/Aetf/646a9d5833167f686dae6eaf50b216a3

Using dbus-monitor to see dbus message exchanges, and indeed chiaki is calling the inhibit API

method call time=1725584174.295683 sender=:1.1001 -> destination=org.freedesktop.login1 serial=7 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=Inhibit
   string "sleep"
   string "Chiaki"
   string "Remote Play session"
   string "delay"
signal time=1725584174.306961 sender=:1.6 -> destination=(null destination) serial=4278 path=/org/freedesktop/login1; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.freedesktop.login1.Manager"
   array [
      dict entry(
         string "DelayInhibited"
         variant             string "sleep"
      )
   ]
   array [
   ]
method call time=1725584183.035312 sender=:1.1002 -> destination=org.freedesktop.login1 serial=2 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=ListInhibitors

systemd-inhibit shows that it is registered.

❯ systemd-inhibit
WHO                    UID  USER PID    COMM            WHAT                                                                       WHY                                                       >
NetworkManager         0    root 2196   NetworkManager  sleep                                                                      NetworkManager needs to turn off networks                 >
UPower                 0    root 3119   upowerd         sleep                                                                      Pause device polling                                      >
net.reactivated.Fprint 0    root 646445 fprintd         sleep                                                                      Suspend fingerprint readers                               >
Chiaki                 1000 aetf 646649 xdg-dbus-proxy  sleep                                                                      Remote Play session                                       >
PowerDevil             1000 aetf 191552 org_kde_powerde handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch KDE handles power events                                  >
Screen Locker          1000 aetf 2595   kwin_wayland    sleep                                                                      Ensuring that the screen gets locked before going to sleep>

6 inhibitors listed.

However, it is not shown in the KDE PowerDevil plasmoid:

For comparison, this is what it should look like, when I manually inhibit sleep (note the mode I used is block rather than delay in code):

> systemd-inhibit --who="test" --what="sleep" --mode="block" --why="test" sleep infinity

[streetpea]

@Aetf please copy and paste the output from the konsole not the log file. You can save it as a file if you want. The thing is you can’t see sleep inhibited bc each connection is a separate session. You will only see it if you use the log from the konsole/terminal when launched via the konsole/terminal. That will be the full Chiaki log not just the stream session log.

[Aetf]

I'm not sure I follow what you mean. I'm copy pasting the output from the terminal. That is the full output I pasted.

The thing is you can’t see sleep inhibited bc each connection is a separate session.

Not sure what you mean by each connection... I'm on running chiaki on a desktop Linux PC. There is no SteamDeck involved, if that was not clear before.

Anyway, here's the terminal output after I enabled log_verbose=true in config: https://gist.github.com/Aetf/3074ab4981598f566bd5e84eac66bc79

Reading the doc about inhibition, I now believe that block mode is more appropriate since the default timeout for delay is 5s (source). Also, the inhibition should be for both sleep and idle, because the system can still lock the screen if only sleep is inhibited.

[streetpea]

@Aetf in that case your system is not going to sleep or you are not picking up the signal. you would see 2 separate sessions in the logs (the session is quit before sleeping and a new session is created after sleeping) and there would be logs saying About to sleep as well as resumed from sleep. The expected behavior when sleeping is for the session to quit (and optionally put your console to sleep). Then, when you are ready to pick up play, a new session is started so you can resume your play session. This allows users to sleep their device and resume seamlessly to conserve power of their device. By inhibiting sleep until we close the connection we are able to close the session and resume it appropriately.

[streetpea]

@Aetf I reread your comments and I believe I originally misunderstood what you were asking for. Currently chiaki-ng just impedes sleep so that it can close down and then restart once sleep ends. Many users want to sleep. They just want the session to pick up after sleep. This is the functionality in chiaki-ng. As for the Lock Screen I don’t believe that needs to be impeded. Shouldn’t the app just continue running even with the Lock Screen up. At least that’s what I’ve observed running chiaki-ng on Manjaro natively as well as with the flatpak with hw decoder set to none on SteamOS (both arch based) using the screen locking feature of kde … tested with kde 5.27.5 on SteamOS and kde 6.0.5 on Manjaro Linux

[streetpea]

@Aetf just a heads up btw you should install pipewire-pulse as opposed to pulse audio to get working haptics with the dualsense if you want that.

[Aetf]

I care about lock screen because even when I'm actively playing, the lock screen shows up and interrupts the session. I have to manually move the mouse every once a while to reset the timer. I can manually enable the keep awake function before playing, but that's just annoying.

As for pipewire-pulse, I have long migrated to pipewire and have pipewire-pulse installed. Not sure why that warning is still there. I do have working haptics with the dualsense though.

[streetpea]

@Aetf when I tested on Manjaro as well as SteamOS (both based from Arch Linux) the lock screen does not prevent chiaki-ng from continuing to play. Do you have a setting set that causes programs to suspend when the lock screen is activated?

[streetpea]

@Aetf have you tried adding the game to steam as a non steam game using the button in the ui and launching via Steam? According to Reddit, running via Steam prevents auto-locking if you have controller input for arch.

[Aetf]

Hmm, how could a lock screen not prevent chiaki-ng from playing? When it shows up, the full desktop is covered by the lock screen, and I need to unlock it to see my desktop, including chiaki-ng.

Here are my lock screen settings

running via Steam prevents auto-locking if you have controller input for arch.

I haven't tried that. Let me see if it works.

[streetpea]

@Aetf no image is displayed but the app continues running until I open the Lock Screen and then am able to resume playing.

[streetpea]

@Aetf did launching via steam fix your problem with gamepad input not preventing the KDE lock screen from appearing?

[Aetf]

Sorry for the late reply. Yeah launching via steam indeed fixes the problem.

[streetpea]

@Aetf is it ok if I close this then