From a0cc677491cc3fb08e720a692fcba54b6a31aacb Mon Sep 17 00:00:00 2001 From: sdolbec Date: Thu, 29 Oct 2026 09:04:07 -0400 Subject: [PATCH 1/2] docs: refresh dock candidate and Pages status --- docs/build-status.html | 2 +- docs/index.html | 2 +- mseries/OS9-HANDOFF.md | 32 ++++++++++++++++++++++++++++++++ mseries/ROADMAP.md | 25 +++++++++++++++++++++++++ 4 files changed, 59 insertions(+), 2 deletions(-) diff --git a/docs/build-status.html b/docs/build-status.html index b2676f70..721d7cfa 100644 --- a/docs/build-status.html +++ b/docs/build-status.html @@ -18,7 +18,7 @@

OS 9 build monitor

Aurora source enhancements

The separate .20-enh1 source lane has build and later hardware receipts; its old “staged but unbooted” description is historical. Check each exact build’s receipt rather than transferring acceptance between .20, enh1 and wip2. No paired energy saving is established.

Per-build hardware receipts and gates · Source and build scope
Separate qualification lanes

Aurora .20 hardware freeze

Experimental .20 packages and their scoped boot/PMP/idle/GPU/filesystem receipts remain available. .20 is the last documented persistent boot default, while the October 21 attended boot used wip2. Actual return-to-.20 recovery, full suspend and paired energy testing remain open.

Frozen package, source and checksums · Tested scopes and release gates
Experimental fallback
-

Aurora unified 7.2 trials

October 21 wip2 booted on J314S; all three USB-C ports produced WD22TB4 picture at 1080p/60 in that scoped trial. The retained October 20–27 wip3 observations show DPTX timeouts when first plugging within about four seconds of resume; changing ports restored picture in one observed case. This suggests, but does not prove, a post-resume DCP state issue. A separate user-space monitor-profile watcher restored the saved layout in two observed same-port cycles; automatic restore was confirmed only on the later cycle after a fallback association fix. This does not qualify kernel recovery. Open wip4 revision-6 proposals #533 at f68fd1d9 and #619 at 1dfb6ecc have different patch lists; an owner decision is needed before either merges. At this audit, #619 head 1dfb6ecc had diverged from current dev 57b143c: eight commits behind and four ahead. On #619 head 1dfb6ecc, both ARM64 candidate and unified72 build/payload-inspection jobs passed in run 40605242087; see the immutable receipt. DCP KUnit, wip4 installation/arming, attended J314S boot, repeatable dock recovery, suspend, long-run stability and paired-power qualification remain open. Aurora .20 remains the documented persistent boot default. Wip3 identity and qualification limits.

First-boot receipt · All-port follow-up · Source and remaining gates
Rev-6 candidate conflict · wip4 unbooted
+

Aurora unified 7.2 trials

October 21 wip2 booted on J314S; all three USB-C ports produced WD22TB4 picture at 1080p/60 in that scoped trial. Retained October 20–27 wip3 observations record DPTX timeouts when the dock was first plugged shortly after resume; changing ports restored picture once. This is consistent with, but does not prove, a post-resume DCP state issue. Current proposal: wip5 revision 7, PR #698, exact head 4ea1ea28c5118bc558749203192eef08f042b7b2, pinned to omacom/linux-aurora integration/aurora at 2f725546d6ac6afe0bd5abfa1a844971519f0076. The owner-approved re-pin retains the five ordered patches and required UDMABUF/DMABUF_HEAPS config overlay. Both ARM64 candidate and unified72 kernel/modules/DTB build and payload inspection passed on that head in run 40866985442; see the immutable receipt. PR #698 remains open, dirty against dev and without a recorded review. DCP KUnit, independent artifact audit, installation/arming, attended J314S boot, repeatable dock recovery, suspend, long-run stability and paired-power qualification remain open. Aurora .20 remains the documented persistent boot default. Wip3 identity and qualification limits.

First-boot receipt · All-port follow-up · Source and remaining gates
Wip5 rev 7 build passed · hardware gates open

