kakra
commented
2 years ago According to your dmesg log, you're not actually using xpadneo:
[ 157.148540] hid-generic 0005:045E:02FD.0003: unknown main item tag 0x0
[ 157.148785] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/bluetooth/hci0/hci0:11/0005:045E:02FD.0003/input/input18
[ 157.148946] input: Xbox Wireless Controller Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/bluetooth/hci0/hci0:11/0005:045E:02FD.0003/input/input19
[ 157.149057] hid-generic 0005:045E:02FD.0003: input,hidraw2: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on 00:02:72:c9:53:f6
[ 157.282468] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/bluetooth/hci0/hci0:11/0005:045E:02FD.0003/input/input20
[ 157.282611] microsoft 0005:045E:02FD.0003: input,hidraw2: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on 00:02:72:c9:53:f6This uses hid-microsoft as the final driver.
The logs seem somewhat inconsistent, the XB1S controller firmware should not have KEY_MODE. Is this the first connect after boot or a later re-connect? There also seems to be a change to how modern kernels handle driver binding and how this interacts with our udev rules. It has been fixed after v0.9.1 but not yet pushed to stable (https://github.com/atar-axis/xpadneo/commit/b6c070831e418b0cfc4e604e4f6687530d66da0a).
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 etc/modprobe.conf.d is missing. Loading the driver manually before connecting the controller can work around that.
This does not happen on the queue/for-0.10 branch
I'd like to ask you to test https://github.com/atar-axis/xpadneo/pull/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 KEY_* event items should actually be present in a separate device so jsdev wouldn't actually see them. Those are not strictly joystick buttons (where the Guide button is subject to discussion, at least it is in the wrong position by how evdev is involved).
If determines that the same controller is showing up on both interface by (amongst other things) comparing the set of axes and buttons.
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 /dev/js* in Linux long ago.
You are seeing two different set of buttons in this bug case because jsdev ignores evdev button bits before BTN_JOYSTICK (which makes it ignore KEY_RECORD) but it will probably map all button bits after it even if they fall out of gamepad/joystick ranges (KEY_MODE). If you adjust your code (or rather jinput) to do the same, it should match again. But I'm not sure if the old jsdev interface should be used at all, I'd rather look into supporting only evdev unless you want to support hardware that is only present on jsdev (I don't know of any except maybe classical old gameports from the last millenium).
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.
markpaters
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