loader children: document the per-process XG block required before XOpenDisplay (XNextEvent is silent without it) #2

New Issue

2026-11-12T07:22:50+02:00

2026-11-12 07:22:50 +02:00

A child created by create_process starts with a NULL per-process Xlib context:

proc = *(@0x001B3900)
XG   = *(proc + 0x100)    ; 0 in a fresh child

The ROM Xlib's _XEnq does XG = *(*(proc+0x100)); free_list = *(XG + 0x198), so XNextEvent treats low RAM as queue nodes and delivers nothing. XOpenDisplay, XCreateSimpleWindow and drawing can still appear to work, so the failure looks like "events never arrive".

The termtris branch documents and fixes this: apps/termtris/VT1200.md ("The Xlib context"), apps/termtris/src/vt1200/xgfix.c, and harness/mame/TERMTRIS_REPORT.md. Its smoke test receives type=2 keycode=194 and XLookupString returns a. Master's dwt/notes/GUI_APPS.md does not mention the XG block, and dwt/loader does not install one, so every loader-child X client has to rediscover it.

Requested fix:

add the XG initialization requirement (the proc+0x100, XG+0x198 addresses, and the zeroed 1 KiB block) to dwt/notes/GUI_APPS.md and dwt/loader/README.md;
consider a shared vt_install_xg() helper in the loader tree, or a loader option that installs the block, so clients do not each copy it.

A loader-side install must happen before the child calls XOpenDisplay, so a helper called from the child's entry stub (as termtris does) is the simplest shared form.

A child created by `create_process` starts with a NULL per-process Xlib context: ``` proc = *(@0x001B3900) XG = *(proc + 0x100) ; 0 in a fresh child ``` The ROM Xlib's `_XEnq` does `XG = *(*(proc+0x100)); free_list = *(XG + 0x198)`, so `XNextEvent` treats low RAM as queue nodes and delivers nothing. `XOpenDisplay`, `XCreateSimpleWindow` and drawing can still appear to work, so the failure looks like "events never arrive". The `termtris` branch documents and fixes this: `apps/termtris/VT1200.md` ("The Xlib context"), `apps/termtris/src/vt1200/xgfix.c`, and `harness/mame/TERMTRIS_REPORT.md`. Its smoke test receives `type=2 keycode=194` and `XLookupString` returns `a`. Master's `dwt/notes/GUI_APPS.md` does not mention the XG block, and `dwt/loader` does not install one, so every loader-child X client has to rediscover it. Requested fix: - add the XG initialization requirement (the `proc+0x100`, `XG+0x198` addresses, and the zeroed 1 KiB block) to `dwt/notes/GUI_APPS.md` and `dwt/loader/README.md`; - consider a shared `vt_install_xg()` helper in the loader tree, or a loader option that installs the block, so clients do not each copy it. A loader-side install must happen before the child calls `XOpenDisplay`, so a helper called from the child's entry stub (as termtris does) is the simplest shared form.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: arti/vt1200#2