Enhanced kernel test build

Historical Fairydust packaging work is retained separately from the current Aurora trial. A local monitor link is useful only if its service is running on your own Mac; this public page cannot tell whether that local build is active.

Local kernel monitor ↗ · Historical build records
Local state unknown

Local Mac build

Native assembly finished in 16m 39s and its checksum passed. Inspection found missing live-session hardware helpers; the corrected GitHub image now passes its hardware-helper payload check. The corrected ISO also passed its independent checksum and graphical VM boot check. This public page does not poll your Mac.

Live local monitor · on this Mac ↗ · Build records and controls
Rebuild needed

Rust compositor performance

The Rust compositor has since been used on the transformed desktop. Recent source and staged-package fixes have their own installed-versus-loaded boundaries. Retained October 19 performance samples remain unmatched, so they establish no CPU, power or latency advantage over Gala; Gala remains a rollback option.

Measurements, dates and limits · Current deployment records
Experimental · no measured win
diff --git a/docs/index.html b/docs/index.html index 90cd52ce..ae26ff6f 100644 --- a/docs/index.html +++ b/docs/index.html @@ -19,7 +19,7 @@

ElementaryOS M-Series

Experimental port of elementary OS 9 (Pantheon, Ubuntu-based) to Apple Silicon Macs (M1/M2/…), informed by the maintained Apple hardware packages in omacom/omarchy-mac-pkgs.

- +

Local AI on M1 Pro 32 GB: measured model comparisons, personal memory and MCP app coverage.

