u/__z3r0_0n3__

Demos and docs: https://zerone-laboratories.github.io/zss

Source: https://github.com/z3r0n3br4instorm/ZrnSelectiveSuspend

Maybe this is stupid

I wanted to share a side project I've been working on to solve a personal annoyance with hybrid graphics. If you've ever dealt with a discrete GPU on a laptop, you know the pain of having to log out, kill your X session, or reboot just to fully power the card down for battery, or to pass it through to a QEMU/KVM virtual machine.

I built ZrnSelectiveSuspend (ZSS) to fix that. It's an alpha tool that takes a graphics card out of service on a live Linux desktop by moving running Vulkan and OpenGL programs to another GPU while they're still drawing, then gives everything back afterwards.

**What it does right now:**

* **Zero-watt power-off:** switches the dGPU completely off under a running X session (~0.4 s) and back on (~1 s). Programs move to the iGPU and back; vkcube never stops spinning. Can also follow the charger or an idle timer.

* **Live VFIO passthrough:** `zssctl lend` moves the host's programs off the card and hands it to vfio-pci; `zssctl reclaim` power-cycles it and gives it back to the host driver with the programs returned. No reboot, no log-out. Tested with a CachyOS guest in QEMU.

Honest caveat: the guest sees the card, but nouveau stops after reading the chip ID because the Mac Edition card has no video BIOS of its own. Passing a ROM file to QEMU is next.

* **Surviving a card that vanishes:** I wrote a kernel module (ZSS_Interceptor) that notices a card losing power within ~0.1 s. If the card was idle, the driver is frozen and resumed. If a program was rendering on it, the program gets rebuilt on the iGPU in ~3.5 s with nothing lost, and `zssctl on` brings the card back in 4 - 7 s by replugging it the way NVIDIA's driver handles an unplugged eGPU. Desktop stays up the whole time. Caveat: after that rescue, the card can't be powered off or lent again until you reboot.

**What moves:** Vulkan 1.1 programs, OpenGL 3.2 programs through Mesa's Zink, Chromium and Electron apps (VS Code, Teams), and Unity games. Proton/DXVK needs Vulkan 1.3, so not yet.

**How it works, briefly:** a user-space Vulkan driver shim (ZSS_AirLock) sits between programs and the real drivers, keeps enough state to rebuild them on another GPU, and emulates missing features so Zink runs even on NVIDIA 470. A daemon sequences moves, freezes, driver suspend and power cuts. The kernel module handles PCI state, power backends and loss detection. NVIDIA additionally needs a small DKMS patch so the driver can sleep under a running display server.

**The bigger picture:**

ZSS is focused on graphics cards right now, but the long-term goal is to safely disconnect, suspend and reconnect any PCI device on a live system without taking the kernel down with it. GPUs are just the hardest place to start.

I used Claude Code a lot to build this. I made the architectural calls; it did a big share of the implementation and helped me work through the nastier kernel module and driver interactions. It's been a massive learning accelerator.

**Status:** very much alpha. Proven on one machine: a 2012 MacBook Pro (MacBookPro9,1, GT 650M + HD 4000) on Arch, kernel 7.2, X11, NVIDIA 470.256.02. Power-off currently needs an Apple gmux; an ACPI backend for most hybrid laptops since ~2015 is written but has never been run. Wayland compositors are recognised but untested. The program-moving parts are vendor-neutral and should work with any Vulkan driver.

**How you can help:** there's a tester kit that changes nothing and installs nothing. It collects what your machine has, runs the moving tests in dry-run mode, and saves a report with personal details stripped:

curl -fsSLO https://github.com/z3r0n3br4instorm/ZrnSelectiveSuspend/releases/latest/download/zss-tester.run && sh zss-tester.run

I'd especially love reports from AMD/Intel dGPU laptops (to try the ACPI backend), architecture roasts, and feedback from VFIO folks.

Thanks for reading!

Mankind deserves a less infuriating SSH Experience...

Edit: People keeps asking what's infuriating in ssh, it's the delay. Typing Delay is infuriating. And yes most of you who are living in developed countries does not experience these but the few who are working from countries like Sri Lanka, will definitely experience this delay.

And yeah, you probably already guessed how: a normal SSH session does a full round trip per keystroke you type, wait for the server to echo it back, watch it appear. FlashSSH does the line editing locally, so typing, history, autosuggestions and tab-completion are all instant. It only touches the network once... when you press Enter.

