this post was submitted on 02 Jun 2024

79 points (96.5% liked)

Steam Deck

14797 readers

51 users here now

A place to discuss and support all things Steam Deck.

Replacement for r/steamdeck_linux.

As Lemmy doesn't have flairs yet, you can use these prefixes to indicate what type of post you have made, eg:
[Flair] My post title

The following is a list of suggested flairs:
[Discussion] - General discussion.
[Help] - A request for help or support.
[News] - News about the deck.
[PSA] - Sharing important information.
[Game] - News / info about a game on the deck.
[Update] - An update to a previous post.
[Meta] - Discussion about this community.

Some more Steam Deck specific flairs:
[Boot Screen] - Custom boot screens/videos.
[Selling] - If you are selling your deck.

These are not enforced, but they are encouraged.

Rules:

Follow the rules of Sopuli
Posts must be related to the Steam Deck in an obvious way.
No piracy, there are other communities for that.
Discussion of emulators are allowed, but no discussion on how to illegally acquire ROMs.
This is a place of civil discussion, no trolling.
Have fun.

Link to our Matrix Space

founded 3 years ago

MODERATORS

[email protected]

Is it normal that my OLED discharges 20% per day in standby? (lemm.ee)

submitted 5 months ago by [email protected] to c/[email protected]

16 comments fedilink hide all child comments

Title. It seems excessive. Even when I fully power it down it tends to drop a lot more than I'd expect.

Thanks.

all 17 comments

sorted by: hot top controversial new old

[–] [email protected] 38 points 5 months ago* (last edited 5 months ago) (1 children)

The OLED model has a special Bluetooth module that can wake the system from standby. This causes excessive power drain. You can try disabling Bluetooth if you're not using any Bluetooth accessories.

[–] [email protected] 18 points 5 months ago

Bluetooth is disabled, as is the Wi-Fi antenna. Which I always do with any devices I turn things off that I don't need.

[–] [email protected] 17 points 5 months ago (1 children)

It's the stanby/quick restart that's doing it. It's literally staying on. Best to use the power/shut down option in the menu vs just hitting the power button. Same was happening to me before I figured it out.

[+] [email protected] -7 points 5 months ago (2 children)

Thanks for that. I've been thinking of it as a sleep/hibernate function but obviously it's not. Linux still hasn't seemed to figure that one out for some reason. Not Steam's fault.

[–] [email protected] 31 points 5 months ago (2 children)

Linux has a hibernate function, but the power button activates Sleep, which is higher-consumption. There may be a way to set it to actually hibernate on button press, but I've only seen Hibernation via Desktop Mode.

Sleep = keep processes in memory = more power consumption.

Hibernation = write most processes to disk and keep only vital system processes in memory = less power consumption.

[–] [email protected] 14 points 5 months ago (1 children)

At some point SteamOS has major issues crashing when waking up from hibernation, which is probably why it hasn't been added as an option. Which is annoying, because if you run out of battery, the deck just dies. At the very least, it should force-hibernate itself before dying.

[–] [email protected] -2 points 5 months ago (3 children)

This kinda describes where Linux has been at with sleep/hibernation for quite a few years. I don't understand the deeper implications but it's never seemed like a priority for Linux devs, vs how Windows and Mac have solved it long ago. Maybe because Linux hasn't traditionally focused on portable devices but arm (etc) seems to be changing that.

[–] [email protected] 17 points 5 months ago* (last edited 5 months ago)

Windows hibernation is about as broken as linux hibernation, i.e. they both mostly work most of the time, but there is good reason both hide them away by default (if you can really say linux hides anything, with these things being decided by distros and not kernel devs). It is naive to say windows has “solved” hibernation. Either you don’t use it much or have very basic hardware and software needs.

Edit: as a side note, neither iOS nor android devices use anything similar to hibernate, so I am a bit lost with what you mean by arm causing hibernation implementation pressure.

[–] [email protected] 5 points 5 months ago

idk, for me hibernation has mostly worked fine so long as i don't hibernate with a game running, which seems to be more of a GPU issue than hibernate itself.

[–] [email protected] 2 points 5 months ago

That's because system firmware is designed and tested on Windows, so the supply of new and exciting hardware bugs that need workarounds is endless.

[–] [email protected] -1 points 5 months ago

This is good intel actually. I used HoloISO for a long time on my gaming rig but I never thought to mess around with those settings because I've always just thought of Linux battery use as ass (have run various distros on tons of different laptops as well). Would be good to take the deck deeper hibernation settings for a spin, but it would be kinda a shame if the deck devs haven't already explored these things in ways I'll never understand as a lay user, frankly. You'd think they'd be tweaking this stuff mercilessly for the UX and battery life.

[–] [email protected] 5 points 5 months ago

Try putting a laptop running Windows to sleep for a week and see if it has any battery left.

[–] [email protected] 14 points 5 months ago (1 children)

In stand by you figure that the volatile memory needs to be kept powered so I'm kinda not surprised when the nature of the battery discharging when "shutdown" is a thing.

[–] [email protected] 9 points 5 months ago (1 children)

Thanks yeah I figured. I'm not being very scientific about it yet but for instance none of my laptops discharge that much if I shut the lid and walk away for a couple days, but then again they're bigger cells.

[–] [email protected] 14 points 5 months ago

I think they eventually write to disk and hibernate after a while but I might be wrong.