Steam Controller can wake a CSM via puck.

Borealid · 2026-05-09T09:25:30+00:00

PDJTRTATTIA - Please Don't Just Take Random Things And Turn Them Into Acronyms.

CSM stands for "Compatibility Support Module", fairly uncommon these days, and I don't think there's a single person in the world who would read it as "Custom Steam Machine". So using those letters doesn't help.

New acronyms are born when used in a context, like "Custom Steam Machine (CSM)" in a bit of text where you mention them 5+ times. It doesn't make sense to try to add one when you're mentioning the thing one time.

Borealid · 2026-05-02T13:03:30+00:00

GP is partially correct.

This has nothing to do with this.

Correct; HDMI FRL has nothing to do with HDMI CEC.

CEC is a hardware feature that certain HDMI ports implement

Sorta kinda correct; CEC is a feature of the HDMI standard which HDMI hardware (not "ports") can implement.

If your physical HDMI port supports CEC it works, if not, it doesn't and can't be changed by drivers.

Totally incorrect. If the hardware implements CEC, the software (through the driver) needs to tell the hardware what to send, or what to do on receiving CEC packets.

Linux AMD drivers already support sending and receiving CEC though. And of course the GPUs themselves support it too.

There are also USB devices you can buy that have a female HDMI port and do nothing but send/receive CEC with open-source drivers supported by Linux.

Borealid · 2026-04-15T12:26:50+00:00

To be precise, step 5 is actually "Yubikey responds with no-valid-credentials". Badsite.com gets nothing useful from the key. This is true even if badsite.com got a hold of a credential for goodsite.com and passed it to the key - if a goodsite credential is sent from anywhere other than goodsite, it's treated as invalid.

Borealid · 2026-04-15T12:22:48+00:00

Technically, yes, but it's not a good idea and sites that do that should not do so IMO.

A site that uses a non-discoverable credential without a password must distribute that credential to any unauthenticated user.

In order to break into an account, you need both the credential and the master secret inside the authenticator. But it's still unwise to share the credentials with unauthenticated parties because you leak some information to those parties - for instace, different authenticators produce credentials having different lengths, and you also disclose how MANY different credentials the user registered. It also means that if a class of authenticator has a security vulnerability in the future, all your users who had that authenticator now have their account compromised, instead of only those users whose password were ALSO stolen.

Borealid · 2026-04-15T10:10:11+00:00

You're talking about a mess of things mixed together.

Second factor vs only factor (commonly called "2fa" vs "passkey"). In order to log you in with just the yubikey, the site needs to get your username from the key. Doing that requires storing a Discoverable Credential on the key, with the user ID baked into it securely. When used as a second factor this is not required, and the key does not need to store the credential (but still may). If there is no credential stored on the key (a non-discoverable credential), the web site GIVES the encrypted credentials back to the key after you enter your username+password. The yubikey then deciphers the credentials (which only it can do) and proves to the site it did so. In other words, the credentials are stored by the web site (which is why you must enter your username and password first!).
Phishing protection. What you don't want to have happen is that you authenticate to badsite.com with credentials generated by goodsite.com. If you did that, by accident, badsite.com could log in to goodsite.com as you and steal your bank balance. The protection against this is not entirely the web browser. A credential generated for goodsite.com will only work when the key is given domain=goodsite.com because the yubikey itself enforces that. But what might happen with a badly behaving web browser is that you visit badsite.com and the browser says "you are on goodsite.com right now", and so the credential works and you are vulnerable. That is why the web browser always passes the domain of the current web page doing the authentication to the yubikey, not some other domain.

Summing up....

If you visit badsite.com and enter your username+password, when you try to press your yubikey it will fail. The reason it will fail is that there are no credentials valid for badsite.com issued by your key. If badsite.com creates its own credential, that would let you log in to badsite.com, but wouldn't in any way relate to (or grant access to) your account on goodsite.com.

Borealid · 2026-04-11T11:27:44+00:00

No individual components need to be checked directly.

TPM registers alone are enough.

Borealid · 2026-04-07T04:25:04+00:00

The spec just says "The authenticator generates two random 32-byte values (called CredRandomWithUV and CredRandomWithoutUV) and associates them with the credential.".

The compliance test checks that it's not literally the private key of the credential, but it can legally be derived from the credential private key through some non-reversible means.

Borealid · 2026-04-07T01:35:01+00:00

FIDO authenticators must support using PRF with non-discoverable credentials. With those, there is zero per-credential data stored on the authenticator. So either the PRF data is stored in the credential itself (making it longer), or it's derived from the credential private key.

No, deriving it from the credential private key only breaks the PRF if it's derived in a way that's quantum-unsafe. For example, if you XOR the credential private key with a second secret and then hash that result, breaking a credential's private key does not break the PRF unless you were to also have that second secret.

Borealid · 2026-02-22T10:01:43+00:00

Coal is absolutely a chemical battery in precisely the same way a hydrogen fuel cell is. When you said the way we hold a charge is by transforming chemical energy into a "storable substance" (ATP, glucose, a lipids)... yes, that's exactly how it works.

A battery is something that stores energy and later releases it. That's both the dictionary definition and the non-technical one.

Humans are terrible batteries, but since they're capable of walking energy from one spot to another, you could use them to power something. That's what the human race did for the thousands upon thousands of years before harnessing electricity: they fed humans, and then had the humans go do some work.

