A wired VR headset can run directly from an M1 MacBook Air. The setup here uses an HP Reverb G1, a powered USB hub, an ordinary USB-C-to-DisplayPort adapter, and a native Swift/Metal application. The Mac drives the headset’s display and talks to its USB devices itself.

This provides a general approach to wired VR on Apple silicon: get the Mac’s display pipeline to send a usable signal, handle the headset’s USB protocol, and render the two eye views. The Reverb G1 is the working implementation described here.

The source repository includes both demonstrations: native macOS desktop output and a rotating cube rendered in stereo at 4320×2160, targeting 90 Hz.

Running the demo

The tested machine is an M1 MacBook Air running macOS 15.6.1 (24G90), with Swift 6.1.2 from Apple’s Command Line Tools. The headset is an HP Reverb G1 (VR1000-2xxx). Its USB lead connects through a powered Anker hub. Its DisplayPort lead connects through a Cable Matters USB-C-to-DisplayPort adapter, model 201086, in the Mac’s other USB-C port.

System configuration

Disable System Integrity Protection (SIP): shut down the Mac, hold the power button until startup options appear, choose Options, and continue into Recovery. Authenticate as an administrator when prompted. Open Utilities → Terminal, run the following, follow its prompts, and restart:

csrutil disable

Back in macOS, check SIP and read the current boot arguments:

csrutil status
nvram boot-args

The configuration needs two boot arguments:

• hdcp-fuse-mask=0 disables HDCP on the display connection. This is the fix for the headset’s repeated blanking.
• amfi_get_out_of_my_way=1 allows the ad-hoc entitled helper used for connection recovery. It does not fix HDCP.

Set both, retaining any other boot arguments needed by the machine:

sudo nvram boot-args="amfi_get_out_of_my_way=1 hdcp-fuse-mask=0"
nvram boot-args

boot-args is one string: writing it replaces the previous value. Restart, then verify:

sysctl -n kern.bootargs

It should include both flags. As a one-time check before connecting the headset:

ioreg -l -w0 | grep '"HDCPTXCapabilities"'

The Protocols list should be empty: {"Protocols"=()}, rather than (1,2). The separate HDCPCapabilityMask field can remain 2 or 3.

SIP and AMFI changes reduce system protections. Disabling HDCP affects protected video playback on external displays. To undo the HDCP change, remove only hdcp-fuse-mask=0 from the boot-argument string and restart.

Clone and build

Install Apple’s Command Line Tools if needed, then clone the source and build:

xcode-select --install
git clone https://umhau.org/code/reverb-m1.git
cd reverb-m1
zsh tools/build.sh

The build produces the stereo application, recovery helper, USB wake tool, and passive display observer in .build/debug.

Connect the headset’s USB lead through the powered hub, and its DisplayPort lead through the adapter on the other USB-C port. If macOS asks Allow accessory to connect?, choose Allow. Until permission is granted, HID calls fail with 0xe00002cd (kIOReturnNotOpen).

Native macOS desktop output

Run the wake tool and leave it running:

.build/debug/hmdwake

In System Settings → Displays, select the headset and choose an extended display or mirroring. Windows placed on that display appear inside the headset.

macOS sends one desktop image across the entire display surface. It does not duplicate the desktop for each eye or apply lens correction. The stereo demo below supplies those operations for its own scene.

A passive observer can run in another terminal:

.build/debug/displaywatch

It reports display connections and pixel modes through CoreGraphics without capturing screen pixels. The wake tool itself does not run automatic connection recovery.

Stop hmdwake with Ctrl-C before starting the stereo application. Both programs use the headset’s HID devices and must not run together.

Stereo 3D demo

.build/debug/VRWorkstation --run-seconds 600

Omit --run-seconds to run indefinitely. The scene contains a rotating colored cube, a floor grid, and reference objects at several depths. Each eye gets a separate rendered view with factory lens correction. The viewpoint stays fixed as the headset moves.

The Headset optics window on the Mac provides scene and grid patterns, color-correction controls, and Quit. The factory setting is 100% for each color control; the reset button restores it. Adjustments save automatically to ~/Library/Application Support/ReverbM1Demo/optics-adjustments.json.

On first launch, the application reads the headset’s factory calibration over USB before enabling the rendering session. It validates and caches the result at ~/Library/Application Support/ReverbM1Demo/factory.json. Later launches reuse the validated file. To select another calibration:

