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.

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.

"Is this the one?"
"Yeah, that's the one."
Yank!

As the last of the servers died with a pathetic beep, I think I heard the poor electrician, still holding the unlabeled end of the rack's power line, invoke the name of Jesus.

(Obviously dramatized, but mostly accurate.)

The virtualization servers came back online with some fuss, but they at least look functional. My tasks for the day are set: wade through about 400 error messages, verify the functionality and integrity of 117 virtual machines, restore backups as needed, and verify the SMART status on every physical hard drive.

(edit 1) High Availability tried to migrate all of one host's VMs to the other, but it isn't worth much if both HA hosts are on the same circuit and die within seconds of each other. Now all but a few VMs are running on a single host.

(edit 2) Some of the PhDs are angry because their long-running ML projects got interrupted. They didn't set up checkpoints or live backups, so entirely their fault.

(edit 3) Five hours later, only one VM needed manual intervention (apart from migrating the VMs back to their original hosts), and all the hard drives are in good condition for their age. This turned out to be a really boring disaster.

I mean all the unnatural, wireframe-like features. It's a fascinating design and I was hoping that some quests would elaborate on the lore of how that area came to be like that. I'm caught up on the archon quests and have just finished Nightingale's Song... not a word so far.

Is there a world quest that at least mentions it? Or was there some limited event that I missed?

Obviously things didn't turn out like that, and I'd love to know if any quest touches on the topic, because the wacky geometry is just way too cool of a detail to just drop and never elaborate.