diff --git a/mseries/OS9-HANDOFF.md b/mseries/OS9-HANDOFF.md index 855f2ee9..934f39fb 100644 --- a/mseries/OS9-HANDOFF.md +++ b/mseries/OS9-HANDOFF.md @@ -37,6 +37,38 @@ Audited the linked announcement against the running wip5 host and current dev pi ## Rust compositor: frames for X11 windows — 2026-10-29 Owner report: the WiFiman Desktop window (Electron, X11, `_MOTIF_WM_HINTS 0x2, 0x0, 0x1`, min 420x460) could not be moved or resized. The Rust compositor drew no server-side decorations at all, so X11 apps that rely on the window manager's title bar had nothing to grab. New `rust/pantheon-compositor/src/decorations.rs`: X11 windows that ask for a frame (no Motif hints, or hints with a title; normal/dialog/utility types) get a 34 px title bar above the client, an invisible 8 px resize band, and the `org.gnome.desktop.wm.preferences button-layout` buttons (close, minimize, maximize; the owner's `close,minimize,maximize:`), drawn with pango/cairo and rounded with the window corners. Drag moves, edges resize within the size hints, double-click and the maximize button toggle maximize, close sends WM_DELETE_WINDOW. Snapped/maximized framed windows are configured below the title bar; work-area fitting counts the title bar. Fixes on the way: X11 resize ignored WM_NORMAL_HINTS min/max; moving an X11 window (title bar or Super-drag) never told the client its new position. `_NET_WM_MOVERESIZE` was already routed by smithay and is now covered by the probe. Wayland windows, header-bar (CSD) X11 windows and fullscreen windows are unchanged. Verified: `mseries/pantheon-rust-compositor/ssd-probe/run.sh` (nested, 11/11 pass with a window carrying WiFiman's exact hints), 184 unit tests, activation probe 7/7. Not verified: the real WiFiman window on the M1 Pro (needs the owner's install + re-login); the real app was not started nested because its root daemon carries the owner's live VPN. Not done: `_NET_FRAME_EXTENTS`, a window shadow, frames during gesture animations. +## Current WD22TB4 candidate and Pages status — 2026-10-29 + +Verified `dev` at `dc6f7b10d8ca15df429f5373db3b320535ee2ef9`. Pages run +[40874742041](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40874742041) +succeeded for that exact revision, and the live `index.html`, `build-status.html` +and `build-status.js` byte-match `docs/` at that source. This status correction +is prepared on top of that revision and remains unpublished until its PR merges +and a new Pages deployment succeeds. + +The current proposal is wip5 revision 7, [PR #698](https://github.com/techmore/ElementaryOS_MSeries/pull/698), +head `4ea1ea28c5118bc558749203192eef08f042b7b2`. The PR records owner approval +for re-pinning unified72 to omacom/linux-aurora `integration/aurora` at +`2f725546d6ac6afe0bd5abfa1a844971519f0076` (7.2.11), 388 commits newer than +the prior wip4 source. The distinct `7.2.11-elementary-aurora72-wip5` package +identity prevents overwriting wip4. The retained five ordered patches apply to +the full pinned archive without fuzz; the UDMABUF/DMABUF_HEAPS config overlay +is required by the .20 recipe config. Exact-head CI run +[40866985442](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40866985442) +passed both ARM64 candidate and unified72 source preparation, selected kernel +logic checks, kernel/modules/DTB build, payload-only package build and boundary +inspection. The exact source and archive provenance is in +[`review-wip5-2026-10-29.json`](https://github.com/techmore/ElementaryOS_MSeries/blob/4ea1ea28c5118bc558749203192eef08f042b7b2/mseries/aurora/unified72/review-wip5-2026-10-29.json). + +PR #698 is still open, merge state DIRTY, and has no recorded review. DCP KUnit, +independent artifact audit, package installation/arming, attended J314S boot, +dock recovery, suspend, long-run stability and paired-power qualification are +not done. No wip5 package is installed or armed and no hardware acceptance is +claimed; .20 remains the documented persistent boot default. PR #533 remains +open with its additional Aurora20 ports; those changes are not part of #698. +Next: update/rebase #698 against current `dev`, complete review and KUnit, audit +the exact build artifacts, then leave any attended boot to the owner. + ## wip4 revision 6: DP routing candidate — 2026-10-27 Owner report: dock HDMI and Ethernet not working on wip3; HDMI worked after moving the dock to another port. Journals show `apple-dcp 28cc00000` timing out the DPTX validate call (-110 x6, "Type-C DPTX reconnect failed after 5 retries") on every failing boot, each time on the first plug within ~4 s of resuming from s2idle; the same dock then worked on `289c00000`. wip2 used `28cc00000` successfully; wip3 never did. Ethernet (RTL8153, `r8152`) enumerated but had no carrier this boot (it had carrier on the previous wip3 boot with the identical missing-`rtl8153b-2.fw` message), so that looks physical/cable, not kernel. Candidate: wip4 revision 6 = wip3 source + #157 + local 0002 + upstream #186 (0003-0005; #163 excluded as conflicting duplicate). Full-tree `candidate.py prepare`/`check` and 83 aurora tests pass; kernel build, KUnit and boot are NOT done. Nothing installed, staged, armed or rebooted. `thunderbolt_apple.s2idle_teardown/resume_recovery/router_sleep` remain at the default N (upstream did not test them with a real dock). diff --git a/mseries/ROADMAP.md b/mseries/ROADMAP.md index 32d10102..fce1d89e 100644 --- a/mseries/ROADMAP.md +++ b/mseries/ROADMAP.md @@ -1,3 +1,28 @@ +## Current WD22TB4 candidate and Pages status — 2026-10-29 + +Current `dev` is `dc6f7b10d8ca15df429f5373db3b320535ee2ef9`. Pages deployment +[40874742041](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40874742041) +succeeded for that SHA; live homepage and build-monitor files byte-match its +`docs/` sources. This status correction awaits merge and a later successful +Pages deployment. + +The latest kernel proposal is wip5 revision 7, [PR #698](https://github.com/techmore/ElementaryOS_MSeries/pull/698), +head `4ea1ea28c5118bc558749203192eef08f042b7b2`, with owner-approved re-pin to +omacom/linux-aurora `integration/aurora` at +`2f725546d6ac6afe0bd5abfa1a844971519f0076`. Exact-head run +[40866985442](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40866985442) +passed the ARM64 candidate and unified72 kernel/modules/DTB build and payload +inspection jobs. The immutable +[`wip5 receipt`](https://github.com/techmore/ElementaryOS_MSeries/blob/4ea1ea28c5118bc558749203192eef08f042b7b2/mseries/aurora/unified72/review-wip5-2026-10-29.json) +records all five patch pins, archive digest and configuration. PR #698 remains +open, DIRTY against dev and without a recorded review. This establishes source +and build evidence only: KUnit, independent artifact audit, install/arm, J314S +boot, recovery, suspend, stability and paired-power gates remain open. No +hardware acceptance is claimed; .20 remains the persistent boot default. PR +#533's additional Aurora20 ports remain separate and are not included in #698. +Next: refresh/review #698 against current dev, run KUnit, audit its artifacts, +and leave attended hardware boot to the owner. + ## WD22TB4 and wip4 candidate status — 2026-10-28 Current `dev` is `57b143c4afd78b0a4a0f9905e48e39632d1ecc3c`. Pages deployment From 0f80c2d0042e5cd99e6a17e79cea84ea4f9c6b05 Mon Sep 17 00:00:00 2001 From: sdolbec Date: Fri, 30 Oct 2026 08:59:48 -0400 Subject: [PATCH 2/2] docs: update wip5 boot and dock status --- docs/build-status.html | 2 +- docs/index.html | 2 +- mseries/OS9-HANDOFF.md | 61 +++++++++++++++++++++--------------------- mseries/ROADMAP.md | 46 +++++++++++++++---------------- 4 files changed, 54 insertions(+), 57 deletions(-) diff --git a/docs/build-status.html b/docs/build-status.html index 721d7cfa..23988b36 100644 --- a/docs/build-status.html +++ b/docs/build-status.html @@ -18,7 +18,7 @@