.build/debug/VRWorkstation --calibration /path/to/factory.json

Invalid calibration stops startup. Each eye renders with its asymmetric field of view to a 3024×3024 target. A final Metal pass applies Polynomial-3K lens correction separately to red, green, and blue, producing the native 4320×2160 output at 90 Hz. Eye spacing is 63 mm. The floor uses a filtered procedural grid to avoid unstable subpixel lines at distance.

For a stationary angular grid, use --optics-grid. For an image rendered through the same correction without opening the headset, use --snapshot /tmp/calibrated.png.

The USB activation sequence, configuration-store decoding, and optical model are based on Monado’s Windows Mixed Reality driver.

Why the display went dark

Before the boot-argument fix, the Mac detected the Reverb as a 4320×2160 display. The headset would turn its panels on, turn them off about 300 ms later, drop the DisplayPort link, and retry roughly every eight seconds.

Power, the hub, refresh rate, resolution, color depth, the proximity sensor, and activation commands were plausible causes. The same headset and hub worked on Linux. macOS already sent 8-bit RGB, and the headset blanked even when no HID commands were sent.

The difference was encryption. A couple of seconds after hotplug, macOS’s display coprocessor started HDCP 2.x encryption on the external DisplayPort link. The headset could not handle it. The Linux setup did not enable that encryption.

Finding the HDCP switch

The search started with the Mac’s own arm64 kernelcache, under:

/System/Volumes/Preboot/<uuid>/boot/<hash>/System/Library/Caches/com.apple.kernelcaches/kernelcache

After extraction and decompression with pyimg4 img4 extract and pyimg4 im4p extract, HDCP strings provided entry points into the disassembly. Capstone and an ADRP/ADD cross-reference scanner connected those strings to code.

Two consumers of hdcp-fuse-mask explained the behavior:

• AppleDCPDPTXProxy calls PE_parse_boot_argn("hdcp-fuse-mask", &mask, 4). Its default is the hardware fuse value masked with 3. Apple’s own “HDCP suppressed per disable-av-content-protection” path sets that mask to zero.
• AppleSEPHDCPManager parses the same argument and replaces each HDCP channel’s protocol bits before passing them to the Secure Enclave:

caps = (caps & ~0x18) | ((mask & 3) << 3);

The external display coprocessor, dcpext, owns HDCP channels 5 and 6. A zero mask leaves the transmitter advertising no HDCP protocols. After rebooting with hdcp-fuse-mask=0, the protocol list became empty and the macOS desktop stayed visible inside the headset. First light was on October 20, 2026.

Activating the headset

With encryption disabled, the headset still needs its USB wake sequence. The wake tool sends:

• To the QHMD control device, 03f0:0c6a: four feature-report sets of [0x50, 0x01], each followed by a get of 0x50; gets of 0x09, 0x08, and 0x06; then [0x04, 0x01] to turn the screen on.
• To the HoloLens Sensors device, 045e:0659: output report [0x02, 0x07], zero-padded to 64 bytes, to enable the IMU.

Within about 1.5 seconds, the DisplayPort link trains at HBR3, 8.1 Gbps across four lanes, and macOS adds the display. The application keeps its IOHIDManager objects alive: releasing a manager closes its devices.

The headset’s 0x05 status report is useful but does not measure presentation rate reliably. Byte 5 varied even while video was visibly running. The native display mode and actual Metal presentation counts provide the relevant measurements.

Recovering a dropped connection

Disabling HDCP made the display usable. Recovering a lost DisplayPort connection required understanding the Mac’s USB-C controller interface.

Some connection losses healed by themselves. Others left the adapter stuck, and another HID screen-on command did not restore the display. The target was a software reset of the adapter’s data path that would retrain DisplayPort without unplugging the cable.

Locating the controller interface

The reverse-engineering target was the decompressed arm64e fileset kernelcache from macOS 15.6.1 (24G90). Addresses below refer to that build. Chained pointers decode with:

BASE = 0xfffffe0007004000
pointer = BASE + (raw & 0xffffffff)

The relevant executable ranges were:

AppleHPM talks to the USB-C “Ace” controller, in the TI CD3217 / TPS6598x family. Its AppleHPMLib.plugin exposes register reads, writes, commands, and vendor-defined messages.

