Soooo my previous toots ended up on Phoronix and here come the entitled users saying how dare you tell me to switch to Wayland.

Repeat after me: Xorg is dead. It is unmaintained. It is buggy and those bugs are not getting fixed. *THIS IS FROM ITS OWN DEVELOPERS*. The people previously working on Xorg are now working on Wayland. They are literally part of the same organization FFS.

If you want Xorg to keep working, fix it yourself. Oh, not interested? Nobody else is either. Guess what, if nobody works on it, it will bitrot into oblivion. Nobody has signed up to fix it. No amount of wishful thinking is going to change that. You can keep using it all you like, but unless YOU sign up to maintain it, it's going to die.

Want Xorg to survive? Take over maintenance. We're all waiting.

*crickets*

Please, please stop using Xorg with Asahi Linux.

It's all but unmaintained, broken in fundamental ways that cannot be fixed, unsuited to modern display hardware (like these machines), and we absolutely do not have the bandwidth to spend time on it.

We strive for a quality desktop on Apple Silicon machines, but we have to pick and choose our battles very carefully, because we can't single-handedly fix all the problems in the entire Linux desktop ecosystem. Yes, some Xorg things might work better on other platforms. That doesn't mean Xorg isn't broken, it means those platforms have spent years working around Xorg's failings. We don't have the time for that. Distributions and major desktop environments are already dropping Xorg support. It's pointless to try to support it well today on a new platform.

XWayland will continue to be supported for legacy client apps, and we do plan to spend time on optimizing the XWayland experience. But for anything that goes beyond "displaying windows" (compositors, IMEs, input management, desktop environments, etc.), please use native Wayland applications, since XWayland will never integrate properly for those things (by design).

Yes, not every random app and feature you use on Xorg will have a Wayland equivalent. Deal with it. The major players in desktop Linux have decided it's time to move on from Xorg, and if you want to go against the tide you're on your own.

We do expect Xorg to continue to function for the bare essentials (i.e. showing a working desktop), but that's it. We won't be working on any features or non-desktop-breaking bugs beyond that.

The only reason we shipped Xorg by default is that Wayland compositors were slower with software rendering. The reverse is true now that we have GPU drivers, and we will be switching all default-Xorg-KDE users to default-Wayland in an update (along with promoting the GPU drivers to the default builds) really soon. At that point Xorg will be relegated to SDDM, and once a native Wayland release of that finally happens, we won't be shipping any usage of the X server any more.

Note to self: speakersafetyd ALSA mixer interlock design:

- Volume unlock is built on the mixer control exclusive lock feature (need to add an ALSA core callback to the kctl to implement this).
- DVC volumes are initially capped at a safe volume known to be safe for the speakers for all possible audio signals (set kernel-side).
- There is a special global watchdog/unlock control (takes an integer timestamp)
- speakersafetyd must first lock the watchdog control and write the current timestamp (CLOCK_MONOTONIC) to it.
- It can then lock the volume controls. This fails if the watchdog control is not locked or not up to date.
- When a volume control is locked by the same PID as the timestamp control and the timestamp is up to date, it removes its volume cap.
- The timestamp must be refreshed at least once per second while the playback PCM stream is active (== the feedback PCM stream is receiving samples). It is allowed to remain unupdated while the PCM is inactive (volumes remain set, but time since last update is cumulative while PCM runs, PCM becoming active does not reset the timeout).
- If at any point the watchdog expires or the unlock control lock is dropped (indicating the daemon died), all volumes are again reset and capped to a safe level.
- If an individual volume control lock is dropped, that individual control goes back to safe mode (only).

There's this particular brand of online abuse I see, where *seemingly* unrelated people all have one very specific, very unique, and very obvious tell that they all are either the same person or from the same small group of people.

Honestly, I have to wonder just how much abuse is actually concentrated in a few small groups of terminally online people who make it their pastime to create random sockpuppets and continuously attack the same person. The Fediverse has also made this pretty clear: I see many abusers of a given slant all end up on the same bad instances (or random one-off instances for the techie type who set up their own).

