The memory requirements for virtualization is not negligible.
rotopenguin
joined 1 year ago
I've had some suspend adventures too, but my experience is just on Intel laptops.
About a month ago, Debian Trixie had a regression that made my laptop wake up right after a suspend attempt. Afaict, it was not directly a kernel change, something in userland changed and triggered problems. This pm_async thing fixed it. Frankly, I don't know why "async" power management is a thing anybody would want. Taking a whole extra millisecond to suspend in a more reliable way seems like a no-brainer.
echo 1 > /sys/power/pm_debug_messages # why would you ever want to not syslog it??
echo 0 > /sys/power/pm_async
Cat /sys/power/pm_wakeup_irq may tell you something about whomst is responsible for sleep failure. Anyways, suspend is the worst thing to diagnose good luck.
Kids can't even read a sundial nowadays, smh
Fun fact: SFC is short for "Super FamiCom", a tribute to the last piece of home consumer electronics ever made that just worked without having to fuss with it.
And then you dd the iso to a flash stick, boot it, start into the windows installer, and watch it shit itself because MS can't even make an iso that just fucking works.
Is it the same as "sometimes when I go to Desktop Mode undocked, KDE decides that I have zero screens" and I'm staring at blackness? I have to ssh in and shutdown to fix it.
Not reboot, shutdown. If I reboot, the next time I go into desktop mode I'll get the same thing. I think there is some ring < 0 or EC shenanigans going on there.
I don't think you can opt in, the Families beta isn't on the deck yet.
The fact that snap has that much telemetry is another reason I stick to Flatpak.
The Steam Deck only does VRR over Displayport. Valve has their own engineers working on every part of the software stack. It's their own hardware and their dock. With all that, Valve still can't get VRR over HDMI to work.
Fuck the HDMI forum.
I just fired it up on an N4000 potato, the whole thing is amazing!
view more: next ›
I made a systemd script that fires when going to / waking up from sleep - it checks how long the sleep was and if it was just a few seconds, it puts the computer back to sleep.
In hindsight, I think the thing that made it work was bluetooth was somehow responsible for the initial failed suspend. The second shot at sleep happened before bluetooth came back up, so it succeeded.