Wrong mapping for buttons #343
Comments
|
Please check the permissions of the xpadneo rawhid device. Did you install RGB software or run qmk? It is most likely that Steam Input has access to the raw hid device. If it does, it uses SDL to directly read the raw device bypassing xpadneo. And SDL has wrong assumptions about our HID report format. First test would be to see if the kernel layers itself see the right mappings. Use Chances are that SDL probably works in rawhid mode. I'm pretty convinced SDL should not try to do that (or at least, only as a fallback) but still Proton et al ship with those patches. Look at Our udev rule ships with settings to disable permissions for the rawhid device but apparently, this becomes overwritten by some software with badly integrated udev rules, the most likely candidate is OpenRGB which ships with a udev rule that makes each rawhid device world readable and writable. I actually consider that a security issue but well, it is like it is currently. The way they deploy the udev rule completely prevents us from overriding that configuration. One other issue we discovered lately is a module loading order problem. You can also try if the problem goes away if you manually which indicates that hid-generic sees the controller first before we rebind the controller to hid-xpadneo. This somehow seems to confuse button mappings recently. |
|
Thank you #343 (comment) i finally fixed my mapping issues. Applying:
and:
fixed it although after reboot i had to do them both again. Removing openRGB and applying:
fixed it permanently. Even tho hid-generic now gets loaded 1st the mapping is correct and 2nd fix is not needed anymore after removing openRGB. |
Well, they unconditionally make all hidraw devices world read and writable... They'd rather need a udev helper which checks if it is really a RGB raw device - and if it isn't, leave the device alone. Currently, they override our own rules. The qmk project has already fixed that with a helper. I'd also suggest the current practice is security nightmare because any process may spy on your keypresses (e.g. password, banking pins). The underlying problem, tho, is an incompatibility between xpadneo and SDL when it comes to raw HID reports. This problem just uncovers what OpenRGB is doing wrong. |
|
If I read correctly, you made an interesting observation: Loading xpadneo first prevents the wrong permission bits. It seems like OpenRGB may actually only act on device nodes that are bound to hid-generic. This doesn't solve the security issue, tho... A lot of HID devices run through hid-generic because they can and need no special driver. Even the Xbox controller work with hid-generic out of the box, although they'll report 15 buttons instead of 10-11, and two additional axes. That can confuse games unless SDL just uses hidraw mode (which it can thanks to OpenRGB). |
|
@kakra I have the same issue of wrong mapping inside Steam games when connected via bt. I do have qmk on my machine as I work with their firmware. None of the recommended steps, changing permission or running modprobe, seems to be working. |
|
There are two other issues that you could hit: Loading the xpadneo kernel module before connecting the controller may work around this. Also, disabling Steam Input can work around it. |
|
I have tried re-installing |
|
@mr-ubik Then your issue may be slightly different. To get started, could you look at the permissions of the hidraw device created by xpadneo? To know which is the correct device, run |
|
Ok, to be clear I wasn’t using Steam Input. I got confused by the template. I simply had Steam installed. I don’t have the time to respond further at the moment but when I do I’ll provide more details.
… On 10 Apr 2022, at 5:08 am, Kai Krakow ***@***.***> wrote:
@mr-ubik Then your issue may be slightly different. To get started, could you look at the permissions of the hidraw device created by xpadneo? To know which is the correct device, run dmesg -W while connecting the controller, it will tell you a hidraw device name. Now run sudo getfacl /dev/hidraw## to get all applied permissions.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
|
Later kernels seem to cache devices when removed from a driver. This commit undoes our fixups so we can properly detect and reapply them when we see the device again, even if the device itself was never removed from the kernel. Fixes: atar-axis#340 Maybe-fixes: atar-axis#347 Maybe-fixes: atar-axis#343 Signed-off-by: Kai Krakow <[email protected]>
Later kernels seem to cache devices when removed from a driver. This commit undoes our fixups so we can properly detect and reapply them when we see the device again, even if the device itself was never removed from the kernel. Fixes: atar-axis#340 Maybe-fixes: atar-axis#347 Maybe-fixes: atar-axis#343 Signed-off-by: Kai Krakow <[email protected]>
Later kernels seem to cache devices when removed from a driver. This commit undoes our fixups so we can properly detect and reapply them when we see the device again, even if the device itself was never removed from the kernel. Fixes: #340 Maybe-fixes: #347 Maybe-fixes: #343 Signed-off-by: Kai Krakow <[email protected]>
Version of xpadneo
0.9.r96.g4fd620c-1
xpad-neo-dkms-git from chaotic-aur
Controller Model
Connection mode
Installed Software
Severity / Impact
Describe the Bug
The button mapping is almost entirely wrong.
Steps to Reproduce
Connect via bluetooth.
Expected Behavior
Button mapping should be the same as not using xpadneo.
Screenshots / GIFs / Videos
System Information
Controller and Bluetooth Information
xpadneo-btmon.txt
xpadneo-dmesg.txt
xpadneo-lsusb.txt
Additional Context
Please let me know any other way I can help.
The text was updated successfully, but these errors were encountered: