The simulated double-click counted any two client clicks within the double-click time, whatever
happened in between, so a click that left the pause menu followed by one in the game toggled
fullscreen, which then got saved. Only count two clicks in the same UI state, and start over when
the window loses focus or the title bar or its buttons are clicked.
May be what's behind #22447.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Windows now uses the same host interface as SDL and iOS: sceUsbMic sends
startRecording/stopRecording/deviceChanged, and drains buffered input on
the CPU thread with pollRecording. A capture thread asks WASAPI for mono
16-bit at the game's rate (it converts from the mix format, so no more
ffmpeg resampling), and copies packets into a lock-free ring buffer.
It reopens the device when the selection changes, and retries once a
second if the device is missing or gets unplugged.
The device list comes from the active capture endpoints. Their friendly
names are the ones Media Foundation reported, so existing MicDevice
settings still match. An empty setting, now selectable as Auto like on
SDL, means the default capture device.
The Media Foundation audio capture code is removed; the camera still
uses it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Windows/MainWindowMenu.cpp's Load/Save/Clear Symbol Map menu actions
mutated g_symbolMap directly from the WinMain thread; route them through
Core_RunOnCPUThread like the rest of the debugger. Windows/MainWindow.cpp's
WM_USER_GET_MODULE_INFO handler read it directly too; guard with
g_frameMutex. Windows/main.cpp's SortSymbols() calls turn out to already be
safe as-is - both notifications that trigger them (BOOT_DONE,
SYMBOL_MAP_UPDATED) are only ever fired from the CPU/NativeFrame thread -
so just fix the stale comment claiming reliance on the (now removed)
internal lock.
With those covered, every remaining caller is either on the CPU/NativeFrame
thread already or routes through Core_RunOnCPUThread/g_frameMutex, so
SymbolMap's internal recursive_mutex is redundant - remove it and all ~40
lock_guard call sites. Qt's mainwindow.cpp still pokes at g_symbolMap
directly and unguarded (a pre-existing issue, out of scope - Qt isn't a
maintained backend), but removing the lock doesn't change its public API,
so it still builds.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Hqm11k99viLfbJm2MkH4BH
We can't create a swapchain in this case but we still want emulation to
keep running. So we ditch the last renderpass in VulkanQueueRunner but
run all the rest (if PauseWhenMinimized isn't set).
Now works without any validation errors or hangs.
For historical reasons, we've actually displayed inside an inner window
completely covering the client area of the main window. This seems to be
entirely unnecessary so I'm just getting rid of it and using the main
window directly for everything.
Not expecting any noticable change, just a nice cleanup.