Joystick testing thread

[Sorgelig]

I remember having seen some mouse emulation configuration during controller setup and I assumed it would use analog stick for mouse movement (just like I use to do with WinUAE). Am I wrong?

You can emulate mouse on gamepad using both analog and digital stick/pad. Currently only axis 0/1 will be used as analog for mouse emulation. Other axis or buttons are used as digital input for mouse emulation so mouse speed is constant if digital buttons are used for movement. Cores are unaware about this trick and receive original mouse events.

[Sorgelig]

XInput devices availability is exaggerated in my opinion. Although it's not new standard, it's not wide used. Most controllers came from or targeted to consoles, so most devices use simple USB definitions. Some controllers may have windows drivers to provide XInput API but this is pure windows thing. If you use device on linux, then you deal with under laid USB i/o where no body hear about xinput
8bitdo devices are piggybacking on existing VID/PID from Microsoft and thus have one of mode closely matching XBOX pad, so they call it as "xinput" mode. Together with Microsoft drivers it just acts as original XBOX pad.
Actually it's illegal to use someone's VID/PID, but yeah.. who care in China

Devices with their own VID/PID may have completely different data from sticks/buttons. With proper driver from manufacturer it will be converted to standard XInput/DInput on windows.

I would like to add that I’d like to try to compile your kernel and the xpad kernel driver https://github.com/paroj/xpad it seems to contain all the custom acknowledgment and handshaking required by some pads. If I have success I’ll perform some other tests and share the kernel module. I’m a Windows dev, with some experience with compilation of unix user space code under native Linux (no cross compiling), OSX and Windows-Cygwin; I never compiled any kernel, driver and never cross compiled any code.

i didn't understand what that driver provide. Current kernel driver works fine already. If it works, why need to change?

[Locutus73]

You can emulate mouse on gamepad using both analog and digital stick/pad. Currently only axis 0/1 will be used as analog for mouse emulation. Other axis or buttons are used as digital input for mouse emulation so mouse speed is constant if digital buttons are used for movement.

Here all the infos we are collecting about xinput event mapping come handy if we confirm that left analog is always axis 0/1 and right analog is always on axis 3/4

Cores are unaware about this trick and receive original mouse events.

This seems to me the correct and most logical way to send this data to the cores. Regarding this I have some ideas about sending keyboard keystrokes to cores using joypad, but I’ll share them on the usability thread.

XInput devices availability is exaggerated in my opinion. Although it's not new standard, it's not wide used. Most controllers came from or targeted to consoles, so most devices use simple USB definitions. Some controllers may have windows drivers to provide XInput API but this is pure windows thing. If you use device on linux, then you deal with under laid USB i/o where no body hear about xinput
8bitdo devices are piggybacking on existing VID/PID from Microsoft and thus have one of mode closely matching XBOX pad, so they call it as "xinput" mode. Together with Microsoft drivers it just acts as original XBOX pad.
Actually it's illegal to use someone's VID/PID, but yeah.. who care in China

Intellectual property and China… don’t mix and match.
[EDIT]At last you agree with me you have implemented Wired XBox360 Controller support, not just 8bitdo, and you should edit your last MiSTer: updates changelog post [/EDIT]
Anyway, exaggerated or not, I think that correctly handling VID:PID (045e:028e) is a great enhancement for MiSTer.

Devices with their own VID/PID may have completely different data from sticks/buttons. With proper driver from manufacturer it will be converted to standard XInput/DInput on windows.

Here I’m not totally convinced: I mean I suspect that, if you design a xinput controller, you must have “IG_” in your Device ID string (i.e. "VID_045E&PID_028E&IG_00") and then you have to adhere to a standard event/axis mapping based upon the device subtype you’re implementing (gamepad, dance pad, guitar, guitar alternate, drum kit, guitar bass, arcade stick, arcade pad, wheel, flight stick). Doing so you don’t have to provide any driver on modern Windows.
Again I’m not 100% sure, I’m investigating this and speculating here.

I would like to add that I’d like to try to compile your kernel and the xpad kernel driver https://github.com/paroj/xpad [...]

i didn't understand what that driver provide. Current kernel driver works fine already. If it works, why need to change?

