Logitech F310, doesn't work correct after the last update.

[ghost]

I have a Logitech F310 gamepad, after the latest update of xpad (commit: 154c208) some controllers buttons doesn't work in game(A,B,X,Y, START,SELECT). The only buttons that are working are the D-pad and L,R. After i downgrade the driver (commit: bc930a5) the controller start to working again.

Machine: Raspberry Pi3 3B+
Gamepad : Logitech F310 (xinput mode)
Operating System: RetroPie version 4.7.21 (Debian Buster Lite 32Bit)
Kernel : Linux retropie 5.10.103-v7l+ #1441 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l GNU/Linux

dmesg:
[ 39.949301] usb 1-1.5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 39.949310] usb 1-1.5.4: Product: Gamepad F310 [ 39.949317] usb 1-1.5.4: Manufacturer: Logitech [ 39.949325] usb 1-1.5.4: SerialNumber: F23C7DEA [ 39.951929] input: Logitech Gamepad F310 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.4/1-1.5.4:1.0/input/input10

[Fmstrat]

@gdniw the latest commit added support for BTN_1 - BTN_4 on Elite controllers, and my guess is the F310 is may be sending the same codes for ABXY as those buttons. It may be that we need to separate out the Elite controller bindings from other XBox One style bindings. Are you familiar with turning on DEBUG mode and providing some output?

[ghost]

@gdniw the latest commit added support for BTN_1 - BTN_4 on Elite controllers, and my guess is the F310 is may be sending the same codes for ABXY as those buttons. It may be that we need to separate out the Elite controller bindings from other XBox One style bindings. Are you familiar with turning on DEBUG mode and providing some output?