The registry node used to identify the port is not the node on which to open the plugin. In the tested layout, AppleHPMDevice with RID 1 has child Port-USB-C@2. Open the plugin on its AppleHPMARMI2C parent. Trying IOCreatePlugInInterfaceForService on the device node returned 0xe00002c7; the plugin’s personality expects IOProviderClass = AppleHPM, which the parent satisfies.

Decoding user-client access

An initial reading of AppleHPMUserClient::initWithTask suggested that both root and an entitlement were required. Following the branches showed an OR condition instead:

AppleHPMUserClient::initWithTask @ 0xfffffe0009b49570

rootResult = IOUserClient::clientHasPrivilege(token, "root")
entitlement = copyClientEntitlement(task, "com.apple.USBCEntitlement")

allow = (rootResult == 0) || (entitlement == kOSBooleanTrue)

The deciding branches are at 0x9b49614, 0x9b4961c, 0x9b49620, and 0x9b49624. Hardware testing agreed: an unsigned non-root process failed, while a non-root process signed with com.apple.USBCEntitlement=true could read the controller. With AMFI disabled, an ad-hoc signature can carry that entitlement.

This permits a small entitled helper while the rendering application runs as an ordinary user.

Mapping the external methods

The dispatch at 0xfffffe0009b497dc uses a getTargetAndMethodForIndex-style switch rather than an IOExternalMethodDispatch array. A shared argument checker at user-client vtable +0x990 (0xfffffe0009b49b10) returns 0xe00002c2, kIOReturnBadArgument, for count mismatches.

The useful command paths are:

• iecsWrite, selector 1: scalar inputs [route, register, length, userBufferPointer, flags]. Length is limited to 64 bytes. This exposes the controller’s raw host interface.
• iecsCommand, selector 2: scalar inputs [route, command, flags]. The handler validates three scalar inputs and calls provider+0x8f0(route, command, flags, 5).
• sendVDM, selector 3: scalar inputs [route, SOPtype, length, userBufferPointer, flags]. It copies the message buffer and forwards it to provider+0x990.
• forceMode, selector 6, and forceUpdateMode, selector 7: entry points into controller mode logic.

Selector 2 has no command allowlist in the user-client handler. That mattered because early command attempts returned 0xe00002c6, kIOReturnBadMessageID. The error needed to be traced farther down the path.

Finding a reset command

The driver’s own AppleHPMInterface::exitPDMode, at 0xfffffe0009b5bc44, supplied the strongest lead. It reads “Exit PD Mode TX Identity” and “Exit PD Mode DRST Data” properties, then invokes the controller command executor with DRST:

provider+0xb10(this, reg=8, &DRST, drstData[0x40], length=0x40)

The raw host interface uses register 0x08 for CMD1 and 0x09 for DATA1. A command with payload writes DATA1 first, then the four command bytes to CMD1. The controller clears CMD1 when finished; DATA1 contains the task result.

Other candidates appeared in the disassembly:

The driver also sends VDMs through AppleHPMInterface at 0xfffffe0009b5d7bc. Its internal DATA1 payload contains [u32 VDM header][u8 SOP type][VDOs…]. DisplayPort uses SVID 0xFF01, with command 6 for Status Update, 5 for Exit Mode, 4 for Enter Mode, and 7 for Configure. These were useful leads, but the accepted DRST command made further VDM experiments unnecessary.

The byte-order trap

Early DRST attempts failed because constants copied from driver-internal code were wrong for the user-client boundary.

Inside the driver, 0x54535244 stored as a little-endian integer produces the bytes DRST. Selector 2 expects the opposite integer representation: 0x44525354. Its provider byte-swaps the input before writing CMD1.

The provider mapping was confirmed by a chained-pointer vtable scan, including the matching PAC discriminator 0x191d.

For selector 2, the command values are:

DRST = 0x44525354
HRST = 0x48525354
Gaid = 0x47616964

Sending 0x54535244 through that path puts TSRD on the wire. The controller rejects it as an unknown command. Correcting the encoding made DRST return success in about 50 ms.

Tracing the return codes

The provider first reads CMD1 and can clear an outstanding command. It writes the byte-swapped input, then normally polls CMD1 every 100 microseconds. With flags bit 0 clear, the limit is 1,000 attempts; setting that bit raises it to 100,000. Flags bit 1 selects a fire-and-forget path. The recovery helper uses flags zero.

