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

Thanks.

  • Kit@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    39
    arrow-down
    1
    ·
    edit-2
    7 months ago

    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.

    • TerkErJerbs@lemm.eeOP
      link
      fedilink
      arrow-up
      18
      ·
      7 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.

    • TerkErJerbs@lemm.eeOP
      link
      fedilink
      arrow-up
      12
      ·
      7 months ago

      Thank you. Was wondering if mine was normal in this way after having it for over six months.

  • Bumrocky@lemmy.world
    link
    fedilink
    arrow-up
    18
    arrow-down
    1
    ·
    7 months ago

    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.

    • TerkErJerbs@lemm.eeOP
      link
      fedilink
      arrow-up
      5
      arrow-down
      12
      ·
      7 months ago

      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.

      • Telorand@reddthat.com
        link
        fedilink
        arrow-up
        31
        ·
        7 months ago

        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.

        • JohnEdwa
          link
          fedilink
          arrow-up
          14
          ·
          7 months ago

          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.

          • TerkErJerbs@lemm.eeOP
            link
            fedilink
            arrow-up
            5
            arrow-down
            7
            ·
            7 months ago

            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.

            • ferret@sh.itjust.works
              link
              fedilink
              English
              arrow-up
              18
              arrow-down
              1
              ·
              edit-2
              7 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.

            • Swedneck@discuss.tchncs.de
              link
              fedilink
              arrow-up
              5
              ·
              7 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.

            • zurohki@aussie.zone
              link
              fedilink
              English
              arrow-up
              2
              ·
              7 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.

        • TerkErJerbs@lemm.eeOP
          link
          fedilink
          arrow-up
          1
          arrow-down
          2
          ·
          7 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.

  • halfwaythere@lemmy.world
    link
    fedilink
    English
    arrow-up
    15
    arrow-down
    1
    ·
    7 months ago

    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.

    • TerkErJerbs@lemm.eeOP
      link
      fedilink
      arrow-up
      9
      ·
      7 months ago

      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.

      • Rin@lemm.ee
        link
        fedilink
        arrow-up
        15
        arrow-down
        1
        ·
        7 months ago

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