If you are or have been the target of this brand of abuse, with similar takes coming from a bunch of seemingly unrelated accounts, remember that. There's a good chance it's all the same 2 people, or the same small group chat of haters, whose heads you live in rent-free to the point they spend their time creating alts instead of doing something productive with their lives.

I think I never told this story here... how I fixed a server with a very precisely placed piece of tape.

So at Euskal Encounter we got shiny new servers a few years back, and they worked great except one of them developed a peculiar problem. It would not shut down.

When told to shut down, it would either hang, or boot back up, or power back up but then fail to boot. This was a problem, because we normally relied on servers shutting down and staying down during our shutdown procedure. Having to have someone babysitting the machine to yank the power is not great. Plus it meant that if we ever got into that state, we couldn't fix it remotely (and some events are run remotely). Once the problem happened, no amount of shutdown/power up/reboot commands to the BMC would fix it (eventually it would start logging power control errors).

So we pulled the server out after an event, and sent it for RMA. It came back saying the techs couldn't reproduce the problem. And indeed, we powered it up on the bench, and it seemed fine.

Stuck it back in the rack at the next event, and it stopped working again.

At this point I was thinking this must be some kind of electrical issue caused by mechanical stress, so we tore it apart and jiggled all the cables and made sure all the connections were tight.

No dice.

This whole thing took several years, since we could only really work on the machine during events (and I kind of live halfway across the world). It just kept on limping on with that bug since we couldn't find time to dive deep into the issue.

At one point I started thinking... What's the difference between the server being in the rack and not? That all the cables are plugged in, particularly USB and Ethernet cables.

Could it be Wake-on-LAN? So I checked the WoL settings, but it was indeed switched off on all the Ethernet interfaces. And besides, we had two identical servers and only one had the issue. I sniffed the network looking for stuff that might pass as a WoL magic packet, but came up empty.

Still, I couldn't find another explanation, so I did the logical test. Unplugged the Ethernet cables, and tested it. It worked fine. Plugged the cables in. The problem reappeared.

Oooookay.

In particular, it was the 4 cables connected to the add-on PCIe network card.

So I swapped the cards on both servers and guess which other server started having buggy shutdowns!

Just in case, I tried upgrading the firmware on the card, but that didn't help.

At this point I'm starting to think about RMAing the card, but that would take time and it'd be hard to explain what the problem is. Buying another card would be an extra expense, and cause us to have different configurations on both servers (which is less desirable).

And then I thought... I'm never going to use this feature, ever. These are servers with BMCs, we can turn them on over IPMI. So this Ethernet card is sending broken/random wake signals to the PCIe slot when it has an Ethernet link? Okay.

I asked for some tape and scissors, pulled the server out again, took the card out, carefully cut out a small sliver of tape, and placed it over the WAKE# pin on the PCIe edge connector. Put it all back together and tested it again.

Problem fixed.

I just realized that one of the things that bugs me is people equating stereotypical Linux problems on Asahi with other platforms, because it's not the same, because we actually care.

Suspend not working, audio not working, display tearing issues, power management being bad... all those things are Linux on $random_platform support memes. And they're memes because they never get fixed, because nobody cares. Acer isn't fixing their ACPI to make suspend not break for you. Nobody is spending time getting your speakers on your OEM laptop sounding good. Intel sure aren't fixing their Linux drivers to not tear on my Ivy Bridge laptop. And good luck getting anyone to even think about debugging why your NVMe drive stays warm in suspend and kills battery life.

Yes, you're going to run into similar things in Asahi today, but the difference is we care. And we're going to fix them. And since we control all the drivers and the pre-Linux bootloaders and everything is open source and we know things can be made to work at least as well as macOS, we can fix them.

For those wondering why the hell we need all this safety system stuff for the speakers: because the speakers sound nice and loud and crisp, but only if you drive them well past the max "always safe" volume level. With current kernel settings, that level is at -14dBFS on the 14" M1 Pro MBP. That means that while your system will work without speakersafetyd (once this is all tested and enabled), the speakers will be much quieter.