This located the earlier BadMessageID error: the provider translates the firmware’s !CMD response into it. With correct encoding, HRST still returned that error; DRST did not.

In the successful recovery test, the display was stuck after an induced screen-off event. Calling iecsCommand(route=0, command=0x44525354, flags=0) on RID 1 returned zero in 50 ms, with CMD1 zero and DATA1 byte 0 zero. CoreGraphics added the 4320×2160 display about 2.209 seconds later. No physical replug was needed.

Why the other display interfaces were insufficient

IOAccessoryManager contains the OS-side DisplayPort transport logic. IOPortTransportStateDisplayPort exposes setHPDState at 0xabe5adc, triggerHPDIRQ at 0xabe5f98, and pin-assignment controls. These change or propagate the state seen by the display pipeline. They do not by themselves make the USB-C controller renegotiate alternate mode with the adapter.

The controller drives this state through AppleHPM’s communicateDPHPDChange. Its sendDpStatusUpdates at 0xfffffe0009b58490 extracts HPD from bit 15 of the cached DP status word and propagates changes to the transport.

Other examined interfaces included IOPortTransportUserClient, gated by com.apple.iokit.IOPort.user-access, and IOPortFeatureLDCMUserClient, gated by com.apple.iokit.IOPortFeature.LDCM. Accessory-ID bus reset methods reset a different bus. None supplied the working USB-C alternate-mode recovery path.

AppleHPM’s diagnostic boot arguments—such as hpmI2CRetries, hpmI2CRetryInterval, and hpmlog—also did not provide a DisplayPort reset switch. The working route was the controller command interface.

The working recovery implementation

The application uses a small signed hpmctl helper. Before resetting anything, it finds RID 1 and verifies the Port-USB-C@2 child, then opens the plugin on the parent. In the tested wiring, that is the DisplayPort adapter’s port. RID 0 carries the hub, headset USB, and Mac power; the helper refuses to reset it. Port identity must be verified before adapting the helper to another layout.

On display loss, the application allows a two-second grace period for spontaneous recovery. If the display remains absent, the helper sends DRST with route zero and flags zero. The application imposes a three-second helper timeout and a limit of three resets per minute. A display-add event cancels a pending reset.

The helper checks both IOReturn and DATA1’s task result. DATA1 0x04 has occurred after an accepted reset that nevertheless restored the display, so the application’s decisive evidence is the display returning, rather than the helper exit status alone.

Keeping recovery off the main thread

During display reconfiguration, macOS’s SkyLight code could block the main thread for about ten seconds in SLSWaitThroughReconfigurationCycleForcingNotificationHandling. Recovery queued on that thread waited with it.

The implementation separates the work:

• AppKit manages windows and display arrangement on the main thread.
• A dedicated rendering thread runs CAMetalDisplayLink and presents frames using its supplied drawable.
• A separate serial recovery queue receives CoreGraphics display events before main-thread work is scheduled.

Moving recovery to that queue reduced measured forced-outage duration from about 14.4 seconds to about 4.4 seconds: the two-second grace period plus roughly 2.2 seconds for reset, retraining, and display addition. A brief lane-sync retrain could follow the reset and was handled automatically.

The renderer uses a non-activating borderless panel at native 4320×2160, 90 Hz, without exclusive display capture. It restores the mode if macOS changes it. Mode checks use CoreGraphics; recovery does not repeatedly enumerate IOPortTransportStateDisplayPort registry properties.

Checking the result

Every ten seconds, the application logs submitted and presented frames, skipped frames, presentation rate, presentation age, GPU time, GPU errors, and IMU sample count. Presented frames count Metal callbacks with actual presentation timestamps. A healthy settled line looks like:

fps=90.00 presentAge=0.01s GPUerrors=0

A recorded native-resolution soak ran for 649.965 settled seconds with 58,496 presented frames: 89.9987 fps, zero GPU errors, and zero DP resets. There was a 0.637-second self-heal during startup, followed by no drops. The repository contains the measurements in evidence/verified-90hz-soak.json and its accompanying log. A separate calibrated-rendering trial sustained 89.996 presented fps over its settled interval with no display drops or GPU errors.

Offline calibration and recovery checks run with:

zsh tools/check.sh

Those checks exercise the calibration model and recovery logic. The desktop-output and stereo commands above provide the hardware demonstrations.

Co-authored with AI assistance from GPT-6.1 Sol low.