Even for full-screen stuff (vim, tmux, btop…) where it hands over a real PTY, it does mosh-style predictive echo: your keystrokes show up immediately in grey and turn white the moment the server confirms them same idea as mosh, minus the full terminal emulator. And it decides whether prediction is actually helping at runtime instead of guessing from the program name, so it works in sessions it's never heard of.

Best part: anything that needs a terminal but isn't on the known list just works now. A plain exec that fails with a "needs a terminal" error gets transparently re-run under a PTY (or you force it with a ! prefix). No allowlist editing.

One-line install, C on libssh, MIT. Still early tell me what breaks:

Direct Install:

curl -fsSL https://raw.githubusercontent.com/z3r0n3br4instorm/FlashSSH/main/install.sh | sh

Hi Everyone!,

I created this fork of zed to work with OpenGL 3.3 backends. Mainly because I'm daily driving this old macbook pro on Arch Linux with intel HD3000 graphics as a hobby project and I wanted to use zed with it.

Anyways, here's the repo if anyone wants to check it out: https://github.com/z3r0n3br4instorm/zed/tree/gl33-backend

And here's the Pre-Compiled binary for Linux

https://drive.google.com/file/d/1BwfKQZ244XbmhXzCnXNBHm9PPlfuZTIr/view?usp=drive_link

https://reddit.com/link/1v2osto/video/v62f8lgr8meh1/player

https://github.com/z3r0n3br4instorm/AutoBrightnessLinux

My laptop doesn't have an ambient light sensor, and I was sick of squinting at 100% brightness in a dark room or getting blinded at max brightness near a window. So I wrote a small Python tool that uses the webcam instead of dedicated hardware.

It grabs a frame, does a bit of weighted luminance + percentile analysis on the center region (to avoid getting thrown off by a bright window in the corner or a dark hoodie filling half the frame), and maps that to a brightness percentage via brightnessctl. There's smoothing baked in so it doesn't yank your screen between values every time you glance away.

It's built to slot into Hypridle on idle-timeout and resume it re-samples the room and adjusts both screen and keyboard backlight (keyboard scales to ~20% of screen brightness). No daemon, no polling loop eating CPU in the background — it just fires when hypridle tells it to.

Still early (v0.0.1), Python + OpenCV, Hyprland-specific for now but the core brightness logic doesn't care what compositor you're on happy to take PRs for other idle daemons.

Repo's here if you want to poke at it: https://github.com/z3r0n3br4instorm/AutoBrightnessLinux

Feedback, roasts, and "why didn't you just use X" comments all welcome.

I bought this used early 2011 13 inch MacBook pro to daily drive it. I kinda did something stupid to be honest, I initially installed Sonoma with OCLP, it was working fine but not smooth, so I decided to dual boot it with Catalina, with dosdude1's Catalina patcher. Then I installed Snow leopard as well. So it had three operating systems. I removed Sonoma after a while and had been using Catalina for like a week now. 

I have to mention this as well, when I tried to install a RAM card to the bottom slot & It didn't boot, sometimes it boots but crash in the OS or 3/4th of the boot progress. Also when I put pressure on the CPU area it manages to be on the OS for a while before crashing again. Eventually I gave up and now it only has a single stick of 8GB RAM on the top slot.

Circleling back to the main issue, I left my laptop idle on my table today, I went out came back to a black screen, I thought it might've been sleeping I tried waking up, nothing happened so I force turned it off (I have a secondary HDD installed in a caddy I heard the HDD stopping when I did that). Then when I boot it back up the display doesn't work, no backlight or image. But it boots up because I can see the keyboard backlight gets initialized and I can blindly enter password and do a `sudo reboot` which will actually reboot the laptop. I tried blindly booting to the snow leopard entry, somehow that initializes the backlight, but no image is showing up. When I boot it to Snowleopard and reboot, when the laptop turns back on the backlight initializes. But if I do a PRAM reset, backlight doesn't initialize again. 

Bear in mind I'm booting Snowleopard from the opencore menu. So I tried resetting PRAM and booting a clean Snowleopard installation from my other SSD which will turn on the backlight on boot but when I reboot the backlight is not turning on again. Currently I don't have a mini display port adapter so I don't know if the display output works,

Crippling my laptop on purpose ;)