Jake Wharton @jw@jakewharton.com

Google Rust crate audits are now open source: https://opensource.googleblog.com/2023/05/open-sourcing-our-rust-crate-audits.html

🦀👀🥳

Web developers: when you say, “your browser does not support this site,” what you REALLY mean is that YOU don’t support the browser. Don’t turn it around on the user because you chose not to stick to well-supported standards, or worse, are doing user agent sniffing.

If you truly use some feature shipped by one browser and not everyone, at least say, “We use x standard feature, which is unsupported in this browser.” But even then, the web is all about progressive enhancement.

#WebDevelopment

🔥 Introducing telephoto, a compose library for displaying zoomable images with automatic sub‑sampling of large bitmaps: https://saket.github.io/telephoto/

A bit of (simplified) X history and how we got here.

Back in the 90s and 2000s, X was running display drivers directly in userspace. That was a terrible idea, and made interop between X and the TTY layer a nightmare. It also meant you needed to write X drivers for everything. And it meant X had to run as root. And that if X crashed it had a high chance of making your whole machine unusable.

Then along came KMS, and moved modesetting into the kernel. Along with a common API, that obsoleted the need for GPU-specific drivers to display stuff. But X kept on using GPU-specific drivers. Why? Because X relies on 2D acceleration, a concept that doesn't even exist any more in modern hardware, so it still needed GPU-specific drivers to implement that.

The X developers of course realized that modern hardware couldn't do 2D any more, so along came Glamor, which implements X's three decades of 2D acceleration APIs on top of OpenGL. Now you could run X on any modern GPU with 3D drivers.

And so finally we could run X without any GPU-specific drivers, but since X still wants there to be "a driver", along came xf86-video-modesetting, which was supposed to be the future. It was intended to work on any modern GPU with Mesa/KMS drivers.

That was in 2015. And here's the problem: X was already dying by then. Modesetting sucked. Intel deprecated their GPU-specific DDX driver and it started bitrotting, but modesetting couldn't even handle tear-free output until earlier this year (2023, 8 whole years later). Just ask any Intel user of the Ivy Bridge/Haswell era what a mess it all is. Meanwhile Nvidia and AMD kept maintaining their respective DDX drivers and largely insulating users from the slow death of core X, so people thought this was a platform/vendor thing, even though X had what was supposed to be a platform-neutral solution that just wasn't up to par.

And so when other platforms like ARM systems came around, we got stuck with modesetting. Nobody wants to write an X DDX. Nobody even knows how outside of people who have done it in the past, and those people are burned out. So X will *always* be stuck being an inferior experience if you're not AMD or Nvidia, because the core common code that's supposed to handle it all just doesn't cut it.

On top of that, ARM platforms have to deal with separate display and render devices, which is something modesetting can't handle automatically. So now we need platform-specific X config files to make it work.

And then there's us. When Apple designed the M1, they decided to put a coprocessor CPU in the display controller. And instead of running the display driver in macOS, they moved most of it to firmware. That means that from Linux's point of view, we're not running on bare metal, we're running on top of an abstraction intended for macOS' compositor. And that abstraction doesn't have stuff like vblank IRQs, or traditional cursor planes, and is quite opinionated about pixel formats and colorspaces. That all works well with modern Wayland compositors, which use KMS abstractions that are a pretty good match for this model (it's the future and every other platform is moving in this direction).

But X and its modesetting driver are stuck in the past. It tries to do ridiculous things like draw directly into the visible framebuffer instead of a back buffer, or expect there to be a "vblank IRQ" even though you don't need one any more. It implements a software fallback for when there is no hardware cursor plane, but the code is broken and it flickers. And so on. These are all problems, legacy nonsense, and bugs that are part of core X. They just happen to hurt smaller platforms more, and they particularly hurt us.

That's not even getting into fundamental issues with the core X protocol, like how it can't see the Fn key on Macs because Macs have software Fn keys and that keycode is too large in the evdev keycode table, or how it only has 8 modifiers that are all in use today, and we need one more for Fn. Those things can't be properly fixed without breaking the X11 protocol and clients.

So no, X will never work properly on Asahi. Because it's buggy, it has been buggy for over 8 years, nobody has fixed it in that time, and certainly nobody is going to go fix it now. The attempt at having a vendor-neutral driver was too little too late, and by then momentum was already switching to Wayland. Had continued X development lasted long enough to get modesetting up to par 8 years ago, the story with Asahi today would be different. But it didn't, and now here we are, and there is nothing left to be done.

So please, use Wayland on Asahi. You only get a pass on using X if you need accessibility features that aren't in Wayland yet.

In our first episode back to talking #AndroidDev shop on @fragmented we chat with my good friend and (ex)colleague @colin who helps us make sense of Square’s bold take on Compose!

https://fragmentedpodcast.com/episodes/245-treehouse-redwood-and-zipline-with-colin-white/

Wild: “In January 2022, the system leaked 14% of all its gas into the atmosphere – the highest leak rate ever recorded by the utility in a month. In the past four years, the system leaked between 4 and 6% of its total supply each year, according to city data.”

https://richmond.com/news/local/climate-richmond-gas-methane-leaks/article_3e47a766-f0c8-11ed-8262-236e52f13eac.html#tracking-source=home-the-latest

Back when Danger was in stealth mode, pre-launch, the website just showed a random teaser flash animation. I found the SWF files and through the magic of WASM and something called Ruffle (ruffle.rs), you can now experience these in all their rotoscoped glory!

http://frotz.net/hiptop/danger-animations/

#danger #animation #hiptop

Updates on Android Performance at I/O:
https://medium.com/androiddevelopers/whats-new-in-android-performance-google-i-o-2023-edition-21a1832c9fa3

Introducing dex layout optimizations with startup profiles, and the new Baseline Profiles Gradle plugin that automates your baseline profile workflows end to end.

Kier and I's "Modern Compose Architecture with Circuit" talk from #KotlinConf is finally up!

Video: https://youtu.be/ZIr_uuN8FEw

Slides: https://speakerdeck.com/zacsweers/modern-compose-architecture-with-circuit

Bluesky: Brought to you by the same guy who said he trusted elon musk as the singular solution to extend the light of consciousness.