OS 9 build monitor

Aurora source enhancements

The separate .20-enh1 source lane has build and later hardware receipts; its old “staged but unbooted” description is historical. Check each exact build’s receipt rather than transferring acceptance between .20, enh1 and wip2. No paired energy saving is established.

Per-build hardware receipts and gates · Source and build scope
Separate qualification lanes

Aurora .20 hardware freeze

Experimental .20 packages and their scoped boot/PMP/idle/GPU/filesystem receipts remain available. .20 is the last documented persistent boot default, while the October 21 attended boot used wip2. Actual return-to-.20 recovery, full suspend and paired energy testing remain open.

Frozen package, source and checksums · Tested scopes and release gates
Experimental fallback
-

Aurora unified 7.2 trials

October 21 wip2 booted on J314S; all three USB-C ports produced WD22TB4 picture at 1080p/60 in that scoped trial. Retained October 20–27 wip3 observations record DPTX timeouts when the dock was first plugged shortly after resume; changing ports restored picture once. This is consistent with, but does not prove, a post-resume DCP state issue. Current proposal: wip5 revision 7, PR #698, exact head 4ea1ea28c5118bc558749203192eef08f042b7b2, pinned to omacom/linux-aurora integration/aurora at 2f725546d6ac6afe0bd5abfa1a844971519f0076. The owner-approved re-pin retains the five ordered patches and required UDMABUF/DMABUF_HEAPS config overlay. Both ARM64 candidate and unified72 kernel/modules/DTB build and payload inspection passed on that head in run 40866985442; see the immutable receipt. PR #698 remains open, dirty against dev and without a recorded review. DCP KUnit, independent artifact audit, installation/arming, attended J314S boot, repeatable dock recovery, suspend, long-run stability and paired-power qualification remain open. Aurora .20 remains the documented persistent boot default. Wip3 identity and qualification limits.

First-boot receipt · All-port follow-up · Source and remaining gates
Wip5 rev 7 build passed · hardware gates open
+

Aurora unified 7.2 trials