If you take a look to https://github.com/paroj/xpad/blob/master/xpad.c line 460 and subsequent, you can see that this driver implements initialization packets needed by some controllers (do you remember when I was talking about possible acknowledgement/handshaking). This seems to be consistent with some tests where we can see VIDs and PIDs, but no events. Compiling this module for this main reason, we could benefit from some frivolous features, like fiddling with /sys/class/leds/xpadN/brightness in order to change the status led of the joypads; i.e. it seems to me that MiSTer controls if a joypad is treated as emulated joystick n.1 or 2, this could be reflected by the respective joypad led.

Locutus73

[Sorgelig]

I've replaced original xpad driver inside the kernel, so you can test:
https://mega.nz/#!IEJW2b7Z!SIZMQ8wL3_DB ... vQoJzq-Vt8

Original xpad driver also supports LEDs and FF, by the way.

[Locutus73]

I've replaced original xpad driver inside the kernel, so you can test:
https://mega.nz/#!IEJW2b7Z!SIZMQ8wL3_DB ... vQoJzq-Vt8

Original xpad driver also supports LEDs and FF, by the way.

We should coordinate bro, so we can offload you. Guess what? This evening I compiled your kernel with the last xpad.c (just like you did) and did some tests.
First, compiling the kernel (it was the first time I compiled the kernel and I crosscompiled anything), I discovered that the current kernel contains the xpad driver (as you just said), an old version, but still a working version so I did some tests with the current kernel.
I tried again the Wireless Xbox360 joypad with the sync’n’charge cable, but, again I got nothing. Then I tried the Wireless Xbox360 joypad with the official Microsoft dongle and boom! It works, correctly lighting the second led (because it was the second joypad connected). Here’s the observed events:

Code: Select all

XBox360 Wireless + Microsoft dongle  (045e:0719)

UP:Input event: type=EV_KEY, code=706(0x2c2), value=1
Input event: type=EV_ABS, Axis=17, Offset:=-1
Input event: type=EV_KEY, code=706(0x2c2), value=0
Input event: type=EV_ABS, Axis=17, Offset:=0

DOWN:Input event: type=EV_KEY, code=707(0x2c3), value=1
Input event: type=EV_ABS, Axis=17, Offset:=1
Input event: type=EV_KEY, code=707(0x2c3), value=0
Input event: type=EV_ABS, Axis=17, Offset:=0

LEFT:Input event: type=EV_KEY, code=704(0x2c0), value=1
Input event: type=EV_ABS, Axis=16, Offset:=-1
Input event: type=EV_KEY, code=704(0x2c0), value=0
Input event: type=EV_ABS, Axis=16, Offset:=0

RIGHT:Input event: type=EV_KEY, code=705(0x2c1), value=1
Input event: type=EV_ABS, Axis=16, Offset:=1
Input event: type=EV_KEY, code=705(0x2c1), value=0
Input event: type=EV_ABS, Axis=16, Offset:=0

A:Input event: type=EV_KEY, code=304(0x130), value=1
Input event: type=EV_KEY, code=304(0x130), value=0

B:Input event: type=EV_KEY, code=305(0x131), value=1
Input event: type=EV_KEY, code=305(0x131), value=0

X: Input event: type=EV_KEY, code=307(0x133), value=1
Input event: type=EV_KEY, code=307(0x133), value=0

Y: Input event: type=EV_KEY, code=308(0x134), value=1
Input event: type=EV_KEY, code=308(0x134), value=0

LB:Input event: type=EV_KEY, code=310(0x136), value=1
Input event: type=EV_KEY, code=310(0x136), value=0

RB:Input event: type=EV_KEY, code=311(0x137), value=1
Input event: type=EV_KEY, code=311(0x137), value=0

LT:Input event: type=EV_ABS, Axis=2, Offset:=26
Input event: type=EV_ABS, Axis=2, Offset:=48
Input event: type=EV_ABS, Axis=2, Offset:=73
Input event: type=EV_ABS, Axis=2, Offset:=99
Input event: type=EV_ABS, Axis=2, Offset:=123
Input event: type=EV_ABS, Axis=2, Offset:=156
Input event: type=EV_ABS, Axis=2, Offset:=164
Input event: type=EV_ABS, Axis=2, Offset:=191
Input event: type=EV_ABS, Axis=2, Offset:=209
Input event: type=EV_ABS, Axis=2, Offset:=232
Input event: type=EV_ABS, Axis=2, Offset:=241
Input event: type=EV_ABS, Axis=2, Offset:=252
Input event: type=EV_ABS, Axis=2, Offset:=255
Input event: type=EV_ABS, Axis=2, Offset:=235
Input event: type=EV_ABS, Axis=2, Offset:=161
Input event: type=EV_ABS, Axis=2, Offset:=109
Input event: type=EV_ABS, Axis=2, Offset:=62
Input event: type=EV_ABS, Axis=2, Offset:=24
Input event: type=EV_ABS, Axis=2, Offset:=0

