JInput webstart demo

Engines, Libraries and Tools JInput
#21

Okay that link fails for me(never opens any frames.)

I’m going to do the docs over the next few days as Im traveling. (Going to see a major publisher I can’t name, sorry.)

If i get a chance Ill also DL the latest tree to my OSX box and try to debug more

Here is the output in the console if it means anything to you:

Java Web Start 1.4.2_03 Console, started Wed Feb 25 14:22:58 PST 2004
Java 2 Runtime Environment: Version 1.4.2_03 by Apple Computer, Inc.
net.java.games.input.OSXEnvironmentPlugin instance created
Creating HID engine
Enumerating devices
Found keyboard [Keyboard] device address [3907552]
Adding key [224]
Adding key [225]
Adding key [226]
Adding key [227]
Adding key [228]
Adding key [229]
Adding key [230]
Adding key [231]
Adding key [-1]
Adding key [-1]
Adding key [-1]
Adding key [-1]
Adding key [-1]
Adding key [-1]
Adding key [-1]
Adding key [0]
Adding key [1]
Adding key [2]
Adding key [3]
Adding key [4]
Adding key [5]
Adding key [6]
Adding key [7]
Adding key [8]
Adding key [9]
Adding key [10]
Adding key [11]
Adding key [12]
Adding key [13]
Adding key [14]
Adding key [15]
Adding key [16]
Adding key [17]
Adding key [18]
Adding key [19]
Adding key [20]
Adding key [21]
Adding key [22]
Adding key [23]
Adding key [24]
Adding key [25]
Adding key [26]
Adding key [27]
Adding key [28]
Adding key [29]
Adding key [30]
Adding key [31]
Adding key [32]
Adding key [33]
Adding key [34]
Adding key [35]
Adding key [36]
Adding key [37]
Adding key [38]
Adding key [39]
Adding key [40]
Adding key [41]
Adding key [42]
Adding key [43]
Adding key [44]
Adding key [45]
Adding key [46]
Adding key [47]
Adding key [48]
Adding key [49]
Adding key [50]
Adding key [51]
Adding key [52]
Adding key [53]
Adding key [54]
Adding key [55]
Adding key [56]
Adding key [57]
Adding key [58]
Adding key [59]
Adding key [60]
Adding key [61]
Adding key [62]
Adding key [63]
Adding key [64]
Adding key [65]
Adding key [66]
Adding key [67]
Adding key [68]
Adding key [69]
Adding key [70]
Adding key [71]
Adding key [72]
Adding key [73]
Adding key [74]
Adding key [75]
Adding key [76]
Adding key [77]
Adding key [78]
Adding key [79]
Adding key [80]
Adding key [81]
Adding key [82]
Adding key [83]
Adding key [84]
Adding key [85]
Adding key [86]
Adding key [87]
Adding key [88]
Adding key [89]
Adding key [90]
Adding key [91]
Adding key [92]
Adding key [93]
Adding key [94]
Adding key [95]
Adding key [96]
Adding key [97]
Adding key [98]
Adding key [99]
Adding key [100]
Adding key [101]
Adding key [102]
Adding key [103]
Adding key [104]
Adding key [105]
Adding key [106]
Adding key [107]
Adding key [108]
Adding key [109]
Adding key [110]
Adding key [111]
Adding key [112]
Adding key [113]
Adding key [114]
Adding key [115]
Adding key [116]
Adding key [117]

#22

Good news, was a bad JWS cache. I celared it and nwo it runs.

I see the Mac KB problem. It brings up an interesting issue. Should we either:

(a) Require that well known key names be returned and make the plug-in translate where necessary

OR

(b) Add a function or two to the plugin to convert kb button numbers to/from well known key names.

I’m tempted to say (b) and leave what is returned the raw return values from the OS but I’m not sodl on one or the other. I do agreee that there needs to be a way to find out that a given button is the “w” key on any given platform.

#23

Given that we agree that getting the real key name is a requirement, I don’t see why we don’t go with (a). I just makes things more consitent for the app programmers. If the API sometimes returns valid key names people may not ever call the function in (b). Specially people that don’t have a Mac to test on.

#24

Alright, then Ill suggest we use the Win32 key names as the “standard” as they seem reasonable.

Everyone else agree?

Edit: as part of my doc job this week I will list the well known key names in the docs.

#25

Greg is the one to consult, he has a much better idea of what it will take to get that to work. He also as voiced an objection to “hacking” out the phantom second button (I assume you saw that issue as well?), so I’m going to wait to read what he has to say. He’s not online at the moment, otherwise I would poke him with a stick and get his response.

#26

On the phantom second button issue I can see at elast two reasonable compromises…

(1) Add a property like jinput.osxplugin.nophantombutton
to control the hack

or

(2) Do a seperate plug in that returns the more
“cooked” versions of values.

Just suggestions guys whatever you decide is fine.

#27

I vote for (1).

#28

[quote]On the phantom second button issue I can see at elast two reasonable compromises…

(1) Add a property like jinput.osxplugin.nophantombutton
to control the hack

or

(2) Do a seperate plug in that returns the more
“cooked” versions of values.
[/quote]
You’ll have to do something above the API. I have no idea that its a laptop trackpad. I don’t even know that its actually a one button mouse. I only know that HID gave me a device that has two buttons. Nothing I can do at the API layer. It would have to be done at the application layer where someone can actually take a look at the device string and say ‘ah a laptop trackpad, I will set this up to only have one button’

I’ll go with B on that other requirement. I don’t know key names - the OS doesn’t tell me key names and they will vary based on keyboards for more than a few keys. There is no OS function called ‘getKeyName( scanCode )’ so this would have to be some form of keymap method hardcoded based on the scan codes.

