Generic gamepad device

[Crionic]

Hi everyone

I recently asked myself, why there is no generic gamepad device on the Pandora. I mean, we have the nubs and the gp-buttons, but they are all different devices (/dev/input/eventX) instead of one single device.

Now, let's say someone ports a game to the Pandora that supports joysticks/gamepads. This game would usually open '/dev/input/jsX' as input device. But all it would find is a simple 2-axis joystick with no buttons (a nub). Not very useful for that game.

So, I thought it should be possible to create a full featured gamepad device that can be used by games. I came up with a solution that uses the kernels user level input subsystem (uinput)

The tool basically creates one single joystick device (/dev/input/jsX) and maps all input from the nubs and gp-keys to that device.

- Left and right nubs are mapped to analog joysticks 0 and 1

- Dpad is mapped to hat-axis

- A/B/X/Y/Shoulders/Select/Start are mapped to the corresponding buttons

So, if a game opens this device, I would find a fully featured gamepad.

However, as I don't know, if there is actually any software on the Pandora that could profit from a gamepad device, I wanted you to judge if this might be useful. 

The attached file contains the compiled binary (gamepad), it's source code (just one file) and a tool (jstest) to test 'jsX' devices (the source for 'jstest' is available here: https://aur.archlinux.org/packages.php?do_Details=1&ID=6693)

gamepad.zip

 

[TrashyMG]

Nice! Perhaps this is finally a solution to DOSBOX and some DOS games that require real joystick buttons that can't be mapped to any thing else.

 

[ptitSeb]

Looks good.

Can both nubs be mapped to the same joystick, but axis 0 to 4 instead?

Also, can the driver be installed inside the game PND, at the launch, and unstalled at quit?

I can use that, because it's a very common problem when porting game!

 

[Crionic]

Looks good.

Can both nubs be mapped to the same joystick, but axis 0 to 4 instead?

They already are. It's basically a 6-axis device (4 analog, 2 digital) with 8 buttons. It can easily be extended or modified.

Also, can the driver be installed inside the game PND, at the launch, and unstalled at quit?

That shouldn't be a problem. You could run the tool from the start script (with '&' option to run in background) and just kill it when it's no longer needed. The kill signal will be caught to do a proper cleanup.

But there is a drawback: You would need root access to load the needed uinput module. Maybe not the best solution for a game.

 

[ptitSeb]

The root access is an issue yes. Not the best way for a game.

 

[Linux-SWAT]

There is no root access problem, as the OP is already bloated with sudoers permissions. Just add a rule to the firmware.

 

[LTStone]

would this be of any use for android games?

 

[Neelix]

Is there any disadvantage to starting this on boot and keeping it active in the background?   Maybe add it to the list of services that can be enabled on boot.  I can't help thinking this should be added to the firmware once it's been thoroughly tested.

- Neelix

 

[God Ginrai]

This has already been done. I don't remember who did it, tho', it was more than 2 years ago.

-God Ginrai

 

[TrashyMG]

This has already been done. I don't remember who did it, tho', it was more than 2 years ago.

-God Ginrai

But what have they done for us recently.

 

[God Ginrai]

This has already been done. I don't remember who did it, tho', it was more than 2 years ago.

-God Ginrai

But what have they done for us recently.

What does that matter?

-God Ginrai

 

[TrashyMG]

What does that matter?

-God Ginrai

I don't know, seemed as valid of a point as what you posted prior.

 

[Crionic]

Is there any disadvantage to starting this on boot and keeping it active in the background?   Maybe add it to the list of services that can be enabled on boot.  I can't help thinking this should be added to the firmware once it's been thoroughly tested.

- Neelix

There shouldn't be a disadvantage to keep it running in background. But would have to do some modifications to reduce cpu usage (maybe using blocking reads). But the question still is, if this is useful anyway, as most Pandora software is probably optimized to use the existing (multiple) devices.

This has already been done. I don't remember who did it, tho', it was more than 2 years ago.

-God Ginrai

Not sure, what you want to tell me. It's been useless junk two years ago, so it still is? 

 

[Neelix]

There shouldn't be a disadvantage to keep it running in background. But would have to do some modifications to reduce cpu usage (maybe using blocking reads). But the question still is, if this is useful anyway, as most Pandora software is probably optimized to use the existing (multiple) devices.

It's been raised as a sticking point several times in the past that it wasn't possible to address the gaming controls as a single device.   I've always figured that the obvious solution would be to do exactly this.  If nothing else I would expect that it would to make it easier to integrate the gamepad controls into future projects, especially ports of software that expects an integrated gamepad.

- Neelix

 

[God Ginrai]

What does that matter?

-God Ginrai

I don't know, seemed as valid of a point as what you posted prior.

No, my point is that this has already been done, so he is reinventing the wheel. Not that it is bad to do so, but he made it sound like he was solving a problem no one else had attempted. Thus, I wanted to make him aware that someone had already done this.

-God Ginrai

 

[TrashyMG]

^ is there a link to this "already done before" project? I don't remember any prior attempts at this and who is to say this project isn't better then the prior attempt.

 

[God Ginrai]

^ is there a link to this "already done before" project? I don't remember any prior attempts at this and who is to say this project isn't better then the prior attempt.

I don't have a link. I was in #openpandora as they were developing it. They were discussing their project as they worked on it.

-God Ginrai

 

[TrashyMG]

So you are saying he should give up working on his project because someone made a similar project that never materialized outside of an IRC chat? because that is what it sounds like.

 

[God Ginrai]

So you are saying he should give up working on his project because someone made a similar project that never materialized outside of an IRC chat? because that is what it sounds like.

No, I'm saying that he's not the first person who thought of, or acted upon, this idea. No more, no less. Don't put words in my mouth.

-God Ginrai

 

[sebt3]

I don't have a link. I was in #openpandora as they were developing it. They were discussing their project as they worked on it.

-God Ginrai

Ho so all you've seen is aTc whining about the current drivers model and how it should be done. You might also have seen a few dev arguing with him.But that's it. No code have been writen in that direction.

(btw aTc solution is nicer and easier that this, but well at least this works)