USB keyboard oddities

Engines, Libraries and Tools JInput
#1

Hi,

Have experienced strange results with a Memorex USB keyboard under DX9. I haven’t installed the drivers for the additional silly buttons (never use them anyway).

I wrote up a little diagnostic prog to dump the name and type of all controllers to the console.

When I run it, my USB keyboard shows up as 3(!) separate devices of type STICK with the name “09292003”.

Anyone else noticed this happening?

  • 5parrow

EDIT - Am running WinXP (if that wasn’t already implied). I checked Device Manager, and sure enough 3 “extra” devices show up on the same port as the keyboard - probably the silly buttons. I’m still a bit puzzled as to why JInput seems to think they’re STICKs given that the system does not know what they are at all.

Oddly enough, the USB keyboard and my laptop keyboard do not register as separate controllers.

#2

Won’t help solve your problem, I’m afraid, but…could you send an email to ceo @ grexengine.com with the full details, i.e.:

  • make
  • model
  • manufacturers URL (if you know it)

and I’ll add it to the hardware list for Jinput (go to JGF - link in my sig - and in the TECH section there’s a set of pages dedicated to JInput).

For now I could add it with details on your problems. If it gets fixed, let me know and I can update it.

The list is short at the moment, but with the help of people like you we will build up a long list of what is known to work and what doesn’t (e.g. already we’ve got several PS2 controller-converters reported as working OK, which is great to know!)

#3

Having oddities with an USB keyboard too: It is named KeySonic ACK-610EL and shows up as 2 different devices in Linux (kernel 2.6.5).

The first device is usable but cursor right & cursor down are missing.
The second one has the same name but has nearly no named keys and it does not work anyways. the first visible key is named ‘Second Digitiser Stylus Button’ …

and here an image of that:

http://page.mi.fu-berlin.de/~rschuste/2nd-keyboard.png

#4

Seeing that screen shot reminds me… did we ever solve the problem of how to use JInput… I mean how to know what Key ID to check for? It seems that we still don’t have a way to map between key caps that the user can see on their keyboard and key ids for JInput. Or maybe I’m just way out of the loop and someone needs to school me on how to program with JInput. E.g. the key IDs must be standardized across all platforms, mustn’t they?

#5

It was at least tried … but I am not sure whether it actually works.
endolf defined a mapping between the native definitions and its counterparts in jinput:

buttonIDs[NativeDefinitions.KEY_9] = StandardKeyboard.KeyID._9;
buttonIDs[NativeDefinitions.KEY_0] = StandardKeyboard.KeyID._0;

sometimes that counterparts where not available:
buttonIDs[NativeDefinitions.KEY_F16] = null;
buttonIDs[NativeDefinitions.KEY_F17] = null;
buttonIDs[NativeDefinitions.KEY_F18] = null;

although these are seldom used keys …

#6

oh and I would be happier if stuff like that:

// Gamepad
buttonIDs[NativeDefinitions.BTN_A] = LinuxDevice.ButtonID.BTN_A;
buttonIDs[NativeDefinitions.BTN_B] = LinuxDevice.ButtonID.BTN_B;
buttonIDs[NativeDefinitions.BTN_C] = LinuxDevice.ButtonID.BTN_C;
buttonIDs[NativeDefinitions.BTN_X] = LinuxDevice.ButtonID.BTN_X;
buttonIDs[NativeDefinitions.BTN_Y] = LinuxDevice.ButtonID.BTN_Y;

would have been simply defined as:

buttonIDs[NativeDefinitions.BTN_A] =
buttonIDs[NativeDefinitions.BTN_B] =
buttonIDs[NativeDefinitions.BTN_C] =
buttonIDs[NativeDefinitions.BTN_X] =
buttonIDs[NativeDefinitions.BTN_Y] = Axis.Identifier.BUTTON;

because LinuxDevice.ButtonID.BTN_C is unknown to a generic Jinput application.
some of that was discussed here: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jinput;action=display;num=1079729939

#7

[quote]oh and I would be happier if …
buttonIDs[NativeDefinitions.BTN_A] =
buttonIDs[NativeDefinitions.BTN_B] =
buttonIDs[NativeDefinitions.BTN_C] =
buttonIDs[NativeDefinitions.BTN_X] =
buttonIDs[NativeDefinitions.BTN_Y] = Axis.Identifier.BUTTON;

because LinuxDevice.ButtonID.BTN_C is unknown to a generic Jinput application.
[/quote]
Aren’t IDs supposed to be unique?
At least for most game controllers it would be reasonably safe to just number the buttons and make sure the interface allows the buttons to be re-assigned. The exceptions would be direction pads and such which should have their structure standardized… Buttons like A,B,C,X,Y,Z, Square, Circle, Triangle, etc… aren’t all that important to standardize because they don’t really have any implicit meaning. Just numbering them would work. Hat switches and direction pads though should not be treated as arbitrary buttons for sure. The should be grouped as direction controls.

But…I could be talking nonsense… it has been too long since I’ve looked at how it works.

#8

Are they?

I thought the more important thing is to conclude about the range of getPollData. Axis.Identifier.BUTTONs are never negative, Axis.Identifier.X are in the range [-b,b] (depending on other values like isNormalized, too).

but uniqueness may be a good idea too.

any ideas ???

#9

[quote]Are they?
[/quote]
Well I thought so… but I could be confused.
I thought the ID was key to identifying a specific control, but as I said it has been a long time and I haven’t really used JInput… (damn day job steals my time)… I did play around with the Mac plug-in to get support for my gamepad… but I just ran the standard test code… I haven’t done anything with it as a user of the API.

#10

Hi
Mmy take on this. The button ID’s especially for gamepads are p.i.t.a. as under windows the driver assigns the axes their names, but under linux, the kernel has them set. This means that the ID’s are different per OS, however, they could be mapped, like we do for standard keyboards, I don’t think it would be too bad, I’m trying to get hold of Jeff to get some input from the team who developed the interface to see what they come back with.

Cheers

Endolf