October 21 wip2 produced WD22TB4 picture at 1080p/60 on all three USB-C ports in that scoped trial. Retained October 20–27 wip3 observations show DPTX timeouts when the dock was first plugged shortly after resume; moving ports restored picture once. This pattern is consistent with, but does not prove, a post-resume DCP state issue. wip5 revision 7 is pinned to omacom/linux-aurora integration/aurora at 2f725546d6ac6afe0bd5abfa1a844971519f0076 and merged in PR #698. Exact-head run 40866985442 passed the ARM64 candidate and unified72 kernel/modules/DTB build and payload inspection; the immutable receipt records source and archive provenance. The J314S wip5 install record reports one boot, with internal panel, external DP, GPU, Wi-Fi and SEP working; it does not record a WD22TB4 replug or suspend/resume check. The October 30 handoff says wip5 remains running; the install record says wip4 remains the GRUB default. Dock recovery, suspend, long-run stability and paired-power qualification remain open. No wip5 dock acceptance is claimed. Wip3 identity and qualification limits.

First-boot receipt · All-port follow-up · wip5 install and boot record
wip5 boot recorded · dock qualification open

Enhanced kernel test build

Historical Fairydust packaging work is retained separately from the current Aurora trial. A local monitor link is useful only if its service is running on your own Mac; this public page cannot tell whether that local build is active.

Local kernel monitor ↗ · Historical build records
Local state unknown

Local Mac build

Native assembly finished in 16m 39s and its checksum passed. Inspection found missing live-session hardware helpers; the corrected GitHub image now passes its hardware-helper payload check. The corrected ISO also passed its independent checksum and graphical VM boot check. This public page does not poll your Mac.

Live local monitor · on this Mac ↗ · Build records and controls
Rebuild needed

Rust compositor performance

The Rust compositor has since been used on the transformed desktop. Recent source and staged-package fixes have their own installed-versus-loaded boundaries. Retained October 19 performance samples remain unmatched, so they establish no CPU, power or latency advantage over Gala; Gala remains a rollback option.

Measurements, dates and limits · Current deployment records
Experimental · no measured win
diff --git a/docs/index.html b/docs/index.html index ae26ff6f..460a4d79 100644 --- a/docs/index.html +++ b/docs/index.html @@ -19,7 +19,7 @@

ElementaryOS M-Series

Experimental port of elementary OS 9 (Pantheon, Ubuntu-based) to Apple Silicon Macs (M1/M2/…), informed by the maintained Apple hardware packages in omacom/omarchy-mac-pkgs.

- +

Local AI on M1 Pro 32 GB: measured model comparisons, personal memory and MCP app coverage.

