The data type used for identifying key/butt press

[endolf]

Ok
 Issues 25 and 26 have been sorted now, and I can confirm I see the same thing, I will have a look at the code that guesses the device type at some point and see if I can get it playing nicely. Can you give me the output from

1	ant texttest

so that I can see what values your devices have and compare those with mine and see if I can come up with some new guessing rules.

Thanks

Endolf

[endolf]

Ok, I still want the output from that test, but I found a bug, and have updated CVS, the jinput bug can be tracked/modified from here.

Thanks

Endolf

[endolf]

1)
@endolf: You asked my for some code regarding the topic of finding the right controller. Well lets have a look at this. It is currently used to find my gamepad.

This all looks logical until "type.equals(Controller.Type.UNKNOWN))". The problem is that under Linux no device identifies itself as a gamepad or stick with the corresponding Controller.Type instance. If  I leave the last check out the gamepad is not found in Linux (but this works in Windows ).

issue 27 should fix this.

Another bad thing: In another thread I have shown you that my PC speaker is now a Controller as well and is now recognized by this method. Very bad because I wanted a pad or joystick-like device

This is the first thing I want to see corrected.

you should now be able to remove the UNKNOWN check from that list and get sticks and gamepads.

2)
Regarding the primary problem of this thread (identify used Axis at runtime, save something into a config file, find the Axis which was described in the config file) I would propose generating something like a unique identifier. This identifier should include device name and manufacturer. So what do you think about that?

