# Phase 0 — X11 paths + measurement-instrument inventory **Date captured:** 2026-05-03 09:08 CEST (ohm uptime 17h34m, 1280×800 panel) **Session under capture:** Plasma X11 (`startplasma-x11`) on tty3, session-id 347, Type=x11, kwin_x11 6.6.4 active (`--replace`). **Captured from:** `mfritsche@noether` over SSH (`ohm.fritz.box`), no operator interaction required for the captures themselves. Raw evidence files in this directory: - `01_live_session.txt` — Xorg cmdline, kwin_x11 cmdline, plasmashell, full process tree, thermal/governor, Xorg.0.log tail. - `02_x11_paths.txt` — installed packages, drivers, SDDM sessions, WM availability, mpv, rockchip-drm bind. - `03_xprotocol_extensions.txt` — xdpyinfo, per-extension probes, glxinfo, drm_info (16k lines — large because drm_info dumps every property). Excerpts copied below. - `04_measurement_instruments.txt` — tool availability + perf paranoid + xtrace probe. - `05_repo_check_and_planes.txt` — repo availability of not-yet-installed tools + planes-table head from drm_info. ## TL;DR - **The currently-live "X11" session is Plasma X11 with `kwin_x11` as compositing WM.** Per `phase0_findings.md`, this is **explicitly excluded** from the without-KWin cell of the matrix. It is still useful as the Phase 0 X11-substrate ground truth (live `Xorg`, live drivers, live extensions). A second X11 *session type* — no compositor — has to be created before the matrix can run its without-KWin cells. **Operator action required** (see § "What the campaign cannot acquire over SSH alone" below). - **X11 stack is healthy on ohm:** `xorg-server 21.1.22-1`, sole DDX is `modesetting_drv.so` (in-server), Mesa `26.0.5-arch1.1`, Panfrost (Mali-G52 r1 MC1), DRI3 + Present + Composite + XVideo + RANDR all initialized. Direct rendering: yes. - **All required X protocol extensions for the matrix are present** on the running server: Composite, DAMAGE, DRI3, Present, RANDR, SYNC, XVideo. (Confirmed via xdpyinfo extension listing — 28 extensions total.) - **rockchip-drm planes are the same ones the predecessor cataloged** on Wayland: Plane 39 (Primary, on CRTC 1 / object-id 52), Plane 45 (Overlay, on CRTCs {0,1}). Format-support details not re-extracted in this capture but predecessor's `kwin_overlay_subsurface/phase2_source_findings.md` is valid for reference (Plane 39 is the only NV12-LINEAR-capable plane). - **Most measurement tools we'll want are missing but free in extra:** `xorg-xrandr`, `xorg-xev`, `xorg-xinput`, `xorg-xwininfo`, `xorg-xkill`, `sysprof`. Operator-installable via one `pacman -S`. - **mpv 0.41.0 is installed** with libplacebo 7.360.1 — the reference X11-overlay client called out in `phase0_findings.md` § "Open questions" can be added to the matrix without further install. - **Firefox is NOT installed.** Two of the six matrix cells (`C-W-ff-*`, `C-X-ff-*`) need it. Operator decision whether to install or to drop Firefox from the matrix. - **The X11 protocol tracer `xtrace` is AUR-only**, NOT in extra. The `/usr/bin/xtrace` shipped with glibc is a *syscall* tracer, unrelated. If protocol-trace evidence is wanted for X11 cells parallel to `WAYLAND_DEBUG=1` for Wayland cells, this is an operator-tasked install (or a build-from-source, or a switch to `xscope`/Python xcb capture). - **`perf_event_paranoid = 2`** so perf record on Xorg PID needs sudo or a one-line sysctl tweak. ## Deliverable 2 — X11 paths inventory ### Installed (confirmed, no install needed) | Component | Version | Notes | |---|---|---| | `xorg-server` | 21.1.22-1 | binary `/usr/lib/Xorg`, runs as `vt3 -seat seat0 -keeptty -novtswitch -verbose 3 -auth ...` | | Sole DDX driver | `modesetting_drv.so` | shipped *inside* `xorg-server`; no `xf86-video-*` package needed (and none would help on rockchip-drm) | | Mesa | 1:26.0.5-1 | Panfrost (Mali-G52 r1 MC1), GL 3.1 core / GLES 3.1 | | `libdrm` | 2.4.131-1 | | | `libglvnd` | 1.7.0-3 | | | `xorg-xwayland` | 24.1.11-1 | for the Wayland axis only — NOT used for native X11 cells | | AIGLX module | rockchip | per Xorg.0.log line "AIGLX: Loaded and initialized rockchip" | | GLX provider | DRI2 | Xorg log: "GLX: Initialized DRI2 GL provider for screen 0" — DRI3 also initialized via separate extension; both available to clients | ### SDDM-advertised sessions | File | Type | Exec | Status | |---|---|---|---| | `/usr/share/xsessions/plasmax11.desktop` | X11 | `/usr/bin/startplasma-x11` | **the only X11 session SDDM offers today** | | `/usr/share/wayland-sessions/plasma.desktop` | Wayland | (Plasma 6.6.4 startup) | predecessor's baseline session | | `/usr/share/wayland-sessions/weston.desktop` | Wayland | weston | reference Wayland compositor (separate concern) | ### WM availability | WM | Installed? | Available in repo? | |---|---|---| | `kwin_x11` | yes (running) | (KDE) — **excluded** from without-KWin cell per matrix definition | | openbox | **no** | yes (extra) | | fluxbox | **no** | yes (extra) | | i3-wm | **no** | yes (extra) | | xfwm4 | **no** | yes (extra) | | awesome | **no** | yes (extra) | | bspwm | **no** | yes (extra) | | icewm | **no** | yes (extra) | | jwm | **no** | yes (extra) | **Verdict:** zero non-compositing WMs are installed today. The without-KWin cell of the matrix needs operator install + SDDM session-entry creation (or a `startx` from a free TTY). **Recommendation: openbox.** Smallest install, no compositing by default, well-documented, used by the LFS/X11-tutorial canon for this exact "minimal X11" purpose. ### Display + DRM - DRM driver: **rockchip-drm** (compatible `rockchip,display-subsystem`). - `/dev/dri/card0` (active) and `/dev/dri/card1` (secondary VOP — drm_info fails to read it, normal on dual-VOP rockchip), plus `/dev/dri/renderD128`. - Panel: 1280×800 @ 59.98 Hz (the panel is mounted portrait so the DRM mode reads as 800×1280; Xorg presents it 1280×800 logical after rotation). - Xorg.0.log shows `modeset(0): Damage tracking initialized` and a re-allocation `Allocate new frame buffer 1280x800 stride` — modesetting + DRI3-Present are wired up cleanly. - `/dev/video0..2` present (hantro VPU character devices — unchanged from predecessor). ### Browsers | Browser | Installed? | Path | |---|---|---| | brave | yes | `/usr/bin/brave` (`brave-bin 1:1.89.145-1`) | | chromium-fourier | yes | `/tmp/chromium-ohm-gl-fix-step2/chrome` (149.0.7812.0, Step 1 + Step 2) | | firefox | **no** | NOT installed — operator decision needed | ## Deliverable 4 — X11 measurement-instrument inventory ### Installed and verified working | Tool | Path | Owner pkg | Notes | |---|---|---|---| | `xprop` | `/usr/bin/xprop` | xorg-xprop 1.2.8 | window-property dump (works) | | `xdpyinfo` | `/usr/bin/xdpyinfo` | xorg-xdpyinfo 1.4.0 | display + extension probe (works); per-extension probe limited (e.g. `-ext Present` returns "not supported by xdpyinfo" — the ext IS on the server, xdpyinfo just lacks the printer) | | `xset` | `/usr/bin/xset` | xorg-xset 1.2.5 | DPMS + repeat etc. | | `xmessage` | `/usr/bin/xmessage` | xorg-xmessage 1.0.7 | popup notifier — useful for unattended tests as ack-flag | | `glxinfo` / `glxgears` | `/usr/bin/glxinfo` etc. | mesa-utils 9.0.0 | GL renderer + benchmark fallback | | `drm_info` | `/usr/bin/drm_info` | drm-info 2.9.0 | plane/CRTC/format dump under live X11 | | `perf` | `/usr/bin/perf` | perf 7.0.2 | works; **perf_event_paranoid=2** so attaching to Xorg needs `sudo perf record -p ` or `sysctl kernel.perf_event_paranoid=1` first | | Python `libxcb-present.so.0` | shared lib present | (libxcb) | xcb_present capture from a small Python client is doable — the protocol-side present-feedback path the matrix wants for end-to-end latency timing | ### Missing-but-installable (single `pacman -S` from extra) | Tool | Pkg | Why we want it | |---|---|---| | `xrandr` | `xorg-xrandr 1.5.4-1` | output / vblank / mode CLI for the cells | | `xev` | `xorg-xev 1.2.6-2` | per-window event capture (X equivalent of `wayland-info` event echo) | | `xinput` | `xorg-xinput 1.6.4-2` | input-device probe for the touchscreen/touchpad confound | | `xwininfo` | `xorg-xwininfo 1.1.6-2` | get the browser window's geometry/wid for targeted xprop/xrandr crop math | | `xkill` | `xorg-xkill 1.0.7-1` | clean kill of a stuck client between reps | | `sysprof` | `sysprof 50.0-1` | userspace alt to perf with nicer flamegraph defaults | **Recommend:** install all six together — `sudo pacman -S xorg-xrandr xorg-xev xorg-xinput xorg-xwininfo xorg-xkill sysprof` (no session restart needed; doesn't affect kwin_x11). ### Missing — AUR or build-from-source | Tool | Source | Why we'd want it | |---|---|---| | `xtrace` (X protocol tracer, NOT the glibc syscall xtrace) | AUR | parallel to `WAYLAND_DEBUG=1` for the X cells of the matrix — captures every X protocol request/reply per browser frame | | `xrestop` | AUR | per-X-client resource (windows/pixmaps/GCs) snapshot — handy for "browser leaks GC handles per video frame" diagnostics | | `intel-gpu-tools` | not applicable | rockchip GPU is Mali, irrelevant here | `xtrace` (X-protocol) is the only one that materially affects the research question. Whether to install is an operator decision — the matrix doesn't strictly need protocol traces to answer the research question (effective fps, drops, CPU% are extension-independent), but they would be useful for cross-server parity claims. Default-conservative: skip `xtrace` for now, add later if a Phase 1 cell needs it. ### What the X server itself supports (live xdpyinfo) 28 extensions. Of the seven the matrix actually needs: | Extension | Status on running X server | Use | |---|---|---| | Composite | initialized (line 87 of Xorg log) | window-redirect base; *off* by default in non-compositing WMs which is what we want for the without-KWin cell | | DAMAGE | initialized | per-window invalidation events | | DRI3 | initialized | dmabuf import/export from clients (needed for browser/mpv hardware paths) | | Present | initialized | flip-presentation w/ vblank-aligned timing — **the X-side equivalent of `wp_presentation_feedback` for end-to-end latency** | | RANDR | initialized | mode + output info, vblank events | | SYNC | initialized | `XSyncCounter` for present timing fences | | XVideo | initialized | legacy hardware-overlay path (Xv); mpv `--vo=xv` uses this | All seven are present. ### Extension-level "is it really wired up" probe results - `xdpyinfo -ext Present|DAMAGE|DRI3|RANDR|XVideo` all return "extension not supported by xdpyinfo" — that's an `xdpyinfo` capability gap, **not** a server gap. Confirmed via the master extension list above. - For a definitive Present-extension probe, use a small XCB client (`xcb_present_query_version`) — `libxcb-present.so.0` is on the system. This is the same shape of probe `mpv --vo=gpu --gpu-context=x11` would do at startup; a successful mpv launch doubles as the probe. - Composite extension is initialized, but the matrix's without-KWin cell wants Composite to be *unredirected for the browser window* so that the X server's plane allocator can scanout the browser's NV12 dmabuf onto Plane 39 directly. Whether each browser actually issues `XCompositeUnredirectWindow` (or just trusts no-compositor-WM default) is the **browser-side open question** in `phase0_findings.md` § "Open questions". The Phase 0 browser-overlay-path inventory will address that. ## Cross-checks against the predecessor These ground-truth confirmations are from this campaign's session, **not** imported as data per the campaign-contained-data rule: | Predecessor claim | This-session check | Match? | |---|---|---| | "Plane 39 is the Primary plane on the active CRTC" | drm_info under X11 shows Plane object-id 39 on CRTC object-id 52 (CRTC 1) | ✓ | | "Plane 45 is the Overlay plane" | drm_info shows Plane object-id 45 on CRTCs {0,1} | ✓ | | "rockchip-drm is the active DRM driver" | sysfs `card0/device/uevent` confirms `DRIVER=rockchip-drm` | ✓ | | "kernel 6.19.10-danctnix1-1-pinetab2, Mesa 26.0.5" | uname -a + pacman -Q match | ✓ | | "CPU governor is `performance`" | `/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor` all = performance | ✓ | | "/dev/video0..2 are the hantro VPU nodes" | confirmed (root:video, mode 660, present at session start) | ✓ | These are agreement-with-substrate checks, not measurement imports. They establish that the hardware/kernel/Mesa/governor substrate the predecessor described is the substrate this campaign starts from. ## What the campaign cannot acquire over SSH alone These items require operator action because they involve session switches at the SDDM greeter or root-only state changes that warrant explicit ack: 1. **Install the missing measurement tools** (one-shot): ```sh sudo pacman -S xorg-xrandr xorg-xev xorg-xinput xorg-xwininfo xorg-xkill sysprof ``` (Optionally also: `sudo pacman -S openbox` and `sudo pacman -S firefox` — see items 2 and 3.) 2. **Create a non-compositing WM session for the without-KWin cell.** Operator decision: openbox (smallest, recommended) vs i3 vs fluxbox. Steps once a WM is installed (e.g. openbox): - `sudo pacman -S openbox` - Verify `/usr/share/xsessions/openbox.desktop` exists (the openbox package ships one); SDDM picks it up at next greet. - **Operator switches at the SDDM greeter** (logout from current Plasma X11 → choose "Openbox" → log in). Cannot be SSH-driven. - Once in the openbox session, this campaign re-runs the live- session capture (`01_live_session.txt`-equivalent) under the no-compositor WM to confirm `kwin_x11` is gone from the process list and the Composite extension is *unused* for browser windows. 3. **Decide whether Firefox is in scope.** Two cells of the matrix reference Firefox; it is not currently installed. Either `sudo pacman -S firefox` (and the `firefox-vaapi` is already part of mesa's `va_gl` driver) or accept Firefox cells as N/A. 4. **Enable perf to attach to Xorg without sudo per-rep.** Either the per-run cell uses `sudo perf record`, or do once: ```sh echo "kernel.perf_event_paranoid = 1" | sudo tee /etc/sysctl.d/90-perf.conf sudo sysctl --system ``` The latter is consistent with what the predecessor used for per-rep perf-on-`kwin_wayland` capture; recommend setting it the same way here. 5. **Optional: install the X-protocol `xtrace` from AUR** (`yay -S xtrace`). Only if Phase 1 wants protocol-level evidence parallel to `WAYLAND_DEBUG=1`; the matrix's primary metrics (effective_fps / drops / latency / CPU%) don't require it. ## What this inventory does NOT cover These were called out as separate Phase 0 deliverables in `worklist.md` and are **not addressed** here: - **Browser X11-overlay-path inventory** (worklist.md § "browser X11-overlay-path inventory"). The matrix's strongest hypothesis depends on whether each browser actually requests hardware-overlay presentation under X11. Source-grep + chrome trace inspection — separate work item. - **A1 in-session Wayland baseline** (worklist.md § "A1 baseline"). Mandatory per the governing rule. The user is currently in the X11 session, so the A1 Wayland baseline cannot be acquired until the user either switches back to Wayland or starts a parallel Wayland-only test rep. Operator-tasked. - **State snapshot of ohm under current Plasma Wayland** (worklist.md item 1) — same constraint: requires the user to be in Wayland for the snapshot to be of Wayland. The current capture covers Plasma X11 instead, which is *adjacent* to but not a replacement for the Wayland snapshot. ## Verdict for Phase 1 readiness (deliverables 2 + 4 only) **Phase 0 deliverables 2 and 4 are complete.** The X11 substrate exists, is healthy, and supports every protocol extension the matrix will need. The without-KWin matrix cells are blocked on a small operator-action list above (one `pacman -S`, one WM install + SDDM session switch). No technical surprises — nothing structurally prevents the matrix from running.