watchthelight labs

xe: 2026-11-11 to 2026-11-13

Read from GitHub only. Nothing below is reproduced on our machine.

  • A user of our XeGfx stack on an Arrow Lake-H laptop relaxed the hardware cursor guard, and we have the same hard-coded check. The ThinkPad E16 repo (Core Ultra 7 255H, Arc 140T 8086:7D51) shipped "XeGfxIntelFB 0.9.5" because 0.9.4 refused the cursor plane with "display not as the GOP left it": the check wants the firmware framebuffer at exactly 0xff000000, and this laptop's firmware puts it at 0xff600000, so WindowServer drew a software pointer and recomposited around it. The change accepts any firmware block that ends below the cursor pages (E16 diff). The same literal test is in our intelfb.cpp. It matters because firmware framebuffer addresses differ per machine (our Meteor Lake report #13 has the boot framebuffer at 0xFE800000). Their fix is only reported as built; the commit does not show the pointer then sitting on its own plane. Confidence: High that the guard exists and differs, Low that the new guard is safe on every machine.
  • The same E16 user ran WTLLegionCpuPower with only the HWP part, next to XeGfx, right after our caution. cpu-perf.sh enables the plugin and adds -legioncpunofan -legioncpunopl -legioncpunosched, so only per-core HWP requests and EPP are on (K15 commit, script). The next commit's tune script prints debug.legioncpu.status (K16). That is the configuration we suspect for our rendezvous panics (I-116), on a second Arrow Lake machine. No result, panic or clock reading is published in the window, so it tells us nothing yet. Confidence: High that it was set up, Unverified for any outcome.
  • The same user also tried a different Metal-on-Vulkan front end on our ANV. K14 builds the metal2vulkan runtime with another project's bridge patches and times a desktop-like scene against the NullMoth Metal driver (phase 1, phase 2a). Scripts only, no numbers yet. Worth rechecking when results appear. Confidence: Low.
  • New project: yusufklncc/intel-gpu-macos-driver, the same architecture as ours, reported working on an Arc B580. It is a Linux-xe-style kernel driver, Mesa ANV and Metal on Vulkan, with the NullMoth plugin, and claims a GPU-composited desktop on macOS 26.7.1, VRR and video decode (README). Its own platform table lists Meteor Lake and Arrow Lake as "not yet", with descriptors only (PLATFORMS.md). Original code is MIT; NullMoth-derived parts are PolyForm Noncommercial (NOTICE). The README says it was written with an AI model; the benchmark and conformance numbers are the author's own. Confidence: Medium that it exists and is related, Low on the performance claims.
  • Its HybridPM plugin documents a CPU clock problem close to the 255H "stuck near 550 MHz" report, but leaves Arrow Lake alone. It hooks the XCPM routine that writes IA32_HWP_REQUEST and converts ratio units on Alder and Raptor Lake hybrid parts, and says Core Ultra (Meteor, Arrow, Lunar, Panther Lake) uses other units and is skipped (HybridPM README). In the source I saw _mp_rendezvous_no_intrs used for turning off energy-efficient turbo and for status sampling, not a once-a-second loop (HybridPM.cpp), but I did not read every call site. It credits the unit finding to the NootedGreen XE-PM work (XPS13Plus repo). Confidence: Medium.
  • A Panther Lake user is running a fork of our stack and is stuck at stage 4 in the xe memory managers. Over 2026-11-13 the repo shows a persistent step trace read back from NVRAM on Windows, then checkpoints around the stolen-memory manager, the TTM and buddy VRAM manager and the stolen write-combined mapping. The last log line is after the firmware framebuffer range at 0xff000000 was excluded from stolen allocation, and no hang point is confirmed yet (GPU_PANTHER_LAKE.md, latest commit). It touches our #8, #11 and the Meteor Lake stage 4 report #13, and the NVRAM step trace is a cheap way to localise a stage that freezes the machine. The repo is GPL-3.0. Confidence: Medium.
  • One Meteor Lake user opened three issues asking whether a picture before WindowServer (installer or recovery) is possible. Same text in ArrowWhatever #3, XEGFX-MIGRATE #2 and XeMac #1: Core Ultra 5 125H (8086:7D55), 2880x1800 eDP, ACPI rebuilt from firmware, NVMe and APFS up, and a hang when XeGfxIntelFB 0.9.4 applies the mode. No replies yet. This is our open display question in #9 (flip-only framebuffer, untested) and the person is a possible tester for #3. Confidence: High that the threads exist, Unverified for their logs.
  • New project, early: claw8-xe2-macos ports that same B580 stack to Lunar Lake (Arc 140V). The README says it is untested on hardware, milestone 3 of 8 (GuC firmware load), and CI builds an installer (README). GPL-2.0. It relates to our #8. Confidence: Medium.
  • A hybrid-laptop repo found a way to show the 60/144 Hz menu for a built-in panel, still pending a reboot. It writes a display override with display-refresh-rate-policy = 1, as Apple's own 2019 16-inch MacBook Pro override does, and a 10 second 144 Hz probe worked on a Tiger Lake framebuffer (wex-1.md, commit). The menu itself was not confirmed at the time of writing. No licence, so ideas only. Our panel runs 165 Hz, so the idea may apply. Confidence: Low.
  • FreeBSD drm-kmod: users report GPU hangs on the 6.12 branch that went away on the 6.6 branch. Alder Lake and Rocket Lake, "Resetting rcs0 for preemption time out" (#467). Relevant only if our i915 import tracks the 6.12 branch, which I did not check. Confidence: Low.

Skipped as not relevant to our hardware or open problems: WhateverXe 0.8.1 and 0.8.2 and Graphics 0.4.2 to 0.4.4 with their issue traffic (Tiger, Alder and Raptor Lake with Apple's own accelerator, no Arrow Lake), NootedGreen reports about GPU reset teardown, idle power and scaled-mode scanout on Iris Xe, metal2vulkan runtime churn, and discovery hits that are EFI folders or unrelated tools.