#29

[quote]You’ll have to do something above the API. I have no idea that its a laptop trackpad.
[/quote]
Hmm… the device is called “Trackpad” and the controller name is “Trackpad buttons” - this is what ControllerReadTest shows me. Is that not good enough? Regardless, if we remain undecided on this one, I think we can leave this for a post 1.0 ‘bug’ fix.

That’s what I thought based on the last time we discussed it. It makes things very hard for us to deal with reliably.

Jeff, is there someone at Apple that you can get interested in this issue? I can’t imagine how their HID APIs are useful in the slightest for keyboard input if this is the case. (How does the rest of Mac OS know what key has been pressed? Is the keyboard hacked into the HID APIs but never actually used through HID? A Logitech USB keyboard that I plugged in has the same problem… yet I can use it to type - is there an undocumented API that does the translation? Somewhere in the OS is the information we need… it would be a real shame if we can’t get at it. If we can get someone at Apple involved I’m sure they could get us what we need.

#30

Okay, we may have someone at Apple we can ping on these so I’ll get on that in the next day or so (on the road today and tomorrow.)

On the KB yeah I was figuring it would require a hard-coded translation table.

JK

#31

Well I’ve got hard-coded tables from some other Apple mailing lists… the problem of course is that they don’t cover the various keyboard layouts. The one that comes up most often is German… and I would like for Germans to be able to play a game I make.

Update: I just got a reply from George Warner at Apple.

[quote]You may want to look at the sample HID source code “HID Utilities” at:

http://developer.apple.com/samplecode/Sample_Code/Devices_and_Hardware/HID_Manager/HID_Utilities_Source.htm

The (English) HID usage strings are in “HID_usage_strings.plist” which is an
XML file that can be loaded and searched via the “HIDGetUsageName” function
in <HID_Name_Lookup.c>.
[/quote]
… sounds like he is really just pointing me to another hard-coded table. I’ll prod him for more info on an international solution.

However another developer has responded:

[quote]You should not use a hard coded table to get to the key labels but a hard coded table to get to the virtual key codes instead. I believe you can pull one from one of the headers of the OS 9 USB SDK. Next you can use calls such as KeyTranslate and UCKeyTranslate to convert your virtual key codes to the right keys taking into acount the international keyboard layout.
[/quote]

#32

The qualifier keys not working on the powerbook appears to be a bug in the JInput plugin. Apples HID Explorer shows the state of keys like CTRL changing. (Keyboard Usage 0xe0)

#33

The bug was in Apple’s enumeration code. There qualifier keys are being enumerated more than once. I changed the code such that only the first key that gets enumerated is used. This is a HUGE assumption, but it works for now.

#34

Hello everyone!

Sorry if the question has already been answered but I’m not able to know the required java property(ies) to get jinput working with java webstart?

Can anyone copy paste them for me please?

thanks

#35

Read the intro threads, one of them covers exactly this.

HTH

Endolf

#36

Modified my intro post:

[]highlighted the properterty
[]added a list of known class names

#37

We should really use the Wiki more for this sort of thing… better than trying to find a post here.

#38

now i know you may have heard this before, but for those still having a hard time with jinput and webstart…

read through the JNLP file that is used to launch the webstart demo. most of it is pretty standard, but mainly what you need to look at are the sections for each individual OS. eg:

<resources os="Mac OS"> <j2se href="http://java.sun.com/products/autodl/j2se" version="1.4+"/> [b] <property name="jinput.plugins" value="net.java.games.input.OSXEnvironmentPlugin" />[/b] <jar href="HIDWrapper.jar"/> [b]<nativelib href="jinput-osx-native.jar"/>[/b] </resources>

The property tag named jinput.plugins must point to the class that is the plugin you are using for the OS. (eg. for macOS: net.java.games.input.OSXEnvironmentPlugin).

if you’re distrtibuting the native libs in the same way this demo did then you shouldn’t really need to alter the property from those shown in that JNLP.

to distribute the actual native binaries, you just have to jar them like you would any other class and sign them with the same keystore you did your main game jar. the nativelib tag will allow webstart to handle them properly. you don’t even need to make your own manifest file for these jars.

this’s an example of what i do to prepare the native binaries:
jar -cvf JInputWindowsNative.jar dxinput.dll jarsigner JInputWindowsNative.jar mykey

you also need to sign all the jinput jar files you are distributing with your own key as well.

#39

Hi

There have been a few changes with jinput recently so I’ve gone back and updated the webstart demo. It’s now available here. I’ve tried it on windows and linux, and works as well as it does from the command line. If you look at the jnlp you’ll see that there is no longer a need for the property. There are 3 jars containing just java, 1 for each platform. The data size could be reduced by pulling the plugins out, so there would be 1 shared jar, and 1 for each platform, but that’s an exercise for the reader :).

Endolf

#40

First, thanks for getting the builds sorted, nice job. Sorry… now on to the moan:

Right, I’m totally confused now then… and yes I know it doesn’t take much.

a) The packages I can download either form the jinput site (or direct from newdawn) only contain binary files for windows. I.e. I can get a dll but I can’t get a .so or a .jnilib.

b) Having given up on just getting a normal distribution I thought I’d steal what I needed from the webstart - however:
- I thought there was now just one common java jar between all platforms. That appears not be the cast since there is a jinput java jar in each platform jar (all of which are different sizes).
- Each of the jars is actually expanded into the outer jar aswell. Not sure why this is, but got me even more confused.
- I’ve got the natives out now, but I’m also confused why the natives are appearing in both the jars refered to in the JNLP (i.e. libjinput-linux.so appears in both jinput-linux.jar and jinput-linux-native.jar)

So, wtf is going on?

Kev