Avoid Docker Hub pull limits using pinned Docker Official Images on ECR. Fetch the same OpenOrbis release directly and verify its SHA256; retain the existing toolchain and runtime dependencies.
The ps4-payload-sdk v0.9 release has no kernel offsets for firmware 13.52 or
14.00, so on those consoles the payload quit in its start-up code before
main(): PayLoader reported it launched, but no log or service ever appeared.
The SDK added both on master (573b4a0); crt1.o is rebuilt from that commit
with the SDK's own crt/Makefile. It exports the same symbols as v0.9's.
Connecting a controller took a second or two in the middle of the request
handler: drain the kernel log, prove it delivers, call AddDevice, then read the
log until the device turns up. Everyone else waited. A second player adding a
controller froze the first player's input for as long as it took.
The service now owns one kernel-log reader and reads it a line at a time from
its main loop, and creating a controller is a state machine that loop advances:
drain, verify with a marker, AddDevice, adopt the DeviceId. Nothing blocks, so
the other players keep playing and keep being answered while it runs. Their
slots show "Connecting" until the claim is complete. One controller is created
at a time, because two AddDevice calls at once produce two log lines with no way
to tell which device is which; a second request is refused rather than queued.
Nothing in vda.c waits any more, so the callback that kept pads reporting
through those waits is gone, and the line parsing moved to src/klog_line.c,
which the host tests build as it is.
Only the login manager's own line is accepted as our new device now:
SCE_MBUS_EVENT_DEVICE_ADDED with subType 2. The old code fell back to any
"device added" line it saw, so a real pad being plugged in while a controller
was being created could hand us a DeviceId we do not own, and every input would
go to someone else's pad.
On the page: a refused claim re-reads the console's view and gives up only the
controllers that are in use elsewhere, instead of disconnecting everything this
device was playing with; and when getGamepads() starts throwing, every gamepad
source is blanked, so a held button cannot be flushed for ever with nothing left
to release it.
The test stub is now a fake kernel log: it writes the lines firmware 10.01
writes, our own mirrored output included, so the real reading, marker check and
DeviceId matching are what the tests exercise. SECURITY.md writes down what the
open-LAN design does and does not defend.
An OpenOrbis app that sends the bundled payload to GoldHEN's PayLoader,
shows its address and a QR code, and stops it through the loopback API.
It draws its screen in software in the controller page's style
(stb_truetype with Roboto), and its icon with the same code.
The package (title ID CFRE00001) carries OpenOrbis's stub libc.prx and
libSceFios2.prx in sce_module/, as the toolchain asks.
The README covers GoldHEN AutoRun, the launcher, the page and the build.
A GoldHEN ELF payload that creates virtual DualShock 4 controllers with
scePadVirtualDevice*, the path Remote Play uses, so they work on the home
screen, at sign-in and in games. A phone or PC drives them from a page the
payload serves on port 4264.
- Stage 0 (default) is the browser controller: four slots, explicit
creation, native PS4 user selection, input over a WebSocket.
- Stages 1-8 are the diagnostics that established the VDA call order.
- Loopback-only /api/status and /api/stop for the launcher app.
- The klog connection is reopened when a controller is created, so a
start through GoldHEN AutoRun still works if it beats the klog server.
The VDA code is ported from seregonwar/SplashDown (GPL-3.0).
MoHadiShibli