RT:Input event: type=EV_ABS, Axis=5, Offset:=57
Input event: type=EV_ABS, Axis=5, Offset:=116
Input event: type=EV_ABS, Axis=5, Offset:=182
Input event: type=EV_ABS, Axis=5, Offset:=255
Input event: type=EV_ABS, Axis=5, Offset:=254
Input event: type=EV_ABS, Axis=5, Offset:=210
Input event: type=EV_ABS, Axis=5, Offset:=138
Input event: type=EV_ABS, Axis=5, Offset:=60
Input event: type=EV_ABS, Axis=5, Offset:=0

L3:Input event: type=EV_KEY, code=317(0x13d), value=1
Input event: type=EV_ABS, Axis=1, Offset:=1279
Input event: type=EV_ABS, Axis=1, Offset:=895
Input event: type=EV_ABS, Axis=1, Offset:=383
Input event: type=EV_KEY, code=317(0x13d), value=0

R3:Input event: type=EV_KEY, code=318(0x13e), value=1
Input event: type=EV_ABS, Axis=4, Offset:=-129
Input event: type=EV_ABS, Axis=4, Offset:=-513
Input event: type=EV_ABS, Axis=4, Offset:=-1025
Input event: type=EV_ABS, Axis=3, Offset:=1649
Input event: type=EV_ABS, Axis=3, Offset:=2157
Input event: type=EV_ABS, Axis=4, Offset:=-1537
Input event: type=EV_ABS, Axis=4, Offset:=-2177
Input event: type=EV_ABS, Axis=4, Offset:=-2561
Input event: type=EV_ABS, Axis=3, Offset:=2665
Input event: type=EV_ABS, Axis=4, Offset:=-1921
Input event: type=EV_ABS, Axis=4, Offset:=-1
Input event: type=EV_ABS, Axis=3, Offset:=2284
Input event: type=EV_ABS, Axis=3, Offset:=1776
Input event: type=EV_ABS, Axis=4, Offset:=639
Input event: type=EV_KEY, code=318(0x13e), value=0

BACK: Input event: type=EV_KEY, code=314(0x13a), value=1
Input event: type=EV_KEY, code=314(0x13a), value=0

START:Input event: type=EV_KEY, code=315(0x13b), value=1
Input event: type=EV_KEY, code=315(0x13b), value=0

GUIDE: Input event: type=EV_KEY, code=316(0x13c), value=1
Input event: type=EV_KEY, code=316(0x13c), value=0

LEFT_ANALOG (CW circle from 0 to 12):Input event: type=EV_ABS, Axis=0, Offset:=-32516
Input event: type=EV_ABS, Axis=1, Offset:=22783
Input event: type=EV_ABS, Axis=0, Offset:=-32768
Input event: type=EV_ABS, Axis=1, Offset:=20607
Input event: type=EV_ABS, Axis=1, Offset:=17023
Input event: type=EV_ABS, Axis=1, Offset:=13823
Input event: type=EV_ABS, Axis=1, Offset:=10495
Input event: type=EV_ABS, Axis=1, Offset:=6783
Input event: type=EV_ABS, Axis=1, Offset:=4991
Input event: type=EV_ABS, Axis=1, Offset:=-3201
Input event: type=EV_ABS, Axis=1, Offset:=-4865
Input event: type=EV_ABS, Axis=1, Offset:=-8577
Input event: type=EV_ABS, Axis=1, Offset:=-10241

