Support pre-GCN AMD GPUs and BCM4321 wireless

[alkevintan]

Three hardware fixes found while bringing Omarchy up on a 2007 iMac (iMac7,1 — Core 2 Duo, Radeon HD 2400 XT / RV610, BCM4321). All three affect any pre-GCN AMD machine, not just Apple hardware.

Verified on the machine itself against the stock Arch packages — hyprland 0.56.2-2, aquamarine 0.15.0-2, mesa 26.2.2. Hyprland does run on this GPU: it falls back to a GLES 3.0 context and to the legacy DRM interface, and holds 60 Hz at 1680x1050 with blur and shadows on. These three fixes are what stood between that and a clean install.

1. broadcom-wl-dkms for BCM4321

fix-bcm43xx.sh matched only 14e4:43a0 and 14e4:4331. The 2007–2008 iMacs and MacBooks ship a BCM4321 (14e4:4328, also 4329/432a), which the wl driver covers alongside the two already listed. Without it the machine installs with no wireless at all.

Folded the id checks into a single grep -qE so the list stays readable at five ids.

2. Skip vulkan-radeon on pre-GCN AMD GPUs

RADV only drives GPUs bound to amdgpu. On a radeon-driven card vulkan-radeon still installs radeon_icd.json, and enumeration then fails:

WARNING: radv_physical_device.c:2564: Device '/dev/dri/renderD128' is not using
         the AMDGPU kernel driver: Invalid argument (VK_ERROR_INCOMPATIBLE_DRIVER)
ERROR:   setup_loader_term_phys_devs: Failed to detect any valid GPUs in the current config

That stray ICD is all omarchy-hw-vulkan looks for, so it answered yes on a machine with no working Vulkan — and omarchy-voxtype-install runs voxtype setup gpu --enable off the back of that check. Not installing the ICD on hardware RADV cannot drive makes the probe honest again.

3. Hide nightlight where the GPU cannot apply a CTM

hyprsunset sends its temperature to Hyprland as a colour transform matrix over hyprland-ctm-control-v1, and aquamarine submits a CTM only on the DRM atomic path — impl/Legacy.cpp never does. On radeon, Hyprland logs:

drm: failed to set DRM_CLIENT_CAP_ATOMIC, falling back to legacy
drm: connector LVDS-1 crtc doesn't support CTM

The request is accepted and dropped, so hyprctl hyprsunset temperature 4000 returns ok, the value reads back as 4000, the shell's nightlight state flips to "on" — and the panel never changes. Screenshots taken at 6500K and 4000K were identical. It is a silent no-op rather than an error, which is the part worth fixing.

omarchy-hw-nightlight answers no only when every DRM card is on radeon, so a machine that also has an atomic-capable GPU keeps the feature. The menu drops the row, and omarchy-toggle-nightlight refuses up front rather than running its retry loop and reporting a success nobody can see.

This is the most opinionated of the three. It hides a UI element based on driver-name inference, because there is no shell-visible way to ask whether a CRTC exposes a CTM property. Happy to drop this commit and land only 1 and 2 if you would rather handle it differently.

Testing

New test files:

• test/shell.d/broadcom-wifi-test.sh — 3 assertions, including a regression guard for BCM4360/BCM4331
• test/shell.d/vulkan-hardware-test.sh — 4 assertions (radeon skips, amdgpu still installs, unbound driver skips, Intel unaffected)
• test/shell.d/nightlight-hardware-test.sh — 5 assertions, including the mixed-GPU and empty-tree cases

test/shell.d/nightlight-test.sh gains a stub for the new capability probe plus 2 assertions for the unsupported path; its existing 14 assertions still pass.

Full ./test/shell on Linux / bash 5.2: 20 failures before and after, against a clean clone of quattro (the 20 are missing magick and lua in my environment, not related to these changes). ./test/cli is unchanged.

One note for anyone running these on a Mac: install/hardware/vulkan.sh needs bash 5, since declare -A silently drops the AMD entry under the bash 3.2 that ships with macOS. The test invokes "$BASH" rather than bash for that reason.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AUboE7GBC75XXqJC1pYUSk

[greptile-apps]

Confidence Score: 3/5

[Medium risk] Adds hardware detection for older AMD GPUs and Broadcom wireless.

The PR is not ready to merge because the bar can still claim an ineffective nightlight change and upgrades can still install the unusable Vulkan ICD.

Findings

1.  Bar bypasses nightlight guard ▶
2.  Upgrades still install unusable Vulkan ▶

Summary

The PR adds BCM4321 wireless-driver selection, avoids selecting RADV for radeon-bound GPUs, and gates nightlight controls on a DRM-driver probe.

