Jinput webstart demo wont run on linux 64bit

[gouessej]

When I use this link:
http://www.newdawnsoftware.com/resources/jinput/webstart/jinput.jnlp
I get this on Linux 64 bits:

14 déc. 2010 11:52:09 net.java.games.input.DefaultControllerEnvironment getControllers
INFO: Loading: net.java.games.input.LinuxEnvironmentPlugin
14 déc. 2010 11:52:09 net.java.games.input.ControllerEnvironment log
INFO: Failed to load library: no jinput-linux64 in java.library.path

java.lang.UnsatisfiedLinkError: no jinput-linux64 in java.library.path
   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1734)
   at java.lang.Runtime.loadLibrary0(Runtime.java:823)
   at java.lang.System.loadLibrary(System.java:1028)
   at net.java.games.input.LinuxEnvironmentPlugin$1.run(LinuxEnvironmentPlugin.java:66)
   at java.security.AccessController.doPrivileged(Native Method)
   at net.java.games.input.LinuxEnvironmentPlugin.loadLibrary(LinuxEnvironmentPlugin.java:58)
   at net.java.games.input.LinuxEnvironmentPlugin.<clinit>(LinuxEnvironmentPlugin.java:101)
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:169)
   at net.java.games.input.DefaultControllerEnvironment.getControllers(DefaultControllerEnvironment.java:159)
   at net.java.games.input.test.ControllerReadTest.<init>(ControllerReadTest.java:252)
   at net.java.games.input.test.ControllerReadTest.main(ControllerReadTest.java:301)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at com.sun.javaws.Launcher.executeApplication(Launcher.java:1799)
   at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1745)
   at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1507)
   at com.sun.javaws.Launcher.run(Launcher.java:129)
   at java.lang.Thread.run(Thread.java:619)
14 déc. 2010 11:52:09 net.java.games.input.ControllerEnvironment log
INFO: net.java.games.input.LinuxEnvironmentPlugin is not supported

Do I still have to change some rights on some directories to use controllers on Linux? If so, maybe this could be a nice source of inspiration (SFML does not need such tinkerings according to the author but I'm sceptical):
http://sfml.svn.sourceforge.net/viewvc/sfml/trunk/src/SFML/Window/Joystick.hpp?view=markup
http://sfml.svn.sourceforge.net/viewvc/sfml/trunk/src/SFML/Window/Linux/Joystick.hpp?view=markup
http://sfml.svn.sourceforge.net/viewvc/sfml/trunk/src/SFML/Window/Linux/Joystick.cpp?view=markup

[endolf]

The webstart demo is probably a fair bit out of date, I will take a look and see at some point. Looking at SMFL, it doesn't support rumblers, which JInput does, it needs read access to /dev/input/js* devices, but most distros give this as it's not considered insecure. JInput should offer the same functionality (ie, less) if it can't read the /dev/input/event* nodes as SMFL does (no mouse, no keyboard, joysticks only and no rumbler support).

Endolf

[gouessej]

On Mandriva Linux and Cent OS, these devices are still readable only by the root Is it different on Ubuntu?

Games published by our own members! Check 'em out!

[endolf]

I believe so, but I always give access to /dev/input/event* devices to my own user too as I need to test mouse and keyboard, so I've not checked recently.

Endolf

[gouessej]

Hi!

Sorry to ressurect this old thread. The Web Start demo does not work even now. Where can I find a working demo of JInput?

Does JInput work fine when it has a read access on /dev/input/event* and /dev/input/js*? Is there an elegant way of doing a chmod in Java otherwise? Could I use PosixFileAttributeView.setPermissions(Set<PosixFilePermission> perms) to do it?

I plan to use JInput in my first person shooter because I would like to support controllers.

[endolf]

Sorry to ressurect this old thread. The Web Start demo does not work even now.

You'll have to give more information than that, what distro, any error messages on the java console?, which jdk?

Does JInput work fine when it has a read access on /dev/input/event* and /dev/input/js*? Is there an elegant way of doing a chmod in Java otherwise

JInput does work with read access, but rumblers won't, they need write access. Doing a chmod is not in the remit of JInput, you'll have to figure that one out outside of java probably.

Endolf

[gouessej]

Java Web Start 1.6.0_26
Using JRE version 1.6.0_26-b03 Java HotSpot(TM) 64-Bit Server VM
----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
0-5: set trace level to <n>
----------------------------------------------------
Aug 1, 2011 12:59:29 PM net.java.games.input.ControllerEnvironment log
INFO: Failed to load library: no jinput-linux64 in java.library.path

java.lang.UnsatisfiedLinkError: no jinput-linux64 in java.library.path
   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1738)
   at java.lang.Runtime.loadLibrary0(Runtime.java:823)
   at java.lang.System.loadLibrary(System.java:1028)
   at net.java.games.input.LinuxEnvironmentPlugin$1.run(LinuxEnvironmentPlugin.java:69)
   at java.security.AccessController.doPrivileged(Native Method)
   at net.java.games.input.LinuxEnvironmentPlugin.loadLibrary(LinuxEnvironmentPlugin.java:61)
   at net.java.games.input.LinuxEnvironmentPlugin.<clinit>(LinuxEnvironmentPlugin.java:104)
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:169)
   at net.java.games.input.DefaultControllerEnvironment.getControllers(DefaultControllerEnvironment.java:159)
   at net.java.games.input.test.ControllerReadTest.<init>(ControllerReadTest.java:253)
   at net.java.games.input.test.ControllerReadTest.main(ControllerReadTest.java:302)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at com.sun.javaws.Launcher.executeApplication(Launcher.java:1809)
   at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1750)
   at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1512)
   at com.sun.javaws.Launcher.run(Launcher.java:130)
   at java.lang.Thread.run(Thread.java:662)