diff --git a/mseries/OS9-HANDOFF.md b/mseries/OS9-HANDOFF.md index 934f39fb..72f194dd 100644 --- a/mseries/OS9-HANDOFF.md +++ b/mseries/OS9-HANDOFF.md @@ -37,37 +37,36 @@ Audited the linked announcement against the running wip5 host and current dev pi ## Rust compositor: frames for X11 windows — 2026-10-29 Owner report: the WiFiman Desktop window (Electron, X11, `_MOTIF_WM_HINTS 0x2, 0x0, 0x1`, min 420x460) could not be moved or resized. The Rust compositor drew no server-side decorations at all, so X11 apps that rely on the window manager's title bar had nothing to grab. New `rust/pantheon-compositor/src/decorations.rs`: X11 windows that ask for a frame (no Motif hints, or hints with a title; normal/dialog/utility types) get a 34 px title bar above the client, an invisible 8 px resize band, and the `org.gnome.desktop.wm.preferences button-layout` buttons (close, minimize, maximize; the owner's `close,minimize,maximize:`), drawn with pango/cairo and rounded with the window corners. Drag moves, edges resize within the size hints, double-click and the maximize button toggle maximize, close sends WM_DELETE_WINDOW. Snapped/maximized framed windows are configured below the title bar; work-area fitting counts the title bar. Fixes on the way: X11 resize ignored WM_NORMAL_HINTS min/max; moving an X11 window (title bar or Super-drag) never told the client its new position. `_NET_WM_MOVERESIZE` was already routed by smithay and is now covered by the probe. Wayland windows, header-bar (CSD) X11 windows and fullscreen windows are unchanged. Verified: `mseries/pantheon-rust-compositor/ssd-probe/run.sh` (nested, 11/11 pass with a window carrying WiFiman's exact hints), 184 unit tests, activation probe 7/7. Not verified: the real WiFiman window on the M1 Pro (needs the owner's install + re-login); the real app was not started nested because its root daemon carries the owner's live VPN. Not done: `_NET_FRAME_EXTENTS`, a window shadow, frames during gesture animations. -## Current WD22TB4 candidate and Pages status — 2026-10-29 - -Verified `dev` at `dc6f7b10d8ca15df429f5373db3b320535ee2ef9`. Pages run -[40874742041](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40874742041) -succeeded for that exact revision, and the live `index.html`, `build-status.html` -and `build-status.js` byte-match `docs/` at that source. This status correction -is prepared on top of that revision and remains unpublished until its PR merges -and a new Pages deployment succeeds. - -The current proposal is wip5 revision 7, [PR #698](https://github.com/techmore/ElementaryOS_MSeries/pull/698), -head `4ea1ea28c5118bc558749203192eef08f042b7b2`. The PR records owner approval -for re-pinning unified72 to omacom/linux-aurora `integration/aurora` at -`2f725546d6ac6afe0bd5abfa1a844971519f0076` (7.2.11), 388 commits newer than -the prior wip4 source. The distinct `7.2.11-elementary-aurora72-wip5` package -identity prevents overwriting wip4. The retained five ordered patches apply to -the full pinned archive without fuzz; the UDMABUF/DMABUF_HEAPS config overlay -is required by the .20 recipe config. Exact-head CI run -[40866985442](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40866985442) -passed both ARM64 candidate and unified72 source preparation, selected kernel -logic checks, kernel/modules/DTB build, payload-only package build and boundary -inspection. The exact source and archive provenance is in -[`review-wip5-2026-10-29.json`](https://github.com/techmore/ElementaryOS_MSeries/blob/4ea1ea28c5118bc558749203192eef08f042b7b2/mseries/aurora/unified72/review-wip5-2026-10-29.json). - -PR #698 is still open, merge state DIRTY, and has no recorded review. DCP KUnit, -independent artifact audit, package installation/arming, attended J314S boot, -dock recovery, suspend, long-run stability and paired-power qualification are -not done. No wip5 package is installed or armed and no hardware acceptance is -claimed; .20 remains the documented persistent boot default. PR #533 remains -open with its additional Aurora20 ports; those changes are not part of #698. -Next: update/rebase #698 against current `dev`, complete review and KUnit, audit -the exact build artifacts, then leave any attended boot to the owner. +## WD22TB4, wip5 boot and Pages status — 2026-10-30 + +Current `dev` is `17045e80db1f958e69048418ead12f7c0aeaa1b6`. Pages deployment +[41058736063](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/41058736063) +succeeded for that exact revision. The live homepage and build monitor each +byte-match their `dev/docs` source (SHA-256 `62acac58159490406333886dae68f8eb5c4dedd6b1fe909f3b0a30c99e12b9e5` +and `e06a2f4648cd3225872a91df7d724305ccd266adf00903a97c410edfdec624bb`). +Those source pages still describe the older wip4 candidate; this correction is +prepared on the current revision and remains unpublished until merge and a +successful Pages deployment for the resulting `dev` revision. + +wip5 revision 7 is pinned to omacom/linux-aurora `integration/aurora` at +`2f725546d6ac6afe0bd5abfa1a844971519f0076`; PR #698 merged on October 29. +Exact-head CI run [40866985442](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40866985442) +passed the ARM64 candidate and unified72 kernel/modules/DTB build and payload +inspection. The immutable [source/build receipt](https://github.com/techmore/ElementaryOS_MSeries/blob/4ea1ea28c5118bc558749203192eef08f042b7b2/mseries/aurora/unified72/review-wip5-2026-10-29.json) +retains the pin and patch provenance. The [J314S install record](aurora/unified72/wip5/README.md) +reports a first good wip5 boot on October 29, with the internal panel, external +DP, GPU, Wi-Fi and SEP working. It does not record WD22TB4 replug or +suspend/resume qualification. The October 30 handoff records wip5 still running; +the install record says wip4 remains the GRUB default. This is one boot record, +not dock acceptance or a repeatability result. + +Reuse the October 21 wip2 scoped result: picture at 1080p/60 on all three +USB-C ports in one plug cycle per port. Retained October 20–27 wip3 observations +record early post-resume DPTX timeouts and one alternate-port recovery; they do +not qualify wip5 recovery. No new dock or hardware trial was performed for this +status update. Dock replug/recovery, suspend, long-run stability and paired-power +qualification remain open. Next: perform the owner-authorized wip5 dock and +recovery checks, then update this page only from their retained receipt. ## wip4 revision 6: DP routing candidate — 2026-10-27 diff --git a/mseries/ROADMAP.md b/mseries/ROADMAP.md index fce1d89e..5fbc3e6f 100644 --- a/mseries/ROADMAP.md +++ b/mseries/ROADMAP.md @@ -1,27 +1,25 @@ -## Current WD22TB4 candidate and Pages status — 2026-10-29 - -Current `dev` is `dc6f7b10d8ca15df429f5373db3b320535ee2ef9`. Pages deployment -[40874742041](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40874742041) -succeeded for that SHA; live homepage and build-monitor files byte-match its -`docs/` sources. This status correction awaits merge and a later successful -Pages deployment. - -The latest kernel proposal is wip5 revision 7, [PR #698](https://github.com/techmore/ElementaryOS_MSeries/pull/698), -head `4ea1ea28c5118bc558749203192eef08f042b7b2`, with owner-approved re-pin to -omacom/linux-aurora `integration/aurora` at -`2f725546d6ac6afe0bd5abfa1a844971519f0076`. Exact-head run -[40866985442](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40866985442) -passed the ARM64 candidate and unified72 kernel/modules/DTB build and payload -inspection jobs. The immutable -[`wip5 receipt`](https://github.com/techmore/ElementaryOS_MSeries/blob/4ea1ea28c5118bc558749203192eef08f042b7b2/mseries/aurora/unified72/review-wip5-2026-10-29.json) -records all five patch pins, archive digest and configuration. PR #698 remains -open, DIRTY against dev and without a recorded review. This establishes source -and build evidence only: KUnit, independent artifact audit, install/arm, J314S -boot, recovery, suspend, stability and paired-power gates remain open. No -hardware acceptance is claimed; .20 remains the persistent boot default. PR -#533's additional Aurora20 ports remain separate and are not included in #698. -Next: refresh/review #698 against current dev, run KUnit, audit its artifacts, -and leave attended hardware boot to the owner. +## WD22TB4, wip5 boot and Pages status — 2026-10-30 + +Current `dev` is `17045e80db1f958e69048418ead12f7c0aeaa1b6`. Pages run +[41058736063](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/41058736063) +succeeded for that revision; live homepage and build-monitor bytes match source. +The current `dev` pages still contain the older wip4 status, and this correction +awaits review, merge and its own successful Pages deployment. + +wip5 revision 7, pinned to omacom `integration/aurora` at +`2f725546d6ac6afe0bd5abfa1a844971519f0076`, merged in PR #698. Its exact-head +ARM64 build and payload inspection passed in run +[40866985442](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40866985442). +The J314S install record reports one boot and working internal panel, external +DP, GPU, Wi-Fi and SEP; WD22TB4 replug and suspend/resume remain unchecked. +The October 30 handoff says wip5 remains running, and the install record says +wip4 remains the GRUB default. Do not transfer wip2 dock picture results to wip5. + +The October 21 wip2 trial remains the scoped evidence for WD22TB4 picture on all +three ports. The October 20–27 wip3 DPTX timeout and alternate-port recovery +observations do not establish wip5 recovery. No new hardware trial was performed +for this status update. Next: owner-authorized wip5 WD22TB4 and recovery checks; +record dock replug, suspend/resume, stability and recovery independently. ## WD22TB4 and wip4 candidate status — 2026-10-28