4 Commits

Author SHA1 Message Date
gblues
2cf89feb86 Code clean-up
== DETAILS

Now that I have a working implementation, it's time to tidy up a bit:

- there was no need for the HID subsystem's object data to have a reference
  to the global hid state (since it's global), so removed it.
- refactored the users of that member to use the global state, defining
  reusable macros.
- reorganized the information in *.h files
- removing the hid state also made the constructor changes to the hid driver
  unneeded, so I reverted those changes.

== TESTING
Confirmed clean build. Haven't tested the build yet to make sure everything
still works, though.
2018-03-31 22:25:30 -07:00
gblues
0100d58ffb WIP: evolve driver implementation
== DETAILS

I've created the concept of a hid_driver_instance_t which is basically
a central place to store the hid pad driver, hid subsystem driver,
the pad list, and the instance data for the above in a central location.

The HID pad device drivers can use it to perform HID operations in a
generic manner.

This is more-or-less a pause point so I can catch up with upstream.

== TESTING

Haven't tested this yet. Compiles without warnings though!
2018-03-29 23:37:11 -07:00
twinaphex
cf8e7cd362 (wiiu) small style nits; declare variables at top; C comments 2018-01-05 13:09:05 +01:00
gblues
52c754cfa8 Split wiiu_gamepad into three sub-drivers
== DETAILS
Well, after a lot of code analysis, this seems like the
best way to handle things on the Wii U without also completely
re-architecting the I/O handling in RetroArch.

How it works:

- the top-level wiiu_joypad driver is now nothing more than a
  delegator.
- the wiiu-specific drivers live in `wiiu/input/`
- wpad_driver.c handles the WiiU gamepad
- kpad_driver.c handles the wiimotes
- hidpad_driver.c will handle HID devices like the GC adapter, DS3/DS4, etc.

  (I say "will" because this isn't implemented yet)

== TESTING
Haven't actually tried the build to see if it works, but it does
compile.
2017-12-30 04:43:18 +01:00