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.
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.
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.
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.
What you're looking for is called "debouncing". I think the answer I'm linking here is wrong, the time is not tuneable in libinput. If you want to go through the ordeal of re-compiling libinput and shoving it in your system (without breaking it all?), it is
debounce_set_timer() and debounce_set_timer_short() in evdev-debounce.c. I think it's the ms2us(25) call.
rotopenguin @ rotopenguin @infosec.pub Posts 0Comments 614Joined 2 yr. ago
And there's a separate effort called Mineclonia.