This is especially true for the tweeters. You can hear that in the stream where I played I Won The Loudness War: during the dubstep parts of the song, the snares sound nice and crisp. At those points, the tweeters are probably putting out 2-4x the amount of power they could handle without melting - briefly. But then when the nasty clipped lead comes in, that overloads them a lot more and the safety daemon clamps down on the tweeter volume. After that part, you can hear them recover over a few seconds and the snares gradually come back.

Most music does not have ridiculous clipped leads like that song, but it very often does have loud snares and cymbals, and other high-frequency transients. Additionally, the tweeters are high-passed in hardware at 800 Hz, and most music does not have that much energy in the high end to begin with relative to the bass, but could. So if you want to set the overall max volume to a safe level, you have to assume the input is a 4000 Hz square wave or something ridiculous like that. And that's how you get that -14dBFS "dumb" level limit, which makes the speakers sound a lot quieter and worse, even though the vast majority of music played at 100% would never come close to needing that much reduction to be safe.

With a dynamic temperature/power limit model for the speakers, you can squeeze out a lot more of that headroom and still remain safe. And that gives you nice and punchy music without requiring harsh limiters or low volume caps to keep the speakers from melting.

And this is one reason why Mac speakers sound better and louder than most. Because most manufacturers don't bother to do this.

LRT: I think this really illustrates just how dumb present AI systems are. They aren't reasoning or "thinking"; what they're doing is just learning to imitate the behavior they're trained on. They can produce outputs that look novel, but in the end it all boils down to a combination of the inputs they were trained on.

Effectively, AIs like Stable Diffusion and ChatGPT know how to extrapolate and interpolate from their training data. Sure, it looks cool, and it feels intelligent because they're riffing off of a corpus of material produced by actually intelligent humans. But give them a problem they haven't seen before, or for which the obvious "extrapolated" solution is just hilariously and obviously wrong, and they'll show you just how dumb they are. They also have no concept of logic or facts, so there is no expectation of accuracy - an AI won't tell you it doesn't know how to do something, it'll just make up some BS.

Another way to put it is that AI models are just fancy generalized (very) lossily compressed versions of their training inputs. Think about that next time the copyright implications of AI come up again.

Hi (some) kernel folks: please stop trying to convince me (and the rest of the world) that email patches are better.

They aren't, and the rest of the world knows that already. We're tired, and countless people have been driven away from contributing thanks to this utterly broken process.

Before you manage to drive *me* and all my contributors away, I *will* start pushing alternate mechanisms for trees I am involved with. If you don't like it, tough luck. Complain to Linus, and make sure he knows if he kicks me out his shiny M2 MacBook no longer gets upstream support.

Did you know Asahi Linux is introducing support for some brand new Apple Silicon features faster than macOS?

The M1 has a virtual GIC interrupt controller for enhanced virtualization performance. Linux supports it, macOS does not.The M2 introduced Nested Virtualization support. The patches for supporting that on Linux are in review; macOS still doesn't support it.The M2 introduced BTI, a hardware security mitigation. Fedora Asahi ships with it enabled, macOS does not. I'm also going to be working on adding that to Apple's WebKit/JavaScriptCore soon, because it's still missing (which breaks it on Fedora).

Updated my M1 Pro die map a bit based on what we know these days.

AVE = Apple Video Encoder
APR = Apple ProRes
ATC = Apple Type C
ANE = Apple Neural Engine
APCIE = Apple PCIe
AMCC = Apple Memory Cache Controller (SLC)
DCS = DRAM Command Scheduler? (LPDDR5 channel PHY/backend)
LPDP = Low Power DisplayPort
MIPI CSI = MIPI Camera Serial Interface
MIPI DSI = MIPI Display Serial Interface
DISP = Embedded display controller
DISP EXT = External display controller
mGPU = GPU cluster (Cores, Tile Accelerator, MMU, pixel load/store stuff, etc.)