Lepton's Vulkan driver has no external memory or sync fd extensions,
so the Steam Frame gets a native SteamOS build instead. Its backend is
the PC's: OpenXR creates Dawn's own Vulkan instance and device, and the
eyes are copied into the swapchain on Dawn's queue, with nothing shared
between devices.
- openxr_vulkan_win32 and Aurora's vulkan_win32_interop now compile on
desktop Linux. Dawn links statically there, so the bridge calls the
patched package's hooks directly, and exists only when the package's
aurora-dawn.json declares the Vulkan hook ABI (AuroraDawnProvider
turns AuroraVulkanAbi into AURORA_DAWN_VULKAN_HOOKS); a stock Dawn
keeps the stubs and VR falls back to the desktop.
- openxr_integration.cpp gains a Linux branch: XR_KHR_vulkan_enable2,
the timespec clock, refresh rate, performance level, the Frame
controllers and eye gaze; fragment density maps are requested on
Linux as on the Quest (fdm.cpp and gpu.cpp, AURORA_FDM=0/1 overrides).
- Controller motion uses XR_KHR_convert_timespec_time on any Linux.
- CMake: Vulkan headers are fetched for Linux OpenXR builds, the
headset option is MKW_HEADSET on Android and Linux, and Linux aarch64
builds take MKW_LINUX_CPU (cortex-x4 for the Steam Frame, else native).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019HBRGKTE1GnN2ah8gcZKr3
- Eyes render under a VK_EXT_fragment_density_map: full rate around each eye's forward direction,
2x2 then 4x4 pixel blocks towards the edges ([vr] foveation = off|low|medium|high, default off).
XR_FB_foveation cannot help here: the runtime's maps only shape passes drawing into its
swapchain, and the eyes reach it through a copy.
- aurora-main/patches/dawn/aurora_fdm.inc: Dawn enables the extension only on request and for
dynamic rendering, flags every render pipeline, and chains an immutable RG8 map into any pass
whose first color attachment is a view bound to one (ABI: include/aurora/dawn_fdm_abi.h).
- android/Build-QuestDawn.ps1 builds the pinned Dawn revision with those patches for arm64
(dawn-build CI flags, protobuf off) into a cached package; Build-Quest.ps1 links it
(-StockDawn opts out) and AuroraDawnProvider.cmake enables the ABI from its manifest.
- lib/gfx/foveation.hpp generates the maps (32 px per texel, densities 255/127/63); an eye is
foveated only when single_pass_eyes draws it in one render pass. Menus never are.
- Live level from the headset panel's VR tab and the launcher; the launch decides whether the
device has maps. debug.wiicompiled.foveation and debug.wiicompiled.fdm for A/B.
- Tests: Foveation cases in gx_fifo_tests, mkw_vr_config_tests. Docs: OPENXR.md, quest-port.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Brings in the keyboard/mouse rebinding overhaul (#162), the Kamek
skip-return hook fixes (#182, #218), the exit button and controller LED
fix (#221), the autohide-cursor and mute hotkey fix (#211), the Linux
--sysroot plumbing (#224) and the switch to the theofficialgman
dawn-build fork (#215).
Conflicts resolved to keep the VR integration intact:
- settings_overlay.cpp/.h: kept both new declarations. The controller
rebinding UI takes upstream's click-to-rebind widgets wholesale - our
only edit there was wrapping the combo width in Scaled(), and
upstream's bindingWidth is already font-relative, so the headset
panel still scales. Kept our DrawResolutionMenu() extraction (the VR
panel reuses it) while adopting upstream's DrawExitPrompt() and its
new DrawTopBar() prologue; kept our Diagnostics menu alongside
upstream's exit-button width math. HandleEvents merges both keyboard
paths, with the VR recenter hotkey now guarded by !g_rebind.active so
it cannot fire while a binding is being captured.
- AuroraDawnProvider.cmake: dropped our now-dead Android hash block.
Upstream restructured the pins into an if/elseif chain that already
covers android/aarch64, with the digest for the new dawn-build fork;
our leftover block was unreachable and carried the old encounter
digest.
- Version plumbing (Build-Installer.ps1, Setup.Windows Program.cs and
csproj): kept this fork's own line, which is 0.2.39 and centralised in
Launcher/Directory.Build.props, rather than regressing to upstream's
hardcoded 0.2.32.
Verified: translator 654/654; runtime ctest 14/14 including every VR
test; WiiCompiled and RetroRewind link; aurora gx_fifo_tests 262/263,
the one failure being the TevRegisterLiveness case already documented as
pre-existing on this branch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fixes https://github.com/patchzyy/Wiicompiled/issues/159
previous requirement for ubuntu 24.04+ libstdc++ inherited from dawn prebuilds now dropped to ubuntu 22.04+ libstdc++ like the rest of the prebuilds
also add all architectures to the URL_HASH check since the dawn tag doesn't change but the binaries have
* Bluetooth Wii Remote support: the game reads a real Wii Remote through KPAD
Enable SDL3's HIDAPI Wii driver and hand a paired Wii Remote (bare or with
Nunchuk) to the game as a real Wii Remote: WPADProbe reports CORE/FREESTYLE
and KPADRead fills KPADStatus[0] from SDL every frame (buttons, accelerometer
in KPAD's g frame, Nunchuk stick and accelerometer), while the GameCube pad
view of that port reports no controller. The game's own motion code then
handles wheelies, tricks and Wii Wheel steering. Classic Controllers and
Wii U Pro Controllers keep going through the GameCube pad path with a default
button table picked by name.
SDL's Wii driver drops a remote on a failed Bluetooth read or when the
Nunchuk is plugged or unplugged and never re-adds it, so the runtime keeps
rescanning (Dolphin style) while no Wii controller is present by toggling the
driver hint off and, a few frames later, on again; a dropped remote is back
within 1-2 s. Settings live in the F10 overlay under Wii Remotes (Bluetooth)
and in Config.toml (wii_remotes, wii_continuous_scan).
* Fix Wii U Pro / Classic Controller ZL and ZR not registering
SDL's Wii driver reports ZL/ZR as the LEFT_TRIGGER/RIGHT_TRIGGER analog
axes, never as digital shoulder buttons. Binding them to
LEFT_SHOULDER/RIGHT_SHOULDER meant they never fired and also disabled
aurora's own analog-trigger fallback (a button table entry for
PAD_TRIGGER_L/R marks the trigger as "handled", even when the bound
digital button never actually presses). Leaving them unbound lets the
default axis mapping drive them like every other analog-trigger pad.
Reported by an end-to-end tester connecting a real Classic Controller to
a Wii Remote.
* Wii Remotes menu: live raw D-pad/ZL/ZR readout for Classic Controller / Wii U Pro
Diagnostic aid for a reported issue where the Classic Controller's D-pad
does not do anything in-game (no wheelies). Shows what SDL itself sees so
a driver-level problem (nothing lights up) can be told apart from a
mapping problem (it lights up but the game does not react).
* Fix Classic Controller D-pad input
* Address CodeRabbit review on PR #73
- PADRead: hide KPAD-served ports even while input is blocked so the port
error state does not flip when the overlay opens/closes.
- WPADProbe: run the Wii Remote rescan state machine before probing so a
reconnect probe before the next PADRead can see the remote.
- EnsureSensors: only cache the gamepad id once every accelerometer enabled,
so a failed activation is retried.
- ConfigureSdlHints: reset the in-flight rescan bookkeeping.
- Settings overlay: disable "Rescan now" while Wii Remotes are turned off.
* Bluetooth Wii Remote: fix wheel steering, native Classic Controller, extension hot-swap
Accelerometer
- The SDL -> KPAD conversion negated the wrong axis: SDL's z is the remote's
+Y (towards the user), so KPAD acc is (-wiiX, -wiiZ, +wiiY). Fixes mirrored
Wii Wheel steering.
- Drop reports whose accelerometer bytes arrive zeroed (+-5.12 g on every axis,
a few times a minute over Bluetooth) and repeat the last good sample; they
read as a full-lock steer plus a 9 g shake.
- One-button zero-point calibration in the overlay (remote flat, buttons up),
stored in Config.toml as wii_accel_offset_x/y/z. SDL's read of the remote's
factory calibration times out over Bluetooth and falls back to a nominal
zero point, which left a per-axis bias of up to ~0.3 g on the tested remote.
- Live accelerometer readout and an optional per-frame CSV trace
(wii_accel_trace = true) for debugging.
Classic Controller through KPAD/WPAD
- WPADProbe reports WPAD_DEV_CLASSIC; KPADRead fills ex_status.cl and
KPADGetUnifiedWpadStatus the raw WPADCLStatus (WPAD_CL_BUTTON_* bits, sticks
in the SDK's signed -512..511 range, triggers), so the game shows the Classic
layout and icons and no button mapping is involved. Ports served through KPAD
are hidden from PADRead; only the Wii U Pro Controller stays a GameCube pad.
Extension hot-swap
- SDL's Wii driver destroys the joystick on an extension change but keeps the
HID handle open, and HIDAPI never re-creates a joystick for such a device.
Patch the vendored SDL at configure time (AuroraSDL3Patches.cmake, wired into
AuroraSDL3Provider.cmake for both the downloaded tarball and a pre-provided
FETCHCONTENT_SOURCE_DIR_SDL) so the joystick is rebuilt in place with the new
extension type, without touching the Bluetooth handle.
- Keep a vanished remote's channel alive with neutral input for up to 3 s while
SDL re-creates the joystick, so the game never sees a disconnection. The
driver-hint rescan stays as a fallback for real drops, starting 3 s after
the loss, and also runs from the overlay's per-frame Draw. Log rescans.
Mappings / overlay
- Do not apply the shared positional [controller] bindings to Wii pads: that
override is what made a Classic Controller's A/B and X/Y look swapped.
- Raw D-pad fallback also for the Wii U Pro Controller; overlay readouts read
joystick buttons directly (SDL's generated HIDAPI mapping expects a hat).
- Overlay: Classic Controller readout, accelerometer readout and calibration.
- README: Bluetooth Wii Remote section and known limitations.
* Review pass on the Wii Remote input path
- EffectiveKind: stop bridging an extension swap once a different controller
has taken the port, and note that everything touching the scanner state runs
on the guest thread.
- KPADGetUnifiedWpadStatus: fill every requested entry (the SDK returns `count`
recent samples), capped at KPAD's 16 read buffers.
- IsKpadKind gets internal linkage; the calibration accessors get their
comments; clarify why Draw() also runs Poll().
* Drop the dead Classic-Controller-as-GameCube-pad matching
A Wii Remote with a Classic Controller is served through KPAD and its port is
hidden from PADRead, so the name matches that once gave it a GameCube button
table and the raw D-pad fallback could never take effect any more. Both now
match only the Wii U Pro Controller, and the default table is renamed
accordingly (g_defaultButtonsWiiUPro).
---------
Co-authored-by: LOL <andresguerra2k26@gmail.com>
Co-authored-by: Nick <89667145+Nick1232345@users.noreply.github.com>
Claude