org.lwjgl.test.input.TestControllers crash

[elias]

And so it is Alright, I'll have to get a hold of Kevglass and see if he can figure this out.

- elias

[kevglass]

I'll take a look right away.

Kev

[kevglass]

Fixed it, can't commit to SVN for some reason.

I've also got a minor change to prune out controllers with zero buttons OR zero axis since they're not likely to be game controllers in either case - that should get rid of monitors being picked up and my new laptop keyboard reporting as 4 seperate game controllers.

I'd like to commit this aswell unless theres a good example of why it shouldn't be so.

Kev

[wayne]

Good news, thanks very much, but by excluding controllers with 0 axis you are ignoring:

Infrared remotes
'Media' Keyboards.
Retro button only controllers.
Some crazy homebrew device, okay the original Amiga 'joystick' was a meditation device with an axis or two.

I'm just thinking that LWJGL might be used in situations, such as mediacenter or perhap a set-top box, where an axis might not be present, but buttons are.

[kevglass]

Thanks for the feedback, I was a little worried about this. Bit of a rock and hard place though I suppose. If we don't ignore odd controllers in a "select your controller list" you potentially get a bunch of devices that arn't devices (and actually fail if you poll them). If we ignore them we might miss some controller variants.

I can change the check to buttons=0 only but that means we'll still get things like my 31 button only random device showing up.

The best solution would be if JInput was able to report the devices type as what they are rather than STICK which is what all my test devices here come back as (even the ones with no axis )

FWIW, the only one that would worry me in the list would be "Media Keyboards" - not really sure what they are though? Would they not be reported as Keyboards - anyone got one to check

Kev

[kevglass]

Thinking about it, since the check can be implemented by the developer really easily (it's what I do for tilt for instance) - I suppose the sanity checks are more hassle then they're worth.

Kev

[wayne]

JXInput from http://www.hardcode.de/jxinput/ identifies only game controllers.  
Perhaps this is a bug in jInput? or is it a limitation of JXInput?

My keyboard is a 'media' and 'internet' fandangled keyboard.

The Jpanel of the LWJGL TestControllers test case reports my keyboard twice, and I have buttons named things like:

Scan Previous TRack
Scan Next Track
Volume Incement
VolumeDecrement
Mute
System Sleep
System Power

My Windows Media remote returns lots of anonymous numerically named buttons, as well as those power related named ones too.

Also, oddly IMHO, they all seem to have a "POV X" and a "POV Y".

[elias]

Kevglass: I've tweaked jinput to use Controller.Type.UNKNOWN for the catch-all device type, and only STICK for the ones we know are stick-like.

- elias

[kevglass]

Ok, does stick-like handle do gamepads aswell (never really got that ).

I'll update the controllers stuff to pick up STICK only then? If a controller that is considered a "Game Controller" doesn't get picked up it'll have to be revisited in JInput (god knows how you detect a gamepad as a gamepad if the driver reports unspecified)

Kev

[kevglass]

The new version of jinput jar and dlls (in subversion) fail to detect any controllers for me on win32 with a:

Failed to enumerate devices: Failed to acquire device (8007001e)

Kev

[elias]

Gamepads will get the Controller.Type.GAMEPAD type. It's not that devices reported themselves as unknown type, it was me simply making the default case in DirectInputEnvironmentPlugin.createControllerFromDevice a STICK type. Now only the obvious stick device types will be STICKs and the weirdos will be UNKNOWNs.

- elias

[elias]

I can't reproduce the acquire problem. Could you please test with the latest jinput with the "ant readtest" or "ant eventtest" test and tell me which device is failing and where? (Now the entire enumeration won't fail because one device fails). Also, if you could test with line 256 in IDirectInputDevice.java set to

setDataFormat(DIDF_ABSAXIS);

instead of

setDataFormat(axis_mode);

I'll be grateful.

- elias

[kevglass]

Running ControllerReadTest I get this fail:

Failed to initialize device SMSC HID CIR - Consumer IR because of: java.io.IOException: Failed to acquire device (8007001e)

So my Infra Red is being picked up? How cool is that

Anyway, in JInput I can see all the other devices (mouse, keyboard, controller and 3 others) show up fine. Just in the version with LWJGL I get zero controllers back from

ControllerEnvironment env = ControllerEnvironment.getDefaultEnvironment();
			
net.java.games.input.Controller[] found = env.getControllers();

I made that code change on 256 in IDirectInputDevice, tried the test again. This time I got this output:

Component count = 10
Component count = 127
Component count = 31
Component count = 0
Component count = 1
Component count = 0
Component count = 17
Failed to poll device: Failed to get device state (8007001e)
SMSC HID CIR - Consumer IR disabled
Failed to poll device: Failed to poll device (8007001e)
Failed to poll device: Failed to poll device (8007001e)
Failed to poll device: Failed to poll device (8007001e)
Failed to poll device: Failed to poll device (8007001e)
Failed to poll device: Failed to poll device (8007001e)
.... and so on

Kev

[elias]

I've put the latest jinput.jar in lwjgl, which should simply ignore the failing device.

 - elias

[kevglass]

Ok, I'll update to LWJGL Controllers only returns GAMEPAD and STICK devices - but I think it might be worth adding a property that allows you to get any device detected and do the filtering yourself - that should account for people who want to write games using IR Remotes and such.

Kev