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.
I’ve recently changed the default shell /bin/sh on my Leopard install to dash from bash. Why would I do this? Well, by bash’s own admission (see BUGS in its manpage), bash is “too big and too slow”. dash is used for /bin/sh by default on Ubuntu nowadays, and it’s a goal for Debian (supposedly for Lenny, but I can’t see it noted in the release notes and it’s only “confirmed” in the Lenny goals). dash is significantly smaller and faster.
Ubuntu and Debian ran into plenty of bashisms when they tried to change, how about Mac OS X? So far I’ve found problems with /usr/libexec/path_helper (I just changed the shebang line to #!/bin/bash). There was also a problem with X11’s startx, and my patch was quickly committed.
Interestingly enough, when I went to move the sh binary, there are actually two versions of bash in /bin. Both report
GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)
but differ at the binary level (they aren’t even the same size). I wonder if Apple tried to optimize their /bin/sh given that it gets more usage.
I built dash-0.5.5.1 from the tarball without a problem.
XMMS2 is cool. In my experience, its architecture does everything The Right Way, and their support tools (git, mantis, mediawiki, doxygen-generated documentation) are all modern.
The clientlib is good enough that clients (frontends) can be very lightweight. FWICS there are some good Qt and GTK based clients that would probably run fine on OS X, if you can be bothered getting them and their dependencies working.
Even then, other Qt and GTK based applications I have on scud always feel slightly out of place (or very out of place for those using X11). There were no Cocoa/Application Kit based GUIs on the old clientlist. I set out to create a Cocoa UI.
I like Winamp Classic’s UI; it is functional and compact, especially in windowshade mode. If you are used to the keyboard shortcuts (and they make a lot of sense with a QWERTY keyboard), you don’t need huge buttons.
Hence I made a client with similar minimalism, without trying to be Winamp-skin-compatible. I’m quite happy to use the CLI and other clients for managing the media library, but for something that’s sitting on my desktop all the time I wanted small, and I wanted it to fit in with OS X. It’s got Growl support too!
Muxic is a minimal user interface to XMMS2. It should be ready for a release soon, meanwhile you can browse the Muxic source.