Hows about the string from getName, and the order it appears in the controllers array. Then you can get the axis id and use those. The problem with this is that under linux especially (I don't know about windows), if I boot my system, then plug in some devices, they appear in /dev/input in the order they were plugged in, however, on reboot, they appear in the order of the USB ports and allowing for USB hub drivers to load, so the order may be very different. Using any kind of index or native deviceID from jinput will cause this, the only thing you can be sure is the same is the name and type (for the same jinput binaries).

HTH

Endolf

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

[TheBohemian]

it works! thank you!

Here the texttest output of the new plugins: (only gamepad and mouse)

Mega World
Type: gamepad
Axis Count: 18
Axis 0: X axis
   Identifier: x
   AxisType: Absolute Analog
Axis 1: Y axis
   Identifier: y
   AxisType: Absolute Analog
Axis 2: Button 0
   Identifier: Button 0
   AxisType: Absolute Digital
Axis 3: Button 1
   Identifier: Button 1
   AxisType: Absolute Digital
Axis 4: Button 2
   Identifier: Button 2
   AxisType: Absolute Digital
Axis 5: Button 3
   Identifier: Button 3
   AxisType: Absolute Digital
Axis 6: Button A
   Identifier: Button A
   AxisType: Absolute Digital
Axis 7: Button B
   Identifier: Button B
   AxisType: Absolute Digital
Axis 8: Button C
   Identifier: Button C
   AxisType: Absolute Digital
Axis 9: Button X
   Identifier: Button X
   AxisType: Absolute Digital
Axis 10: Button Y
   Identifier: Button Y
   AxisType: Absolute Digital
Axis 11: Button Z
   Identifier: Button Z
   AxisType: Absolute Digital
Axis 12: Thumb Left Button
   Identifier: Thumb Left Button
   AxisType: Absolute Digital
Axis 13: Thumb Right Button
   Identifier: Thumb Right Button
   AxisType: Absolute Digital
Axis 14: Second Thumb Left Button
   Identifier: Second Thumb Left Button
   AxisType: Absolute Digital
Axis 15: Second Thumb Right Button
   Identifier: Second Thumb Right Button
   AxisType: Absolute Digital
Axis 16: Select Button
   Identifier: Select Button
   AxisType: Absolute Digital
Axis 17: Uknown button
   Identifier: Uknown button
   AxisType: Absolute Digital
---------------------------------
Microsoft Microsoft IntelliMouse® Optical
Type: mouse
Axis Count: 0

[endolf]

it works! thank you!

Your welcome. I'm glad your gamepad is found as one, it's up to the driver what they call the buttons, my gamepad has it's native button IDs different to your so it gets detected as a stick, however, the name of mine contains the text 'Gamepad'. Can you guess how I got mine to be detected as a gamepad in the 'guess what type of controller this is' code?  

Endolf

[TheBohemian]

No need to guess because I know how the Linux plugin guesses itself

Sorry but I was curious of how the plugins actually work. Its a shame that you are forced to guess the device type that way.

I found my 'PC speaker' is incorrectly identified as a stick. Maybe thats because it has no axes. What about throwing away all zero-axis controllers?

[TheBohemian]

What about overriding the kernel's name scheme (at least for non-keyboards)?

Whenever you identify a certain type of axis you increase an id and name it: <axis type name> + id

This will have the following result:

.
.
.

Axis 16: Button 10
   Identifier: Button 10
   AxisType: Absolute Digital

Axis 17: Button 11
   Identifier: Button 11
   AxisType: Absolute Digital

[endolf]

I found my 'PC speaker' is incorrectly identified as a stick. Maybe thats because it has no axes. What about throwing away all zero-axis controllers?

what, no keyboards?

Endolf

[TheBohemian]

well Axis is used for keys and buttons. Maybe put this after getSupportedButtons() in LinuxDevice.guessType():

1   2   3   4   5   6

// without any buttons this device is and should be reported as of        // unknown type        if(numButtons == 0) {             // nothing is needed to be set, because guessType is already set to unknown            return;         }

-- EDIT: had to use numButtons ...

[endolf]

Hi
 What I was going to do was either add a 0 check for each characteristic if statement, or add another one that sees if they are all 0, as I suspect that in the case of the speaker they are all 0

Endolf

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

[endolf]

Try now  

Endolf

[TheBohemian]

Yeah much better now but there is still a problem:
I think the Axis.Identifier class should be used as a typesafe enum and therefore you should not create any instances of it. Instead the existing instances have to be mapped.
Currently there is no benefit by calling someAxis.getIdentifier() because its name is the same as someAxis.getName() and a comparison with any Axis.Identifier instance will fail.

(The same problem applies to the MacOS implementation of the mouse!)

Btw: I find the linux plugin is in a very good state. Especially the native code is clearly separated from the Java code. I know that it is harder to write the Windows version because of DirectInput's nasty callbacks but even there 'business code' should really live only in ONE world. And I think we all know which is the better one

[endolf]

Ok, type safe enums are a 1.5 feature arn't they?, and thats still beta, I know jinput requires a 2.6 kernel for some features, but requiring *everyone* to have 1.5 isn't an option yet, not for something like that.

The axis identifiers being equal might need to be updated, right now I have another sigsegv to fix, so it's far more important , raise an issue on jinput.dev.java.net to remind me

Cheers

Endolf

[TheBohemian]

err no ... as of <1.5 typesafe enums are like a design pattern.
To achieve type-safeness one declares a private constructor and then creates some public final instances with it:

1   2   3   4   5   6   7

public class TypeSafe {    public final TypeSafe CONSTANT1 = new TypeSafe();    public final TypeSafe CONSTANT2 = new TypeSafe();    private TypeSafe(){    } }

This is a minimal example. But as you can see that Axis.Identifier uses exactly this pattern (but I wonder why the constructor is 'protected').

And btw Typesafe enums in 1.5 are internally much the same as this.

---

reported this as a bug

[TheBohemian]

I looked at StandardKeyboard.java to see how Axis.Identifier is used there and in the hope to find a confirmation of what I thought the class is used for but did not find that and now I am confused:

Why does Axis.Identifier declares some constant instances which invite everyone to do '=='-like checking and is then subclassed and instantiated everywhere?

Non constant and subclassed Axis.Identifier instances are completely useless because they provide mostly the same information like the axis which they belong to?

And now the really confusing part: The constant instances of Axis.Identifier are only (and only there) used from the DX8 plugin's native code!

Can someone sheer me up with some good news?

[TheBohemian]

Amazing!
After wakeup I finally got it. Now I know what Axis.Identifier is meant to be. Look up this thread's topic: Axis.Identifier wanted to be the answer.

It could not achieve that goal because some implementations broke the rule of uniqueness of the name of an Axis.Identifier (and subclasses) instance.
Eg: the linux plugin gives the name 'unknown' to all Axis-objects and its identifiers.

having said that:
When I first got my hands on JInput I generated the Javadoc and simply guessed how to use certain things of the library. These static constant instances of Axis.Identifier called X, Y, RX, RY etc. looked truly like a nice method of getting the actual Axis type. And for the DirectInput plugin this is true! All buttons on my gamepad get the same instance of Axis.Identifier. If I want to write an application that  needed to select the first button it can find programmatically it would simply search for the first controller which is a GAMEPAD or STICK and then use Axis.Identifier.BUTTON to find some buttons.

So in conclusion we have the following:
a) once in a time Axis.Identifier was meant as an AxisType-identifier
b) after that time someone thought it would be the way to reidentify a certain Axis (Axis.Identifier's name could be saved to disk ....)

but neither a) nor b) are implemented consistly and there is a need for both!