• The nightlight guard does not cover the bar indicator’s direct service action.
• Existing upgrade paths can still install the Vulkan package that the new hardware path skips.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Menu[Menu or CLI] --> Guard[Nightlight capability guard]
  Guard --> Toggle[Guarded toggle]
  Bar[Bar indicator] --> Service[QML nightlight service]
  Service --> Hyprctl[hyprctl temperature]
  Hardware[Hardware install] --> VulkanGuard[Radeon guard]
  Upgrade[Quattro upgrade or migration] --> Package[vulkan-radeon]
  VulkanGuard --> Package

Loading

_{Reviews (1) · Last reviewed commit: "Use a brcmfmac id for the Broadcom negat..."}

[greptile-apps]

Bar bypasses nightlight guard

On a radeon-only machine, this guard blocks the CLI toggle, but the bar indicator calls the QML nightlight service directly. That service still sends the temperature to Hyprland and marks nightlight as enabled. Clicking the indicator therefore reports success even though the panel does not change. The same capability check needs to cover the bar’s control path.

Knowledge Base Used: Hardware profiles and device controls

[greptile-apps]

Upgrades still install unusable Vulkan

On a radeon-only machine, this hardware pass skips vulkan-radeon, but the quattro upgrade and its hardware backfill migration still install it for any AMD display device. The skip also leaves an already-installed package in place. Those machines can therefore retain or acquire the unusable ICD, so the Vulkan probe can still report support where there is no working Vulkan device.

Knowledge Base Used: Install stages and package sets

[omarchybot]

The classification is unsettled, so this round stopped before testing anything.

Two models classify items for the queue, and they disagree on this one. Claude Opus 5.5 reads it as a hardware compatibility fix: Omarchy installs on these machines and then leaves them with no Wi-Fi, with a Vulkan probe that answers yes on a GPU RADV cannot drive, and with a nightlight toggle that reports success while doing nothing. Codex Medium reads it as an enhancement that adds support for hardware the installer never covered. Both readings fit part of the change. The BCM4321 ids are new hardware support, and the Vulkan and nightlight changes fix wrong behaviour on hardware Omarchy already installs on. An item gets no class label until the two agree, so I removed bug and compatibility. It is waiting on the maintainer to say which class it is.

Nothing ran on a worker this round. Here is what was read against quattro at 8e7f294:

• Greptile's bar indicator finding is correct, within limits. The indicator stays hidden unless night light is on or alwaysShow is set. When it is visible, clicking it calls the shell's nightlight service (shell/plugins/services/nightlight/Service.qml) directly, without going through omarchy-hw-nightlight. The service sends the temperature, reads 4000 back, and shows night light as on while the panel stays the same. That already happens without this pull request, so it is not a regression. How the shell should present a feature the GPU cannot apply is a design decision for the maintainer.
• Greptile's upgrade finding is correct. bin/omarchy-upgrade-to-quattro:784 and migrations/1784401744.sh:21 still add vulkan-radeon for any AMD display device. A radeon machine upgrading from 3.x therefore gets the stray ICD that this change keeps off fresh installs, and nothing removes one that is already installed. Extending the guard to those paths, and deciding whether to uninstall a package, is a scope question for the maintainer. Stop mistaking the T2 chip for an Apple GPU in Vulkan detection #13728 rewrites the same detection in all three places and Detect BCM43xx, T2, Vulkan, and NVIDIA via sysfs helpers #12076 moves install/hardware/vulkan.sh to sysfs, so whichever lands second will need reconciling.
• Codex Medium found one gap in the previous round. At install/hardware/vulkan.sh:35, an unbound AMD GPU next to a radeon one still skips vulkan-radeon. The comment above it keeps the package for an unbound GPU on its own, because that GPU may be on amdgpu after boot, and the same reasoning applies here. The fix is to skip only when every AMD display device is on radeon. It has not been pushed, because nothing has been run against it.

omabot added three commits to this branch in earlier rounds:

• 38f95ed merges quattro in.
• 93a0fdb keeps vulkan-radeon when the installer's AMD GPU has no driver bound. That happens when the installer boots with nomodeset, and it says nothing about the installed system.
• 8e7f294 changes the Broadcom test's negative case to 14e4:43a3 (BCM4350, which uses brcmfmac). The previous id, 14e4:4353, is a BCM43224, which wl does drive.

Whatever class it gets, the GPU and Wi-Fi behaviour can only be confirmed on real hardware. A worker VM has neither a radeon GPU nor a BCM4321, so a stubbed sysfs tree would only show that the detection does what it says. #10910 and #13532 also edit install/hardware/fix-bcm43xx.sh.

[jandrusk]

Useful for pre-GCN + BCM4321 machines. Needs a rebase (CONFLICTING), and it pairs with the docs in #10942 — keeping the supported-model claims aligned between the two would help. Related Wi-Fi install work: #11311.