From: Ben Skeggs

This series adds support for loading and running on top of NVIDIA's GSP-RM firmware, instead of directly programming large portions of the hardware ourselves.

The implementation is a little crude in places, but the goal of this series is to get (more-or-less) GSP-RM support on par with what we already support on HW. Next steps would be to look at what features GSP-RM enables us to more fully support, and clean up the GSP-RM integration once it's known what those will require.

Things should be somewhat faster when running on GSP-RM, as it's able to control GPU clocks, which wasn't possible for us previously.

SVM support is not available when running on top of GSP-RM at this point, due to GPU fault buffers not being implemented yet. This won't effect any real use-case, as SVM is experimental at best in nouveau anyway.

Aside from that, things should more or less work as normal.

GSP-RM support is disabled by default for now (except on Ada, where it's the only option) and can be enabled with nouveau.config=NvGspRm=1.

There'll likely be some nit-picky bugs to sort through, but I don't anticipate any huge disasters. I've smoke-tested this on a selection of GPUs right back to nv50, testing both HW and GSP paths depending on the GPU, and more thoroughly tested on Turing/Ampere/Ada, both discrete and laptop GPUs.

Firmware from NVIDIA is required to enable this support.

For gaming, I've been rocking cheapo Superlux 668b with velour pads for 5 years or so and I'm looking for a bit of an upgrade.

What I like about them is just how wide they are. That's what I was looking for when buying them, it's what I've gotten used to over the years and it's what I still want.
Second to that is comfort. The 668b themselves are pretty bad in this regard but the velour pads are truly transformative here. Comfort is pretty decent with them, so I'd like at least that or (ideally) better. On-ear or shallow pads are out of the question.

What I don't like is how bright and kinda sharp they sound. It kinda gets on my ears after a while. This is what I'd like to upgrade the most but build quality is kinda wonky too.

I had a pair of Sennheiser 660s for a while and while and while I much prefer their sound signature (still a bit odd tbh) and greatly appreciate their comfort and imaging, they just don't do it for me in the sound stage department, so I returned them.

I tried the HD800S at a local HiFi store and they're amazing. Probably my end-game as I didn't like any of the other (supposedly) HiFi headphones they had there (x000€ headphones that rattle when shook and/or have the comfort of a 30€ gaming headset; wtf?).
They're a tad too expensive for me though. They're extremely good but not 10x as good as my 668b, so they fall very flat w.r.t. value, and kinda overkill for my purposes (mainly gaming).

Other headphones I have tried:

• AKG K712: Didn't immediately seem to be a downgrade in sound stage but I don't think I fully liked them. I'll have to re-test them.
• ATH-M40x: Didn't buy them for gaming but they're obviously very tight. While also quite V-Shaped, they're not as "sharp" as the 668b
• HiFiman Ananda: Decent sound stage but terrible material quality (I want to upgrade away from that). Also too expensive for what it is and the bass makes me sick

Other constraints:

• AMP is a MOTU M2. Should be able to power everything that isn't terribly inefficient.
• No wireless.
• Must be reasonably purchasable in Germany

What other headphones do you think are worth checking out?

I've been using Consent-O-Matic which works pretty well but built into the browser? Wow.

cross-posted from: https://lemmy.ml/post/1840134

This is a changeset adding encryption to btrfs. It is not complete; it
does not support inline data or verity or authenticated encryption. It
is primarily intended as a proof that the fscrypt extent encryption
changeset it builds on work. 

As per the design doc refined in the fall of last year [1], btrfs
encryption has several steps: first, adding extent encryption to fscrypt
and then btrfs; second, adding authenticated encryption support to the
block layer, fscrypt, and then btrfs; and later adding potentially the
ability to change the key used by a directory (either for all data or
just newly written data) and/or allowing use of inline extents and
verity items in combination with encryption and/or enabling send/receive
of encrypted volumes. As such, this change is only the first step and is
unsafe.

This change does not pass a couple of encryption xfstests, because of
different properties of extent encryption. It hasn't been tested with
direct IO or RAID. Because currently extent encryption always uses inline
encryption (i.e. IO-block-only) for data encryption, it does not support
encryption of inline extents; similarly, since btrfs stores verity items
in the tree instead of in inline encryptable blocks on disk as other
filesystems do, btrfs cannot currently encrypt verity items. Finally,
this is insecure; the checksums are calculated on the unencrypted data
and stored unencrypted, which is a potential information leak. (This
will be addressed by authenticated encryption).

This changeset is built on two prior changesets to fscrypt: [2] and [3]
and should have no effect on unencrypted usage.

[1] https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing
[2]
https://lore.kernel.org/linux-fscrypt/cover.1687988119.git.sweettea-kernel@dorminy.me/
[3]
https://lore.kernel.org/linux-fscrypt/cover.1687988246.git.sweettea-kernel@dorminy.me

I assume many of you host a DMS such as Paperless and use it to organise the dead trees you still receive in the snail mail for some reason in the year of the lord 2023.

How do you encode your scans? JPEG is pretty meh for text even at better quantisation levels ("dirty" artefacts everywhere) and PNGs are quite large. More modern formats don't go into a PDF, which means multiple pages aren't possible (at least not in Paperless).

Discussion on GH: https://github.com/paperless-ngx/paperless-ngx/discussions/3756