Any comments on this?

[endolf]

Hi
 Before any changes are made on this I'd like to get some input from Jeff.

Cheers

Endolf

[TheBohemian]

Well, I thought this would start a little discussion ...
I am very interested in what other people think about that.

[TheBohemian]

ahem. any news on that?

[endolf]

Jeff seems kinda busy atm, so not got any responce yet

Endolf

[Jeff]

I am INCREDIBLY busy right now, sorry guys.

From my memory I think you teo have doped it otu pretty well. (Keep in mind that I inehrited that original code myself )

I'd say if you both agree then go for it!  Thsi sia  community owned API after all.

If theres a disagrement and you want me to mediate then tell me and ill dig back into the code and come up with a half-assed opinion

[swpalmer]

Ok.. well do we have a unique identifier for an axis?  We *need* one, don't we?    And that must be separate from a displayable name, right?  I wish I had time to get back into this.. argh... I need to write some code that actually uses JInput so I can see where all the confusing bits are.

[endolf]

Hi
 Right,  I think we need both, a unique ID for an axis, and also a type, that is a constant across platforms and instances of that axis. I don't have access to the code right now, but I'll take a look tonight and tomorrow and see what I come up with, does anyone else (TheBohemian/swpalmer) have any suggests?

Cheers

Endolf

[TheBohemian]

nice. things start moving

for Axis.Type (and I suppose to do this with inner classes like Controller.Type):
We need to find a number of types which can be reliably detected on all platforms. Some answers can be found in Axis.Identifier.

for Axis.Identifier:
Do it like endolf did? That means every plugin has its own mechanism of creating identifiers or can we find a way to let JInput create them*?

And some other questions regarding identifiers:
Are they supposed to be device-unique or truly (at least for this machine) unique?
What kind of information do they want to give us (eg. Keyboard keys) ?

* that may mean:
Controller (or better AbstractController) has static method like getIdentifier(Controller.Type, Axis.Type, int index). This can then be used by plugin developers to get (device-unique) identifiers for their Axis instances and application developers may use the method to find a single Axis instance.
eg. find the 20th button on the gamepad:
ctl.getAxis(Controller.getIdentifier(Controller.Type.GAMEPAD, Axis.Type.BUTTON, 19));

(Results with the subcontroller thing have to be discussed.)

Only suggestions I am prepared for critics

[swpalmer]

Is it just me, or does having a Axis.Type field smell bad?  Should we not use a derived class to determine the Axis type?  Which of course could add methods appropriate for the type.  All of them descending from the root Axis class of course.