Follow up of #18345 to add support (currently only on `Windows`; see
notes below) for playing a PS3 disc game directly from a Blu-Ray Disc
Drive.
### HOW IT WORKS:
- The BD drive can be added as any other game so from `VFS games` or
from `Add Games` menu. In case it is selected from `VFS games`, any
attempt to write files is discarded, e.g. file `Disc Games Can Be Put
Here For Automatic Detection.txt`
- It scans the default redump keys folder `<rpcs3>/data/redump` (it
currently needs to be manually created due it is not yet provided by
rpcs3 installation) to find a matching decryption key
### NOTES:
- Support is currently provided on `Windows` where I can fully test it.
I cannot test under other OS. However, the additions needed for the
other OS are limited only on `fs::file.h/cpp`. In particular inside the
following new functions:
- `bool is_optical_raw_device(const std::string& path);`
- `bool get_optical_raw_device(const std::string& path, std::string*
raw_device = nullptr);`
- Icons etc. are always refreshed (ISO cache cannot be used due `mtime`
on raw device is not available and any cache check would always fail)
- Code in `ISO.h/cpp` needed some rework to properly manage a read on a
raw device (alignment on offset, size and memory is mandatory). The BD
drive needs to be detected as a file, not as a folder
### MINOR FIXES:
- Fixed wrong specifier used in logging on `ISO.h/cpp`
The passthrough path was fake-completing zero-length bulk/interrupt IN
URBs to mirror the emulated path, so games that drain-poll between
transfers wouldn't stall the libusb worker thread. This baked an
emulator-side assumption about device behaviour into the host stack.
Real PS3 USIO devices issue a ZLP on the read endpoint after any
transfer that would otherwise leave the host's drain URB outstanding
(notably after a CMD_WRITE). Devices that follow the same protocol
(e.g. ITAIKO firmware) are expected to do the same; faking it here
masks firmware bugs and diverges from real hardware behaviour.
Drop the workaround and let libusb submit the URB normally. The IN
URB now completes when the device sends its ZLP, matching real PS3.
Refs: https://github.com/RPCS3/rpcs3/pull/18636#discussion_r3143290987
The PS3 USB stack routes both bulk and interrupt requests through
usb_device_passthrough::interrupt_transfer. The old code unconditionally
called libusb_fill_interrupt_transfer regardless of the endpoint type,
which on Linux's usbfs backend is rejected with EINVAL whenever the URB
type doesn't match the endpoint's bmAttributes. Reads against bulk IN
endpoints therefore never completed and the worker thread stalled.
Look up the endpoint descriptor and dispatch to libusb_fill_bulk_transfer
when bmAttributes indicates bulk. A new usb_device::find_endpoint helper
walks the descriptor tree once per submission.
Confirmed broken on Linux and working on Windows pre-fix; macOS
untested. WinUSB silently accepts the type mismatch, which is why this
went unnoticed. Reproduces with any passthrough device that has a bulk
IN endpoint, e.g. a Bandai Namco USIO (0b9a:0910) under Taiko no Tatsujin
S111 [SCEEXE000]: the game's boot-time the I/O board check runs and then hangs.
Two related defensive fixes uncovered while debugging the above:
- Zero-length bulk/interrupt IN URBs hang in libusb until the device
sends a ZLP. The emulated path fake-completes them immediately; mirror
that here so drain-polls between transfers don't stall the worker.
- An unexpected libusb_submit_transfer error used to leave
UsbTransfer::busy = true forever. Mark it as a fake completion with
EHCI_CC_HALTED so the USB manager processes the failure cleanly
instead of deadlocking the request.
The color/depth alias collapse heuristic at get_framebuffer_layout()
picks depth whenever depth_test_enabled or stencil_test_enabled is set.
But test means read, not write - so deferred renderers that run a
Z-prepass and then a G-buffer pass with depth-test ON, depth-write OFF,
color-write ON get classified as a depth pass even though they're
writing color. The color writes get silently dropped.
In Starhawk this killed every lit surface - characters, skybox, anything
that goes through the deferred lighting path rendered black or
invisible. Terrain, particles, and emissive geometry kept working
because they don't go through that same pipeline.
Fix is to check writes instead of tests:
if (zeta_write_enabled && !color_write_enabled)
keep_as_depth(); // Z-prepass, shadow gen
else
keep_as_color(); // G-buffer / lit pass
For the both-writes case I went with color since losing color is much
more obvious visually than losing depth (the engine's Z-prepass usually
still has the depth around).
Tested with Starhawk [BCUS98181] in menu and gameplay - before: missing
characters and sky. After: matches PS3 reference. Logged every aliasing
event during a couple minutes of gameplay and they were all the G-buffer
pattern (depth-test ON, depth-write OFF, color-write ON), all handled
right. The depth-keep branch wasn't actually exercised in Starhawk, but
it's there for games that do use a Z-prepass to an aliased buffer.
Fixes#11877.
The constructor inserted rows into m_list_captured_frame for the command queue but never did the same for m_list_captured_draw_calls. GetMemory()'s setItem() loop for draw calls then no-op'd on missing rows, so the Captured Draw Calls tab always appeared empty after a frame capture.
The previous approach used munmap followed by mmap without MAP_FIXED
(since Apple rejects MAP_FIXED | MAP_JIT). Between the two calls,
another thread could claim the unmapped address range, causing mmap
to return a different address and triggering a fatal verification error.
Under concurrent load (e.g. PPU LLVM compilation with many worker threads),
this race manifests reliably as "Verification failed (object: 0x0)" crashes
across all PPUW threads in memory_decommit.
Fix: Use MAP_FIXED without MAP_JIT instead. This atomically replaces the
mapping without any window for other threads to interfere. The MAP_JIT
attribute is lost on the replaced pages, but the application's code signing
entitlements (allow-unsigned-executable-memory, disable-executable-page-protection)
permit executable mappings without it.
Applied the same fix to memory_reset which had the identical pattern.
Replaces the plain text "Show Details" changelog in the update dialog
with a QTextBrowser that converts PR references like (#1234) into
clickable GitHub links.
**Why? :** Easy to check PRs you are interested in beyond the title.