RIGHT_ANALOG (CW circle from 0 to 12):Input event: type=EV_ABS, Axis=3, Offset:=-3431
Input event: type=EV_ABS, Axis=3, Offset:=-764
Input event: type=EV_ABS, Axis=3, Offset:=1776
Input event: type=EV_ABS, Axis=3, Offset:=3681
Input event: type=EV_ABS, Axis=3, Offset:=5967
Input event: type=EV_ABS, Axis=3, Offset:=6475
Input event: type=EV_ABS, Axis=3, Offset:=7110
Input event: type=EV_ABS, Axis=3, Offset:=8888
Input event: type=EV_ABS, Axis=3, Offset:=11174
Input event: type=EV_ABS, Axis=3, Offset:=13206
Input event: type=EV_ABS, Axis=3, Offset:=15619
Input event: type=EV_ABS, Axis=3, Offset:=16254
Input event: type=EV_ABS, Axis=3, Offset:=16889
Input event: type=EV_ABS, Axis=4, Offset:=-32001
Input event: type=EV_ABS, Axis=4, Offset:=-29697
Input event: type=EV_ABS, Axis=4, Offset:=-28033
Input event: type=EV_ABS, Axis=4, Offset:=-25473
Input event: type=EV_ABS, Axis=4, Offset:=-23297
Input event: type=EV_ABS, Axis=4, Offset:=-20225


As you can see we have a new VID:PID 045e:0719, but we get the same exact events and axis mapping (with the same ranges) as the 8bitdo mimicking the wired Xbox360 controller. So we have another clue leading to my hypothesis about a standardized xinput HID event mapping. The only difference is that, with the DPad we have double events, just like it’s acting both as an axis and a button. This seems to be coherent with xpad.c which has a kernel module parameter dpad_to_buttons. How do I pass a value to a static kernel module parameter? Through uboot?
Then I tried fiddling with /sys/class/leds/xpadN/brightness as suggested here https://github.com/paroj/xpad/ and it works! Pretty cool! Tomorrow I’ll try to see if the led light show works with Nintendo joypads through 8bitdo dongles. @Sorgelig, why don’t you try with your SF30Pro?
Anyway, after this tests I compiled my first kernel, with the last xpad.c (just as you did) and… it works!!! I’m very satisfied. Here’s my compiled kernel http://www.filedropper.com/zimagedtb pretty useless, since you did the same, but I’m happy and I want to share. I didn’t many tests with this kernel, because the old one works with my joypads, but the main difference should be that this new one supports more joypads and, in particular, the Xbox One joypad… so, why @Newsdee don’t you try and, eventually, make a log of the event mapping? If it is confirmed the standard event/axis mapping, I think it should be useful that Sorgelig extends the new analog axis handling to more VID:PID than just 045e:028e; he could use the VIDs and PIDs enumerated in https://github.com/paroj/xpad/blob/master/xpad.c or he could search for device IDs containing “IG_” as suggested by Microsoft here https://msdn.microsoft.com/library/wind ... 17014.aspx

Thank you and good night.

Locutus73

[Sorgelig]

everything is about XBOX controller.
As i've told above, it's not correct to talk about common features exploring just one gamepad and its clones.
Need to explore more non-Microsoft and non-mimicking it gamepads.

[Sorgelig]

SF30Pro connected by wire has other VID/PID (054C:05C4) and acts as a standard PS3 or clone controller.
Analog sticks are pretty standard axis 0/1 for left stick and 2/5 for right with range 0..255.

[Sorgelig]

correction: SF30Pro has different VID/PID depending on mode. It will have the same VID/PID as receiver if you use START+X mode.
anyway, 2 modes are compatible with MiSTer:
- Start+A - will act as a PS3 clone. MiSTer will work with it as with generic gamepad
- Start+X - will act as 8bitDo receiver.

Both modes will work equally, but you will need to define the buttons for each mode.

[Newsdee]

So a quick check of the XBox one controller... it seems to freeze the USB bus so the keyboard doesnt work anynore. :/ Perhaps the power draw is too strong. I'll have to try to find a powered hub.

[Locutus73]

everything is about XBOX controller.
As i've told above, it's not correct to talk about common features exploring just one gamepad and its clones.
Need to explore more non-Microsoft and non-mimicking it gamepads.

Well, again, not exactly just a single XBox controller, but an entire family of Windows centric controllers; my original point is about finding an easy change to the VID:PID filter in order to make your last code (the 16bit analog axis handling) compatible with a wide array of controllers (ok there are others, but at least is a family). I mean a semi free improvement. [EDIT]Once you cover official console controllers (I.e DualShocks) and xinput, you gain compatibility with all the main official gaming controllers; what remain is a bunch cheap Chinese stuff.[/EDIT]
Ah, yes, and learning new stuff (at least this is a point for me), possibly not bothering other people.

Locutus73

[Locutus73]

correction: SF30Pro has different VID/PID depending on mode. It will have the same VID/PID as receiver if you use START+X mode.
anyway, 2 modes are compatible with MiSTer:
- Start+A - will act as a PS3 clone. MiSTer will work with it as with generic gamepad
- Start+X - will act as 8bitDo receiver.

Both modes will work equally, but you will need to define the buttons for each mode.

Yep, Start+A is an HID mode Apple oriented, Start+X acts as an XBox360 controller... you see, they used, mnemonic combos (A=Apple, X=XBox).
Then you have Start+B which is another DInput mode (an old Windows Standard) and Start+Y which is Nintendo Switch mode. I suspect that just Start, pressed alone, is another mode or is equal to Start+B.

Locutus73

[Locutus73]

So a quick check of the XBox one controller... it seems to freeze the USB bus so the keyboard doesnt work anynore. :/ Perhaps the power draw is too strong. I'll have to try to find a powered hub.

Mhhh... do both the old and new kernel freeze the bus? Any output from the serial console or any strange dmesg log?

Locutus73

[Sorgelig]

Just for note: SF30Pro(SN30Pro) should be in Start+B mode when connected to 8bitDo receiver in order to work properly on MiSTer.

[Locutus73]

Just for note: SF30Pro(SN30Pro) should be in Start+B mode when connected to 8bitDo receiver in order to work properly on MiSTer.

Well, it's a bit complicated, basically: 8bitdo joypads provide 4 modes, both via USB or Bluetooth:
1) Start+A = Apple mode
2) Start+B = (just Start on older joypads like my SNES replica) = Direct Input mode (old Windows standard)
3) Start+X = xinput mode (Wired XBox360 mode)
4) Start+Y = Nintendo Switch mode

Then we have two kind of dongles/receivers, both require the joypad to pair in dinput mode
a) The retro receivers (the ones with a retro console legacy physical connector). These have a mini USB which can be connected to

1) PC - The retro receiver automatically goes in xinput mode (Wired XBox360 mode)
2) PlayStation 3 - The retro receiver automatically goes in wired dual shock 3 mode

b) The wireless USB adapter (the brickwall one) which loses the legacy retro console connector, but gains 4 modes; it always requires the joypad to be paired in dinput mode, but then you can choose 4 modes:

1) Select+Right for 3 seconds = Apple mode
2) Select+Left for 3 seconds = Direct Input mode
3) Select+Up for 3 seconds = xinput mode
4) Automatically by connecting to a Nintendo Switch = Nintendo Switch mode

Locutus73

[Sorgelig]

yeah.. too complicated for newcomers.
Ok, i've tested it.
Select+dpad not only switches the mode, it also switches the VID/PID on the fly, so linux sees it as old device unplugged and then new device plugged.
So, working modes with MiSTer are:
Select+Right: looks like PS3 controller. Analog sticks have 0..255 range. MiSTer treat this mode as generic gamepad.
Select+Up: XBOX vid/pid. Analog sticks have -32768..+32767 range. MiSTer with recent changes supports this mode.
Select+Left: almost working mode. It has unusual axis 9 mapping to option button (will adjust in next release).

So, with ability to select 2 different modes with different VID/PID you can have 2 layouts which you can switch on the fly.

P.S.: There is a problem with Select+Right mode on Dualshock 4. It start to flood with analog stick messages even no stick is touched. So, with DS4 use Select+Up mode. Probably it's firmware problem.

Another problem with DS4: gamepad goes to power off state if MiSTer reboots and when mode is switched. So you need to press PS button to connect again. Not a big issue, but still..

[Sorgelig]

The wireless USB adapter (the brickwall one) which loses the legacy retro console connector

it still can be connected to PS3. It works with PS3 although PS button isn't mapped which is weird.

[Newsdee]

The debugger shows that the USB stack crashes when I connect the XBox one gamepad:

Code: Select all

