New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trigger calibration in LibGDX #672

Open
WalkerWhite opened this Issue May 13, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@WalkerWhite

WalkerWhite commented May 13, 2018

There is a problem with this driver and games developed in LibGDX (https://libgdx.badlogicgames.com). It is hard to tell whether this is a driver issue or a LibGDX issue. However XBox controllers work fine in Windows on LibGDX -- this is only an issue with this driver -- which is why I mention it here.

In LibGDX, a trigger registers 0 for no pressure and 1 for full pressure. Indeed, when the controller is first initialized, the value is 0. However, when you press and release the trigger, the value produced is now -1, and the axis range is now -1 to 1. This new range lasts until the game is restarted.

Seeing as the Windows API (https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.xinput_gamepad(v=vs.85).aspx) uses a unsigned byte for the trigger, a value of 0 for the rest state seems correct to me. Therefore, a -1 value appears to be a bug.

This has actually been a long-running issue dating back to Colin Monroe's original driver. I have reproduced it on multiple OS X releases from Mavericks to High Sierra. It happens on both XBox 360 and XBox One controllers. Because you can work around it in your source I have just never gotten around to reporting it before now.

@FranticRain

This comment has been minimized.

Show comment
Hide comment
@FranticRain

FranticRain May 14, 2018

Collaborator

This is pretty well known, but there is not exactly a great way for us to fix it. We have to choose between two options. 1. Fundamentally change how the driver works at this point, and break backwards compatibility, or 2. Implement features in the driver that force the user to make configurations to alter this behavior. If implemented in the driver, it would likely require a disconnect and re-connect of the driver in order to re-load the HID descriptor.

I'm definitely not going to do number one. As for number two, and I speak as the person who added controller customization to the driver, is a bad idea for a driver space application. All of those configuration features were a mistake and a hack. The best space for a configuration like this is in user space, not kernel space. So this creates two new options. 1. LibGDX alters its implementation on macOS, or 2. A user space application like Joystick Mapper is used to alter this configuration for games that use this library or a joystick configuration like this.

So yes, this is a "bug," but it's one that most likely won't get fixed here. I'd be interested in hearing opinions on the subject, but it's something that is pretty well known amongst the developers.

Collaborator

FranticRain commented May 14, 2018

This is pretty well known, but there is not exactly a great way for us to fix it. We have to choose between two options. 1. Fundamentally change how the driver works at this point, and break backwards compatibility, or 2. Implement features in the driver that force the user to make configurations to alter this behavior. If implemented in the driver, it would likely require a disconnect and re-connect of the driver in order to re-load the HID descriptor.

I'm definitely not going to do number one. As for number two, and I speak as the person who added controller customization to the driver, is a bad idea for a driver space application. All of those configuration features were a mistake and a hack. The best space for a configuration like this is in user space, not kernel space. So this creates two new options. 1. LibGDX alters its implementation on macOS, or 2. A user space application like Joystick Mapper is used to alter this configuration for games that use this library or a joystick configuration like this.

So yes, this is a "bug," but it's one that most likely won't get fixed here. I'd be interested in hearing opinions on the subject, but it's something that is pretty well known amongst the developers.

@WalkerWhite

This comment has been minimized.

Show comment
Hide comment
@WalkerWhite

WalkerWhite May 14, 2018

I would not have a problem with this (it can be handled at the application layer) if there were some way we could query the driver. For example, I can connect an XBox One S controller straight with bluetooth, and that does not use this driver.

However, GFLW (which provides controller support for LibGDX) only gives the controller name, not the driver name. A workaround that would be very helpful is if the driver could tag the controller name somehow.

WalkerWhite commented May 14, 2018

I would not have a problem with this (it can be handled at the application layer) if there were some way we could query the driver. For example, I can connect an XBox One S controller straight with bluetooth, and that does not use this driver.

However, GFLW (which provides controller support for LibGDX) only gives the controller name, not the driver name. A workaround that would be very helpful is if the driver could tag the controller name somehow.

@FranticRain

This comment has been minimized.

Show comment
Hide comment
@FranticRain

FranticRain May 14, 2018

Collaborator

I'm not sure how developers do it, but I know that developers can identify 360Controller devices specifically. Sometimes it is through seeing if the device is attached to the com.mice.360Controller identifier for its driver. I have no idea how to implement that, though. But perhaps a bit easier, is to look at the identifiers that are attached to the devices. Each type of controller has it's own identifier, the "Product String," as noted in the preference pane. For example:

OSString* Xbox360ControllerClass::newProductString() const
{
return OSString::withCString("Xbox 360 Wired Controller");
}

OSString* XboxOneControllerClass::newProductString() const
{
return OSString::withCString("Xbox One Wired Controller");
}

These should be unique to controllers from 360Controller, and should be pretty close to what you are looking for.

Collaborator

FranticRain commented May 14, 2018

I'm not sure how developers do it, but I know that developers can identify 360Controller devices specifically. Sometimes it is through seeing if the device is attached to the com.mice.360Controller identifier for its driver. I have no idea how to implement that, though. But perhaps a bit easier, is to look at the identifiers that are attached to the devices. Each type of controller has it's own identifier, the "Product String," as noted in the preference pane. For example:

OSString* Xbox360ControllerClass::newProductString() const
{
return OSString::withCString("Xbox 360 Wired Controller");
}

OSString* XboxOneControllerClass::newProductString() const
{
return OSString::withCString("Xbox One Wired Controller");
}

These should be unique to controllers from 360Controller, and should be pretty close to what you are looking for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment