Enable emulator hotkeys and controller input (when that option is enabled) when a TAS Input window has focus, as if it was the render window instead. This allows TASers to use frame advance and the like without having to switch the focused window or disabling Hotkeys Require Window Focus which also picks up keypresses while other apps are active. Cursor updates are disabled when the TAS Input window has focus, as otherwise the Wii IR widget (and anything else controlled by the mouse) becomes unusable. The cursor continues to work normally when the render window has focus.
Will manually controlling both an accelerometer and a gyroscope at the same time be reasonable to do? No idea. Was this easy to implement thanks to the input override system? Yes. Fixes https://bugs.dolphin-emu.org/issues/12443.
IIRC we needed this before the input override system was added.
This gets rid of a blocking operation, improving performance and fixing https://bugs.dolphin-emu.org/issues/12893. This also makes us no longer directly access the state of certain UI elements from the CPU thread, which probably wasn't thread-safe but doesn't seem to have caused any observable issues so far.
This lets the TAS input code use a higher-level interface for overriding inputs instead of having to fiddle with raw bits. WiiTASInputWindow in particular was messy with how much controller code it had to re-implement.
SPDX standardizes how source code conveys its copyright and licensing information. See https://spdx.github.io/spdx-spec/1-rationale/ . SPDX tags are adopted in many large projects, including things like the Linux kernel.
This is a feature which existed in DolphinWX. Seems like it got implemented in DolphinQt for IRWidget/StickWidget but not sliders.
As a side effect of 9c5c3c0, Dolphin's frame counter was changed to run at 60/50 Hz even if the game is running at a lower framerate such as 30 fps. Since the TAS input turbo button functionality toggled the state of a button every other frame as reported by the frame counter, this change made the turbo button functionality not work with 30/25 fps games. I believe it would be hard to change the frame counter back to how it used to work without undermining the point of 9c5c3c0, and I'm not sure if doing so would be desireable or not anyway, so what I'm doing instead is letting the user determine how long turbo button presses should last. This lets users avoid the 30/25 fps game problem while also granting additional flexibility. Perhaps there is some game where it is useful to mash at a speed which is slower than frame perfect.