evdev configuration has more buttons than jsdev #359
Comments
|
According to your This uses hid-microsoft as the final driver. The logs seem somewhat inconsistent, the XB1S controller firmware should not have How did you install the driver? At a first glance, this looks like xpadneo wasn't even loaded which could mean that the file in
I'd like to ask you to test #325 - it has a backport of the above mentioned commit (plus a lot other fixes). Plain xpadneo master should also work. The queue/for-0.10 branch doesn't actually include any commits relevant for this issue, it's just two commits ahead of master. Both
I'm not sure if it is a good idea to combine jsdev and evdev. Any evdev joystick device will automatically show up in jsdev (it's actually what jsdev uses as the lower layer). And I'm not sure if there even exist devices that would only be shown in jsdev but not in evdev. As an example, it seems SDL dropped support for You are seeing two different set of buttons in this bug case because jsdev ignores evdev button bits before Maybe jinput does have a setting to just ignore jsdev and use evdev alone? (a quick glance says "no") I know that the Chrome gamepad API uses a very similar approach and compares jsdev and evdev, then uses evdev to map the buttons and axes, but then uses jsdev to read the values, which creates all sorts of funny effects if the order of mappings does not match (jsdev can actually re-order buttons using the jscal application to make things match jsdev games expectations). Simply speaking, it's bad design: Those both APIs have nothing in common except that jsdev creates devices from evdev in the kernel, they should not be used in combination, at least not in the way Chrome does it, I don't know jinput. |
|
Thanks so much for the detailed explanation! |
|
Thanks for testing. Yes, the mentioned commit removes the key events from the main device, thus it also fixes jinput because that no longer sees the additional key bits. The v0.9 branch won't have this commit backported. Maybe we should filter out buttons in v0.9 that jsdev cannot support instead. Could you try changing v0.9 xpadneo.h to use different event ids? Change (near the top of the file) #define BTN_SHARE KEY_RECORD
#define BTN_XBOX KEY_MODEto #define BTN_SHARE BTN_TRIGGER_HAPPY1
#define BTN_XBOX BTN_MODEI'll reopen this so we can make a v0.9-only fix for it. |
|
That works perfectly! Thanks :) |
Do not expose keyboard events to the gamepad device as this may confuse user-space software that's using evdev and jsdev in combination, and is against the spec anyways. Later versions of xpadneo split the gamepad into sub-devices per each category of buttons, and thus don't need this fix. Fixes: atar-axis#359 Signed-off-by: Kai Krakow <[email protected]>
Do not expose keyboard events to the gamepad device as this may confuse user-space software that's using evdev and jsdev in combination, and is against the spec anyways. Later versions of xpadneo split the gamepad into sub-devices per each category of buttons, and thus don't need this fix. Fixes: #359 Signed-off-by: Kai Krakow <[email protected]>
A new SDL gamecontrollerdb entry allows us to get rid of the Xbox button fixup we are carrying around. While this button is still not exactly a button for games, all software expects it to be part of the gamepad mapping anyways. This leaves only the Share button left in the consumer control bits which doesn't have an jsdev equivalent. Affects: atar-axis#286 Maybe-affects: atar-axis#283 Fixes: atar-axis#362 Fixes: atar-axis#359 Closes: atar-axis#301 Signed-off-by: Kai Krakow <[email protected]>
A new SDL gamecontrollerdb entry allows us to get rid of the Xbox button fixup we are carrying around. While this button is still not exactly a button for games, all software expects it to be part of the gamepad mapping anyways. This leaves only the Share button left in the consumer control bits which doesn't have an jsdev equivalent. Affects: #286 Maybe-affects: #283 Fixes: #362 Fixes: #359 Closes: #301 Signed-off-by: Kai Krakow <[email protected]>
Version of xpadneo
0.9.1
Controller Model
Connection mode
Installed Software
Severity / Impact
Describe the Bug
It's not clear to me whether this is really a bug in xpadneo, or a wrong expectation, so this is a question as much as anything. We have a robotics application that uses a third-party library (jinput) that looks at both js* and event* for controllers. If determines that the same controller is showing up on both interface by (amongst other things) comparing the set of axes and buttons. With xpadneo v0.9.1, evtest returns a KEY_RECORD button that does not appear on the jstest output, causing the library to think that there are two controllers present. This does not happen on the queue/for-0.10 branch, and I can also work-around the problem by commenting out the usage map entry for KEY_RECORD in 0.9.1.
So, is it a bug that the jsdev and evdev have a different number of buttons, or is this a bad assumption by the library?
Steps to Reproduce
Nominal install of v0.9.1. Run evtest and jstest.
Expected Behavior
evtest and jstest report the same set of axes and buttons
Screenshots / GIFs / Videos
System Information
Controller and Bluetooth Information
Additional Context
xpadneo-lsusb.txt
xpadneo-dmesg.txt
xpadneo-btmon.txt
The text was updated successfully, but these errors were encountered: