how to get JInput to work under linux?

endolf · February 10, 2004, 8:20pm

Hi
I was right, thats not the code you are running, the code you are running has the comments in :), ok, if kb.poll() is causing the null pointer then I guess kb is null. That means it’s not found a controller of type KEYBOARD (looking at your constructor). How many controllers are listed when you dump cont.length?

It looks like it is due to the plugins code. the linux.jar should be in a directorycalled controllers that is located from where you are running. Either that, or you can specifiy the class to use for the environment with the property jinput.plugins and use the classname of the plugin, in this case net.java.games.input.LinuxEnvironmentPlugin. But by default the controllers directory is scanned for any plugins so you should use that ideally.

HTH

Endolf

Conzar · February 10, 2004, 10:46pm

0 controllers are listed.

so the directory called ‘controllers’ should be in the same directory as the code that is to be executed? I’ve tried that and it didn’t work.

endolf · February 11, 2004, 5:12am

Was the linux.jar in there?

Conzar · February 11, 2004, 12:17pm

yep. maybe I’m not spelling the directory correctly???

endolf · February 11, 2004, 4:01pm

Hi
Take a look at the layout of the ready to run binaries, and mirror it, that should get you running.

Cheers

Endolf

TheBohemian · February 11, 2004, 5:06pm

Why is that strange plugin mechanism needed btw? And aren’t there enough of such mechanisms (Eclipse?!?)?

I once read that it would be possible to selectively load multiple plugins. But I am wondering how many plugins one need per machine? I think every OS offers only one API for comprehensive input management. Well one could write a jinput plugin using Win32 API oder DirectInput but what would be the benefit?

I am very happy with the way JDBC drivers are loaded or every other classpath-compatible library. But Jinput seems to be doomed to suffer not only from features but also from a really odd plugin mechanism.

@Endolf:
I am going to provide you with problematic sample code (see end of 1st page) just when my exams are over … (2 weeks or so)

Jeff · February 11, 2004, 9:03pm

I’ll take Design for 200, Bob

The plug-in mechanism exists fro a few reasons:

(1) To make the fundemental library platform neutral. The only cdoe that is paltform specific is well-isolated in the plug-ins. This is a stability feature.

(2) To allow for arbitrary additional controllers. (eg See the post by the guy who wants to support his flock-of-birds position detection system.)

Fundementally I believe its a strong, good mechanism and was written for the job at hand. I don’t know eclipses plug-in structure, but I suppose someone could as easily ask why Eclipse came up with one when NetBeans had had one for years. If you did you would likely get a similar answer.

As the JUtils plug-in system has already proved useful to another project (not a core project) here I think its proving out that its combination of simplicity and features hits a sweet spot for some apps at least.

Jeff · February 11, 2004, 9:05pm

FWIW btw I am NOT happy on a personal level with the JDBC solution.

Having to put a string reference to the driver into the context of the app to me is just wrong. Drivers are a matter of environment, not application. And havign to do a manaul class load that you throw away just so it can run its static initializers and register itself IMO is very very ugly.

Conzar · March 17, 2004, 5:11pm

Hello again.

I’m frustrated with getting this to work. I don’t understand the directory structure needed to get the JVM to find the plugin and I don’t understand the jinput.plugins environment variable.

Could someone clear this up. Maybe write a small howto or some documentation on how this works? If there is such documentation, please point me there.

Thanks

endolf · March 18, 2004, 4:55am

Hi
Jeff is working on such a document, but I suspect he is rather busy with GDC right now. If you get the nightly builds it has the directory structure in it.

Cheers

Endolf

Conzar · March 18, 2004, 6:02pm

so I put the following dir struction in the same directory as my program and it doesn’t work:

plugins/linux/src/native/libjinput.so

This is the same as whats in the nightly builds as well as cvs.

endolf · March 19, 2004, 6:35am

Hi
Ok, I was wrong, the binaries are not right. In your classpath you need jinput.jar and jutils.jar then in the directory you run from you need a controller directory that contains libjinput.so and linux.jar

The test I did was to create a new empty directory, I copied the jinput.jar and jutils.jar to that directory, I created a controller directory and copied libjinput.so and linux.jar to the controller directory so I ended up with

./jinput.jar
./jutils.jar
./controller/libjinput.so
./controller/linux.jar

and then ran

java -cp jinput.jar:jutils.jar net.java.games.input.test.ControllerTextTest

it found the linux plugin fine.

You can move jinput.jar and jutils.jar around as long as you update your classpath. If you move the plugin then you must use the plugin property to cope.

For example, with a fresh copy of the binary the following command works

