Notes on berezovskyi notes

Rebuilding a HyperHDR Host on a Dell Wyse 3040 with DietPi

Wed, 17 Jun 2026 00:00:00 +0000

The Goal

The Raspberry Pi 4 that ran my HyperHDR ambient-lighting setup died. With current mini-PC and Pi prices, a used Dell Wyse 3040 thin client (Intel Atom x5-Z8350, 2 GB RAM, 8 GB eMMC) was the cheaper and frankly nicer replacement: fanless, x86_64, and plenty for HyperHDR’s ~250 MB working set. This note documents rebuilding the host on it with DietPi - including the part that the official installer would not do for me, and getting the 10-bit p010 capture format working on x86 via DKMS.

HyperHDR Ambient Lighting: My TV Backlight Rig

Sun, 07 Jun 2026 00:00:00 +0000

The Goal

Ambient lighting (you may know it as bias lighting, or by Philips’ “Ambilight” brand) puts an LED strip around the back of the TV and lights it to match the edges of whatever is on screen: a forest scene spills green onto the wall behind the panel, an explosion throws orange. Beyond looking good, a lit wall behind the TV reduces eye strain in a dark room and makes the picture feel larger than the panel.

DualSense Access Lost When Switching Linux Users

Mon, 18 May 2026 00:00:00 +0000

The Problem

The multi-seat gaming setup runs Steam in a gamescope session as a systemd user service. The machine has two users: the gaming user who owns the gamescope service, and a separate work user. Both users are on seat0. Switching to the work user while the gamescope session is running caused the DualSense controller to stop responding in Steam.

Why the Controller Goes Through hidraw

Part 3 explains this in detail. The short version: TemporaryFileSystem=/dev/input in the gamescope service hides all evdev devices from the service process tree. Steam Input bypasses this entirely - it reads the DualSense through /dev/hidraw* (the raw HID interface) for full-feature support: adaptive triggers, haptics, gyro, touchpad. The evdev path is never used.

Linux Multi-Seat Gaming: Fixing Input Isolation with LIBSEAT_BACKEND=noop (Part 3)

Sun, 17 May 2026 00:00:00 +0000

The Problem

Part 2 ended with a gamescope TV session that could be started and stopped independently - but with an immediate new problem: moving the desk mouse moved the cursor in Steam Big Picture on the TV. Keyboard keys navigated Steam menus.

This shouldn’t happen. The desk mouse and keyboard are seat0 devices - they are not tagged for seat1 in udev, so seatd should not have given gamescope access to them. The gamescope log confirmed this - there were no “Adding device” messages from libinput. gamescope itself received no input devices through seatd.

Linux Multi-Seat Gaming: greetd, seatd, and Independent Session Control (Part 2)

Sun, 17 May 2026 00:00:00 +0000

The Goal

Part 1 ended with a working setup and one major limitation: the TV gaming session on seat1 was always-on. To stop it - for GPU passthrough to a Windows VM, or to run Steam on the desk instead - required restarting all of LightDM, which also killed the Sway session on seat0 and lost all open windows.

The goal: replace LightDM’s static seat1 management with something that can be stopped and started independently, without touching seat0.

Linux Multi-Seat Gaming: Dedicated TV Session with Gamescope (Part 1)

Sat, 16 May 2026 00:00:00 +0000

The Goal

I have a Linux desktop that doubles as my workstation and gaming machine. The CPU is a Ryzen 7900X - which has integrated graphics - paired with a discrete RX 9070 XT for gaming. Two monitors sit on my desk connected to the motherboard’s video output (iGPU), and a long HDMI cable runs from the RX 9070 XT to a TV in the living room.

The idea is simple: play games on the TV without touching what’s running on the desk. On Windows this would mean “just connect the TV and extend the desktop.” On Linux, I want something better - a fully independent gaming session on the TV, with Steam Big Picture UI, HDR, VRR, and gamepad-only control, while my Wayland desktop on the desk keeps running untouched.

Migrating a Seagate HDD to Native 4K Sectors on a Synology NAS

Sat, 16 May 2026 00:00:00 +0000

The Goal

I was adding a new Seagate Exos X20 (ST20000NM007D, 20 TB) to my Synology DS1821+ running DSM 7.2.2. These drives ship from the factory in 512e mode - they physically use 4096-byte sectors but advertise 512-byte sectors for legacy OS compatibility. Since my NAS and DSM support native 4K sectors, I converted the drive to 4Kn (native 4K) before adding it to the storage pool.

Why Native 4K?

512e is a compatibility shim. The drive’s physical sectors are 4096 bytes, but when the OS writes a 512-byte block, the drive must read the entire 4096-byte physical sector that contains it, modify the relevant 512 bytes, and write the full sector back - a read-modify-write cycle on every write. Native 4K eliminates this: every OS write maps directly onto a physical sector.