60 watts to illuminate just one room used to be the norm. Now it sounds insane. Maybe losing the perfect color rendering index was a worthwhile tradeoff after all.

Thoughts about the Steam Frame, Factorio's native ARM64 port, and how it integrates into the Steam Frame and Linux ecosystem. Written by Raiguard and Sanqui, the developers who made Factorio's Linux-native build happen.

An article about her work at Oculus and Meta: XR Update

No Frame today, it looks like.

It takes approximately nineteen thousand winedbg processes to fill up 32 gigabytes of RAM.

Is it angry at me because I blew up a steam locomotive's boiler in Derail Valley earlier?

Four tonnes of firewood arrived on Friday afternoon. It took my family of four a little over five hours to carry it to the storage shed. I had a reference because my autism demanded stimulation.

The shed has about 3.5 x 6 x 1.5 metres of usable volume. That amount of firewood lasts us the entire heating season with a bit left over.

(edit: replaced photo with a smaller one)

It was released a few years ago. It's not Singularity and not Timeshift.

The title was short, two or three words, and I'm pretty sure it was some kind of physics technobabble.

The game follows the Portal formula where the player has to solve a sequence of self-contained cube-and-button challenges in a decaying facility, except it's on a space station. The player has a device that can reverse time and cause the cubes to retrace their paths through space. The act of solving the challenges somehow generates energy. There are friendly robots with faces drawn on sticky notes. We also see the Earth explode.