Aug 1, 2011 12:59:29 PM net.java.games.input.ControllerEnvironment log
INFO: net.java.games.input.LinuxEnvironmentPlugin is not supported

I use Cent OS Linux 5.3, Oracle Java 1.6 update 26. Read access is ok on /dev/input/event*

[endolf]

Can you take a look at your properties and see what os.name, os.arch and other os properties contain?

Cheers

Endolf

[gouessej]

These data are used by Java to compute os.arch, os.name, etc:

uname -a
Linux ***** 2.6.18-238.el5 #1 SMP *** *** ** **:**:** *** **** x86_64 x86_64 x86_64 GNU/Linux

os.arch = amd64 on this machine as far as I know

[endolf]

Hi

It's the values that are important, in the jnlp it has x32_64 or something IIRC for 64 bit linux, but if that is not what is being checked, then it won't work. So I just need to confirm the values you are seeing.

Cheers

Endolf

Games published by our own members! Check 'em out!

[gouessej]

I have just tested the JNLP file of JOGL 1.1.1a and it gets the JAR containing native libraries unlike your JNLP file. If you use x86_64, it will not work here but maybe with another JVM. You can detect both x86_64 and amd64 but point them to the same JAR containing the native dependencies, it will work fine.

This works for JOGL 2:

1   2   3   4   5   6

<resources os="Linux" arch="amd64">       <nativelib href = "jogl-natives-linux-amd64.jar" />     </resources>     <resources os="Linux" arch="x86_64">       <nativelib href = "jogl-natives-linux-amd64.jar" />     </resources>

[endolf]

Agreed, that's exactly what I was checking for when I asked for information on the properties, but I wanted to confirm that was the issue before changing anything, so can you confirm the contents of your properties that java holds.

Endolf

[gouessej]

Agreed, that's exactly what I was checking for when I asked for information on the properties, but I wanted to confirm that was the issue before changing anything, so can you confirm the contents of your properties that java holds.

Endolf

This:

1   2   3   4   5   6

public class Test {    public static final void main(String[] args){       System.out.println(System.getProperty("os.name") + " " + System.getProperty("os.arch"));    } }

returns this:

Linux amd64

[endolf]

Cool, thank you, I'll update the JNLP tonight.

Endolf

[gouessej]

Cool, thank you, I'll update the JNLP tonight.

Endolf

You're welcome. I will test JInput on some other machines with Linux, I hope that only a very few of them require a modification of file access.

For 32 bits Intel machines, please use at least x86 and i386 so that it is consistent with JOGL. Some weird VMs may return the former or the latter.

Is it possible to use plain AWT for the keyboard and JInput for the controllers?

[endolf]

I will test JInput on some other machines with Linux, I hope that only a very few of them require a modification of file access.

My experience is that js devices are fine, the rest are normally not even readable by default. Which sucks, but such is life in linux it seems.

Is it possible to use plain AWT for the keyboard and JInput for the controllers?

Yes, there is an AWT plugin provided, with all the limitations that brings (no support for multiple mice/keyboards as seperate controllers, no input when not in the application window for mouse/keyboard). As long as that is ok, then you can use that plugin. The details for how to change plugins should be on the forum somewhere

Endolf

[gouessej]

I get this on Mageia Linux 1 (fork of Mandriva Linux):

[gouessej@localhost ~]$ ls -l /dev/input/event*
crw-r----- 1 root root 13, 64 août   1 18:53 /dev/input/event0
crw-r----- 1 root root 13, 65 août   1 18:53 /dev/input/event1
crw-r----- 1 root root 13, 66 août   1 18:53 /dev/input/event2
crw-r----- 1 root root 13, 67 août   1 18:53 /dev/input/event3
crw-r----- 1 root root 13, 68 août   1 18:53 /dev/input/event4

