* Initial DualSense Support
* Add Vibration Support
* Add CRC32 Validation to Incoming Bluetooth Packets
Cleanup report sizes
* Consistency, remove button comments, add two buttons.
Co-authored-by: Ani <ani-leo@outlook.com>
Please, stop pretending...
You need these templates for generic code.
In other words, in another templates.
Stop increasing compilation time for no reason.
The latest MSVC 16.8 Preview 3.1 cl.exe no longer likes the implicit conversion from false->std::shared_ptr
But it's happy with nullptr
Not the ideal solution, but it will kick the can down the road a little.
We accidentally always saved keyboard to Player 1 if null was selected.
The new code will only apply keyboard by default if the config file was not found.
- fix headers
- update cursor whenever the mouse is moved
- unify cursor logic
- move m_mouse_hide_and_lock logic to handle_cursor (toggle_fullscreen is the trigger, not the handler)
- disable mouse lock and idle timer if the window is inactive
Used to access get_mouse_lock_state rather than going through the QWindow property tables.
Modify mouse hide and lock to default OFF when entering Windowed mode, and to default ON when entering Fullscreen unless 'show cursor in fullscreen' is configured
This should address the second point of #4502.
A few notes:
1. it changes the current behaviour of the 'Fullscreen cursor'. Currently it defaults to be captive. This changes it so that it defaults to NOT being captive, but can be made captive with the CTRL+L key combination.
2. There are situations when in windowed mode it's possible to escape the captivity (it's like a minigame if you will). This requires the mouse movement to exceed the bounds of the window in a single event scan. It will just show up as a temporary visibility of the cursor when outside of the window bounds. It's not too difficult to 'fix', but might not be a likely enough scenario to warrant either.
3. There currently isn't an ability to change what this keyboard combo maps to, but it's inline with a collection of other similar keyboard mappings. I think adding such a more generic keyboard mapping system (not for just keypad items, but system items.. e.g. so that Emulator stop could be mapped to something other than CTRL+S etc) is a bit out-of-scope of this particular PR.
This is just some workaround until we either use a different input api for keyboards or until we refactor the keyboard_pad_handler to use Qt with native scan codes
