AnyPS5/docs/dev/debt/libSceVideoOut.md

libSceVideoOut technical debt

Silent stubs

• sceVideoOutOpen validates the priority and CPU affinity that the open param requests for the VideoOut service thread but does not apply them: the port's present and vblank threads are host threads, and guest priorities and affinities do not reach host scheduling
• sceVideoOutAddVrrStatusFlagsPrivilege returns 0 and does nothing: the host output has no VRR state to report. The name comes from an assert message in a title that requires SCE_VIDEO_OUT_OK; the NID hashes to it, the arguments are unknown (it is called without any)
• sceVideoOutVrrPegToFixedRate, sceVideoOutVrrUnpegFromFixedRate (libSceVideoOut) - PPSA05684 passes the handle to both, two further zero arguments to sceVideoOutVrrPegToFixedRate, and ignores the results. The meaning of those two arguments is unknown, so only zeros are accepted. VRR is not modelled and the output always runs at a fixed rate, so both calls only validate the handle and return 0

Unknown function info

• sceVideoOutDeleteVrrActiveStatusEvent (libSceVideoOut, NID -q-vbO859Tw) - the name hashes to the NID PPSA02530 imports and is listed in sce_symbols aerolib.csv at fe2cc2948e. The signature (eq, handle) and the behaviour, removing the handle's VRR status registration from the queue as the other Delete*Event calls do, follow sceVideoOutAddVrrActiveStatusEvent; no title has been observed calling it
• sceVideoOutGetOutputStatusWithVrr (libSceVideoOut, NID gWT7X8H0bYs) - (int handle, void* status), the 80-byte layout and the return codes follow the clean-room description in #2746. Bytes 0-47 are sceVideoOutGetOutputStatus's; bytes 48-53, which the console copies from an internal query whose fields are not established, are written as zero, as are the rest, so the 16-bit value at byte 52 never adjusts refreshRate. A null status returns 0x80290002 and an unknown handle 0x8029000B. The console's earlier global-flag check (0x8029001C) and its object-field check (0x8029001B) test states that are not modelled and are never reported.
• sceVideoOutRegisterBuffers2 (libSceVideoOut) - buffer option 8 (STRICT_COLORIMETRY) is presented as option 0, with the stored values unchanged; what the console changes for it is unknown. Only options 0 and 8 are accepted
• sceVideoOutAddBufferAttributeOption (libSceVideoOut, NID MBlv8YWoyOk) - the signature (VideoOutBufferAttribute2*, uint64_t option) comes from SharpProspero and the call site in PPSA25380, which passes 0x20 and ignores the result. The option is ORed into attribute->option; whether the console validates the bits, keeps them elsewhere or fails on an unknown option is unknown. A null attribute throws. Option 0x20 makes sceVideoOutRegisterBuffers2 throw, as every option other than 0 and 8; what it selects for an overlay buffer is unknown
• sceVideoOutRegisterBuffers2 (libSceVideoOut) - DCC buffers (category 1): dcc_control is taken as the CB_DCC_CONTROL block layout, only bits 0x10026c are accepted; dcc_cb_register_clear_color as the register-clear texel, only 32-bit values are presented
• sceVideoOutIsOutputSupported (libSceVideoOut) - mode 1 is supported; mode 15 is supported when the current host display runs at 120 Hz or above. Configuring mode 15 requires attribute3 bit 0x40; this single-bit mask is inferred from the measured full value 0x80040, not isolated by a console measurement. Vblanks run at 119.88 Hz until mode 1 restores 59.94 Hz. Display modes are read through SDL; a move to a slower display rejects further high-frame-rate presentation. Selecting another host display mode and VRR are not implemented. The console answers per display and per title: with a 120 Hz TV it also answers 1 for mode 15 (119.88 Hz), and PS5_Vulkan measured that sceVideoOutConfigureOutput accepts 15 only from a title whose param.json declares high-frame-rate output (attribute3 0x80040). Modes 4, 7, 8, 12-14, 16-17 and 19 return VIDEO_OUT_ERROR_UNSUPPORTED_OUTPUT_MODE here, as they did on the measured display. Mode 18 throws, because one console answered 0x80290016 and another 0x8029001E. The name VIDEO_OUT_ERROR_UNKNOWN_OUTPUT_MODE for 0x8029001E is ours. Word 3 of the output options is accepted with any value, as on the console, and its meaning is unknown. PPSA12544 probes 0xd000000a, which the console answers with 0x8029001E, so the title selects 3840 pixels
• sceVideoOutGetResolutionStatus (libSceVideoOut) - the 48-byte layout follows the declarations in ps5-opengl and EVO-PLAYER-PS5 (#1578), which agree; not confirmed on a console. screenSizeInInch is 0, the value EDID uses for an undefined size, since the host display's size is not read; flags is 0, its bits are unknown. The pane equals the full size because sceVideoOutSetWindowModeMargins applies no margins
• sceVideoOutOpen (libSceVideoOut) - the open param's first word is unknown (PPSA21564 passes 16; it is not the byte size, since the affinity mask is at offset 16); only 16 is accepted. Whether the param continues past offset 24 is also unknown
• GPU flips (libSceVideoOut) - a command-buffer flip of a buffer index with no registered buffer when the GPU reaches it presents black and completes like any flip (flip event, count, flipPendingNum). The console's behaviour is unknown; PPSA05684 requires that it completes: its renderer submits a flip of buffer 0 while another thread waits for sceVideoOutIsFlipPending to reach 0 before registering the buffers, and flipPendingNum counts that flip from its submission as in shadPS4
• sceVideoOutAddPreVblankStartEvent (libSceVideoOut) - how long before the vblank the console signals pre-vblank start is unknown. The event is triggered on each emulated vblank tick immediately before the vblank event, with its own count as the event data

Functional

• sceVideoOutOpen (libSceVideoOut) - opening a bus that is already open returns SCE_VIDEO_OUT_ERROR_RESOURCE_BUSY (0x80290009), as shadPS4's PS4 driver does for its main port; the PS5 result is unverified. PPSA99764 opens the main bus twice and carries on, presenting through the first handle
• Overlay output bus (libSceVideoOut) - flips on a port opened with SCE_VIDEO_OUT_BUS_TYPE_OVERLAY complete and signal their events like main-bus flips, but their buffers are not shown: the overlay is not composited over the main output. Presenting them as whole frames made the window alternate between the two buses
• Mouse capture and delta scaling (libSceVideoOut) - the console's mouse reports relative motion only, so a host cursor can never coincide with the title's cursor; while a title has a mouse open and the window is focused the host cursor is hidden and captured (SDL relative mode, released on focus loss or while the pad's mouse-to-stick toggle is on). Motion deltas are scaled from the presented image's size in window units to the title's display resolution with sub-pixel carry; the console's deltas are counts, so a title that applies its own sensitivity moves its cursor that much faster than the host pointer would have. The scale takes SDL's relative motion in logical window units, the units of SDL_GetWindowSize; under Windows DPI scaling SDL may report it in physical pixels, which is unverified (no Windows run yet), and a drawable larger than the window does not change the scale.
• Windows game controllers (libSceVideoOut) - SDL's DirectInput joystick backend is disabled at default hint priority before SDL_InitSubSystem, because its device enumeration blocks forever on some vendor HID devices (#1042). XInput and HIDAPI controllers are detected; controllers reachable only through DirectInput are not. Setting SDL_DIRECTINPUT_ENABLED=1 restores them on hosts without such a device