-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FOME Arcade buttons] Joystick mapping(invert axis/possibly working, but unconfirmed) #3
Comments
Sorry for the delay. Absolutely! I'm coming from the web side, so hardware I/O like this are new to me. But, I'm definitely game! I appreciate you listing out the utilities. I'll start trying to map the buttons later this week or the start of next. |
Ok! Received two new gamepads by mail order today, and see that the event buttons aren’t as standardized as I initially thought with only my PS3 controllers at hand. I’ll look closer at this as soon as possible, to try to make a more general solution with broader/more (manually)customizable gamepad support(if I manage). Any tips in general from the community is appreciated! |
Hi again @robertjdominguez, Sorry to nag, but it would be of great help if you could please provide me with the name/type of your controller and the RAW event key information as described in the numbered list here: #5 (comment) Br, |
All good -- I'll hopefully be able to get you something by tomorrow! For reference, this is the model. |
I have now updated and tested with expanded controller support. Also added a "nomap" options argument, which you could use to skip autoconf of gamepads with uinput-mapper and instead manually edit and use /sd/arcade.cfg directly, if you prefer. I hope and assume that the latest fixes also work for you, and will close this issue if I don't hear back from you in a couple of days with something new. I would really appreciate, though, that you could test and confirm if it now works for you with your FOME arcade buttons DIY kit. |
Hi again @robertjdominguez, Yet some fixes today which I hope might help with your setup... |
Did you get your FOME arcade controllers to work, or is there anything I could help with? |
Hey -- incredibly sorry for the delay. I have a project deadlining on Feb. 1. I'll have some time to test after that! |
No worries, I’ll just keep this issue open until some time into February. Good luck! Like your office arcade coffee table, by the way! |
About to test! Will update later today. |
Yo! Progress! The controls actually work in a game environment using the FOME arcade controllers. However, the axes are inverted ( |
Good news! You can invert both axis independently for one controller by setting these variables to 1 in arcade1.py:
And same two places in the code for two controllers in arcade2.py. The buttons you can play around with in both files in sections (0 and 1, EV_KEY) for controller 1 and (2 and 3, EV_KEY) for controller 2. Left sides are inputs(controller) and right side in line “code” are outputs, corresponding to the MakeCode button codes in /sd/arcade.cfg.
Lastly, you can get a faster/better working setup by skipping over the self calibrating functions which requires moving the stick to the full extended range in all directions of the controller, by setting the corresponding min and max values(from evtest/input-read.py) manually instead.
|
Any success with this eventually? |
Did it work, @robertjdominguez? |
Strong indications that @robertjdominguez got it to work by inverting an axis, but unconfirmed. |
New issue here as a continuation of @robertjdominguez’ question about joystick mapping here:
#2
Hi Robert,
I’m on a little thinner ice here regarding joystick mapping, as I only have PS3 controllers at home and I am waiting for a couple more gamepads to test out soon.
Basically, launCharc scans gamepads recognized as RAW input events, in numbered files event0...n, under /dev/input. You can hopefully find your joystick(s) eventX by installing and running «evtest» or doing a «more /proc/bus/input/devices».
Since event number often change between reboots, at least on my system, I use «.../uinput-mapper -v -p /dev/input/eventX» on all events, to scan all events for occurences of «BTN_DPAD*», which means all (old arcade style) gamepads with digital directional buttons, which are then mapped to the keyboard keys/event in /sd/arcade.cfg by «.../uinput-mapper/input-create», using config file arcade1.py if one controller is found, and arcade2.py if 2 controllers are found. Default mappings as shown in the table in readme.md.
As these are «RAW» inputs and not directly related to es_input.cfg, I’m not sure how this translates to your particular joystick(you can check its buttons with evtest or input-read), especially not if your directional controls are analog, which «axis» might indicate.
It is maybe possible with an analog threshold value for triggering direction command, and I’m sure you figure out the mappings in arcade1.py, when you have found the eventX and its buttons.
As I’m expecting trouble identifying every possible joystick option automatically, and I don’t know how many types(of the most commonly used) actually are covered by «BTN_DPAD*» I am thinking about a command line option to disable auto-discovery of gamepads in launCharc, and support manual keyboard and gamepad mappings in /sd/arcade.cfg and arcade1.py and arcade2.py.
Sadly, at the moment, launCharc overwrites the SCAN_CODES=/dev/input/eventX with the keyboard if no gamepad with «BTN_DPAD» is found and with a uinput-mapper virtual event if 1 or 2 such gamepads are found.
Can I suggest that you find and post your joystick’s buttons with «.../uinpt-mapper/input-read -v -p /dev/input/eventX» and I’ll see what I manage to do when I’ve tested with the soon arriving new controllers. Alternatively, if you have any optional controllers with digital DPAD directional buttons you can use?
I doubt I will be able to support auto-detection every controller type/driver/setup, especially analog ones, anyways. I also know of another project which used xboxdrv included with RetroPie to map joysticks to keyboard, which is another argument to have an option to disable auto-detection from launCharc, and rather leave it possible to manually map however you want to the keyboard instead, if it’s not automatically detected.
What do you think?
Br,
Vegard
The text was updated successfully, but these errors were encountered: