@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.

@dragu No, unfortunately this didn't help either. There is no difference of just specifying gr.

I wonder though, if the problem is actually somewhere outside dosbox. Just noticed that I can't enter umlauts in ES either... Strangely on the command shell (local and SSH) everything is fine... but I guess I should start another thread for this topic, this one starts to get longish and offtopic...

Yes, speaking of dosbox of course! :-D

Citing myself:

Sure it doesn't help that dosbox doesn't really seem to have an active development...

As for Recalbox implementing my wishlist, sure I know how this open source things works. I'm in this for a long time already .. do it or shut up ;) And when we get a first public drop of dosbox support, it's clear that not everything is as good as it could be right from the beginning. But it could still be food for thought. And I have a good feeling about Recalbox, as usability and ease of use seems to be an important focus here. I like that. I value it if things sometimes "just work", even in open source software :)

@voljega said in Confused Over Dos Games:

Although quite a long time in the making, the latest version was juste released ?

What do you mean? I only see 0.74 from 2010...

And they are clearly open to external help,

Maybe. I don't have first hand experience with them, this was just my impression from reading threads to the various joystick problems. And apparently those proposed, pretty obvious if you ask me, patches aren't yet in. IIRC I read in the release notes of latest recalbox that they applied some joystick button patch, and e.g. the one I linked in the other thread is 5 years old and the problem still not solved... just my impression.

@substring said in Régler manuellement les deadzones:

Just read a part of https://www.reddit.com/r/linux_gaming/comments/5xics8/a_big_problem_with_joysticks_in_linux_right_now/ today, it's the same as what @redm said.

doh .. I should have found this page earlier, it would have saved me a lot of time ;)

The questions so far are :

• can we patch dosbox to add a custom deadzone

I think this is only the 2nd best option. I would do as much as possible outside of dosbox. Not only because configuring dosbox is a pain anyway, but also because you could then reuse the calibration for all other SDL based emulators and possibly add a UI somewhere.

• is there a way to calibrate a joystick for evdev

Apparently there is a calibration tool now, but evdev is still lacking making the changes persistent though udev.

I would add another point related to this:
-is there a way to select joystick devices for dosbox?

With joydev and SDL1 you could set the env variable SDL_JOYSTICK_DEVICE, which is not possible anymore with SDL2. Patch dosbox? Apparently somebody created a patch for dosbox to add a config option: https://sourceforge.net/p/dosbox/patches/253/. But also here, doing this from outside would be nicer. You could add per rom controller configuration to the ES context menu...

Just a reminder : we're talking about a system that needed joystick calibration. Today, is the emulation right regarding this technologic gap ?

What do you mean with this question? I think we need calibration outside of dosbox, if that is the question. At least in my (limited) experience I found it to be more reliable to calibrate with system tools and leave alone all possible in game joystick calibration. That only made things worse. Or are you questioning whether we need calibration at all? In this case I would also say: yes.

@voljega Yea, I didn't say it's a simple task ;) Or that everything needed is already there just needs to be plugged together. But I think aside from the inherent DOS problems, that already existed back then, quite a bit can be done to make DOS games easier consumable.

When I started to look into dosbox on Retropie I had questions like:

• how should I go when I need to install that game first? from where, to where? how do I get that CD into the dosbox?
• where is the dosbox config I need to modify? should I copy it to my rom? or somewhere else?
• why does that fricking keyboard layout not work properly inside dosbox? (I couldn't make it do proper german layout. Even manually setting it to gr makes it kinda german, but some keys are dead, some have a different mapping, some characters are missing... It's been a while, but I'm sure under the real DOS we did have german umlauts...)
• how do I get the games into ES in a nice way and without tons of directories? Esp. when you are also new to Recalbox/Retropie/ES these are points which are unclear.
• how can I select joystick devices for dosbox?
• how does that weird mapper work? (I didn't ever figure out how to modify the Shift layer or how to make german special characters work)

All such questions. Many of which I think are solvable. You spent days to figure out all the basics and haven't even started with special problems of certain games. Sure it doesn't help that dosbox doesn't really seem to have an active development (latest version is pretty old I think) and apparently not really open to integrate even obvious patches, like for the various joystick problems. But some things can also be done around dosbox. And I think Recalbox already does some things well here. E.g. those txt files in the rom folders with simple instruction what to do are actually extremely helpful if you are new. ES could automatically get special context menus for the dos case: to run an interactive dosbox, entries to run install/setup programs or to select input devices and set appropriate env variables (as far as possible). Sure, somebody has to do it...

And yea, I for instance don't have a Windows anymore and still would like to run those good old games ;)

@voljega Yea, I had a look at Exodos, it's just that this are some 300gb O_o

Anyway, right such a bat file could be an option. Downside is that I can't have separate gamelist entries. And I, or any other user, have to figure out how to write batch files (beyond calling an exe file). Would be great if Recalbox could take care of this somehow. I kinda like the idea of treating directories as roms and launch the game by a usually simple bat file. But it also has it's down sides. For instance also when you need to initially install a game first, re-run setup/install later or do things outside of dosbox, like setting SDL variables per game.

The DOS stuff will always be something you need to fiddle around with to get the games running, it has always been that way, but if as many as possible of the tasks could be taken care of by the system this would help a lot.

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.)