Home

A linux userspace device driver that allows joystick events to be remapped. Several joysticks can be combined into a single controller, and button/axes events can be remapped to new joystick, keyboard or mouse events. Advanced scripting also supported.

For a graphical UI to program the joystick (using this software) please see https://rensg.home.xs4all.nl/rb3d/joymixerUI.html

Project Admins:

• Alexandre Hardy

[Alexandre Hardy]

Thanks, I meant the configuration file you use to setup joymap. The code and/or button mapping file.

[Anish Desai]

Sorry, I misunderstood. Please find attached the test button mapping file I have been using.

[Alexandre Hardy]

Thanks for the test map file. I managed to get it running in the virtual machine.

The problem was silliness on my part. (Because I had been working on an OSX version).

I moved the mapping code to before the devices were scanned, and thus no devices were picked up. And I never picked it up, because I was driving the testing by a script since the virtual machine I tested on has no joystick hardware plugged in.

Sorry for the inconvenience. joymap-0.3.1 should solve the issue. Please let me know if it works for you.

[Alexandre Hardy]

Oh, and please note that things have changed a little.

To correctly send the keypress "1", you need to say "num1". Otherwise it is interpreted as an integer key code, and not as a string literal. This was changed to fix some of the problems handling the mapping of axes to buttons. It isn't great, but it works.

[Anish Desai]

Thank you, Alexandre. I can confirm that joymap 0.3.1 is working fine now.

I am trying to map the buttons to the numeric keypad. I found code in your xwing.code example that seems to do this so I took the relevant lines of code and tested it with joymap 0.3.1. The D-pad works fine but I am not getting any input from the buttons. Any advice how I can fix this would be much appreciated. I attach the mapping file and code used.

[Alexandre Hardy]

Hi Anish,

That code looks mostly correct to me. I may be mistaken, but I believe the D-pad is simply a set of buttons. So buttons and the D-pad should work identically.

I suggest you compile and execute jsinfo.c in the tools directory and use that to inspect the device you are using. It should report buttons and axes, and allow you to see how they are reported.

You can then verify what the code should be seeing. If there is a mismatch then that would be the first thing to correct.

Kind regards
Alexandre

[Moshe Dahan]

Thank you for this simple, but very useful utility Alexandre.
I am using it on Raspberry Pi with EmulationStation (as many others do) to control Kodi with the game pad.

Took me a while to figure it out, but eventually I got it working :) Still a few snags...
I am using the 8Bitdo SFC30 Joystick with a wired connection. My configuration file is this:

# Mapping for 8Bitdo SFC30 Joystick

# A for Enter and B for Backspace
button vendor=0x1235 product=0xab21 src=0 target=kbd button="enter"
button vendor=0x1235 product=0xab21 src=1 target=kbd button="backspace"
# X for Context Menu
button vendor=0x1235 product=0xab21 src=3 target=kbd button="c"

# Shutdown menu
button vendor=0x1235 product=0xab21 src=6 target=kbd button="s"

# Escape
button vendor=0x1235 product=0xab21 src=7 target=kbd button="esc"

# Navigation
axis vendor=0x1235 product=0xab21 src=1 target=kbd minus="up"
axis vendor=0x1235 product=0xab21 src=1 target=kbd plus="down"
axis vendor=0x1235 product=0xab21 src=0 target=kbd minus="left"
axis vendor=0x1235 product=0xab21 src=0 target=kbd plus="right"

The only issue I am still having is that the D-pad is acting as if "stuck" when pressing a direction and then it loses the ability to control navigation at all. The rest of the buttons work just fine.

Any thoughts are appreciated!
Moshe

[Alexandre Hardy]

Hi Moshe,

For one thing, you can specify minus and plus on the same line, which will help to avoid confusion in the handling of events.

axis vendor=0x1235 product=0xab21 src=1 target=kbd plus="down" minus="up"

There should be only one line per axis, or per button. If you need something more complex then you will have to resort to writing joymap code (see x-wing examples, and included documentation).

You can also try the binary flag which will make this act a bit more like a keyboard (but depends on how bad the deadzone is):

axis vendor=0x1235 product=0xab21 src=1 target=kbd plus="down" minus="up" flags=binary

Let me know if that helps.

Kind regards
Alexandre

[Moshe Dahan]

Thank you for the response Alexandre.
I have switched from 4 lines to just two by consolidating the plus and the minus in one line per src.
I tried running both with and without the flags=binary but I'm afraid I am still getting the same bahavior. It seems like after pressing the button it's as if it is stuck in a loop. Unlike with the "button" assignments where it does act like a keyboard and a single click is handled like a single click on a keyboard, with "axis" it seems like it remains stuck.
Is there maybe a "limit" function where you can limit to a single movement on the axis?

I obviously understand that you may not want to limit the movement to a single press until you release during a game, like a car and flight game, but if you could maybe add a "Kodi" mode option to the program that will have this limited by default if you enable it, since there are many users leveraging your SW for that purpose, it may be very beneficial.

