tell me the most ass over backward shit you do to keep your system chugging?
here’s mine:
sway struggles with my dual monitors, when my screen powers off and back on it causes sway to crash.
system service ‘switch-to-tty1.service’

[Unit]
Description=Switch to tty1 on resume
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/local/bin/switch-to-tty1.sh

[Install]
WantedBy=suspend.target

‘switch-to-tty1.service’ executes ‘/usr/local/bin/switch-to-tty1.sh’ and send user to tty1

#!/bin/bash
# Switch to tty1
chvt 1

.bashrc login from tty1 then kicks user to tty2 and logs out tty1.

if [[ "$(tty)" == "/dev/tty1" ]]; then
    chvt 2
    logout
fi

also tty2 is blocked from keyboard inputs (Alt+Ctrl+F2) so its a somewhat secure lock-screen which on sway lock-screen aren’t great.

  • @UNY0N@lemmy.world
    48•4 months ago

    This certainly isn’t of the same caliber as some of these other comments, but I found it to be fitting to the topic.

    Last year I was having problems getting the game stellaris working on arch. (I use bazzite now, btw) My solution was the following:

    1. download the game via steam.
    2. switch it to use proton
    3. switch it back to linux version
    4. use the terminal to make the entire game folder read-only, so that steam couldn’t touch the game anymore and screw it up.
    5. add the exicutable to PATH
    6. start the game via terminal

    If any one of those step was left out, it didn’t work. I’m no linux expert, so I didn’t have the skills to actuality find the real problem.

    • JulianEnglish
      19•4 months ago

      I… What? Why does that work? How did you figure this out?

      • @UNY0N@lemmy.world
        7•4 months ago

        Blind trial and error, mostly. Making the game folder read-only was the real “duct-tape” part, it occued to me to do that after steam kept “updating” the game and breaking my solution.