FEXCore's CMake already wraps its compiles in ccache when it is installed,
so the global CMAKE_<LANG>_COMPILER_LAUNCHER doubled it into
"ccache sloppiness=time_macros ccache clang" and every compile failed.
Pass the launcher to shadPS4's configure alone (patches/0005).
Need for Speed Hot Pursuit Remastered stopped when a game thread's
destructors ran: the FEX engine's pre-flight check read /proc/self/maps
and required every page of the thread's writable range to be host-
writable, but the game keeps a PROT_NONE guard hole inside it
("host_permissions=---p", "pthread thread dtors failed at stage 1: 13").
Skip such holes; read-only or W+X pages still fail the check.
The build now compiles through ccache and keeps apt's downloads, both in
the workspace and carried between runs with actions/cache, so a rebuild
with the same pin recompiles only what a patch touched.
Need for Speed Hot Pursuit Remastered (and EA's engine generally) maps
'EAOSGlobal' fixed at 0xfbffffc000, the top of the PS4 user area. On a
39-bit Android kernel the ARM64 core's user area ends at 0x3fffffffff, so
MapMemory asserted ("Attempted to access invalid address"). Place such a
mapping at the top of the range the device has instead and log the move;
the game receives the new address through out_addr. Experimental: it only
helps if the game uses the returned address rather than a hard-coded one.
The ARM64 core's build script turns SDL's Wayland driver off, so on the
desktop shadPS4 could only reach labwc through Xwayland ("wayland not
available"). Patch it back on (libdecor off, loaded at run time like X11),
install the arm64 Wayland/EGL/xkbcommon headers and the host
wayland-scanner, and check both drivers made it into SDL's config.
AppRun picks the driver: X11 inside gamescope (GAMESCOPE_WAYLAND_DISPLAY),
Wayland when a compositor is there (the desktop), and leaves an explicit
SDL_VIDEODRIVER alone, so game sessions keep today's path.
libfakeinput.so links libstdc++ and libgcc statically and is preloaded into
every session process, so it exported the whole C++ runtime (~7000 symbols,
__gxx_personality_v0 and __cxa_* among them). Programs then unwound through
its copy: shadPS4 aborted in pthread_exit the first time a game thread ended
(forced unwind -> foreign personality -> terminate). Link with
--exclude-libs,ALL so only the input hooks are exported, fail the build if
the runtime leaks out again, and bump the preload cache so it is rebuilt.
Download/droiddeck-catalog-url points one device at another catalog,
to install a package from a catalog branch before it is live. The
shadPS4 AppImage adds the ROMs folder's ps4 folder to its game folders
the first time it is opened from the menu.
Cross-builds the ARM64 shadPS4 core (FEXCore guest CPU) in Debian
trixie with a patch so it runs stand-alone in the runtime: SDL
controllers and SDL audio when there is no Android control socket.
With the check reached from the client's own runs right after login, the Steam client segfaulted
within seconds, four sessions out of four; the same build without the check (test/bisect-no-launch-check)
and the last build before it both reach Big Picture. Now every run that is not a game launch -
the client's probes, app id 0 - is left exactly as before. Each check logs one line.
Steam runs its graphics probe through every registered Proton at once after login, all in
compatdata/0. Prefix system32 links point into the Proton that set it up last, and the other
Protons' Wines, running outside Proton's pfx.lock, wrote their builtin DLLs through them into that
Proton's tree (device: GE's FEX DLLs became Proton Experimental's at session start).
- bannerlator-steam-compat: both wrappers (Valve's depot launcher and the third-party
bannerlator-proton-wrap) give a tool-0 run STEAM_COMPAT_DATA_PATH=.../compatdata/0-<tool>, and
before every other launch check the Proton's files against the app's desired.tsv and put back
anything that differs (same Proton build only), logging to reapplied.log.
- ComponentsManager writes desired.tsv plus unpacked copies of the packages in use into the
runtime after every change; the page and the drawer show 're-applied at launch'.
In touchpad mode the cursor moved but Big Picture highlighted nothing and a tap-to-click
selected nothing: the nested pointer's motion reaches wlserver as touch 0, and in Passthrough
(the touch mode Big Picture sets) a motion for a touch that is not down moves nothing, so the X
pointer stayed where it was. 0111 passes bAlwaysWarpCursor, as the other touch modes already warp.
3.16.29's Wayland backend bound only wl_pointer and wl_keyboard; touch from DroidDeck's
compositor was never read, so Steam could not be touched. 0110 binds wl_touch in the input
thread and feeds each finger to wlserver_touchdown/touchmotion/touchup, the Steam Deck
touchscreen's path, so Big Picture's Passthrough touch mode gets real touches.
Tried on device: with a session bus the client still sat on "Switching to Desktop..." and
never reached its legacy path (no "No SteamOSManager support" line, steamos-session-select not
called), so the bus was not what it waited on. Sign-in was unaffected.
This reverts commit 40fc5463f3.
Big Picture's Switch to Desktop asks SteamOS Manager over the session bus before falling back to
steamos-session-select (steamui.so). The Steam session had no session bus, the ask never
finished, and the client sat on "Switching to Desktop..."; the new stub was never called. A
bus with nothing on it answers at once, and the client takes its legacy path.
- The front end's "Steam Desktop UI" started a Steam session without -gamepadui, and the client
put itself into Big Picture under gamescope anyway. It now opens the desktop with Steam's
desktop client started in it (BL_DESKTOP_STEAM, the desktop's autostart, the same
bannerlator-steam-launch the menu's Steam entry uses).
- Big Picture's power menu "Switch to Desktop" runs steamos-session-select, which did not exist,
so it sat on "Switching to Desktop..." for ever. The new stub leaves the app a request
(session=desktop in the steam-launch file); the app ends the Steam session and starts the
desktop with Steam's desktop client open.
AutoPlace on its own left the resized window in the top-left corner; with policy="center" it
opens in the middle of the desktop. Tried in a running desktop (labwc --reconfigure).
melonDS remembers a 1x window for the front end's full-screen toggle, too small on a desktop.
A labwc window rule (only the desktop reads rc.xml) resizes it to 800x600 on open and places
it again by the desktop's centre policy.
The desktop set QT_QPA_PLATFORM=wayland for every program. The melonDS AppImage bundles only
Qt's xcb plugin, so from the desktop it exited at once: "Could not find the Qt platform plugin
wayland ... Available platform plugins are: xcb" (exit 127). "wayland;xcb" keeps LXQt on
Wayland and lets such an AppImage use Xwayland. Proven in a running desktop: labwc mapped
"melonDS 1.1".
The guide button's toggle returns to melonDS's saved window size. A 512x288 window (1x wide,
16:9) is stretched by gamescope to fill the panel, menu bar and cursor with it; at 2x and up
the menus stay at their real size, tiny on a handheld. Written once, with the layout.
Hybrid repeats the big screen, small, above the bottom one. Horizontal with the top screen
emphasised fills the panel's height with the top screen and centres the bottom screen in the
rest. Installs set up with Hybrid (or still on melonDS's defaults) move once.
- bannerlator-pad-defaults: new installs start on the Hybrid layout with sharp pixels; an
existing install is moved once, only where still on melonDS's defaults (marker keeps later
choices). Guide = HK_FullscreenToggle. The user's DS/DSi BIOS, firmware and NAND are found in
ROMs/nds/{bios,firmware} and filled in only where melonDS has no path.
- Front end starts melonDS with -f, at the panel's own resolution unless the user chose one.
The412Banner