ChristophFranzen
commented
2 months ago Suggestion (apart from fixing the "wrong silent remapping" issue above):
Even if not assigning them by default, let MG make all event codes assignable to a virtual gamepad device; that includes at least adding _BTNC=0x132, as well as _BTNZ=0x135.
It would also be nice to have predefinded alias names for A, B, C, X, Y, Z according to the table below, as well as "cross" (A), "circle" (B), "square" (Y), "triangle" (X).
I see the difficulty here: NORTH=X, EAST=Y as defined in libevdev is the other way around as normally seen on most pads.
Since I have actually got a gamepad natively using codes from the "joystick block", please consider to make those usable as well in the virtual gamepad event device. I used the game "Dex", a "platform action adventure RPG" to test, which did not "see" the codes, which lead me to try MG as a possible solution, so this would not have helped me here, but would extend MG to be useful for games made for old joysticks, but not gamepads.
From "input-event-codes.h" from "libevdev": Event codes for "old-fashioned joysticks":
#define BTN_JOYSTICK 0x120
#define BTN_TRIGGER 0x120
#define BTN_THUMB 0x121
#define BTN_THUMB2 0x122
#define BTN_TOP 0x123
#define BTN_TOP2 0x124
#define BTN_PINKIE 0x125
#define BTN_BASE 0x126
#define BTN_BASE2 0x127
#define BTN_BASE3 0x128
#define BTN_BASE4 0x129
#define BTN_BASE5 0x12a
#define BTN_BASE6 0x12b
#define BTN_DEAD 0x12fEvent codes for "modern gamepads":
#define BTN_GAMEPAD 0x130
#define BTN_SOUTH 0x130
#define BTN_A BTN_SOUTH
#define BTN_EAST 0x131
#define BTN_B BTN_EAST
#define BTN_C 0x132
#define BTN_NORTH 0x133
#define BTN_X BTN_NORTH
#define BTN_WEST 0x134
#define BTN_Y BTN_WEST
#define BTN_Z 0x135
#define BTN_TL 0x136
#define BTN_TR 0x137
#define BTN_TL2 0x138
#define BTN_TR2 0x139
#define BTN_SELECT 0x13a
#define BTN_START 0x13b
#define BTN_MODE 0x13c
#define BTN_THUMBL 0x13d
#define BTN_THUMBR 0x13e
NOTICE: Sorry, I just saw that I have mistyped the name of the device, and copied the wrong name to several places. The correct name (and use in file names) is "SL-6515-BK", the wrong one is "SL-6545-BK". Perhaps this is causing the problem of "weird implicit assumptions" described below. <—No: TESTED: Correcting the name in all places does not change anything in the behaviour described below. I leave the comments here instead of updating the whole text below to only use the correct name.
Hello,
I tried to get the "Thunderstrike" gamepad to work; the result: many hours of testing, and still no success.
Here's the "native" event list copied over from "evtest":
As you can see, they've used
BTN_TRIGGER(which I assume is meant for the first button of old, simple, non-gamepad joysticks) for the first button, and simply continued the assignment by increasing the key code by one for the 11 remaining "normal" buttons. This is a severe problem, because even "configurable" games, where you can remap buttons to in-game functions, ignore the events from most of the "special" buttons, so you cannot use them.Oddly, the right stick uses the two "Z" axis events. This seems to be related to the problem I have with MG.
The game pad has got a "mode" button, but that does not trigger an event on its own. Pressing it without pressing any other button produces events for the primary left stick's ABS_X and ABS_Y with the center values 128 (LED off->on), and 127 (LED on->off). It just changes the mode of operation, indicated through the LED. The event list doesn't change, but in the startup mode with LED=off, misleadingly named "digital", the "hat" events from the d-pad on the left side are remapped to the left stick events, and the right stick's events are remapped to the 4 "direction" buttons on the right side, so the startup mode after attaching the pad produces less different events, because the left stick and the d-pad do the same, as well as the right stick and the 4 buttons. So you generally want to use it in the "analogue" mode with LED=on.
So I've created a "generic driver definition" as follows, using the "gamepad" profile in my first attempt:
For my own event names for this pad I followed the button numbering by the manufacturer, and the actual button/stick locations and functions, I did not check for possibly overlapping definitions in the profiles in the repository.
This is my configuration file:
I've not yet chosen an install method, to facilitate debugging I've also not grabbed/hidden the original event device (tried both, just to be sure). Everything resides in
/usr/localand/var/tmp.Now the big problem is: the driver definition above seems to be correct to me, but the two lower front buttons do NOT get mapped to TL2/TR2 as defined, they produce axis events ABS_Z & ABS_RZ instead. Those even get "picked up" as core events from Xorg's "joystick" driver, resulting the pointer to be "dragged" to the top of the screen as soon as I press TR2. Conclusion: it gets somehow mapped to the left Y axis, but I don't see such events in "evtest" (I probably will, if I find the correct
/dev/input/event#and look into it). Without MG running, the ABS_RZ event from the gamepad's right stick does not lead to an Xorg core pointer event. MG should be able to coexist with the "joystick" driver, and not silently create weird mappings.Various attempts to remap those 2 buttons again in a second step have failed, also using the analogue trigger names of the internal gamepad profile instead. In most cases the buttons simply didn't do anything.
This is the event list created, note the missing TL2/TR2:
Note also that switching on "rumble" does not create/copy over the events EV_FF from the original event device.
My last attempt was to do everything on my own, trying not to use the gamepad profile, but the following profile definition:
The lines commented out are from previous futile attempts to remap things from the gamepad profile.
To switch to this configuration, I load the profile above, set
device_type = "THUNDERSTRIKE_SL-6545-BK", and (optionally, tried both) comment out the alias definitions.With that done – deliberately avoiding any "gamepad profile names", MGP says the following:
Note that MG still uses the internal "gamepad profile names".
This one makes the analogue remappings axis2… work, but all the normal digital buttons don't do anything. (Remark added later: it seems that this approach "sends" them to the "virtual keyboard" instead.)
The event list reported is exactly the same as the one created when using the "gamepad" profile. So this is implicitly still used?
My latest attempt:
Using "btn2btn" instead of "key" works, but creates wrong mappings! "btn_north" is translated to "first", which creates the event "btn_west" for me: effectively "north" and "west" get swapped. MG seems to have an inconsistent "view" of "first" and "third" being "north" or "west".
However, this doesn't change anything regarding TL2 & TR2: they get mapped to the two Z axis.
Now trying to avoid TL2 & TR2 entirely:
"Sort of" works:
Well, BTN_JOYSTICK is silently ignored, and BTN_C is silently remapped to BTN_EAST, despite having another "official" key code of 132. BTN_Z instead of BTN_JOYSTICK is also ignored.
How can I prevent MG from making wrong assumptions, or how can I get keycodes included into the created event device, which MG stubbornly considers to be "non-gamepad"? Perhaps the game would listen to the "ancient joystick trigger button", or the "esoteric" buttons "C" and "Z"…