Switch to a signed range for ABS_ values

[ipkpjersi]

Describe the bug
When I use my Xbox One controller with RPCS3, it does not work properly with the control sticks. For example, when I press left on the left control stick it looks like this: https://i.imgur.com/EEXovM7.png and when I press up on the left control stick it looks like this: https://i.imgur.com/LhhWiWt.png

Notice that it is always in the bottom right center of the stick. The other buttons work fine both in gamepad settings and in games. My Wireless 360 controller with the 360 PC adapter works perfectly 100% as expected in RPCS3.

To Reproduce
Steps to reproduce the behavior:

1. Download RPCS3 then run it and go to Gamepads Settings (Pads)
2. Connect your XB1 controller and change handler to Evdev
3. Move either of the control sticks in either direction.
4. See error

Expected behavior
I expect the control sticks to work properly.

System information:
Linux fast-desktop 4.15.0-39-generic #42~16.04.1-Ubuntu SMP Wed Oct 24 17:09:54 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 16.04 with Xfce 4.12

Additional Information
Is this an RPCS3 issue or xpadneo issue?

[atar-axis]

hey there!

please run evtest /dev/input/eventX (please replace X with the number your gamepad has - mostly the biggest one in this folder).

how does the output look like of you move the stick as you described?

[ipkpjersi]

Here is what it looks like when I move the left stick to the left:

https://hastebin.com/zovoveyawe.css

Here is what it looks like when I move the left stick up:
https://hastebin.com/vugomikegi.sql

I'm not an expert but it looks okay to me. The controller works great for games like Geometry Wars 3, Halo 1, Gears of War 1, etc.

[atar-axis]

I installed RPCS3.
The problem seems to be that RPCS3 expects values in another range (most probably from –32.768 to 32.767) while xpadneo does report values from 0 to 65.535 for the absolute axis like ABS_RX.

Should be a configuration issue in RPCS3 - let's see.
edit: see RPCS3/rpcs3#3817 and RPCS3/rpcs3#3962

[atar-axis]

@ipkpjersi: could you please give me a log for the evtest output (without pressing any button) for the Wireless 360 gamepad?

I am especially interested in the following two parts:

    Event code 0 (ABS_X)
      Value  34804
      Min        0
      Max    65535
      Flat    4095
    Event code 1 (ABS_Y)
      Value  33617
      Min        0
      Max    65535
      Flat    4095

and

    Event code 3 (ABS_RX)
      Value  33386
      Min        0
      Max    65535
      Fuzz     255
      Flat    4095
    Event code 4 (ABS_RY)
      Value  35413
      Min        0
      Max    65535
      Fuzz     255
      Flat    4095

[atar-axis]

Hey again! I had contact to GalCiv (one of the RPCS3 developers), he pointed me to the following issue: RPCS3/rpcs3#3974

That means that the problem is on their side but there is a workaround described in the issue, in short:

• open ~/.config/rpcs3/evdev_positive_axis.yml
• change false to true in the following lines:
  • ABS_X: false
  • ABS_Y: false
  • ABS_RX: false
  • ABS_RY: false

Maybe xpadneo should switch to a range from –32.768 to 32.767 in future version... I am not yet sure.
I would be still interested in the evtest log for the other gamepad.

[atar-axis]

Okay, I have to backpedal... looks like the problem is on my side too. I will definitely switch to a signed range in the next version! Thank you Megamouse for pointing out!

I decided so because:

1. The linux gamepad spec does advice so: https://www.kernel.org/doc/html/v4.18/input/gamepad.html
2. Other drivers do that as well (e.g. xpad)

Thanks @ipkpjersi you for reporting!

[ipkpjersi]

Sorry, I was sleeping while you made all this excellent progress! I'm glad you were able to narrow down the issue and will be fixing it. If you need me to test a beta build feel free to give me a holler. Thanks again for all your hard work.

edit: I just tested the evdev_positive_axis workaround and it is working quite well, thanks once again.

[atar-axis]

hey there @ipkpjersi , could you please give it a try?

git clone https://github.com/atar-axis/xpadneo -b axis_offset
I think you already know the other stuff like uninstalling the old version and so on...

I would really appreciate if you could test it at least on Steam, RPCS3 (wo the hackaround) and maybe some other common systems you use.

Thanks!

[ipkpjersi]

I just tried it and the right stick works perfectly, but the left stick completely spazzes out. I'm not sure how to describe it, so I will show a gif:

I made sure to uninstall it, reboot, install it, reboot, and it started doing this. I also made sure I had removed ~/.config/rpcs3/evdev_positive_axis.yml as well.

[atar-axis]

hey there! thanks for testing - on my machine it was working as expected. strange. I will take a closer look.

[atar-axis]

hum, I have no idea at the moment where the problem is - it is perfectly running on my machine. the visualization is a bit slow but that's it - maybe the problem is just the visualization on your machine too? have you tried it already ingame?

[ipkpjersi]

Hi,

In-game acts very strangely, it goes all the way to the left in RPCS3. I will delete all RPCS3 config files and try the latest version, I will also try other games and let you know how it goes.

Thanks.

[atar-axis]

thanks! could you maybe also take a look at evtest /dev/input/event<X> | grep ABS_RX?