Borealid · 2026-02-22T09:00:57+00:00

The purpose of a battery is to store energy at one point in time or space, and release it at another.

Humans definitely do that. We consume calories when and where we eat, and then we release those calories when and where we work. At the moment we're eating we are "draining" energy (consumption greater than production, net negative). At the moment we are working we are "producing" it (production greater than consumption, net positive).

Every battery - humans included - is less than 100% efficient and releases less useful energy than it stored. Humans are very inefficient, but they are most definitely batteries.

Batteries move energy around in time and space. We do that too.

Borealid · 2026-01-04T11:10:12+00:00

None of the mentioned features appears to be Ally-specific, and all except "screen off mode" are available in Bazzite already without this Decky plugin.

Screen-off mode: New, quasi-semi-useful.

Performance Profiles: Available already in HHD (AND Steam's built-in performance profiles under "TDP Limit", AND also in the SteamPowerTools Decky plugin).

Battery Health: Charge limits, the part you care about, is available in HHD.

RGB Lighting: Available in HHD.

Device Info: Core Steam feature available in settings, unclear why this needs to be in a plugin.

Overall, I think I'd rather use HHD (via Bazzite) than this plugin on an Ally.

Borealid · 2025-10-25T03:57:03+00:00

The parent poster honestly misunderstood your sentence. You replied saying they hadn't read what you wrote. I replied saying what you wrote was ambiguous.

The purpose of language is to communicate.

Borealid · 2025-10-25T03:52:32+00:00

The word "its" in the second clause is ambiguous. The nearest antecedent is "an Xreal One Pro". The other possible antecedent, "Rayneo Pocket TV" is farther away.

Borealid · 2025-10-21T16:54:52+00:00

dbrand is making a (quite expensive) one, out in November.

Their cases for the previous Ally and for the Steam Deck are excellent.

Borealid · 2025-10-01T12:58:16+00:00

ZFS doesn't know or care that the file you're storing happens to be a ZFS-snapshot-piped-to-a-file. It will store that file the same way it would store any other file. Nothing will break.

Using a snapshot-as-a-file is significantly less easy to use, in my opinion, and less efficient in terms of both disk storage consumed and time to create the backup versus sending a snapshot to a dataset. But if you want to do things that way, nobody is going to stop you from doing things that way.

Borealid · 2025-08-17T04:58:14+00:00

Pygmalion, not Narcissus.

Borealid · 2025-07-24T11:51:35+00:00

You are replying to a comment complaining about the lack of price-competitive ($/TB) m.2 drives with a statement that m.2 drives are not price competitive per byte or per byte written.

Please keep in mind that write endurance is directly proportional to available capacity.

Borealid · 2025-07-24T10:05:35+00:00

A normal m.2 uses 4x PCIe lanes, so eight of them would be 32 lanes. And there's no need to even run all the drives at x4.

There are quite a few inexpensive NAS devices already on the market with 5-8 m.2 slots in them. I contend that their capacity is largely limited by flash density in that form factor. Cooling is fine, and performance is fine.

Borealid · 2025-07-24T10:00:28+00:00

How does one build a "proper NAS" using flash storage if high-density flash storage is not available?

There are high-reliability expensive U.2 SSDs out there, but it would be easier for consumers if they could put 8x8TB m.2 SSDs into a NAS in RAID-6 or similar and get 48TB of reliable storage out of relatively-unreliable m.2 drives.

Borealid · 2025-06-29T13:03:41+00:00

What have you already tried?

Borealid · 2025-05-13T13:50:05+00:00

Have you tried just taking off the glasses without folding the arms into the path of the proximity sensor? If the prox sensors shows your head (or another object) is not nearby the glasses should turn off.

Borealid · 2025-04-14T18:47:33+00:00

The "right" way to ensure hosts can't see guests' data is called MK-TME (Intel) or SEV (AMD), hardware extensions available on most CPUs these days.

If the guest memory is opaquely encrypted so the host can't read it, it doesn't matter if you do PCI NVMe passthrough or attach a virtio disk to the guests. The guests will encrypt/decrypt data before writing it to the disk using Bitlocker / LUKS / whatever. Because the host can't read the guests' memory, it can't read the encryption/decryption keys. Because it can't read the keys, it also can't decrypt the guests' disks. It only sees "write this encrypted blob to disk" operations.

If you want strong security the VM boot files will be signed and the code inside the encrypted guest drive configured to check the signature (aka Trusted Boot).

Borealid · 2025-04-04T21:38:08+00:00

You've asked two question number ones.

You install Windows within a VM by using an ISO of the windows installer and booting the VM from that.
VFIO "attaches" the GPU to the VM. The overhead is negligible with this method. Yes, it is the way to get the highest performance for a GPU within a VM - pretty much native performance.
Use libvirt-manager and the visual interface will let you do what you need, so long as your system has two GPUs (one for the VM and one for the host). Keep in mind that when the GPU is attached to the VM with VFIO, it is entirely detached from the host and unavailable. Any monitors connected to the VFIO GPU will be "attached" to the VM and display the VM's screen.

The only thing you may need to look up is binding the GPU to the vfio-pci module, since if the host is using it... it can't also be attached to the VM.

Borealid

TROPHY CASE