Fixes

What it changes

Corrects the built-in panel's clock in radeon's in-memory copy of the video BIOS's panel table: the BIOS says 108 MHz, the panel's EDID 138.5 MHz. Without it, the screen splits into distorted parts unless the Mac boots with nomodeset. It never writes the ROM. OmaBoot? Live also boots this Mac with radeon.dpm=0 radeon.pcie_gen2=0 radeon.uvd=0, as the install fix does: with radeon's defaults the GPU locks up under load.

How it works

The patched radeon checks everything before it changes anything: the GPU must be 1002:9488 with subsystem 106b:00b6, the panel 1920×1080 with an EDID that says 138.5 MHz, and the video BIOS's panel table a version 1.2 table that says 108 MHz. Only then does it correct the clock in its in-memory copy of the table and set the panel's colour format (RGB888, FPDI), keeping the table's dual-link, dithering and spread-spectrum settings.

The boot menu adds radeon.dpm=0 radeon.pcie_gen2=0 radeon.uvd=0 when the Mac's model is iMac10,1. They're harmless on the iMac10,1 with the GeForce 9400M, which doesn't use radeon.

What it changes

Fixes an oops while applesmc starts on Macs whose SMC has a keyboard-backlight key: t2linux patch 3001 takes the SMC's data from the backlight's LED device, which doesn't hold it. A one-line container_of fix. With it, fans, the light sensor and the keyboard backlight work in a live boot.

How it works

t2linux's applesmc patches add keyboard-backlight support. Patch 3001's brightness function takes the SMC's data from the LED device, which holds the LED, not the SMC. Registering the LED sets its brightness straight away, so applesmc writes through a bad pointer before it has finished starting. The fix takes the SMC's data with container_of, as the patch's own work function already does: one line.

With the fixed module on the image, OmaBoot? Live drops the official live system's applesmc blacklist, so applesmc loads as it does on an installed Omarchy.

What it changes

Arms the lid's wake only for a sleep that starts with the lid closed. On these Macs the lid's wake is a bit in the embedded controller, set before every sleep, so a sleep that starts with the lid open (Suspend from the menu, an idle suspend) is woken by the lid a few seconds in. A small systemd-sleep hook turns the lid's wake off in /proc/acpi/wakeup for such a sleep and back on after it; a sleep from closing the lid still wakes when it opens. OmaBoot? Live's sleep test naps once with the stock setting and, if the lid woke it, once more with the fix.

How it works

The lid's ACPI wake method (_PSW) sets a wake-on-lid-open bit in the embedded controller, and Linux calls it before every sleep. With the lid already open, the controller wakes the Mac almost at once.

A small systemd-sleep hook, omaboot-lid-wake, runs before and after every sleep on a Mac. Before a sleep that starts with the lid open, it turns the lid's wake off in /proc/acpi/wakeup, and after the sleep it turns it back on. A sleep that starts with closing the lid is left alone, so opening the lid still wakes the Mac.

What it changes

Keeps the Thunderbolt 3 chip's USB controller awake while OmaBoot? Live's USB-C test runs. On a Mac, Linux doesn't take the PCIe wake signal (PME) that powers the idle controller back up, so a USB 3 device plugged into a USB-C port is never seen; USB 2 devices are, through the Mac's main USB controller. When the test has waited 15 seconds with nothing seen while the controller sleeps, it turns the controller's runtime power management off (power/control on) and puts it back after the test. On an installed system, the kernel option pcie_ports=native does the same.

How it works

On these Macs, the USB 3 lines of the USB-C ports run to a USB controller inside the Thunderbolt 3 chip, and their USB 2 lines to the Mac's main controller. When nothing is plugged in, Linux powers the Thunderbolt 3 controller down.

Plugging a device in raises a PCIe wake signal (PME), which should power the controller back up. On a Mac, Linux skips the firmware handshake (_OSC) that would hand it that signal and takes every PCIe service but this one, so nothing answers the signal and the device waits unseen.

The USB-C test checks the controller's power state. When it has slept through 15 quiet seconds, the test sets the controller's power/control to on, which wakes it, and a device already in a port shows up within a second. When the test ends, the setting goes back to what it was.