From 53a04ee869b881b86a6ad3e9680d5ad6548d7e23 Mon Sep 17 00:00:00 2001 From: QIU SHENGMING Date: Fri, 2 Oct 2026 09:59:14 +0800 Subject: [PATCH] Measure the launch on the page's own healthy instance: the menu works, the app never runs With the pristine dump restored the page draws (485 lit bytes) and answers 0x0730 with four committed apps. Driving its /api/key and reading its /api/panel: F then 7 opens the menu (ink 1810 -> 1976), DOWN x3 moves the selection (1976 -> 1832), MENU on the app row drops the screen to the title box alone (1832 -> 210) after which MENU, DOWN, UP and F change nothing, and EXIT brings the menu back (1832). So the launcher is entered and left, and the app neither draws nor reads keys. This supersedes the inconclusive PC measurements taken on hand-started QEMU instances, which came up without a picture while the page's instance draws. Recorded in both AGENTS files: restore work/user-flash.img before testing (the copy carrying the adopted FMP3 marker, image_crc32 0x9d27c3db rather than 0x4d87ce48, comes up blank and makes keys dead, which earlier rounds mistook for the app failing), and measure through the page rather than a hand-started emulator. --- AGENTS.md | 23 +++++++++++++++++++++++ AGENTS.zh-CN.md | 18 ++++++++++++++++++ 2 files changed, 41 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 3f3bc0b..ed321cb 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -726,6 +726,29 @@ So the user-visible symptom ("cannot get into the program") is the key press doi the only way to test an overlay app is to run the Labs build itself. Measure through the page, not through a hand-started QEMU: it is the instance that draws, and its endpoints are the same ones the browser uses. +**Reproduced on the page's own instance, with its own endpoints: the app menu works, and MENU on a row leaves the +launcher and never runs the app.** + +The page was healthy for this run (pristine dump restored: 485 lit bytes, four apps installed and confirmed by +0x0730). Driving /api/key and reading /api/panel: + +* F then 7 **does** open the menu -- ink 1810 -> 1976, a boxed title over the slot list. +* DOWN x3 **does** move the selection -- ink 1976 -> 1832, and the list's text changes. +* MENU on the app row drops the screen to the title box alone (ink 1832 -> 210), and from then on MENU, DOWN, UP + and F all change nothing: the app neither draws nor reads keys. +* EXIT brings the menu back (ink 1832), so the firmware did enter and leave the launcher. + +So the wall is between the launcher and the app, and it is not about the app's own code (a 16-byte app that calls +nothing behaves the same) or its header (Breakout's is field-for-field identical in shape). The screen state -- +title box only, keys dead, EXIT returns -- is what a launcher that has taken over the screen and then never +reaches the app looks like. + +Two measurement notes for whoever continues this. Restore the pristine dump (work/user-flash.img) before testing: +the working copy that carries the adopted FMP3 marker (image_crc32 0x9d27c3db rather than 0x4d87ce48) comes up +with the panel blank or showing only its boot screen, and keys then do nothing -- which is what several earlier +rounds mistook for the app's failure. And never hand-start QEMU for this: the hand-started instances came up +without a picture, while the page's own instance draws. + ## The keypad: two real bugs, both fixed The old note here said "keys reach the firmware but the UI does not react" and diff --git a/AGENTS.zh-CN.md b/AGENTS.zh-CN.md index 52b7bb9..cd55d65 100644 --- a/AGENTS.zh-CN.md +++ b/AGENTS.zh-CN.md @@ -588,6 +588,24 @@ app 区被读过 —— 而多系统菜单读的是**固件槽**，不是应用 所以用户看到的"进不去程序"，实质是**这份构建上按键不生效**；要测叠加应用，只能**跑 Labs 版本身**。 测量要走**页面**，不要走手工启动的 QEMU：会画的是页面那个实例，而它的接口就是浏览器在用的同一套。 +**在页面自己的实例上、用页面自己的接口复现：应用菜单是好用的，而在某一行按 MENU 会停在启动器里，应用始终不运行。** + +这次测量时页面是健康的（恢复 pristine dump：485 个点亮字节，四个应用已装好并经 0x0730 确认 ✓）。驱动 /api/key、 +读 /api/panel，得到： + +* **F 再 7 确实打开了菜单** —— ink 1810 → 1976，带框标题覆盖在槽列表上。 +* **DOWN×3 确实移动了选中项** —— ink 1976 → 1832，列表文字随之变化。 +* 在应用那一行按 **MENU**，画面掉到只剩标题框（ink 1832 → 210），此后 MENU、DOWN、UP、F **全部不再生效**： + 应用既不画、也不读按键。 +* **EXIT 能把菜单叫回来**（ink 1832），说明固件确实进过启动器、也出来了。 + +所以墙在**启动器与应用之间**，而且与应用自己的代码无关（16 字节、什么都不调用的应用表现相同），也与头无关 +（Breakout 的头逐字段同形）。"只剩标题框、按键失灵、EXIT 能回来"，正是**启动器接管了屏幕、却始终没走到应用**的样子。 + +给接着做的人两条测量提醒。测试前先把 **pristine dump**（work/user-flash.img）恢复回去：带已收养 FMP3 标记 +（image_crc32 是 0x9d27c3db 而不是 0x4d87ce48）的工作副本起来时面板是空的、或只显示启动画面，那时按键也不响应 —— +前面好几轮把这当成了"应用失败"。另外**永远不要手工启动 QEMU** 来测这个：手工起的实例没有画面，而页面自己的实例是画的。 + ## 键盘：两个真 bug，都已修复 这里原来的笔记写的是"按键到达了固件但界面不反应"，并且归咎于机器模型。结果发现有**两个