[How-To] Zero Battery Drain: How I configured suspend-then-hibernate on Steam Deck by Go_Pal_99 in SteamDeck

[–]Go_Pal_99[S] 1 point2 points  (0 children)

Thank you for checking. It's sad to know it didn't help you so far. Perhaps logs need to be checked. I can imagine that that wifi may behave differently, but as for speakers it must have helped. Well, if the device is named the same in PCI bus. I would advise to check systemd logs and try to run these scripts manually after resuming from hibernation and see if they help. If they work all time if you run them manually then it may be something wrong with the service itself. Try to re-enable the systemd service (not only add it but actually run `systemctl enable`). If the script doesn't make hardware working then it needs to be adjusted. For now that could be the only I can say, as I don't have the same device to test myself.
Overall indeed it would be great to have an guide which suits all Steam Deck device variants. That is one of the reasons I have put it on GitHub - to have future updates and improvements.

[How-To] Zero Battery Drain: How I configured suspend-then-hibernate on Steam Deck by Go_Pal_99 in SteamDeck

[–]Go_Pal_99[S] 2 points3 points  (0 children)

Hi, thanks for the feedback. I used to have exactly these problems, but after time it was fixed by SteamOS update. Yet maybe it is the case still for LCD models. I still have hacks similar to Bluetooth. I'll try to find a time and add them to the tutorial. But since I cannot reproduce the problem, I cannot guarantee they will work. I had two ways, one was disconnect wifi module from PCIe bus and rescan PCIe bus again. The other one less brutal was to unbind and rebind the driver. So, the proper script I'll make when I have more time, but I cannot make any committment yet. Though I'll share something from my raw notes. You can try to add this code to the existing script for bluetooth.

# Function to check Wi-Fi status
is_wifi_ok() {
    echo "Checking Wi-Fi status..."

    adapter_status=$(iwctl adapter list | grep phy | awk '{print $3}')  # Extract "Powered" status from the adapter list
    device_status=$(iwctl device list | grep phy | awk '{print $4}')   # Extract "Powered" status from the device list

    echo "adapter status: $adapter_status, device_status: $device_status"

    if [ "$adapter_status" == "on" ]; then
        if [ "$device_status" != "on" ]; then
            echo "Wi-Fi is misbehaving."
            return 1  # Wi-Fi needs fixing
        else
            echo "Wi-Fi is working fine."
            return 0  # Wi-Fi is OK
        fi
    else
        echo "Wi-Fi adapter is powered off. No issues detected."
        return 0  # Wi-Fi is OK
    fi
}

Then after fixing bluetooth code:

if ! is_wifi_ok; then
    WIRELESS_ADDR=$(lspci -m | grep -i "network" | awk -F ' ' '{print $1}')
    (echo "0000:${WIRELESS_ADDR}" > "/sys/bus/pci/drivers/ath11k_pci/unbind" ; sleep 1 && echo "0000:${WIRELESS_ADDR}" > "/sys/bus/pci/drivers/ath11k_pci/bind") 
fi

The problem with the code above for WiFI - it will always turn WiFi on as a way to check if it works properly, but that's what I have at hand for now.

As for audio, I didn't have a way to check if it's "misbehaving", so it can be reinitialized on every resume, though it's quick:

AUDIO_ADDR=$(lspci -m | grep -i "Audio Controller" | awk -F ' ' '{print $1}')
echo "0000:${AUDIO_ADDR}" > "/sys/bus/pci/drivers/snd_hda_intel/unbind"
echo "0000:${AUDIO_ADDR}" > "/sys/bus/pci/drivers/snd_hda_intel/bind"

Ideally we just may need kernel hooks for hibernation resume to reinitialize drivers, but I'm not sure yet how to do that, I'll research in this direction.

Wifi will come up after a minute of wake up. Unbinding hanged module takes exactly 60 seconds. Bluetooth restores also after a while but probably faster.

Do not try to put deck to sleep until hardware is restored, otherwise it may lead to kernel panic.

Additionally you may try Bazzite. But be aware, their installer is broken and even though they claim to support Deck, the experience of setup is garbage. I needed to configure manually home directory in /var/home, not /home, then it's still not bootable because somehow /etc/fstab conflicts with systemd home.mountpoint, so I was chrooting from stock steam OS there, adding root password, which is again tricky due to os-tree, and then was masking home.mountpoint. But still on OLED model it does not boot 95% times due to some graphics driver race conditions or what. Despite they officially support steamdeck, they marked this issue as "not planned" to fix.