I'm watching Mandy's old RING 2 stream VODs (because I like watching grown men fail at slide puzzles, don't judge) and he lost it when the Lowry chat started posting gifs and photoshops of Morrow. I know that every single Lowry post is an incomprehensible rabbit hole of in-jokes and references, but I have nothing on Mr. Morrow other than the one appearance in his SOMA video. What context am I missing?

@who@feddit.org pointed me to the solution. Since XInput is implemented using SDL2, it can be told to selectively ignore devices by setting the SDL_GAMECONTROLLER_IGNORE_DEVICES environment variable. The value should be a hexadecimal VID/PID pair separated by /, or a comma-separated list of VID/PID pairs for multiple devices.

For the 2026 Steam Controller:

SDL_GAMECONTROLLER_IGNORE_DEVICES='0x28de/0x1304'

For other devices using a USB cable or dongle, the VID/PIDs can be listed using this command:

lsusb | sed -E 's/.*: ID ([a-z0-9]{4}):([a-z0-9]{4})/0x\1\/0x\2/'

cross-posted from: https://lemmy.world/post/47349151

There are some non-Steam games that I can't run through Steam because of its sandboxing (bubblewrap, Steam Linux Runtime, pressure-vessel and such). For those, I've set up SISR to capture the SC's input and remap it to a virtual controller.

While SISR itself works (and quite well with both the touchpads and the gyro), the game ends up receiving inputs from both the virtual and the physical controllers simultaneously.

Running wine control joy.cpl shows both the real SC and the virtual Xbox 360 controllers as DirectInput devices. The XInput list is empty, but the XInput tab shows that it receives input events from both the SC and the virtual controller. Disabling hidraw or the individual DInput devices has no effect.

I'd like to find a way to either hide the device from Wine's XInput driver, or to prevent the XInput device (within Wine) from sending input events to the game. So far, no luck. Any help would be appreciated.

@who@feddit.org pointed me to the solution. Since XInput is implemented using SDL2, it can be told to selectively ignore devices by setting the SDL_GAMECONTROLLER_IGNORE_DEVICES environment variable. The value should be a hexadecimal VID/PID pair separated by /, or a comma-separated list of VID/PID pairs for multiple devices.

For the 2026 Steam Controller:

SDL_GAMECONTROLLER_IGNORE_DEVICES='0x28de/0x1304'

For other devices using a USB cable or dongle, the VID/PIDs can be listed using this command:

lsusb | sed -E 's/.*: ID ([a-z0-9]{4}):([a-z0-9]{4})/0x\1\/0x\2/'

There are some non-Steam games that I can't run through Steam because of its sandboxing (bubblewrap, Steam Linux Runtime, pressure-vessel and such). For those, I've set up SISR to capture the SC's input and remap it to a virtual controller.

While SISR itself works (and quite well with both the touchpads and the gyro), the game ends up receiving inputs from both the virtual and the physical controllers simultaneously.

Running wine control joy.cpl shows both the real SC and the virtual Xbox 360 controllers as DirectInput devices. The XInput list is empty, but the XInput tab shows that it receives input events from both the SC and the virtual controller. Disabling hidraw or the individual DInput devices has no effect.

I'd like to find a way to either hide the device from Wine's XInput driver, or to prevent the XInput device (within Wine) from sending input events to the game. So far, no luck. Any help would be appreciated.

I started playing in version 0.9.0j and the number of hardware failures made it feel like the whole infrastructure was held together by chewing gum and prayers. I had one or two things to fix every day, which was a great source of tension because I was always under the threat of having to stay out in the dark to keep the place operational.

A few days ago I updated to 0.9.0n and (by entirely my fault) had to start a new save. It's been six in-game days and not a single fault occured (other than scripted events). No server faults at base or any radio dishes, not one blown fuse on the coordinate radars. I can comfortably get my dailies done before noon and collect signals and clean the base all day.

Did anyone else experience this? Was this an intentional change? Or did I just have shit luck on my first save?

The controller is un-bricked! All thanks to this user: https://redlib.catsarch.com/r/SteamController/comments/1tc3ua9/arrived_today_wont_connect_update_failed_bricked/

Symptoms:

• The firmware update failed.
• Turning on the controller causes the LED to flash red.
• The device takes charge from both the Puck and USB.
• Can't connect wirelessly to the Puck.
• When connected using a USB cable, the device shows up as "Valve Software Steam Controller Bootloader" in lsusb's output.

How to fix:

1. Start Steam in developer mode by using the -dev argument.

2. Open Settings -> Developer

3. Under Hardware Updates, press the Update all devices now button.

Steam will go through the usual firmware update steps and flashes all connected devices. This failed for me one more time, then worked fine once I switched to a proper USB C-to-C cable.

4. You might need to flash the Puck too, then pair it with the controller.

Original post:

The controller worked fine until I started Steam. It showed the firmware update popup, I did as instructed, the puck was updated fine, but the controller failed. Now the LED flashes red when I turn it on, it doesn't react to button inputs, doesn't connect wirelessly, isn't recognised as a controller when connected through USB, and shows up only as "Valve Software Steam Controller Bootloader".

I think it's reasonable to assume that the firmware is cooked. Naturally I'm opening a support ticket with Valve, but I'm wondering if anyone has any idea on how to resolve it without waiting, potentially for months, for a replacement.

I recently decided to rebuild my homelab after a nasty double hard drive failure (no important files were lost, thanks to ddrescue). The new setup uses one SSD as the PVE root drive, and two Ironwolf HDDs in a RAID 1 MD array (which I'll probably expand to RAID 5 in the near future).

Previously the storage array had a simple ext4 filesystem mounted to /mnt/storage, which was then bind-mounted to LXC containers running my services. It worked well enough, but figuring out permissions between the host, the container, and potentially nested containers was a bit of a challenge. Now I'm using brand new hard drives and I want to do the first steps right.

The host is an old PC living a new life: i3-4160 with 8 GB DDR3 non-ECC memory.

• Option 1 would be to do what I did before: format the array as an ext4 volume, mount on the host, and bind mount to the containers. I don't use VMs much because the system is memory constrained, but if I did, I'd probably have to use NFS or something similar to give the VMs access to the disk.

• Option 2 is to create an LVM volume group on the RAID array, then use Proxmox to manage LVs. This would be my preferred option from an administration perspective since privileges would become a non-issue and I could mount the LVs directly to VMs, but I have some concerns:

  • If the host were to break irrecoverably, is it possible to open LVs created by Proxmox on a different system? If I need to back up some LVM config files to make that happen, which files are those? I've tried following several guides to mount the LVs, but never been successful.
  • I'm planning to put things on the server that will grow over time, like game installers, media files, and Git LFS storage. Is it better to use thinpools or should I just allocate some appropriately huge LVs to those services?

• Option 3 is to forget mdadm and use Proxmox's ZFS to set up redundancy. My main concern here, in addition to everything in option 2, is that ZFS needs a lot of memory for caching. Right now I can dedicate 4 GB to it, which is less than the recommendation -- is it responsible to run a ZFS pool with that?

My primary objective is data resilience above all. Obviously nothing can replace a good backup solution, but that's not something I can afford at the moment. I want to be able to reassemble and mount the array on a different system if the server falls to pieces. Option 1 seems the most conducive for that (I've had to do it once), but if LVM on RAID or ZFS can offer the same resilience without any major drawbacks (like difficulty mounting LVs or other issues I might encounter)... I'd like to know what others use or recommend.