I found this project on sourceforce, which adds joystick support to java.
Maybe we should consider adding a jar (of this project or a comparable one) to the tk release like we did for HIAL. And maybe we should add special support for it after we inspected it.
What do you think?
Marvin
First, I’m involved in JInput so I am a little bias. Having said that, javajoystick doesn’t look like it’s been touched in about 3 years, has no support for linux kernels 2.6+ and has no OSX support. All of which jinput has, and is in current development (thanks largly to elias). I’m not oposed to javajoystick, it’s just that there maybe alternatives that you might consider. The choice is yours 
Endolf
Oh, sorry, I forgot JInput. The lib mentioned above was the first one i found by google. I didn’t have a closer look at it so I didn’t discover the long time not updated.
I used JInput about one or two years ago. And I had some problems with it.
It caused a lot of debugging output that the developers weren’t willing to turn off of make optional. This was just ugly but not a no-go (but I would really, really prefer to turn it off). Has this changed?
The second problem, which definitely was a no-go, was that I had to manually set the access bits of the mouse-, keyboard- and joystick devices to read-write. I cannot force the people who are bying my games (in some wonderful future :)) to login as root and change the access bits of device nodes, which isn’t possible for noobs or some kind of “just-gamers” and is unaesthetic for anyone. At least it shouldn’t be necessary. The devices are working fine for other input libraries without these extended access bits. Has this one changed?
If these problems have been solved, I would love to give it a second chance, because it basically looked very good and was quite easy to use.
Marvin
Yes
[quote]The second problem, which definitely was a no-go, was that I had to manually set the access bits of the mouse-, keyboard- and joystick devices to read-write
[/quote]
That was fixed some time in v1, v2 is already out in the wild, give it a try, it’s nicer™
Endolf
Thanks, Croft. Thanks Endolf. I’ll definitely give it a try.
Marvin
An off hand comment for Qudus " From where you get so much time to do all these " …
Reallly wanted to thank you for the kind of support you have given to Xith in recent times …
:o ??? :-\ :’(You’re welcome.
Qudus my friend, the day you don’t answer a question in <5 min., we all know you got one
[quote="<MagicSpark.org [ BlueSky ]>,post:9,topic:28212"]
Qudus my friend, the day you don’t answer a question in <5 min., we all know you got one
[/quote]
hmm… I needed 33 min. Where is she ???
Wait wait wait…are you suggesting that post code and relatively cool exa,ples is not a babe magnet…accckkk wasting time…accckkkk
same for me…I am just on the verge of being able to actively help again
[quote] Reallly wanted to thank you for the kind of support you have given to Xith in recent times … Smiley
[/quote]
Well… what a wonderful world would that be… We are doing what we can do best, and the women loved us for that…
Hey stop that Qudus, you make me dreaming… If only what you said was true…
hmm… I needed 33 min. Where is she ???
[/quote]
Ahmmmm… she wasn’t patient enough… ;D ;D
I tried JInput (2006-08-14er release).
ControllerEnvironment env = ControllerEnvironment.getDefaultEnvironment();
for (Controller c: env.getControllers())
{
System.out.println(c.getName());
}
I got this result:
Failed to open device R/W: Failed to open device /dev/input/event1 (13)
Failed to open device (/dev/input/event1): Failed to open device /dev/input/event1 (13)
Failed to open device R/W: Failed to open device /dev/input/event2 (13)
Failed to open device (/dev/input/event2): Failed to open device /dev/input/event2 (13)
Failed to open device R/W: Failed to open device /dev/input/event0 (13)
Failed to open device (/dev/input/event0): Failed to open device /dev/input/event0 (13)
Linux plugin claims to have found 0 controllers
Am I doing something wrong? I thought it doesn’t need to open the deveices R/W anymore ???
Marvin
PS: I’m using Kubuntu Dapper Drake 6.0.6 with kernel 2.6.15-26-386
Hi
Do you even have read access on those files?
Endolf
Hey, good question. No, I haven’t. Strange. Those files are owned by root:root and have rw bits set for user and group.
I could set rw bits for others now or change the group to something that my user is a member of. But all this shouldn’t be necessary. If I was playing a game utilizing jinput on a system that I don’t have the root password of, it even was not possible. Where does AWT for example get it’s input information from? There must be an input deamon that one should be able to talk to without extended rights.
AWT get’s it from the window manager, and there is an AWT plugin for JInput that exposes mouse and keyboard that does not require direct access to the devices and thus doesn’t need read permissions.
The issue is this. JInput does not rely on the window manager, this it has no concept of one. Under windows, you can open up a window, 0x0 pixels in size, with no task bar entry, and no window around it, and still have access to the devices where ever they are. Under linux, we are not even sure we have a window manager (it will work on a console only terminal), so we have to read/write directly from the event devices, or joystick devices, which are device files like every other character device on linux. On some distro’s you have to modify the access permissions to your graphics card device nodes if you want to use your nvidia card under X in any sort of accelerated maner. So we have no choice but to use the device nodes, and thus we need read access. Write access is optional, but is needed if you want force feedback to work.
There was(is) an SDL plugin around somewhere for JInput 1.0 that might not have had this issue, but required all the SDL libraries to be installed. You would then need to have an SDL window open and forgrounded for the device status changes to be reported though.
HTH
Endolf