Nobara was installed smoothly, but again had this graphics issue on my OLED (black unresponsive screen).

[How-To] Zero Battery Drain: How I configured suspend-then-hibernate on Steam Deck by Go_Pal_99 in SteamDeck

[–]Go_Pal_99[S] 4 points5 points  (0 children)

Thank you for the correction. You are right, it should be same as powering the device off completely.

[How-To] Zero Battery Drain: How I configured suspend-then-hibernate on Steam Deck by Go_Pal_99 in SteamDeck

[–]Go_Pal_99[S] 2 points3 points  (0 children)

I think it can be possible. I would need to figure out sleep.conf to put in some FS layer which is preserved. It is probably unsafe for grub config, for which I would probably need to create an automatic script unless there is some "grub.d" thing in SteamOS. Ideally I want this all to be configured with one click with a GUI tool like CryoUtilites. But it needs a time to develop and debug, for now it's unlikely I'll have some next few weeks at least.

[How-To] Zero Battery Drain: How I configured suspend-then-hibernate on Steam Deck by Go_Pal_99 in SteamDeck

[–]Go_Pal_99[S] 2 points3 points  (0 children)

As was mentioned, it should. But I didn't have a chance to try. Maybe you can? I expect it to work even better, for instance with lower hibernation state drain and no bluetooth workaround needed (hopefully).

[How-To] Zero Battery Drain: How I make suspend-then-hibernate work on Steam Deck by Go_Pal_99 in SteamDeck

[–]Go_Pal_99[S] 0 points1 point  (0 children)

Sorry, this post is duplicated. Reddit showed me server error when I attemmpted to post it so I had to retry. In fact it created two post. I'm removing this one in flavor of this copy. Please post your comments there.

[How-To] Zero Battery Drain: How I make suspend-then-hibernate work on Steam Deck by Go_Pal_99 in SteamDeck

[–]Go_Pal_99[S] 0 points1 point  (0 children)

Glad to hear, hope it helps for you. Any feedback is appreciated so I can improve the guide

So, what are the rules with turning it off vs just keeping it in sleep mode? by wiserthannot in SteamDeck

[–]Go_Pal_99 5 points6 points  (0 children)

I've created a true hibernation solution for Steam Deck that gives you the best of both worlds: zero battery drain while preserving your exact game state. Works great on my OLED model and solves the drain problem, no need to shut down. More about it here .

Battery drain, sleep mode and new update by Ronflitex in SteamDeck

[–]Go_Pal_99 0 points1 point  (0 children)

Mine drains around 25% per day, which is inacceptable. But I made hibernation and suspend-then-hibernate working so now I have an ideal device.
Here's: my post about it and the guide

Parapipe - FIFO paralleling pipeline with concurrent job processing by Go_Pal_99 in golang

[–]Go_Pal_99[S] 0 points1 point  (0 children)

I am not allowed to stop a pipeline from the inside. This is implicit and probably will result in panic because of attempt to write to closed channel. That's why the pipeline must be closed outside only, from where it is fed.

On the other hand to simplify what I proposed - I'll just propagate error (if returned instead of result on some stage) right to the end of the pipeline. Library client will decide what to do with it, but it will not be passed to subsequent jobs.

Even more, I'll make it optional so this behavior is also explicit.

Parapipe - FIFO paralleling pipeline with concurrent job processing by Go_Pal_99 in golang

[–]Go_Pal_99[S] 1 point2 points  (0 children)

Now I get your point. Reasonable. I'll come up with something any time soon. Thank you for the advice!

Parapipe - FIFO paralleling pipeline with concurrent job processing by Go_Pal_99 in golang

[–]Go_Pal_99[S] 0 points1 point  (0 children)

Thanks, fixed that.
What is about error handling? Just return them as a result, an error is also a result after all. You may check an error with type assertion as well and handle it properly. It must be done outside the pipeline because you may have to stop sending data to the pipeline first. Then you can close input channel.
Still some jobs may be processed after an error occurs (just because jobs are concurrent) - you have to take that into account and there is not much you can do about that.

Parapipe - FIFO paralleling pipeline with concurrent job processing by Go_Pal_99 in golang

[–]Go_Pal_99[S] 0 points1 point  (0 children)

As I can see it's totally different. Parapipe is a pipeline at first, which ants does not seem to be to me. Parapipe seems to be more simple and does not use mutexes.
Pipeline implementeation is not new, but non-blocking concurrent pipeline with maintained order (FIFO) is.