I am not very familiar. I try to follow the instructions on the first page, i run first dmesg --level=debug --follow and then i open a new terninal and i run succesfully the jstest /dev/input/js0 but nothing appear on the log.
`

[ghost]

It looks that the change affect more controllers than F310. I have the same issue with Logitech F710 and there two reports on the RetroPie forum with the same problems with 8bitdo SN30 Pro Wired and Xbox 360 controller'
Thanks

[paroj]

I moved the faulty commit to a separate branch (xpadone_paddles) and reset master until this is resolved.

seems xpad_common_btn is the wrong place to add controller specific buttons:

xpad/xpad.c

Lines 1802 to 1803 in bc930a5

	for (i = 0; xpad_common_btn[i] >= 0; i++)
	input_set_capability(input_dev, EV_KEY, xpad_common_btn[i]);

[Fmstrat]

Smart move, wish I had more devices to test with. I will address this by adding a separate custom button section.

[kakra]

@gdniw the latest commit added support for BTN_1 - BTN_4 on Elite controllers, and my guess is the F310 is may be sending the same codes for ABXY as those buttons. It may be that we need to separate out the Elite controller bindings from other XBox One style bindings. Are you familiar with turning on DEBUG mode and providing some output?

I'm the developer of xpadneo.

First and most important: the default Elite profile aliases those paddles to A,B,X,Y - you'd need to switch to profile 1, 2, or 3, to actually get those reported separately by the controller - at least in HID mode but I suspect it's the same in GIP mode (USB, donlge).

But nonetheless important: The driver is not allowed to use BTN_1..BTN_4. These have lower keycodes and will be ordered before the expected button map, and thus invalidate all assumptions user-space makes. Also, they are from the BTN_MISC range and thus identify a misc input device. User-space uses a heuristic where it checks for the first button to devide whether a device is a joystick (BTN_JOYSTICK), a gamepad (BTN_GAMEPAD), a mouse (BTN_MOUSE) or some other device (BTN_MISC). You are not allowed to mix button maps from different categories, otherwise the heuristic breaks. There are few exception when it is allowed for some device to overflow keycodes into the next category. Instead, for this purpose, the BTN_TRIGGER_HAPPY category should be used. As far as I understand, it is allowed to be used as an overflow category for joysticks and gamepads with many buttons. And they will order behind the well-known gamepad mappings which is important.

Here's some thought about it and historical background: atar-axis/xpadneo#286

ping @paroj

[paroj]

@kakra I read if we use BTN_TRIGGER_HAPPY5..BTN_TRIGGER_HAPPY8 instead of BTN_1..BTN_4 we should be fine?

[kakra]

Yeah, that's what I suspect. It should be tested, tho. Also, some additional thought should be put into that regarding future updates to the mapping with new controllers. We already have a Share button which doesn't really match any game input button in Linux. So it should probably be put into the same category.

At this point it may make sense to expose all buttons in the input mapping even if that particular model does not support it. This makes live easier for user-space layers like SDL because they don't need to add an additional mapping for each model. IOW, the positional meaning of a button should be kept in place: BTN_A should always be at position 1, B at 2 etc. I'm currently considering a similar model for xpadneo.

[paroj]

This makes live easier for user-space layers like SDL because they don't need to add an additional mapping for each model.

I dont think this is particularly important. Their API provides SDL_CONTROLLER_BUTTON_B, which they need to remap anyway given this:

also, the xpad driver exposes the DPAD on the x360 differently, depending whether it wireless or not. Yes, this is insane - but cleaning it up will mean breaking SDL..

[kakra]

Yep, touching existing behavior is problematic. SDL should really look at evdev symbols instead of button positions. This could eliminate the need for a lot of mapping entries. The Xbox controllers usually provide a proper evdev symbol mapping in HID mode even without special drivers. Non-HID drivers like xpad should try to achieve something similar, maybe even try matching the symbolic mapping of the HID profile. For existing buttons, it's too late. But future updates should try adding new buttons only behind the well-known positions so it doesn't conflict with existing user-space.

Position is dictated by the event code number of the kernel: They are simply ordered by code number by walking the bits in the button map. This is exactly how jsdev works. And SDL uses the same scheme. The SDL controllerdb is just a conversion table from bit position to symbol name. Thus they are reverting what the kernel did (the HID layer converts HID bitmap positions to symbols, SDL "converts" that back to positions, and then to SDL event symbols).

[Fmstrat]

@kakra I read if we use BTN_TRIGGER_HAPPY5..BTN_TRIGGER_HAPPY8 instead of BTN_1..BTN_4 we should be fine?

I will give this a shot in the new update. I've already limited it down to just within the Elite controllers identifier (just haven't pushed/fully tested yet). Thanks everyone.

[medusalix]

Keep in mind that the paddle bits can be in different positions based on the firmware version of your controller:

https://github.com/libsdl-org/SDL/blob/7c421fec16ccdc7cfb44b7f9120469d5e24db6e5/src/joystick/hidapi/SDL_hidapi_xboxone.c#L534-L545

[kakra]

AFAIR, at least in HID mode, the paddle bits will activate the same time as if button A,B,X,Y is pressed - while in profile 0. So in profile 0, the paddle bits should be masked so a game doesn't see two buttons virtually depressed at the same time.

[Fmstrat]

Keep in mind that the paddle bits can be in different positions based on the firmware version of your controller:

https://github.com/libsdl-org/SDL/blob/7c421fec16ccdc7cfb44b7f9120469d5e24db6e5/src/joystick/hidapi/SDL_hidapi_xboxone.c#L534-L545

AFAIR, at least in HID mode, the paddle bits will activate the same time as if button A,B,X,Y is pressed - while in profile 0. So in profile 0, the paddle bits should be masked so a game doesn't see two buttons virtually depressed at the same time.

Agreed, the paddle activation in the original PR is for profile 0, when all three lights are off on the controller. This is how most users use the Elite on PC for mapping and/or remapper/reWASD. I'll have a new PR tomorrow most likely.

[paroj]

@gdniw can you test again with current master? we updated the paddles code so it should no longer interfere with other gamepads

[ghost]

@gdniw can you test again with current master? we updated the paddles code so it should no longer interfere with other gamepads

I test it and it's working fine. Many many thanks !