but I get this:

1 août 2011 19:14:30 net.java.games.input.ControllerEnvironment log
INFO: Failed to open device (/dev/input/event0): Failed to open device /dev/input/event0 (13)


1 août 2011 19:14:30 net.java.games.input.ControllerEnvironment log
INFO: Failed to open device (/dev/input/event1): Failed to open device /dev/input/event1 (13)


1 août 2011 19:14:30 net.java.games.input.ControllerEnvironment log
INFO: Failed to open device (/dev/input/event2): Failed to open device /dev/input/event2 (13)


1 août 2011 19:14:30 net.java.games.input.ControllerEnvironment log
INFO: Failed to open device (/dev/input/event3): Failed to open device /dev/input/event3 (13)


1 août 2011 19:14:30 net.java.games.input.ControllerEnvironment log
INFO: Failed to open device (/dev/input/event4): Failed to open device /dev/input/event4 (13)


1 août 2011 19:14:30 net.java.games.input.ControllerEnvironment log
INFO: Linux plugin claims to have found 0 controllers

Actually, I would like to use plain AWT to handle the keyboard in Ardor3D and JInput to handle the controllers. I worked a lot on a way of finding an equivalent of default keys for a first person shooter on non-QWERTY keyboards (WSAD); I don't want to rewrite everything.

[endolf]

I get this on Mageia Linux 1 (fork of Mandriva Linux):

[gouessej@localhost ~]$ ls -l /dev/input/event*
crw-r----- 1 root root 13, 64 août   1 18:53 /dev/input/event0
crw-r----- 1 root root 13, 65 août   1 18:53 /dev/input/event1
crw-r----- 1 root root 13, 66 août   1 18:53 /dev/input/event2
crw-r----- 1 root root 13, 67 août   1 18:53 /dev/input/event3
crw-r----- 1 root root 13, 68 août   1 18:53 /dev/input/event4

Are you (gouessej user) in the root group?

Endolf

[endolf]

I've updated the jnlp and the build farm has finished chewing it, see what happens

Endolf

[gouessej]

Are you (gouessej user) in the root group?

I'm silly, I'm not:

1   2

[gouessej@localhost ~]$ id uid=500(gouessej) gid=500(gouessej) groupes=500(gouessej)

I hope it will work at least with controllers. I will perform another test tomorrow on a 64 bits machine, this one is a 32 bits machine. Thank you very much.

[gouessej]

I obtain this now:

java.lang.UnsatisfiedLinkError: .java/deployment/cache/6.0/15/307218f-3999fd85-n/libjinput-linux64.so: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by .java/deployment/cache/6.0/15/307218f-3999fd85-n/libjinput-linux64.so)

[endolf]

Ok, so the version of glibc jinput was compiled against was 2.7 and you have a different version. Without statically linking the whole of glibc in to jinput, I'm not sure what can be done (I confess I've not explored thoroughly).

Any ideas?, otherwise you might have to compile jinput libs yourself. It's one of the joys of linux as I understand it.

Endolf

[gouessej]

Statically linking the whole glibc would solve my problem. I cannot compile JInput with each version of glibc. How are such things done in LWJGL? I don't have such errors with LWJGL and JogAmp (JOGL, JOAL, JOCL, etc...).

[endolf]

Statically linking the whole glibc would solve my problem.

It wouldn't do any good for my bandwidth though

How are such things done in LWJGL? I don't have such errors with LWJGL and JogAmp (JOGL, JOAL, JOCL, etc...).

I don't know, feel free to find out and I'll see what can be done with JInput, it might be as simple as some compiler/linker arguement(s), but I don't know I'm afraid.

Endolf

[gouessej]

JOGL 1.1.1a only contains about 1 and 2 MB, it doesn't have such problems. I will ask some help to Sven. I assume there is a way to use a static link to a library without embedding it entirely.

[gouessej]

Sven answered here:
http://forum.jogamp.org/Is-JogAmp-statically-linked-to-glibc-tp3218570p3218570.html

[endolf]

Hi

Ok, so they do the same as JInput does, the only difference is their build machine is still on an older version of libc. The build farm JInput uses is not exclusively for JInputs use, and I had to upgrade the distribution for another build. I will take a look at the possibility of rolling libc back, or installing an older version in parallel for building against, but I don't know when I'll have time to do this.

My best suggestion currently is for you to build the linux binaries on an old enough version of libc to cover your target user base. Users on newer version will still be fine on that.

Endolf