[RFE] Handling controller disconnect/(re-)connect

Started by nczempin, March 21, 2014, 17:45:38

Previous topic - Next topic

nczempin

I'm on W7 64, LWJGL 2.9.1 (source) stable. Not sure which version of jinput.jar I'm using; probably one that comes with the lwjgl binary distribution.

When I disconnect a gamepad or remove the battery from a Wireless X360 controller, org.lwjgl.input.JInputController.poll() starts spamming "Failed to poll device: Failed to get device state" and similar messages. Leaving it running in Eclipse will eventually produce out of memory conditions or similar evil.

While writing to the console within a library is a big no-no, that seems to be JInput's fault, not LWJGL.

However, net.java.games.input.Controller.poll() has a return value of boolean to indicate success/failure (C style programming instead of exceptions that arguably could be used on the Java side of things), and LWJGL is simply disregarding this value.

Here's what I'm currently using as a workaround to handle this case more gracefully:
/*
	 * @see org.lwjgl.input.Controller#poll()
	 */
	@Override
	public boolean poll() {
		final boolean success = target.poll();
		if (!success) {
			this.setConnected(false);
			return false;
		}
...


I added a "connected" attribute to the ...lwjgl.Controller interface and the implementation.

In Controllers.poll(), I filter like this:
for (int i = 0; i < controllers.size(); i++) {
			final Controller controller = getController(i);
			if (controller.isConnected()) { // TODO:handle reconnect or generally new connect
				final boolean success = controller.poll();
				if (!success) {
				}
			}
		}


(Note that I originally set the controller to disconnected at this place, hence the incomplete code.

I don't know about your philosophies/preferences to determine whether it makes more sense to you to handle the connection inside the controller object only (which also means you don't have to return the "success" boolean in the poll method)).

The result of my proposed change is that controller disconnect is handled slightly more gracefully, yielding only one error message per disconnect instead of one per poll.


I will probably try and figure out how best to handle reconnect of a previously connected controller and/or an entirely fresh connect (which even many commercial games don't seem to care about---controllers seem to be detected only at initialization. So unless I find a simple and elegant solution, I might also ignore the issue).


(I wasn't sure whether to label this an RFE or a BUG]