* Implement the basics of controller auto mapping. From testing doesn't currenlty work.
Opening the controller requires the device index, but it is only known and guaranteed
at boot time or when a controller is connected.
* Use the SDL_INIT_GAMECONTROLLER flag to initialize the controller
subsystem. It automatically initializes the joystick subsystem too,
so SDL_INIT_JOYSTICK is not needed.
* Implement the SDLGameController class to handle open game controllers.
Based on the SDLJoystick implementation.
* Address review comments
* Changes SDLJoystick and SDLGameController to use a custom default
constructible destructor, to improve readability. The only deleters
used previously were SDL_JoystickClose and SDL_GameControllerClose,
respectively, plus null lambdas. Given that both SDL functions
accept null pointers with just an early return, this should be
functionally the same.
with just an early return
* warn the user when a controller mapping is not found
* Get axis direction and threshold from SDL_ExtendedGameControllerBind
* Reject analog bind if it's not axis, for the couple of examples present in SDL2.0.10's db.
Also add SDL_CONTROLLER_BINDTYPE_NONE for the button bind switch, with a better log message.
* sdl_impl.cpp: Log the error returned by SDL_GetError upon failure to open joystick
* sdl: only use extended binding on SDL2.0.6 and up
* sdl_impl.cpp: minor changes
Try fixing macos build.
2to3 from 2.7 is not really used and is interfering with the
installation of Python 3.9, on which one of ffmpeg's dependencies
depends.
Conversions from void* to the proper data type are well-defined and
supported by static_cast. We don't need to use reinterpret_cast here.
Co-Authored-By: LC <712067+lioncash@users.noreply.github.com>
Co-authored-by: LC <712067+lioncash@users.noreply.github.com>
* game_list: Eliminate redundant argument copies
Several functions can be taken by const reference to avoid copies
Co-Authored-By: LC <712067+lioncash@users.noreply.github.com>
* game_list: Make game list function naming consistent
Makes the naming consistent with the rest of the functions that are
present.
Co-Authored-By: LC <712067+lioncash@users.noreply.github.com>
Co-authored-by: Lioncash <mathew1800@gmail.com>
Co-authored-by: LC <712067+lioncash@users.noreply.github.com>
Two of the members of the MicroProfileThreadLog contains two std::atomic
instances. Given these aren't trivially-copyable types, we shouldn't be
memsetting the structure, given implementation details can contain other
members within it.
To avoid potential undefined behavior on platforms, we can use aggregate
initialization to zero out the members while still having well-defined
behavior.
While we're at it we can also silence some sign conversion warnings.
Co-authored-by: Lioncash <mathew1800@gmail.com>
The current inconsistency can result in a developer unintentionally
creating a crash when using UNIMPLEMENTED_MSG, if they're only
familiar with UNIMPLEMENTED. The two macros shouldn't have such
wildly different behaviors.
The feature wasn't working when the "single window mode" was off.
Changed the cursor setting to only affect the render_window and
moved to a signal/slot model to show the mouse.
* service/apt: Add GetModule and GetAppletManager
These will be used to retrieve and set deliver args across system resets (which are currently implemented as complete restarts)
* applet_manager: Implement DeliverArg
`flags` was added to `ApplicationJumpParameters` as flags 0x2 is handled differently from 0x0.
* service/apt: Add ReceiveDeliverArg, implement GetStartupArgument
Some based on guesses.
* Address review comments
* kernel/thread: Change owner_process to std::weak_ptr
Previously this leaked almost all kernel objects. In short, Threads own Processes which own HandleTables which own maps of Objects which include Threads.
Changing this to weak_ptr at least got the camera interfaces to destruct properly. Did not really check the other objects though, and I think there are probably more leaks.
* hle/kernel: Lock certain objects while deserializing
When deserializing other kernel objects, these objects (`MemoryRegion`s and `VMManager`s) can possibly get modified. To avoid inconsistent state caused by destructor side-effects, we may as well simply lock them until loading is fully completed.
* Fix silly typo
Somehow this didn't break?!
