JInput (in fact its is JUtils where the PluginClassLoader lives) does some strange stuff. I tend to avoid this strange plugin system at all and simply call:

This assumes that the native library (e.g. dxinput.dll) is in the directory from where you are calling this.
Jeff's plugin mechanism may be nice but IMHO causes to much hassle especially if you have multiple JVMs installed.

The names of the plugin classes are listed on the introduction page.

do not use the property if you have copied the plugin jar into the controller directory. the two approaches are mutual exclusive.

Yes I meant giving permissions with chmod.

Please try 'cat /dev/input/eventXY' and move around your mouse, press keys. If the console is filled with garbage then everything is ok and JInput should be able to find the devices as well.


Sorry. No idea here.

Hey this looks like my tutorial. :-)

You need to allow reading of /dev/input/eventXX files. For 2.4-kernels only USB-devices make a event-file. I am not used to Fedora (nor mandrake) but I am sure you can create those files with mknod and then it should work (see kernel documentation input/input.txt for information about the event files).

Ultimately I advise using a 2.6-kernel because you get mouse and keyboard support there, too.

@chlafaille: /dev/input/jsXX files are not used by the plugins (I guess this for endolf's linux plugin, mine doesn't thats for sure ).

the location of the mouse pointer? No and it is not planned (IMHO).
But you can use java.awt.MouseInfo.getPointerInfo().getLocation() which is available since JDK 1.5

With 1.1b6 I have the following problem when switching between from fullscreen to windowed mode:

Using ATI workaround of dispatching display() on event thread
Xlib: unexpected async reply (sequence 0x6b80)!

This happens with:
- Linux 2.6.9
- XFree 4.3
- ATI Radeon 9800XT (R350 NJ) - fglrx 3.14.1 (latest)

This worked prior to b06.

The initial problem sounds similar to what I needed in FFMKI. There are controls which can be continously pressed (e.g. fire buttons) and others which needed a pause. I wrapped everything up in a Control interface having the methods:



The magic behind reset() is that it makes isPressed() returning false as long as the user did not release the key, button or axis.

I hope this is what the original poster wanted.

which license will these games have?

This looks more like a bug of the JDK... What version are you running?

I am surprised about endolf's answer because even in C shutdown hooks exist. Additionaly the JVM provides them via the Runtime class: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)

AFAIK DirectInput is not able to do this. On Linux things are a bit different. I just do not know how device additions and removals could be detected but that does not mean that it is not possible. Maybe we should contact the appropriate maintainer for this.

If you want to test my plugin I have very convenient option for you.
The intro post now contains a JNLP link to JInputTester. IMHO a better
app then controllerreadtest and such ...
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jinput;action=display;num=1087611855

I think it would be a good idea to add your experience with JInput on Linux to the wiki.

Btw: Is it this http://wiki.java.net/bin/view/Games you are talking about? Looks pretty empty for JInput ...

I have re-released the app. Links are now available in the sticky introduction thread: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jinput;action=display;num=1087611855

Ready!

Follow the link in the introduction:
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jinput;action=display;num=1087611855

Just wanted to mention that I have updated the first post again and added links to JInputTester.

can you look up the mouse in /proc/bus/input/devices and post its entry?

are there enough access rights for that new event device file?

how is my plugin reacting? does the device show up or is it left out (which means that it was thrown away because the kernel said it had no usable controls on it)?

can you post a link to an online description of the hardware?

And I thought I was alone with this feeling

On what platform do you want to use the wheel? Usage information for JInput can be found in the sticky thread of the JInput forum. Just connect your wheel and run some sample apps. I have written such an application some time ago (JInputTester). But it needs a little cleanup now to work out of the box.
Maybe I get the JNLP working again ... this would allow you to test your wheel very quickly... I post again when I am ready with it.

It seems that you have not activated evdev support in your kernel. Just run 'make menuconfig' and activate 'Event interface' which is under 'device drivers/input device support'.

Maybe you have compiled it as a module. Its called evdev then.
Can you post the output of the zcat-grep thing which I showed you 2 posts upwards? If you recompile the kernel please post the output with the new one, too.

Btw: 'input device support' ... isn't that a nice argument for the discussion about the naming issue in JInput? endolf, anyone?

err I have another idea: you seem to have attached a lot of devices. maybe there are not enough device files.
it may help to create a few eventXX files with mknod.

have you tried 'cat' on the event devices? this should normally spit out some garbage when moving the mouse around. if not its is possible that you have not configured the mouse to be available as event device.

if you have /proc/config.gz enabled try: zcat /proc/config.gz | grep MOUSEDEV it should return something similar to this:

Have you tried my version of the Linux plugin? The links are the end of the first post here: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jinput;action=display;num=1087611855;start=0#0

If this plugin does strange things too, than there might be a problem on your side.

But on the other hand I had told endolf already that on Linux a single USB keyboard consists of two event devices.

Things are even more strange with the kb drivers since these report keys that do not exist. The last USB kb I had provided not a single additional usable key on the second event device but reported to have plenty of them ... eg. power key and such)

But then the whole API should not be named JInput ... no just kidding.

IMHO its more common knowledge that there are force feedback enabled input devices than naming a keyboard key an axis ...

Lets have a look at the Java API: Gues how the Java Sound API (javax.sound.sampled) named the 'thingies' that make the volume, pan etc? A 'Control', right.

Btw: I wish JInput would look more often at the JDK to adopt well-known patterns from it, eg. service provider interface instead of 'yapm' (Yet Another Plugin Mechanism)

With the extreme simplicity of LWJGL's approach to input devices I wonder what cas has to say about JInput's concept of subcontrollers ...

Calling everything an 'Axis' that is in fact a button, slider, axis etc is quite unusual. AFAIK JInput is not the only library that manages input devices so let's have a look what others do:

a) SDL (see libsdl.org - Doc Wiki)
- names everything except mouse and keyboard a 'Joystick'
- each joystick consists of a variable number of axes, balls, hats and buttons

b) ClanLib (see clanlib.org - docs)
- knows mice, keyboard and joystick, and generally input devices
- distinguishes axes and buttons (and keys for kbs)
- assigns id to each axis/button'/key

c) Allegro (see allegro.cc - Online Manual)
- knows joystick consisting of buttons and axes
- uses flags to describe each control (!) of a joystick
- mouse and keyboard are handled completely different

I just do not get why JInput has to do it more complicated than any of these libraries.

Ah thanks. Someone else then me mentioned renaming both. (done that in a different thread)

Now again with Mark's support:
Please rename both classes.

Good thing - as already said: I found documenting complicated with 'axis', 'axes' and 'Axis'.

I am using it for everything except mouse-style input devices in freefodder.dev.java.net . By default it uses an AWT based input system. That kills gamepad coolness but works everywhere. See the project page for details setting up JInput support in the game.

Did I mention that I had written my own version of the Linux based plugin for this game ...

Bug report: Well, I am not sure but there seems to be a problem with JInput in combination with LWJGL on Windows: The keyboard does not return any poll data (always 0.0f). ATM I am not sure whether this might be a problem on my side. If someone has some spare time he/she might write a little app that controls something in a LWJGL window with JInput.

for the linux plugin I can say that it works although there are 4 abs axes which do not do anything - thats why in my plugin i just ignored them. please have a look at the minimum and maximum data the kernel provides. the problem with these axes is that they marked as being pressed constantly (-1) which is very bad for input autodetection.

another bad thing is that my pc speaker is still a non-usable but visible input device.

another small problem: Controller.getAxes() still exists but returns the Component array. apidoc is outdated too.

Ok, I am going to test this.

No problem with that. Hopefully there will be a little summary about the changes then