The input driver was using absolute coordinate arithmetic while making
use of delta changes for each coordinate, as a result the absolute
change netted to zero. This fixes that and tries to mitigate cursor
event sync issues (sync issues will require more work).
For the mayflash N64 adapter, I was getting a BAD EXC ADDRESS (in mac OS 10.13) for this line (tmp was NULL). Retroarch would crash in the gui if I pressed a button from the DPAD on controller 2. With this change, it no longer crashes in the gui and still registers the button push.
I though it was a weak loading but in fact it's explicit so
loading with some define magic, so we need to check for p_AMotionEvent_getAxisValue
to be clean. Binary code is actually the same
Tested by reverting path fix
There's a new (undocumented -_-) API for removing event listeners in emscripten
now, so use that when recreating input listeners. Fixes mouse events breaking
when loading cores.
For systems supporting only a single button, the turbo-button will toggle firing that button without the need to hold it.
When holding the button turbo will be suspended and resumed when the button is released. Holding the button may have a different function to just tapping it, e.g. charging the beam in R-Type on C64/Amiga.
The original implementation in RA is named 'Classic' because I have no
idea where it originates from.
From my analysis I "believe" this is a development bug/typo and is causing issues with mouse and touchscreen input, that would affect touchscreen and lightgun APIs.
This adds touch gestures to the touchpad-style mouse
controls. Before this, there was only pointer motion
via dragging a finger somewhere on the screen. Now,
there's tap to click and more.
Supported touch gestures:
- pointer motion = single finger drag
- left mouse click = single finger short tap
- right mouse click = second finger short tap
while first finger is still down
- left click drag and drop = dual finger drag
- right click drag and drop = triple finger drag
should now be self-contained in one file. Allows us to
turn more functions static, remove more extraneous functions
that just consisted of a single line (mostly getters/setters), etc.
iOS: change default joypad driver to be mfi
iOS: move autodetect of mfi controller to mfi_joypad driver and set the default mapping for both iOS and tvOS
iOS: support unsupported buttons on mfi controller (select,L3,R3) by using hotkey combinations using the MENU button
tvos: use INPUT_TOGGLE_DOWN_Y_L_R as default for menu toggle gamepad combo
- add tvOS target
- support code signing tvOS cores by adding an argument to the code signing cores script
- use NSCachesDirectory for the documents directory
- add some mfi controller handling logic to set non-game controllers to the last index to avoid interfering with operation
- autodetect mfi controller for apple tv on startup - added autodetect to hid joypad
- added a webserver to transfer files for tvOS
- xcode: clean up project, remove unused folders
- remove HAVE_MATERIALUI setting for tvos build, make it use XMB as default
- added retroarch app icon courtesy of @MrJs
- added auto-detect of mfi controller for apple tv
This allows optionally sorting configure files and is needed to fix the
order of inputs in the autoconfig profiles which should not be sorted
alphabetically.
Fixes https://github.com/libretro/RetroArch/issues/7873
Bastien found a fix to the issue
"The lag after 10-15 minutes issue appears to be a bug in the sdl2 input
driver in RetroArch. RetroArch never clears the SDL event queue. After a
while it is so large it takes a significant time to traverse."
Fixes https://github.com/libretro/RetroArch/issues/7868
Solution thanks to Bastien.
Touch code cleanup
Make variabled static as suggest bparker06
C89 compilation error fix (at least for loops)
More C89 fixes
Signed-off-by: Wiktor Strzębała <wiktorek140@tlen.pl>
For my Xbox One Controller the min input for the hat is 1 and not 0. 0
points to the default state that is called after each button press.
On top of that the two axis for the trigger buttons were ignored. I
added some additional axis that are not present on my controller but
will probably help for other input devices.
=== DETAILS
Replaced includes for things that aren't standard library headers so
they use quotes instead of brackets.
Also fixed up a couple of headers that had include-order dependencies.
=== DETAILS
Since @aliaspider wants the `wiiu/` to be something of a mini-SDK, I've
reorganized the code I put in there:
- `wiiu/main.c` now only has the ELF/RPX entrypoints, and the code used
by those entrypoints, with RA code removed (e.g. swapped retro_sleep()
for usleep()). These entrypoints then call main() ...
- Moved `main()` and its support functions back into `frontend/drivers/platform_wiiu.c`
I also renamed some of the support functions I wrote, and better
organized them within the code.
- Moved `wiiu/input/` into the `input/` hierarchy:
* The joypad drivers now live in `input/drivers_joypad/wiiu/`
* The HID driver now lives in `input/drivers_hid/`
* The Wii U specific headers now live in `input/include/wiiu`
* I added `input/include` into the include search path to avoid
using really ugly relative includes
== DETAILS
Thanks to JacobM at GBAtemp for helping me test this.
The WaveBird wasn't being properly picked up due to the port status byte
being different from normal GC controllers. (Why? who knows. Probably
so games could detect the WB and show WB-specific OSDs).
This implementation should be more future-proof, to handle any other
unexpected status bytes.
== DETAILS
- DS3 analog wasn't working mainly because I forgot to actually declare the
axes in input/input_autoconfig.c when declaring the pad. Whoops.
- I also moved the axis decoding logic to a more central place, because it
clearly is not Wii U specific.
- Removed some dead commented-out code
== TESTING
Can use analog inputs on both GCA and DS3. Tested in Mario 3 on Nestopia core.
Haven't tested with any actual analog games, but I did confirm via logging
that the correct ranges are produced.
== DETAILS
So, it turns out that there *is* a autoconfig disconnect handler. Took digging
through tasks/task_autodetect.c to find it!
So, I added a call to the handler when the pad gets disconnected.
This seems to solve the problem of the pad not disappearing from the menu.
(At the very least, the user's pad index reverts to "none" which is still
an improvement)
== TESTING
Tested manually, made sure it didn't crash or leak slots.
This should fix the issue where R/L buttons didn't register when doing
input detection.
This also brings the GC pad in line with the rest of the gamepads in
input_autodetect_builtin.c.
Also fixed a really stupid bug that was part of why analog inputs aren't
being read. Analog still isn't working, mind, but it's a lot closer to
working now that it's actually getting down into the pad driver level!
=== DETAILS
So, the GCA has 2 USB connections; one is the data connection, and the
second is used to drive rumble.
Due to a driver bug, if the second cable wasn't attached, the pads wouldn't
get detected.
I fixed that bug.
== DETAILS
Hooray for conditional compile directives.
Moving things around broke things in unexpected ways on non-WiiU builds.
Well, not *completely* unexpected. But still.
Changes:
- Move some typedefs around to avoid circular include dependencies
- Include the file where the HID driver definition got moved to
== TESTING
- verified build for Wii U still runs successfully
- did a local build without any errors (some weird warnings, but since they
happen in code I didn't change, I'm assuming they're pre-existing?)
== DETAILS
I think this will fix the problem with duplicate pads--pads weren't properly
de-initializing and registering as disconnected. When a pad is disconnected,
the slot should properly release now.
retro_bits_t turned into input_bits_t and there were parts of my
code that needed to update.
== TESTING
No idea if upstream changes broke anything, but it compiles cleanly
now.
== DETAILS
TIL that it's bad to call synchronization code from callbacks.
To avoid that, I made the following changes:
- Implemented an atomic swap (see previous commit) to avoid explicit
locking when working with the event list
- ensure locks are only acquired in either the main thread or the
I/O polling thread
- use an explicit polling loop; we still use async reads, but the
read doesn't immediately re-invoke itself.
- remove the sleep in the polling thread.
- remove unnecessary locking in the thread cleanup call--verified that
the list can't be modified while it is being executed.
== TESTING
I tested locally, and was able to disconnect/reconnect USB devices several times without the worker thread getting deadlocked.
Fortunately, the gcc port implements the builtins and, from basic
testing, they seem to work.
This is only really useful on Wii U--other platforms have more
robust atomic operations, or aren't using gcc to build.
- remapping analogs to buttons works 100%
- remapping analogs to other analogs still messed up for some reason
- need to reset input of the original axis in input_driver.c still
== DETAILS
- fix the bitshift math
- read the right bytes out of the ds3 data packet
- remove verbose logging in critical path
- stop caring about errors in the hid read loop -- seems to just
be benign "device not ready" -- or at least, that's what I'm assuming
given that the read eventually succeeds.
== TESTING
Played Mario 3 with the DS3 with no issues.
== DETAILS
- update to not try starting the read loop until after the device
is successfully initialized
- add new HID wrapper macros needed by ds3 driver
- add some debug logging to help with troubleshooting
- add button map for DS3
== TESTING
Tested with local build. DS3 init is not working.
== DETAILS
Whereas the last commit had a hack (that disabled the wiimote
driver in the process), this has.. well, a *different* hack that
allows pads to register in any order.
Note that due to the initialization routines, the gamepad will still
likely always get slot 0. Not sure if this can be overridden via config
or not.
== TESTING
Tested locally with GC adapter
== 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.
== DETAILS
The WiiU GC adapter is working!
Next up: DualShock 3
I have the skeleton of the driver started, need to work out the
activation packet.
== TESTING
The DS3 driver is broke as hell right now.
== DETAILS
- Added a new method to the joypad_connection_t interface for
getting a single button
- wired everything into the hidpad driver
- for testing purposes, hacking the top-level joypad driver
so that kpad isn't used
- add a new RARCH_LOG_BUFFER method to verbosity for logging the
contents of a binary buffer (useful for writing/debugging pad drivers)
- fix a few bugs in the wiiu GC pad driver
The button mapping isn't quite right, and I'm not sure what's
going wrong.
== DETAILS
Trying to do weird pad math just wasn't working so I bit the bullet and just
let it allocate all 16 pads in the slot list, then just mark 0-4 as
connected so that the slot allocator would start at 5.
I can see it detect the pad, but no idea if it works. Out of time for
today.
== DETAILS
Turns out freeing memory that's already been freed is.. bad.
Fix two double-free instances; one due to over-freeing and the other
due to wrong order-of-operations causing a double free.
Also updated logging a little.
== TESTING
The GC adapter still clobbers slot 0, but the "emergency exit" sequence
works to quit RA cleanly.
== DETAILS
(I think)
- Uncomment the call in the read loop to start feeding packets to the
driver
- implement the GCA packet driver
- implement the pad interface
- fix indentations in GCA driver
== TESTING
Compiles. Haven't tested yet.
== DETAILS
Turns out the cause of the crash was a bad cast, resulting in a
function call to nowhere.
Also, I think the DSI exception handler only works on the primary core;
when this was happening in the background thread, I got a black
screen error instead.
Next up: finishing up the GCA driver.
== DETAILS
We're at a point where we need to do more than just
clean up a local data structure, so I've started
implementing the "detach" part of the code so that
everything gets cleaned up properly.
Also, added error handling inside the polling
thread.
== TESTING
Have not tested yet.
== 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!
== DETAILS
- detect() methods in device_* files now check for VID/PID
instead of just returning false
- add "name" field on hid device, mainly for logging purposes
== TESTING
Verified my WiiU GC adapter detected properly
This code used a keyboardState size of 256 and indexed it with a
retro_key, which can be any value (RETROK_RALT is 307). This fixes
that by using RETROK_LAST as the array size.
Should fix#6322.
The current code get the USB vendor/product controller, in case of
bluetooth connection this means that you get the bluetooth dongle ids
instead of gamepads. This is not fine as we match gamepads using their
product and vendor ids.
Credits go to SDL which helped me to figure out this issue.
http://hg.libsdl.org/SDL/file/f7c6b974d5af/src/joystick/linux/SDL_sysjoystick.c#l208
== DETAILS
We're trying to track down the source of crashes when switching cores.
To rule out the HID code, this commit does the following:
- Wraps the library imports in an ifdef
- Wraps the object files in conditionals in Makefile.wiiu
- In wiiu_joypad, calls into the hidpad driver are wrapped in ifdef
== TESTING
This didn't solve the "System memory error" crash I've been experiencing.
But, maybe it will impact the other flavors of crashes others are seeing.
== DETAILS
The BIT256_GET() macro expects a bit number (from 0-255), and we're giving it
a 32-bit mask (0x000080000).
Solution:
- Define VPAD_BUTTON_xxx_BIT macros using the bit number
- Use said macro in wiiu_input.c
- organizational cleanup:
* put VPAD_BUTTON_TOUCH into the enum in stead of as a hokey define
* put the touch bits in the right order
* put in placeholder enums for (currently) unused bits
== DETAILS
I fixed a similar bug in a past commit, with the same root cause: making
assumptions about the length of the array.
- Add validation to joypad_connection_init() so that if >MAX_USERS is
requested, a warning is logged and only MAX_USERS is allocated.
- Rewrote the iteration routines so they strictly use the
joypad_is_end_of_list() method to detect the end.
== DETAILS
RetroArch's general HID drivers are intended as a full-on substitute for
other input drivers such as XInput, DInput, SDL, etc. The Wii U port is,
to my knowledge, the first case of heterogenous input drivers working
concurrently.
As such, I've moved things around:
- The HID driver source is moved into the wiiu/input/ directory alongside
the joypad subdrivers.
- We no longer use the input_hid_init_first() method to instantiate; instead
we just init the wiiu HID driver directly.
- The HID pad driver and HID subsystem driver enjoy a tighter coupling,
mainly having to do with the initialization of the joypad connections
list, because there's no way to inform the HID driver's init() method
how many slots to allocate.
== TESTING
Will test in a moment, but at least it compiles cleanly. ;)
== DETAILS
The gamepad didn't work because I had tried to rename the pad from
'WIIU Gamepad' to 'WiiU Gamepad'.
I added some debug logging and (to cut out a lot of trial-and-error)
discovered that the reason it didn't work was because a bug in a macro
was using the define literally instead of substituting it (so e.g.
the autodetect handler was trying to match 'WiiU Gamepad' against the
literal string 'PAD_NAME_WIIU_GAMEPAD').
- Fixed the macro bug
- Left a minimal amount of the debug logging in place; may come in
handy for someone else.
- Updated wpad/kpad/hidpad to use the define constants
== TESTING
Did a test build and confirmed the gamepad responded.
== DETAILS
- the free() method of the hid_driver_t interface needs its
parameter defined as const in order for the compiler to stop
complaining about losing const-ness.
- if a joypad list is created with <MAX_USERS slots in it, the
destroy() function will crash because it assumes there are MAX_USERS
entries.
To do this, the allocate function creates n+1 slots, and gives the
last slot a canary value that the destroy() method can then watch for
when iterating through the list.
== 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.
== DETAILS
USB Vendor and Product IDs are in little-endian byte order, and they
need to be byteswapped on big-endian systems.
This approach allows us to use the standard hex notation for the VID/HID
values, and give them meaningful names, and only swap on the platforms
that need it. Also prevents having to abuse SWAP16() in the platform-
specific code.
== DETAILS
I haven't figured out how I'm going to get the data read via HIDRead()
funneled back to the adapter--the handle_packet() method doesn't actually
get called anywhere.
I'm probably going to need to do more tweaking to the function pointer
list.
This commit also adds logging for the data read via HIDRead.
== TESTING
I used my "stress test" (which I used to reproduce the crash caused
by the old HID implementation), and it did not crash.
== DETAILS
Starting to implement the I/O handling on the HID driver.
The old implementation basically had a never-ending HIDRead() callback
set up, so that callback N would start the read process for invocation
N+1.
We will take the same approach here; but now that the I/O thread is
happenning on its own core, we should be able to let it run full-
throttle without impacting emulator performance.
Of course, this hinges on the callback actually running on the same
core as the syscall was initiated on.
== TESTING
Can confirm that the read_loop_callback gets invoked on the same core
that the HIDRead() was invoked on.
== DETAILS
This implements the WiiU-specific functions.
Since the wiiu_hid_t data structure contains the handle and interface
index, the method signatures can be simplified quite a bit. And since
(at least for now) we want these to be synchronous, we don't need to
expose the callback parameters.
== DETAILS
The handshake stuff is derived from the old HID2VPAD, just in knowing
what data goes in what report.
- Added the HID_REPORT_ flags to syshid.h
- Renamed the generic "REPORT_TYPE" flags to be meaningful
- also fixed incorrect parameter list for set_protocol
== TESTING
The functions aren't implemented in wiiu_hid.c just yet,
so this is gonna crash if you try to run it.
== DETAIL
One minor detail missed in the last commit: actually putting the
send_control function into the driver declaration. Woops.
Not doing the Wii U because it will be using the other methods.
== DETAILS
The current HID implementation assumes a very low-level USB library
is being used. This causes a problem on Wii U, because the Cafe OS
only exposes a high-level interface.
To get these functions exposed to the HID pad drivers, I had to make
three changes:
1. I added the legacy "send_control" function to the HID driver
interface
2. I modified the signature of pad_connection_pad_init() to send the
driver pointer instead of the function pointer
3. I updated the HID pad drivers to keep the pointer to the driver
instead of the function pointer, and updated the calls into the
send_control function as appropriate
4. I updated the HID drivers to use the new pad init signature
== TESTING
Untested, in theory it should work without a hitch because at this
point all I've done is abstract things a little. I still need to
update the HID pad drivers to use the Wii U-specific calls as
appropriate.
== DETAILS
Looking at the apple input driver gave me an idea--moving the
HID driver into the wiiu_input_t data instead of piggy-backing
it off the wiiu_joypad driver.
- Remove changes to wiiu_joypad
- Add equivalent to wiiu_input
This is probably broke as hell. Haven't tried to compile.
== DETAILS
- Added entrypoints into `input/connect/joypad_connection.c` to allow
a max value to be passed in, instead of using single macro value
- Created a hand-off between the HID attach handler and the worker thread
- Created a pad initializer in `wiiu_hid.c` leveraging the new functionality
added to `joypad_connection.c`
== TESTING
Compiles cleanly. At best, doesn't do anything. Might crash--not ready
to test quite yet.
== DETAILS
After wasting some cycles trying to isolate a crash, I went back to
basics.
I enabled the network logging, and put in a bunch of logging lines,
and noticed that the HID thread wasn't actually starting.
I did quite a bit of experimenting, working with different
memory alignments, and finally got it working.
== TESTING
As you can see, I put a log output inside the worker thread. When
I run the build, I can see the TICK messages. I can also see that
the thread shuts down as expected.
Also! The HID callback works as expected too! I have the GC
adapter, and when I register the HID callback it fires and I get the
following data:
[INFO] USB device attach event
[INFO] handle: 2058729
[INFO] physical_device_inst: 0
[INFO] vid: 0x7e05
[INFO] pid: 0x3703
[INFO] interface_index: 0
[INFO] sub_class: 0
[INFO] protocol: 0
[INFO] max_packet_size_rx: 37
[INFO] max_packet_size_tx: 5
Note that these are raw dumps of the data passed to the method,
so e.g. the VID/PID might be byte-swapped from how they're usually
represented.
Have not done the stress test to try to reproduce the crash.
== DETAILS
The old code was crashing; I did a minimalized branch and the crash
went away, so I'm bringing that over here. Meaning I'll have to
redo some of the other work I'd put in, but oh well.
(now watch it start crashing again)
== TESTING
Can confirm it builds. Wii U is busy ATM so I can't test.
== DETAILS
I did a minimalist edit of the HID thread that stripped out all
HID* syscalls, and this stopped the crashing. I then re-added just
the HIDSetup() and HIDTeardown() calls, and the crash came back.
This smells like an OS bug. To work around it, I've put the
HIDSetup() and HIDTeardown() calls into the app init/shutdown
section, so they only get called once in the application lifetime
and not each time the input driver is initialized.
== DETAILS
I think I've about got the thread startup/teardown code worked
out. Logically, anyway, if not accurately.
The challenge has been figuring out how best to integrate the
features of HID2VPAD.
I found `input/connect/joypad_connection.c` and this seems like
the logical place for:
- Special-case driver for the Switch Pro controller
- Any other special cases HIDTOVPAD supports that core RetroArch
doesn't
- Parsing of HIDTOVPAD config file to add custom button mapping
== TESTING
Compiles. Haven't tested with a real Wii U. Probably doesn't work
though. I very likely have the threading bit wrong.
== DETAILS
Looking at the other HID USB drivers, it looks like the typical
implementation is to start up a background thread to do the
polling, rather than wait for RA to invoke the poll() method.
This commit sets up the skeleton of the background thread:
- The thread gets created in init()
- The thread gets stopped in free()
Right now the body of the thread is a 10ms sleep.
== TESTING
It compiles cleanly, and links. Don't know if it actually works.
== DETAILS
I think I've about got the thread startup/teardown code worked
out. Logically, anyway, if not accurately.
The challenge has been figuring out how best to integrate the
features of HID2VPAD.
I found `input/connect/joypad_connection.c` and this seems like
the logical place for:
- Special-case driver for the Switch Pro controller
- Any other special cases HIDTOVPAD supports that core RetroArch
doesn't
- Parsing of HIDTOVPAD config file to add custom button mapping
== TESTING
Compiles. Haven't tested with a real Wii U. Probably doesn't work
though. I very likely have the threading bit wrong.
== DETAILS
Looking at the other HID USB drivers, it looks like the typical
implementation is to start up a background thread to do the
polling, rather than wait for RA to invoke the poll() method.
This commit sets up the skeleton of the background thread:
- The thread gets created in init()
- The thread gets stopped in free()
Right now the body of the thread is a 10ms sleep.
== TESTING
It compiles cleanly, and links. Don't know if it actually works.
== DETAILS
We discovered that the controller_patcher code was causing
the WiiU to intermittently crash when switching ROMs.
Changes:
- Completely extricates the controller_patcher code
- Create a skeleton wiiu_hid driver
- Wire up the build system to build/link it successfully
== TESTING
Has not been tested. Probably doesn't crash, since the
skeleton driver is just a copy of the null driver.
As discussed in libretro#5357; controller_patcher is now optional. It's
off by default; though this could be changed with a simple makefile
tweak (ENABLE_CONTROLLER_PATCHER ?= 1, perhaps?)
To re-enable controller_patcher; append ENABLE_CONTROLLER_PATCHER=1 to
your usual make command.
controller_patcher was the only user of c++ constructors in the Wii U
port, so you'll need 26a006c in your tree otherwise you will have a
blackscreen on startup.
Oops! Didn't do this quite right the first time round.
This commit fixes RETRO_DEVICE_ID_POINTER_PRESSED, which would always
return 0 due to to an implicit case to int16_t. Basically, we'd do
(val & 0x00080000) & 0xFFFF; which would return 0 every time. Fixed that
by wrapping it in a ternary. Yes, I know we could use a rotation, but
for a boolean value it really doesn't matter.
I also rewrote scaleTP to deal entirely in integers. While the
floating-point math was theoretically faster on PowerPC; it gets awkward
to cast -0x7FFF to a float.
Speaking of, the driver now actually conforms to the libretro API. Not
sure how I managed to not see the spec; but hey, now its fixed.
RETRO_DEVICE_POINTER_ID_X/Y will now return values between -0x7FFF and
0x7FFF like they're supposed to.
Big thanks to @r-type for hounding me to fix this.
Partially addresses #5294; we still need mouse emulation.
This hopefully fixes the issues when you try to use 2 Controllers with
the same vid/pid at the same time.
Tested with 2 DS4 controller via the Hid to VPAD Network Client.
Adapters with multiple ports (like the official GC-Adapter) are still
working
Allow using the Gamepad's touch screen as a RETRO_DEVICE_POINTER.
Methodology could use some work, had to add an extra axis to
joypad in order to get the data transferred into the input driver.
Feel free to change this.
Needs to emulate RETRO_DEVICE_LIGHTGUN to really be useful.
Potential for Wiimote IR in future.
Partially addresses libretro/RetroArch#5294
input_overlay_add_inputs added, still need to implement dpad and analog visuals on overlay. Also still needs to be restructured so input_overlay_post_poll is only called once.
* the remote control presents itself as ID_INPUT_KEY, not
ID_INPUT_KEYBOARD. However, ID_INPUT_KEYBOARD is a subset of
ID_INPUT_KEY.
* the remote control lacks the backspace and enter keys, which are hard
coded in RetroArch. It has "back" and "ok" instead, so map those to
RETROK_BACKSPACE and RETROK_ENTER as well.
Remote controls also have no ESC key, but that one is customizable
and I used the Power key of the remote (which already has a mapping
to RETROK_POWER).
The functionality provided is really the bare minimum, but it is enough
to teach a kid "press the power button here to watch TV"; compared to
pressing L1+R1+START+SELECT and navigating to the RetroArch's "quit"
menu item, that hopefully has more chances of success.
* the remote control presents itself as ID_INPUT_KEY, not
ID_INPUT_KEYBOARD. However, ID_INPUT_KEYBOARD is a subset of
ID_INPUT_KEY.
* the remote control lacks the backspace and enter keys, which are hard
coded in RetroArch. It has "back" and "ok" instead, so map those to
RETROK_BACKSPACE and RETROK_ENTER as well.
Remote controls also have no ESC key, but that one is customizable
and I used the Power key of the remote (which already has a mapping
to RETROK_POWER).
The functionality provided is really the bare minimum, but it is enough
to teach a kid "press the power button here to watch TV"; compared to
pressing L1+R1+START+SELECT and navigating to the RetroArch's "quit"
menu item, that hopefully has more chances of success.
On branch master
Changes to be committed:
modified: ../griffin/griffin.c
modified: ../input/connect/connect_ps2adapter.c
new file: ../input/connect/connect_psxadapter.c
modified: ../input/connect/joypad_connection.c
modified: ../input/connect/joypad_connection.h
Ben Klopfenstein