java -cp coreAPI/bin/jinput.jar:\
coreAPI/lib/jutils.jar:\
plugins/linux/bin/linux.jar \
-Djava.library.path=plugins/linux/src/native \
-Djinput.plugins=net.java.games.input.LinuxEnvironmentPlugin \
net.java.games.input.test.ControllerTextTest

Note that the library path needs to be updated so that the .so can be loaded.

Cheers

Endolf

Conzar · March 19, 2004, 1:23pm

Hey.
That clears a bunch up. Thank you for posting that mini-howto.

I ran the net.java.games.input.test.ControllerTextTest and all it did was show that it indeed found the linux plugin but thats all it did. I am guessing that it couldn’t find any devices and so exited.

Thats what happened to the previous KeyboardTest.java program did when I ran it (below is the output of that prog — it gets a null pointer b/c it needs at least 1 device there for it to work properly).

Anyways, I am running the 2.6.1 kernel so shouldn’t the keyboard and mouse be reconigzed by jinput?

Thanks


mspeth@fmp keyboard $ ./run
Scanning jar: linux.jar
Examining file : META-INF/
Examining file : META-INF/MANIFEST.MF
Examining file : net/
Examining file : net/java/
Examining file : net/java/games/
Examining file : net/java/games/input/
Examining file : net/java/games/input/LinuxDevice$LinuxHat.class
Examining file : net/java/games/input/LinuxDevice$ButtonID.class
Examining file : net/java/games/input/LinuxDevice$1.class
Examining file : net/java/games/input/LinuxDevice.class
Examining file : net/java/games/input/LinuxAxis.class
Examining file : net/java/games/input/LinuxEnvironmentPlugin.class
Found candidate class: net/java/games/input/LinuxEnvironmentPlugin.class
Adding class to plugins:net.java.games.input.LinuxEnvironmentPlugin
Examining file : net/java/games/input/LinuxKeyboard$KeyID.class
Examining file : net/java/games/input/LinuxKeyboard.class
Examining file : net/java/games/input/LinuxMouse$LinuxMouseBall.class
Examining file : net/java/games/input/LinuxMouse$LinuxMouseButtons.class
Examining file : net/java/games/input/LinuxMouse$LinuxMouseButton.class
Examining file : net/java/games/input/LinuxMouse.class
Examining file : net/java/games/input/LinuxNativeTypesMap.class
Examining file : net/java/games/input/NativeDefinitions.class
cont: 0
Exception in thread "main" java.lang.NullPointerException
        at KeyboardTest.keyboardupdate(KeyboardTest.java:20)
        at KeyboardTest.<init>(KeyboardTest.java:15)
        at KeyboardTest.main(KeyboardTest.java:32)

endolf · March 19, 2004, 2:18pm

Hi
glad it’s finding the plugin now. The output from ControllerTextTest would be far more useful. I can’t do it now, but there is an option in the native build.xml that can be set to have the library dump a whole load of debug at runtime, I think i might try setting it in this case.
You are right, under 2.6.* if you have a k/b plugged in it should be detected, if you have a mouse installed with a driver (usb, ps/2) then it should pick that up too. As long as you have /dev/input/event* devices for them that is, and with read and write permissions for the user running the code.

HTH

Endolf

TheBohemian · March 24, 2004, 11:13am

Although placing the plugin files inside the ‘controller’ directory works nice I think it was meant more like this:

/controller/linux-plugin/linux.jar
/controller/linux-plugin/libjinput.so

The reason for that additional directory is to handle different version of the same library. eg:

/controller/linux-plugin1.0/linux.jar
/controller/linux-plugin1.0/libjinput.so
/controller/linux-plugin1.2/linux.jar [same file as above]
/controller/linux-plugin1.2/libjinput.so [updated or simply a custom build]

This will actually double the amount of devices available to your apps when you do that with two identical plugins.
So imagine someone writes that “flock of birds”-plugin it can be installed like this.

/controller/linux-plugin/linux.jar
/controller/linux-plugin/libjinput.so
/controller/fob-linux/fob-jinput-linux.jar
/controller/fob-linux/libfobjinput.so

Currently nobody will run into problems by not using an additional subdirectory but as soon as there is more than one plugin available for a specific platform confusion may start.

Jeff · April 4, 2004, 9:28pm

yes. It was also desigend that way for another reason.

People tend to name their DLLs with common names. Things like “joystick.dll”. These can clash if ist all in one directory and make it impossible to use two plug-ins together.

A jar name clash can be sovled by renaming the Jar but the DLL name is hrdocded generally in the jar and can’t be changed.

The subdirectory system is ther to support different plugins, written independantly, that share DLL (or for that matter jar) names.