[ipkpjersi]

Hi,

I tested that and both ABS_RX and ABS_RY were completely empty when I moved only the left stick, there is no output when I run that command.

I then tested it in Geometry Wars 3 and the button mappings were wrong - for example, pressing the start button made the game go left. I will uninstall, reboot, reinstall, reboot and then report back.

edit:
I've uninstalled, rebooted, installed, rebooted and made sure I am using the correct xpadneo branch. I am still experiencing the same weird behavior in Geometry Wars 3 - pressing b is now the a button, x is now the b button, pressing start goes to the left then when I go in-game I can only go up and down using the left stick - I cannot move from side to side. This basically mimics the behavior I was seeing on RPCS3. Also, I deleted all RPCS3 config files and I am still experiencing the same weird joystick behavior. I will go back to the master branch and I'll let you know if it works again.

edit 2: It gets even weirder. I went back to the master branch and the control sticks are working now, but in Geometry Wars 3, start still takes me left and b is still a, x is still b, etc. However, RPCS3 is now behaving as it was when I originally created this report so I guess things are "back to normal" and whatever issues I am having are basically with the changes in the new branch.

Thanks.

[atar-axis]

I tested that and both ABS_RX and ABS_RY were completely empty when I moved only the left stick, there is no output when I run that command.

It is the right stick which you need to move 😁
Could you please compare the output (which should range from -32xxx to +32xxx) to the output of evtest /dev/input/event<X> | grep ABS_X while moving the left stick.

Maybe you could also make me a gif again of the output of evtest /dev/input/event<X> | grep ABS_X

Thanks!

P.S.: Let's talk about the Geometry Wars 3 problem afterwards

[ipkpjersi]

Here is the left stick:

https://hastebin.com/socebebili.bash

Here is the right stick:

https://hastebin.com/sabonifiku.bash

[atar-axis]

I pushed a new version which includes some debug output.

Please, in addition to the above, do me a favour and do the following:

1. tell me the output of evtest /dev/input/event<X> (wo pressing any button)
2. activate debug_level 3 - I think you already know how to do that - right? 😁
3. run dmesg -w | grep shifted while moving the axis in question and share the output with me

Thanks!

[ipkpjersi]

Hi,

I'm actually not sure how to do debug_level 3

Thanks.

[atar-axis]

Simply run echo "options hid_xpadneo debug_level=3" | sudo tee /etc/modprobe.d/xpadneo.conf and reboot 😁

[ipkpjersi]

Here is evtest without pressing any buttons before debug_level 3: https://hastebin.com/cadepezipi.bash

Here is dmesg -w | grep shifted first going up and down then going left and right:

Here is evtest without pressing any buttons after debug_level 3:
https://hastebin.com/ifotabuqof.bash

[kakra]

Okay, let's reopen that. I've researched the issue a little, looked at the issue tracker of RPCS3 and at the kernel input layer specs. We should probably bring back the axis shifting and make it default. But I'd like to look at the Wine sources a little more first, they seem to craft their own HID description layers around what SDL tells about the gamepads. Maybe we can find a way to make all parties happy without manual configuration.

If I understand modules correctly, ...

From your point of view, modules are just drivers similar to what you know from Windows. But it's called a module because the kernel is monolithic: Everything you load into the kernel will become part of the kernel and runs in kernel context / kernel space - thus it's a module (to put it simple, and xpadneo is no exception although it's not delivered as "part of the kernel"). The Windows kernel is different: It's a microkernel, it provides only a minimal set of very low-level functions, i.e. for drivers to talk to each other. Except for a few kernel level drivers, most drivers you load in Windows are services running in user space (similar to a daemon you are running in Linux). It's a completely different architectures. Windows drivers are not part of the kernel.

And actually your understanding is correct: You can just unload modules (at least most distro kernels allow that). So rebuilding xpadneo is a matter of rmmod followed by modprobe after reinstalling it. I've included a command in v0.7 that supports just that. Try running make -C hid-xpadneo from the source code project root (the directory you checked out with git): It should rebuild the driver (as long as /usr/src/linux exists), asks for the root password and reinstalls and reloads the driver.

You can even change parameters of the module while it is loaded, without unloading and reloading: Go to /sys/modules/hid_xpadneo/parameters: There a bunch of files and you can write parameters to those files: echo 1 | sudo tee /sys/modules/hid_xpadneo/parameters/combine_z_axis will turn the combine z axis feature on. The change isn't permanent across reboots/module reloads unless you put it into /etc/modprobe.conf.

[ipkpjersi]

If this functionality does become default (this is how I always used it for all games with Proton/Wine and of course RPCS3 it worked great in everything I tried), I definitely think we should have the opposite functionality available as a module parameter - it's a great idea, assuming you don't come up with an even better idea somehow. I'm a big fan of options and customizations whenever possible (which is part of why I like Linux so much). :)

[kakra]

Yes, but my credo is "convention over configuration". That means everything should work by default while still leaving everything open for configuration. So sure you'll get your parameters but I want to have it in a way that requires no manual configuration for the usual user.

[kakra]

Note to myself:

• Investigate how this interacts with the Wine HID driver for gamepads