Thoughts?
Again, very much appreciate the help!
Moshe

[Alexandre Hardy]

Hi Moshe,

We don't have a deadzone for the axis mapping (I should add that...).

In the meantime, you can achieve this by writing a small program.

In the map you would add:

script vendor=0x1235 product=0xab21 device=0
code "dpad.code"

I can help with the code if necessary.

Kind regards
Alexandre

[Colin Dryden]

Hi Alexandre,
I too am struggling with mapping an axis to key(s) for the same reason. The lack of a deadzone seems to be the issue, but I also can't seem to get the binary flag to work.

axis vendor=0x054c product=0x0268 src=0 target=kbd plus="k" minus="i" flags=binary
axis vendor=0x054c product=0x0268 src=1 target=kbd plus="l" minus="j" flags=binary

The above code causes the entire .map file to not load. As soon as I remove "flags=binary", it loads, but immediately returns an "k" as if it was being pressed and not released.

Hoping you can clarify how to use flags=binary properly. I am using RaspberryPi if that helps.

Alternatively, if the code you mentioned above is simple, I'd love to hear your suggestion for adding a deadzone of sorts...

[Alexandre Hardy]

Hi Colin,

Please see my post above to Moshe. Writing code does provide workable alternatives, although it is a bit more complex. I find myself writing a lot of code for old DOS games to give me the exact behaviour I want (well, on the rare occasions I run them). Including using the switching hat for snap views etc.

The short example above should get you going. If you want to see what can be done, you can have a look at the xwing.code example, which I put together for X-Wing. In that case I implemented snap views, power management, and even setup the analog throttle to control the X-wing throttle (which is managed in X-Wing by incremental changes).

The xwing example is available here: https://sourceforge.net/p/linuxjoymap/wiki/xwing.code/

As for the "binary" flag. That should work. Can you confirm which version of linux joymap you are running? Maybe it is an older version...

Kind regards
Alexandre

[Moshe Dahan]

Alexandre,

Just as an addition to Colin's remark here. As you can see above the binary flag did not work for me as well. Weather with it or without it I still had the same problem. Aparently the dead zone issue is a pretty big one based on all several comments and questions in this forum.
Is there any chance you are working on some code that will allow us to fine tune and tweak the deadzone for axis in the near future?

[Alexandre Hardy]

Hi Moshe,

Umm, in your case binary flag did not have the desired effect, but was accepted. In Colin's case the joymap program refused to accept the binary flag. So I think it is a bit different.

I am not currently working on any code for the deadzone at the moment, I have been working on other projects. I may implement the deadzone feature sometime soon, but quite honestly I'm not promising anything. It shouldn't take long. But a "shouldn't take long" at the end of a full work day doesn't always happen.

Just to make sure we are getting what we want out of this, can you use jscal to find out the range being returned? It will help if I can get:
1. The min and max value when you press the D-Pad buttons (please record the value when pressing min, as well as variation, and the value when pressing the max, and variation).
2. What the axis reports when you are pressing absolutely nothing. Please include min and max values, and anything else you think is pertinent.

