The entry said a title that stops flipping never gets an answer. A dialog that
was never drawn is now dropped after three seconds with the automatic answer;
the bound is a host choice.
The key, mouse and pad inputs that drive the message dialog are a host choice.
The mouse has no hit test, and Cross confirms whatever the confirm-button
setting of the console.
PS5_Vulkan measured on a base PS5 set to 1080p output that
sceVideoOutIsOutputSupported(15) answers 0, neither 1 nor an error, and
that sceVideoOutConfigureOutput(15) then returns 0x80290019, in a title
declaring high-frame-rate output. A host display below 120 Hz answered
0x80290016 to both instead. Titles that branch on the answer being 1
are unchanged; the undeclared-title answer stays 0x80290016.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
PS5_Vulkan measured on a PS5 (firmware 13.40) that
sceVideoOutRegisterBuffers2 refuses a set at buffers 15 to 19 with
0x80290001. The call threw instead. The other out-of-range arguments
keep throwing.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
sceVideoOutGetEventId, sceVideoOutGetEventData and sceVideoOutGetEventCount
threw for an event whose filter is not EVFILT_VIDEO_OUT, and
sceVideoOutGetEventId also threw for a VideoOut id this library never
registers. A title that asks for the id of each event in a queue that
also holds other events stopped there. PPSA28180 compares the result
with VIDEO_OUT_ERROR_INVALID_EVENT, as reported in #11376 (item 6).
They return VIDEO_OUT_ERROR_INVALID_EVENT (0x8029000D) instead, before
sceVideoOutGetEventData writes its output, as the PS4 libraries of
shadPS4 and fpPS4 do. The id is compared in full, so an id above 32
bits is no longer read as a registered one. A null pointer still
throws. The PS5 result is unverified and recorded in the libSceVideoOut
debt.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
sceVideoOutGetOutputStatus derived resolution from the size of the
registered buffers, so a title that reads it right after sceVideoOutOpen
got 1 (1080p) whatever the display. In a payload process on a PS5
(firmware 12.70), with no buffer registered, the field changed with the
console's resolution setting: 2 with it on Automatic on a 4K display, 1
with it set to 1080p. Read it from the display mode SDL reports for the
window's display, next to the refresh rate, and keep it independent of
the registered buffers.
When a title has configured 119.88 Hz output (mode 15) and the window moves
to a display below 120 Hz, the presenter fell back to std::terminate via a
require() call. Replace the abort with a graceful fallback: reset outputMode
to mode 1 (59.94 Hz), fire the output-mode event so the title is notified,
and continue presenting.
This matches the HDMI output mode renegotiation a real display change
requires: the system falls back to a compatible mode and notifies the
title, rather than terminating the process.
After the fallback:
- sceVideoOutGetOutputStatus reports refreshRate 3 (59.94 Hz)
- sceVideoOutGetResolutionStatus reports refreshRate 3
- vblanks run at 59.94 Hz (every-other-tick skip resumes)
- sceVideoOutIsOutputSupported(mode=15) returns the unsupported error
- sceVideoOutConfigureOutput(mode=15) succeeds again once the window is
on a 120 Hz display
The console's exact behaviour when a 120 Hz display is lost has not been
measured; this fallback is recorded as unverified in the debt file.
Fixes#7877
Windows.Gaming.Input stays on by default, so racing wheels, arcade and
flight sticks, HID pads without an HIDAPI driver and Xbox One/Series
trigger rumble keep working. Hosts where it faults at
Windows.Gaming.Input.dll+0x10a84 set APS5_NO_WGI to turn it off.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Adrià