x11-session-research/phase0_evidence/x11_inventory_2026-05-03/inventory.md

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 <Xorg_pid> 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):

   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:

   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.