This helps me to simulate the behaviour, which helps me to test that I am actually producing something that works for you (which is important, since I don't have this problem with my own joystick).

Kind regards
Alexandre

[Mayki]

Hi Alexandre,
Need help with setting the PS3 gamepad as a mouse for DOSBox. I created mouse.map:

# General Mouse Mapping for DOSBox

# Map Mouse
axis vendor=0x054c product=0x0268 src=0 target=mouse axis=0
axis vendor=0x054c product=0x0268 src=1 target=mouse axis=1
button vendor=0x054c product=0x0268 src=13 target=mouse button=0
button vendor=0x054c product=0x0268 src=15 target=mouse button=1

The mouse buttons are working properly, problem is analog axis. The left analog stick in the middle : constantly sends the cursor to the upper left corner, analog stick in the right down position : the cursor stops at the zero position. Tested in the game Albion, Abuse and directly in DOSBox, the mouse cursor will automatically move into the upper left corner and not move him.

cd /dev/input/
jstest js0

Axes X - max left -32767, middle 0, max right 32767
Axes Y - max up -32767, middle 0, max down 32767

Can you please help me with this problem?

[Alexandre Hardy]

Hi Mayki,

Sounds like you are doing everything correctly. I suggest you use the desktop to test it out a little.

It turns out I made some assumptions in the mouse code, assuming a certain calibration. Thats what you get for not testing or using code you write.

You have two options:
1. Calibrate the joystick to return values in the range 0-255. I think you can use tools/jscal256.c to do that. I haven't touched it in a long time though.
2. Edit events.c (function process_axis) line 323 to your liking.

                 //it is an axis
                value-=127;
                value/=32;

You can see how we take 0-255, subtract 127 to get this in the range [-127, 128]. And then divide by 32 to prevent the mouse cursor flying off the screen.

Yip. It isn't great.

Or if that doesn't work, you can write code (yes, I write code for a lot of things) to get your desired behaviour via the scripting engine.

I hope that helps.

Kind regards
Alexandre

[Mayki]

So, unfortunately, I have no idea what to do ... :-(
I do not know how to run tools/jscal256.c, change in events.c nothing success.

[Alexandre Hardy]

So, unfortunately, I have no idea what to do ... :-(
I do not know how to run tools/jscal256.c, change in events.c nothing success.

Erm. Then I guess you'll have to wait until I make that more configurable. I could also add a debug mode to help debug this case....

That may take some time.

[Colin Dryden]

Hi Alex,

I ran a seperate map file for dos to see what would happen to the mouse and it goes off to the top left as well. So following your post, I compiled jscal256 and ran it.

Not really sure what it does, but I was curious. It ran just fine and I could see the output of all my controls on my PS3 controller. When I moved the axes, they went from -127 to 127. When left alone they reported 0. Strange that this tool reports 0, but loadmap will send the mouse flying to the top left.

When I move the mouse to the bottom right, it seems to stop the mouse movement when the map is loaded... and jscal256 reports this as 127,127. It's as if loadmap thinks 127,127 is the neutral position. As you can tell, we really don't have any options for mapping in rpi other than your tool ;)

You state that events.c subtracts -127... does this mean it is subtracting -127 from 0,0 and the end result is -127,-127? Because this is starting to make sense. Either that or I need coffee. After all 127,127 appears to be 0,0 when I use loadmap...

And Mayki, to use jscal256, you need to compile it:

cd joymap/tools
make jscal256
./jscal256

The instructions say to move the joysticks around and to press a button to end the script. I really don't know what it does.

[Alexandre Hardy]

The instructions say to move the joysticks around and to press a button to end the script. I really don't know what it does.

It uses ioctls to tell the linux kernel to remap the reported axis range to values determined by the program. You move the joysticks around to let it determine the minimum and maximum axes values, which are then used to compute calibration coefficients for the linux kernel to use. You should see a difference on jsinfo after running this program, unless your joystick is very good already.

When I move the mouse to the bottom right, it seems to stop the mouse movement when the map is loaded... and jscal256 reports this as 127,127. It's as if loadmap thinks 127,127 is the neutral position. As you can tell, we really don't have any options for mapping in rpi other than your tool ;)

I've just pushed a new version to the bzr repository which adds:
1. min and max values (in case your axes aren't reporting the full range).
2. deadzone based on a -32767 to 32768 range.
3. trinary flag (like binary, but the zero position resets. Which I think is what you need for your D-PAD. But I'm guessing here).
4. Adjusted mouse code for the -32767 to 32768 range.

I've only tested min, max, deadzone and trinary (actually, I tested that on osxjoymap, but the code is basically the same). The mouse code is untested.

I'll try test this tomorrow, first going to get some sleep.

If you are eager to test it out, feel free to pull the source from the bzr repository and give it a spin.

[Alexandre Hardy]

joymap 0.4 uploaded (I'm not in the habit of adding a tag in bzr unfortunately). This should help solve your problems. There are new options for mapping axes to buttons (trinary mode which acknowledges the zero position), deadzone. Mouse code has also been reworked to use 0,0 as no movement. speed must be set otherwise the cursor will fly all over the show (because the default passes values through mostly untouched).

[Alexandre Hardy]

joymap 0.4 uploaded. This should help solve your problems. There are new options for mapping axes to buttons (trinary mode which acknowledges the zero position), deadzone. Mouse code has also been reworked to use 0,0 as no movement and work with a range of -32767 to 32767. speed must be set otherwise the cursor will fly all over the show (because the default passes values through mostly untouched).

[Colin Dryden]

Hi Alexandre,

I just did a quick test of joymap 0.4 and it solved the mouse issue I was having in dosbox on my RPi (the cursor was always wanting to move to the top left of screen). I did not have to modify the speed as it seems to work comfortably without modification.

I will try out mapping key presses to the axes now. Thank you for taking the time to work on this! Great work.

[Colin Dryden]

Hmm, mouse works perfectly (yay!), but I am still having an issue when mapping axes to buttons. They don't "release" as expected. Using plus and minus, I mapped axes 0 and 1 to up, down, left, right. If I move the axis at all, it just keeps returning a button press after setting the axis back to neutral. The only way to stop it is to press another button on my gamepad... as if it is stuck in a loop and a button press breaks the loop.

[Alexandre Hardy]

Hi Colin,

Can you please provide the map file you are using, highlighting the mappings that have problems?

Please also use jsinfo to determine the min, max, and centered values of the axes you are having problems with. I can then look at what the problem is.

I believe that the joymap software should handle this case correctly now, so it may be that the mappings just have to be tweaked a bit using the new settings and flags introduced in joymap-0.4.