Skip to content

fix(mister): opening a game manual from the OSD freezes MiSTer after a frontend launch #445

Description

@zaparoo-automation-bot

Issue created from Discord

Source: Zaparoo / #frontend


After launching a game from the frontend, opening its manual (core OSD → Help) freezes the OSD, and MiSTer needs a power cycle. Launching the same core and game from the stock MiSTer menu, with the frontend exited, works.

Manual path (Main_MiSTer menu.cpp, MENU_DOC_FILE_SELECTED): video_chvt(2) (blocking VT_ACTIVATE + VT_WAITACTIVE), video_fb_enable(1), then pdfviewer via agetty on tty2. OSD keys come back only after that process exits (MENU_DOC_FILE_SELECTED_2).

After a frontend launch, the frontend is still alive and dormant, holds its VT in KD_GRAPHICS (rust/frontend/src/mister/tty.rs), and the fork treats the framebuffer as frontend-owned (alt_launcher_scanout_active). Likely causes: Main blocks in VT_WAITACTIVE, or pdfviewer can't take the framebuffer/VT and never exits, leaving OSD keys disabled.

To confirm: over SSH during a freeze, check whether Main is stuck (cat /proc/$(pidof MiSTer_Zaparoo)/wchan), whether pdfviewer/agetty is running, and read /tmp/zaparoo/frontend.log.

Fix direction: when a doc viewer opens, the fork should take the VT and framebuffer back from the dormant frontend (restore KD_TEXT, release the scanout), then hand them back when the viewer closes.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions