Hi guys. Maybe I can shed some light on this. @voljega notified me of this thread... I speak no word of french (exept maybe merci ;), but Google helped so much to understand, but I choose to answer in english if you don't mind...

First thing to note is there there are (at least) two different ways to access joysticks in Linux:

1. the joydev joystick driver and API, with devices /dev/input/js*, which is what you used here. This is configured using jscal and friends.
2. and the raw event devices, /dev/input/event*. It's not clear to me if this is configurable. Some sources say it's just raw events, not configurable, the Archwiki @voljega linked seems to suggest you can configure/calibrate them...). Otherwise the apps or SDL would have to take care of that. No idea if SDL has any support for this.

So what do we have?

• the coefficients you modified for jscal at pretty much wrong. When I take the initial line from @ironic:

  jscal -s 6,1,16,-128,128,16513,16513,1,16,-128,128,16513,16513,1,16,-128,128,16513,16513,1,16,-128,128,16513,16513,1,0,0,0,536870912,536870912,1,0,0,0,536870912,536870912 /dev/input/js0
  

  then the coefficents of the first axis are: -128,128,16513,16513. As you figured out the first two are the borders of the deadzone. But they have to stay in the input range, i.e. between 0..255. So changing them to 8000 or whatever is likely just plain wrong. The other two are actually scaling factors, mapping the remaining input range to the entire output range (-32767..0, 0..32767). You can not simply change them, but you have to actually calculate them, taking into account the actual input range minus deadzone.

• if you want to test these changes you should use jstest. If you want to verify how things behave in SDL apps you can use sdl-jstest/sdl2-jstest, for SDL 1 and 2 respectively.

• as for making the values persistent, you should use some udev magic. Relying on the generic device is likely to fail sooner or later, as they are just numbered by the OS as they are detected or plugged in. If at all, you should use the named devices /dev/input/by-id/usb-Foo_Bar-joystick. And the init script won't work if you plug in the device later on. The debian joystick package (used in Raspbian or Retropie) also ships jscal-store/-restore, which take of the udev magic. But they are not available on Recalbox.

• somehow something else seems wrong on Recalbox as jscal button mapping is broken:

  # jscal -q /dev/input/js0 
  "jscal: error getting axis map: Success"
  

The other thing is, as I just found out, that the joydev driver devices (js0) are ignored by SDL1 and SDL2 (and thus programs like dosbox) on Recalbox. See https://forum.recalbox.com/post/75291

For SDL1 you can override the default device and work around this with export SDL_JOYSTICK_DEVICE=/dev/input/js0. If you do that then sdl-jstest should give you the results you expect, same as jstest. Otherwise you only get the erratic, uncalibrated default behaviour.

For SDL2 however this does not work. It just ignores this variable. As dosbox on Recalbox uses SDL2 your jscal based calibration will never end up there. It will always use the erratic, uncalibrated default.

The open questions are:

• can SDL2 be compile configured to obey SDL_JOYSTICK_DEVICE?
• can SDL2 be compile configured to default to joydev driver devices (js*)?
• can the raw event devices be calibrated (as the archwiki page suggests)? At least the tools are not available in Recalbox.

So yea, I guess we are stuck the way things currently are. No calibration for Dosbox (or any other SDL2 based apps, ScummVM? uae4arm/amiberry?).

Btw: what is this blue program? I couldn't find a "Recalbox Joystick/Gamepad Utility" anywhere...

Ok, I did some investigation... It seems the point of being able to configure joysitck devices at all boils down to an SDL compile configuration problem...

My joystick devices (limited to the said analog stick for simplicity):

# ls -l /dev/input/by-id/*joystick
lrwxrwxrwx    1 root     root             9 Jan  1  1980 /dev/input/by-id/usb-Padix_Co._Ltd._2-axis_4button_joystick_w_view_finder_rudder-event-joystick -> ../event1
lrwxrwxrwx    1 root     root             6 Jan  1  1980 /dev/input/by-id/usb-Padix_Co._Ltd._2-axis_4button_joystick_w_view_finder_rudder-joystick -> ../js0

I.e. /dev/input/js0 and /dev/input/event1 repectively.

Lets see which devices SDL programs use by default with sdl-jstest and sdl2-jstest:

# sdl-jstest - open fds without SDL_JOYSTICK_DEVICE
total 0
lrwx------    1 root     root            64 Oct 31 16:16 0 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:16 1 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:16 2 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:16 3 -> /dev/fb0
lrwx------    1 root     root            64 Oct 31 16:16 4 -> /dev/tty4
lrwx------    1 root     root            64 Oct 31 16:16 5 -> /dev/input/mice
lr-x------    1 root     root            64 Oct 31 16:16 6 -> /dev/input/event1


# sdl2-jstest - open fds without SDL_JOYSTICK_DEVICE
# ls -l /proc/1131/fd             
total 0
lrwx------    1 root     root            64 Oct 31 16:19 0 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:19 1 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:19 2 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:19 3 -> /dev/vchiq
lrwx------    1 root     root            64 Oct 31 16:19 4 -> socket:[9440]
lr-x------    1 root     root            64 Oct 31 16:19 5 -> /dev/input/event2
lr-x------    1 root     root            64 Oct 31 16:19 6 -> /dev/input/event0
lr-x------    1 root     root            64 Oct 31 16:19 7 -> /dev/input/mouse0
lrwx------    1 root     root            64 Oct 31 16:19 8 -> /dev/tty1
lr-x------    1 root     root            64 Oct 31 16:19 9 -> /dev/input/event1

Both use the raw event device /dev/input/event1 as joystick device. Now you can override this by setting the environment variable export SDL_JOYSTICK_DEVICE=/dev/input/js0:

# sdl-jstest - open fds with SDL_JOYSTICK_DEVICE
# ls -l /proc/1140/fd
total 0
lrwx------    1 root     root            64 Oct 31 16:21 0 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:21 1 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:21 2 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:21 3 -> /dev/fb0
lrwx------    1 root     root            64 Oct 31 16:21 4 -> /dev/tty4
lrwx------    1 root     root            64 Oct 31 16:21 5 -> /dev/input/mice
lr-x------    1 root     root            64 Oct 31 16:21 6 -> /dev/input/js0

It uses the configured device, great, so for SDL1 this works.

# sdl2-jstest - open fds without SDL_JOYSTICK_DEVICE
# ls -l /proc/1131/fd             
total 0
lrwx------    1 root     root            64 Oct 31 16:19 0 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:19 1 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:19 2 -> /dev/pts/0
lrwx------    1 root     root            64 Oct 31 16:19 3 -> /dev/vchiq
lrwx------    1 root     root            64 Oct 31 16:19 4 -> socket:[9440]
lr-x------    1 root     root            64 Oct 31 16:19 5 -> /dev/input/event2
lr-x------    1 root     root            64 Oct 31 16:19 6 -> /dev/input/event0
lr-x------    1 root     root            64 Oct 31 16:19 7 -> /dev/input/mouse0
lrwx------    1 root     root            64 Oct 31 16:19 8 -> /dev/tty1
lr-x------    1 root     root            64 Oct 31 16:19 9 -> /dev/input/event1

However, unfortunately it doesn't work for SDL2, it keeps using /dev/input/event1.

The problem: Dosbox as compiled for Recalbox uses SDL2, and thus ignores the env variable and keeps opening the first raw event devices
(Retropie for instance uses SDL1, that's why it works there).

# ps xa|grep dos
1163 root     /usr/bin/dosbox -userconf -exit /recalbox/share/roms/dos/wing2.pc/dosbox.bat -c set ROOT=/recalbox/share/roms/dos/wing2.pc -conf /recalbox/share/system/configs/dosbox/dosbox.conf

# cat /proc/1163/environ 
... SDL_JOYSTICK_DEVICE=/dev/input/js0...

# ls -l /proc/1163/fd
lr-x------    1 root     root            64 Oct 31 16:27 11 -> /dev/input/event1

# cat /proc/1163/maps |grep -i sdl
76be4000-76cc5000 r-xp 00000000 b3:0b 39837      /usr/lib/libSDL2-2.0.so.0.4.0

I didn't find any other possibility to convince SDL2 programs to use a different device. The only thing I found is that there seems to be a compile time option to use the real joystick devices by default instead of raw event devices. Even if, not sure if that would enable the env variable to actually allow selecting them. Or maybe there is another compile option for this?

(Btw: this is most likely also the reason why your configured deadzones are not picked up by dosbox: you configure the joystick driver devices js* with jscal, but dosbox/SDL uses the raw event devices.)

@_arthur_ Hi! Well, the actual problem I did not solve. It's not solvable the way Recalbox handles devices with Amiberry, I think. (I didn't try it, but probably also not for Dosbox... unless you use some libretro based Dosbox, I guess) They are not read form the Retroarch configs, but passed as runtime arguments when starting the game, probably in the order they were plugged in or detected on system start. From this list and order the Amiberry config is then generated on-the-fly. Device ids, names or anything like that is not taken into account. Just the order, which may be anything. (IIRC)

At least with Recalbox 8 or so this on-the-fly generating was fixed, so that the generate config at least makes sense now and shows proper device names. So at least you can change it now in the Amiberry GUI, everytime you start the game.
You could override it with custom uae files. It should work within the limitations. But again, only based on order. So you could store "device #3" as first controller. And it will be whatever the system figures out as #3. If you are lucky it's stable. If there is no #3, because it's not plugged in, well...

@zing Well, sure it's possible to dig through documentation and config files, I'm also capable to dig through code, if needed. But that's not the promise of Recalbox, that's plug and play, which I highly appreciate
And when I bring up such a wish I don't expect immediate implementation. It could simply be taken as a "Hey, here is a use-case which is somewhat difficult to solve currently. Maybe take it up for consideration for future development. Cheers!" And you could say, "We don't have much capacity right now, but interesting point!". Instead of downright turning it down...

Anyway, I went through the docs, the various config files, and tried a few things. But I get the impression that reordering might work for libretro based emulators, but is not possible for Amiberry, which is the case where I'm coming from... (Didn't investigate Dosbox yet)

(And as it is a static config in any case, it probably couldn't react on dynamic conditions, like "use starting controller as primary")

Ok, I think I found the nasty line in /usr/lib/python2.7/site-packages/configgen/generators/amiberry/amiberryConfig.py. And comparing it with the Git version, I'd say it should be fixed with the next Recalbox release.

@acestaruno Hast du irgendeine Lösung gefunden für die Save States? Stehe vor dem gleichen Problem...

So habe ich es im Prinzip auch gemacht. Zips in einzelne Ordner ausgepackt, die Disks 2 bis x versteckt und gescraped (ich glaube erst danach, weil man gescraped ja nicht mehr sieht welche Disk ein Eintrag ist).

Dazu habe ich noch "Show Folder Contents" im Options Menü aktiviert, was die Ordner auflöst und im Hauptlisting mit anzeigt. Sonst hat man ja immer Ordner mit einzelnen Einträgen.

Cooler wäre natürlich wenn man zips direkt verwenden könnte. Zum Beispiel beim Start on-the-fly auspacken. Ich glaube Retropie macht das so.

The auto generated default configuration for Amiberry behaves weird regarding the configured controllers. On closer investigation it seems that the device numbering is broken.

Below is a diff between the auto config and a manual correction as it should be (saved through Amiberry GUI). Apparently the generated joyportX=.. values are off-by-one. And Amiberry is relying on these values.
The friendlyname is correct interestingly, but does not seem to play a role for Amiberry.

Recalbox 7.2.2

--- auto.uae	2021-11-16 23:24:14.000000000 +0100
+++ saved.uae	2021-11-16 23:24:31.000000000 +0100
 joyport0_mode=mousenowheel
 joyport0_mousemap=right
 joyport0_name=MOUSE0
-joyport1=joy2
+joyport1=joy1
 joyport1_autofire=none
 joyport1_friendlyname=MY-POWER CO.,LTD. USB Joystick
 joyport1_mode=djoy
 joyport1_mousemap=right
-joyport1_name=JOY2
+joyport1_name=JOY1
-joyport2=joy3
+joyport2=joy2
 joyport2_autofire=none
 joyport2_friendlyname=USB,2-axis 8-button gamepad
 joyport2_mode=djoy
 joyport2_mousemap=right
-joyport2_name=JOY3
+joyport2_name=JOY2
-joyport3=joy1
+joyport3=joy0
 joyport3_autofire=none
 joyport3_friendlyname=MOSIC      USB 2A4K  GamePad
 joyport3_mode=djoy
 joyport3_mousemap=right
-joyport3_name=JOY1
+joyport3_name=JOY0

@zing said in System Specific Controller Inputs Switching:

We have a small team of developers, and what you are requesting would not exactly suit all users, to do as you suggest you would need the system to request it before each game, which would definitely be something very annoying in my opinion, and I'm sure the same applies to most users.

Well, there are other features in Recalbox that don't suit me. Then I don't use them, so what? I didn't say it's perfect, this may require some more thought, of course. It's just an idea to simplify juggling with different controllers. Currently this does not really work so well. Don't know how common this is, but I wouldn't consider myself a pro and still have a few different controllers.
And I would probably also be annoyed if the system asked me every time. It should be in a way that if you don't like it, don't use it.
As I wrote, I could imagine some cases could be covered by simply declaring the controller I use to start the game as 1st player. That's in my opinion a great thing with even just two controllers...
I also understand that there is always too much work for too few people, but it was just an idea, a suggestion.

It's not that simple, it would require a lot of programming effort, our developer team can't stop improvements and bug fixes to focus on developing something like that.

I would consider this an improvement.. And sorry, there are lots of places where you make handling nicely easy with things like that. I don't have to configure my buttons in a text file, there is a nice UI. Or whatever. That's why I like Recalbox!

Bypassing the development of specific functions, and ignoring popups at each game start, what you are requesting is already available in the controls menu (Switch player 1 joystick),

Going into the Controls menu is what I do right now. And it's a bit cumbersome, not plug and play. (Also configuring a controller order with this weird swapping logic is more like solving a puzzle)

and/or, it is easily configurable with configuration overloads:

You mean that one: https://wiki.recalbox.com/en/advanced-usage/configuration-override ?
Well, "easy" obviously depends on how deeply involved you are with the project But yea, I have it on the list to check it out.
It does not support me if the configured controller is not plugged in, though, by telling my "Hey, you configured the Competition Pro for this game. Plug it in!"

Jumping in on this one... I would like to add this as a feature wish, allow me to configure the used controllers not only per system, but on a per game basis. Always thinking of this when juggling controllers again

I have this game where I want to use the analog flight stick, those other ones which I like best with my Competition Pro(s), most others with SNES/PS controller. May even depend who is using the system. The kid might want to use the smaller SNES controller as primary device, while I like the larger PS controller.
And adding to this, not everything is always plugged in.

I imagine Recalbox pops up a dialog asking me what to do:

• I can select and change the order of the plugged in controllers as primary and secondary
• I can save the settings for this game
• if I saved a certain controller, like the analog flight stick, and it's not plugged in, the dialog asks me to plug it in before I proceed. Or allow me to temporarily select another one as fallback.

Could be optimized by only showing the first time and when something was saved and does not match.

And/or maybe use the controller I started the game with as primary by default. This could already cover most of cases actually, at least for single player (not sure about the analog stick use case, though).

@dragu IIRC -> if I remember correctly I checked, and keyboard layout is set to "de". I also found that input in ES is ok - for the most part. It's mainly lacking just the umlauts plus the <>| key. Interestingly the umlauts produce symbols like {}... Seems partly german, partly english. Weird.
Anyway, so it looks like there is indeed something wrong with dosbox. More so as I found the same problems under Retropie. Keyboard layouts have alwas been a pain in Linux... I think I'll give up for now...

@dragu Hmm, I have to check recalbox.conf, but IIRC I have set the the proper keyboard layout there. Just that I have english as system language. The umlauts are just the most obvious example. This effects a couple more keys, like +/*, '/#, -/_, ´/`, </>, ?/ß, or y and z switched, which you need every now and then. And after all keyboard is something that should be configured once and "just work". Not sure, what you mean with the ssh comment, but as I said with SSH everything is perfect.