== DETAILS
The HID drivers in `input/connect/` were missing an implementation
for button(), so I added it. The only exception is the wii driver,
which is really complicated and more than I wanted to try to tackle--
especially since WIIU has its own wiimote drivers.
== DETAILS
Use a little trickery to ensure the GCA driver continues working
with other HID implementation.
I've expanded the joypad implementation to support multi-pad devices.
However, this requires changes to each HID implementation to actually
function.
I've made the necessary changes for WIIU, but I don't have the means
of making the change in the other HID implementations.
So, I've built in a backwards-compatibilty mode for the driver.
The trick is to have an identifier byte at the top of both data structs
that the driver returns. We can then use that byte to determine which
of the structs has been passed to the pad functions and act accordingly.
In the GCA case, for non-wiiu platforms, it will simply expose port 1
of the GCA and the other 3 ports do nothing.
== DETAILS
cause of crash: trying to deference init when it's null
the reason it was going into deregister: the HID/VID lookup was
failing because it wasn't getting initialized first
cause of 2nd crash: the "end of pad list" method looked for an entry
with a magic value, so we add an end marker
== DETAILS
I'm going to need to re-implement the abstraction between HID device
and gamepad; the changes here lay down some foundation for that work.
- reduce logging priority of some statements I modified while debugging
- factor out the pad driver lookup into its own method
- fix so the pad driver list isn't re-initialized every invocation
- add the button() method for the GCA driver
== DETAILS
When I first implemented the Wii U HID architecture, I ended up
having to design my own implementation because, at the time, I did
not have a way to read the HID device string to allow the existing
code to successfully detect the gamepad.
After spending some time experimenting, I've figured out how to
do this. And that means I can better align the HID driver with other
platforms.
change summary:
- create a single state structure for all three sub-types of wiiu pads
(kpad, wpad, and hid)
- eliminate confusing duplicate pad lists
- eliminate confusing duplicate HID pad drivers (ds3, gamecube
adapter, etc)
- ensure the ds3 driver still works
* re add this after failed rebase
* update
* temp fix for device friendly naming as it is for testing
* add device friendly names in the appropiate place
* add/remove hotplug dev to ra input mouse port list
Co-authored-by: grant2258 <you@example.com>
== DETAILS
File this one under "I'm not sure how this ever worked."
I mean, it did (in 1.8.8). I'm not sure what changed, but ultimately what I did was
a bunch of comparative testing against 1.8.8:
- I confirmed the packet data was still being read successfully
- I confirmed that the axis value being passed into pad->get_axis() had
not changed
- I confirmed the work done in `gamepad_read_axis_data()` was working the same
between 1.8.8 and master
With the only difference between 1.8.8 and current being the return value from
`gamepad_read_axis_data()`, I just rewrote the method to work properly, and
also fixed up the default axis mapping.
I tested this with a sixaxis controller and GCA, configuring the analog-to-digital
control override to use the right stick.
* (3DS) Add bottom screen menu
-> User can save/load state on botom screen with thumbnail.
-> Call a save_state_to_file() when RAM state has data to write a disk.
-> If the bottom screen needs updating, swap the bottom framebuffers.
Add: SAVE/LODE STATE TO RAM
-> This is useful for devices with slow I/O
-> 3DS bottom save state use CMD_EVENT_SAVE_STATE_TO_RAM
-> 3DS bottom load state use CMD_EVENT_LOAD_STATE when RAM state has no data
-> 3DS bottom load state use CMD_EVENT_LOAD_STATE_FROM_RAM when RAM sate has data
* Rewrite path_get_state to retroarch_get_current_savestate_path
* Fix unterminated state_path