[    3.297301] [<c030078c>] (device_add) from [<c04fe704>] (usb_new_device+0x28c
(...)
[    3.343070] Code: e24cb004 e52de004 e8bd4000 e59032e8 (e5130014)
[    3.349137] ---[ end trace a98965a3b8052aa9 ]---
[    3.353734] Fixing recursive fault but reboot is needed!


How do I try the new kernel? Do I need to setup a whole new SD card?

[Sorgelig]

The debugger shows that the USB stack crashes when I connect the XBox one gamepad:

Code: Select all

[    3.297301] [<c030078c>] (device_add) from [<c04fe704>] (usb_new_device+0x28c
(...)
[    3.343070] Code: e24cb004 e52de004 e8bd4000 e59032e8 (e5130014)
[    3.349137] ---[ end trace a98965a3b8052aa9 ]---
[    3.353734] Fixing recursive fault but reboot is needed!


How do I try the new kernel? Do I need to setup a whole new SD card?

no. just copy zImage_dtb(unzip) to /linux folder.

[Newsdee]

Great news, the Xbox one controllers work in wired mode with the new Linux image! Only caveat is that the analog stick is way too sensitive so best not to use it at all. It's probably related to the range problems Sorgelig pointed out).

I also tried the Xbox One receiver for Windows but it did not work; the pairing blinking light doesn't even turn on.
So my favorite remains using 8bitdo receivers for now.

[Sorgelig]

Great news, the Xbox one controllers work in wired mode with the new Linux image! Only caveat is that the analog stick is way too sensitive so best not to use it at all. It's probably related to the range problems Sorgelig pointed out).

you can easily check the analog range in console when running Menu core.

I'm a little confusing now by what you mean old and new kernel. What linux release you've used before?

[Locutus73]

Great news, the Xbox one controllers work in wired mode with the new Linux image! Only caveat is that the analog stick is way too sensitive so best not to use it at all. It's probably related to the range problems Sorgelig pointed out).

you can easily check the analog range in console when running Menu core.

I'm a little confusing now by what you mean old and new kernel. What linux release you've used before?

I think he is using my own wrong wording; some posts ago I referred to the current official MiSTer 4.5 Kernel published on github as old, and the 4.5 with the last xpad.c compiled and shared in this thread, as new.
Anyway @Newsdee could you kindly report the complete analog range plus some complete events? I’m curious to see if the events match the ones we saw so far (I.e. A button = code=304(0x130), Start button = code=315(0x13b)).

Locutus73

[Locutus73]

@Sorgelig checking code online, I noticed that paroj’s xpad.c https://github.com/paroj/xpad/blob/master/xpad.c isn’t much different from the official upstream Linux’s one https://github.com/torvalds/linux/blob/ ... ick/xpad.c
Just in order to choose the one you prefer to backport (in case you want to make it official in your kernel).

Locutus73

[Locutus73]

I did some other tests with /sys/class/leds/xpadN/brightnesss suggested here https://github.com/paroj/xpad and

1) It works perfectly with wireless Xbox360 joypad + Microsoft dongle.
2) It doesn’t work at all with wireless WiiU joypad + 8bitdo Retro Receiver for NES/SNES/SFC Classic Edition.
3) It partially works with wireless Dual Shock 3 + Mayflash PS3003 dongle: it can light up single leds, but all the blinking/rotating tricks don’t work.

@Sorgeling and @Newsdee can you kindky perform some other tests?

Locutus73

[Newsdee]

What linux release you've used before?

"New" is just the kernel with the xpad update. Old one is from the regular SD card installer (latest version as of yesterday).

[Newsdee]

Log for the Xbox One controller.

Code: Select all

Right = Axis 16, offset 1
Left = Axis 16, offset -1
Up = Axis 17, offset -1
Down = Axis 17, offset 1
A: code=304(0x130)
B: code=305(0x131)
X: code=307(0x133)
Y: code=308(0x134)
Start (button with three horizontal lines): code=315(0x13b)
Select (button with two rectangles): code=314(0x13a)
Xbox button: code=316(0x13c)
L: code=310(0x136)
R: code=311(0x137)
L2: Axis 2  (analogue button, 0 to 1024 range]
R2: Axis 5 (analogue button, o to 1024 range]
Left Stick: Axis 0 and 1  [-32000 to 32000 range]
Right Stick: Axis 3 and 4 [-32000 to 32000 range]
L3 (left stick button): code=317
R3 (left stick button): code=318