AnyPS5/docs/dev/debt/libSceVideoOut.md

libSceVideoOut technical debt

Silent stubs

• sceVideoOutSetFlipRate stores a rate of 0, 1 or 2 and returns VIDEO_OUT_ERROR_INVALID_VALUE for any other rate. PPSA13356 calls it with 60; whether the console accepts that value or returns this error is unverified
• 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

• sceVideoOutColorSpaceConversionSettingsSetDefaultSdrToHdrConversion_, sceVideoOutColorSpaceConversionSettingsSetSdrToHdrConversion_, sceVideoOutAdjustColorSpaceConversion_, sceVideoOutSetGlobalBlendSpace (libSceVideoOut) - PPSA30630 imports these to configure color space conversion and global blend space. Color space conversion settings are accepted with size validation (32 bytes) but conversion blocks and blend space parameters are not applied to the presentation swapchain
• 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
• sceVideoOutCursorEnable, sceVideoOutCursorDisable, sceVideoOutCursorSetImageAddress, sceVideoOutCursorSetPosition (libSceVideoOut, NIDs UPZWCH8qTM4, fEPEwROdCwM, u-9bhWQApq8, N17AK88NdD0) - the names hash to the NIDs Prospero Win (PPSA99995) imports, and the parameter lists (handle, index, address), (handle, index), (handle, index, address) and (handle, index, x, y) follow its declarations. The cursor image's format and size and the console's return values are not known; the functions report that they are not implemented.
• 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; PPSA26344 at 0xCD0946 passes (handle, 0xf, nullptr, nullptr, 0) and branches on the result equalling 1
• 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. PPSA26344's only call at 0xCCF5EA passes (0xFF, 0, 0, nullptr). Whether a non-null param continues past offset 24 is also unknown
• sceVideoOutGetBufferLabelAddress exposes a port-owned contiguous array of 16 aligned 64-bit labels and returns its count. Astro Bot PPSA21564's bundled AGC driver passes a pointer output and addresses each label at base + index * 8. The count, zero initialization on registration, and release of the previous displayed buffer when its replacement completes follow shadPS4 and its driver; PS5 console equivalence has not been measured. Labels live until the port closes, and reopening creates a new array. Error precedence follows the reference for null output and the existing open-port policy for handles. Exact scanout release timing, repeated same-buffer flips and concurrent guest label stores remain unverified. EOP-flip registration and interrupt tokens remain unimplemented; exposing these labels does not implement that separate API.
• 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
• sceVideoOutSubmitFlip (libSceVideoOut, libSceAgcDriver) - in the AGC driver, a CPU flip waits for the graphics-queue submissions ahead of it when the calling thread has submitted graphics-queue work itself: a title that submits a frame and flips it without waiting relies on that order, since emulated GPU work finishes later than the console's. A flip from a thread that has never submitted graphics-queue work is presented without waiting for queued submissions, unless a command-buffer or EOP flip ahead of it has not been reached. Such a thread can only know its frame is finished by waiting for it, as the PS5 RADV WSI's flip thread waits on the frame's fence. Whether the console ever orders a CPU flip behind the graphics queue is not measured; APS5_CPU_FLIP_IN_ORDER=1 orders every CPU flip
• 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
• sceVideoOutRegisterBuffers, sceVideoOutGetFlipStatus, sceVideoOutGetVblankStatus (libSceVideoOut) - PS4 callers. A handle is treated as PS4 once buffers are registered through the PS4 sceVideoOutRegisterBuffers; from then on its flip and vblank status are written in the PS4 64- and 32-byte layouts, with tsc and submitTsc 0. A PS4 title that reads a status before it registers buffers gets the larger PS5 layout. The PS4 function accepts only linear A8R8G8B8_SRGB (0x80000000) and A8B8G8R8_SRGB (0x80002200) buffers without options; tiled PS4 buffers throw, as their layout differs from the PS5 tiling. Linear PS4 buffers may be 4 KiB aligned: the OpenOrbis graphics sample registers its second 1920x1080 buffer 8,294,400 bytes after the first. The PS4 alignment rule is not known

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
• sceVideoOutSubmitEopFlip reserves a flip and returns an opaque DWORD token; presentation is driven by a matching graphics-queue RELEASE_MEM with INT_SEL 2 and that token in INT_CTXID. This five-argument ABI and packet use are inferred from PPSA21564's bundled AGC driver, whose original packet-emission routine is checked in an isolated host ABI probe. The console token encoding, output width beyond the observed DWORD, error policy and reservation capacity are unverified. Host tokens occupy 0x04000000..0x07ffffff, never repeat within a process, and exhaustion throws. Closing cancels unsubmitted reservations; only live reservations match; consumed or cancelled context IDs execute as ordinary label writes without targeting a reopened port. Async-queue EOP flips throw. Buffer registration, flip modes, queue capacity and vsync presentation follow the existing host VideoOut model, not measured console behavior.
• 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.
• HDR output (libSceVideoOut, libSceSystemService) - sceVideoOutGetOutputStatus reports dynamic range 2 and flag bit 0 (named HDR in SharpProspero) only on Windows, while the window's Vulkan surface offers a 10-bit HDR10 swapchain with VK_EXT_swapchain_colorspace and VK_EXT_hdr_metadata and DXGI (IDXGIOutput6::GetDesc1) reports the window's monitor in DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020; sceSystemServiceGetHdrToneMapLuminance then reports the monitor's peak, full-frame peak and black level. A monitor that reports no usable peak gets a default of 1000 nits peak and full frame, 0 nits black. On Linux and other hosts the output stays SDR: a surface can offer HDR10 formats while the display is not in HDR (KDE Wayland with RADV lists them with the output's HDR disabled), and SDL2 and Vulkan expose no output HDR state; a compositor or output-state signal is needed first. The surface formats are read again when DXGI's monitor report changes and when the swapchain is recreated; a compositor that changes them without making the swapchain out of date is not seen until then. Every open port's output mode event fires when HDR output becomes available or unavailable and when its luminance changes; the console's events for an HDR change are unknown. Detection starts when VideoOut is first used: sceSystemServiceGetHdrToneMapLuminance called before that reports SDR, and no event fires for the availability found at start-up beyond the one every output-mode subscription gets when it is made. Console HDR settings (calibrated peak, the SDR-in-HDR conversion block) are not modelled
• 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