Hi, [Adding Siarhei who added support for those controllers in the kernel] On Wed, Jan 31, 2024 at 7:27 AM Taco Jerkface <tacodog311@xxxxxxxxx> wrote: > > Resending without HTML: > > Hi, > > I hope this is the correct contact for this report, I found you as the > maintainer in the hid-microsoft.c. > > I believe there is a bug in the microsoft bluetooth driver for the > Xbox Elite Series 2 controller. I have been experiencing issues with > it that I initially thought were SDL related. However the SDL team > seems to think this is driver related. My SDL bug report information > is here: > > https://github.com/libsdl-org/SDL/issues/8907 Hard to say anything with that bug report because we don't know what those tools are supposed to do, and how they access the device (hidraw or evdev). Note that the bluetooth version is using uhid because it's a BLE controller. Basically when there is a BLE controller, bluez handles the transport layer from userspace, and injects the events through uhid so that it's handled as a normal kernel device. So there is no "uhid userspace driver", bluez just blindly forwards the events/reports/commands as it is told. > > Basically, SDL reads the controller correctly when connected by USB, > and if I run "controllermap" with root permission, but with user > permissions it misreads Using root or not shouldn't change the way your program sees the device: if you are capable of opening it, then you should get the same output. However, the immediate explanation that would come to my mind is that you are not using the "same" controller in both cases: - maybe that when you use it with root you are talking to the device through hidraw - maybe when you are not root you are talking to the device through evdev Again, not knowing the tools doesn't help me here :( > the number of buttons as 122, the first paddle > button on the back seems to act like the "screenshot" button from the > 1914 controller, and the other paddle buttons are not read. All > buttons read fine with evites, but the paddle buttons "KEY_UNKNOWN" > > type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0 > > Please let me know if there is a better contact for this, or if there > is anything I can do to help identify the problem. > Ideally I'd like Siarhei to answer here. But in the meantime, we could fetch some logs from the device itself which would allow me to better understand the issue: please use hid-recorder from hid-tools[1] to get the logs, and attach the whole output, with a recording of the events that are problematic: $> pip3 install hid-tools $> sudo hid-recorder Please dump 2 hid-recorder outputs, one with USB, and one with Bluetooth, with the same event sequence if possible so we can compare between the 2. Cheers, Benjamin [1] https://gitlab.freedesktop.org/libevdev/hid-tools
