I thought it would be a good idea to add a persistent WordPress object cache to this blog, to reduce page load times and increase resilience to spikes in traffic. So I added the WordPress Memcached Object Cache drop-in (AKA wp-memcached), and enabled the legacy App Engine Memcache API. However, adding the Memcache object cache increased page load times by 10s or more! Looking into it further, while the App Engine diagnostics reported a high (90%+) cache hit ratio, the drop-in was getting 0% cache hits. The drop-in was adding keys to the cache only for them not to be found in subsequent reads. There were also hundreds of SQL queries that did not occur with WordPress’s default (request-scoped) object cache.
With some additional debugging and perusing of the source code of PECL’s official Memcached module, the App Engine SDK, and the wp-memcached code, I figured out what was going on and how to fix it.
I bought a new OLED monitor, which worked great with my Windows machine, but when I connected it to my MacBook Air and MacBook Pro via a USB-C to HDMI* adapter the colours all looked very wrong.
Blacks were tinted fuchsia, whites were tinted yellow/green, all colours look wrong, yet the macOS UI is still legible. Turns out the issue is that macOS thinks the monitor is a TV and encodes colours as YPbPr instead of RGB.
There appear to be two fixes:
For Intel macs, overriding the EDID information via a plist at /Library/Displays/Contents/Resources/Overrides/DisplayVendorID-$VENDORID/DisplayProductID-$PRODUCTID. There’s a handy patch-edid.rb script for this purpose. It works by setting the IODisplayEDID key in the plist with a base64-encoded EDID payload. While the script clobbers other potentially useful EDID information, it’s a useful starting point.
For Apple Silicon, overriding the LinkDescription in /Library/Preferences/com.apple.windowserver.displays.plist. See Force-RGB-color-on-M1-Mac for a great description of this method. I haven’t tested it though, because I only have Intel macs.
Figuring out the fix was a bit of a process for me: my first few searches suggested it could be a cable problem, but I verified the cables worked just fine with the same monitor and other computers. It also didn’t look like the typical colour aberrations when you’re just “missing” a colour channel. Then I thought it was a problem with the USB-C to HDMI adapter I was using. When I stumbled on old (2013) blog and forum posts I was initially skeptical that it was the same issue or that the workarounds would still work. But it turns out that it is a macOS bug that’s been around for 10+ years, and the old workarounds still work!
* I know DisplayPort would be better, but I want to leave the monitor’s DisplayPort socket permanently plugged into my PC.
Until I got the Iris, I’d been packing my Ergodox to work each day, which was inconvenient, and the constant plugging/unplugging was probably not great for the mini USB port either. I wanted:
portability, so I can take it on a commute or travel
fewer keys (maybe more ergonomic if I learn to use them efficiently?)
quietness, so as not to disturb co-workers
a split ortholinear layout similar to my Ergodox, so I can rely on muscle-memory between both boards
some assembly (to participate in a group custom keeb-building activity)
not egregiously expensive
Overall, the Iris did meet my goals, though it required some experimenting/modifications to the hardware and firmware to do so. This review discusses these aspects, mostly in comparison to my Ergodox and similar split/ortho keyboards. It doesn’t discuss the advantages of splits, ortholinear, or <60% layouts.
The Iris keyboard kit cost about $165 USD, including shipping to Australia. Switches and keycaps were another $70 or so (you only need 56 1Us), and maybe $5 USD for the carriage bolts, for a total of $240. This is much cheaper than high-end prebuilt tented ergos: a Dygma Defy is $399, a Moonlander is $365, and an Ergodox EZ Glow is $324 USD.