Headless: refuse a run that can't honour an explicit --disable-hle

When the firmware module a --disable-hle bit asks for is neither installed nor
on the disc, that library silently runs our HLE instead. For the emulator that
is the right thing; for a test tool it means the run measures something other
than what was asked for and says so only as one INFO line, which is easy to
grep past and easy to never see. It cost a round of wrong results here, where
the memory stick headless defaults to (beside the exe, not the app's) had no
firmware, so a comparison against the real mpeg.prx was quietly a comparison
against the HLE it was supposed to be measured against.

g_unavailableDisableFlags already records exactly which flags fell back, so it
just needed an accessor. Headless now names each one, prints the flash0:/kd and
memory stick it looked in, and fails the run.

Only an explicit --disable-hle binds. sceMpeg and sceMp4 are LLE by default, and
falling back is the correct and expected behaviour wherever no firmware is
installed - making that fatal would fail every run on such a machine.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Henrik RydgårdandClaude Opus 5 committed 2026-09-20 16:39:35 -06:00
1 parent d40953d09b
commit 0b2c6812e1
4 files changed
+51

No files matched your search

+4
View File
@@ -446,6 +446,10 @@ void HLECheckModuleAvailability() {
}
}
DisableHLEFlags HLEGetUnavailableDisableFlags() {
return g_unavailableDisableFlags;
}
void HLEInit() {
RegisterAllModules();
// Latched lazily rather than here: the compat flags this depends on aren't loaded yet.