Gamepad Devices

Configuration options for gamepad and joystick devices, used especially in various games. Through this panel users can remap device buttons and axes as wished, along with calibrating these devices.

Participants

None yet.

Status

• Needs design

  Design in progress

  Needs implementation

  Implementation in progress

  Stable

Relevant Art

jstest-gtk

Device selection

Axes and buttons view with on-change updates

Axes and buttons remapping widget

Manual axes sensitivity and range configuration

Calibration wizard

System Settings in KDE Workspace

Device selection, axes and buttons view with on-change updates

Calibration wizard - introduction, one of the calibration steps and finishing message

Discussion

General problems

Name

While the proposal title implies configuration would be only possible for gamepads, the attempted approach to configuration also applies to joysticks. Perhaps a name like 'Gaming devices' would suit the panel better.

Other non-standard devices like Wii Remote could also be configurable through this panel, though this specific device currently isn't supported well in GNOME (connecting-wise) and is badly supported through udev (the preferred way of accessing devices for this panel) as well.

Device variety

Different devices can have a different layout of axes and buttons. There is also an obvious difference in device look between gamepads and joysticks and any other non-standard devices. This makes it impossible to provide a unified configuration layout through which real-time interaction with the device could be visible in a way that would not confuse the user (for instance providing a generic display for every axis and button on the device).

It's because of this limitation that the manual buttons and axes mapping configuration should be avoided. It is a process that should be avoided by providing a list of supported devices with each being assigned both axes and buttons mapping that was tested and confirmed to work. That way the users do not have to go through a process that would each time (for each user) result in the same mappings. The manual configuration process would also be probably quite complicated and time-consuming, which is another reason to avoid it completely.

An exception to this is the axis calibration. There may be advanced users who would want to specify specific values to the axes' deadzones and range values so they could get the most out of their devices.

Towards design

List of connected devices

The user should be presented with a list of connected devices. Each device should be presented with the device's name and a sign that tells whether the device is supported or not. If the device can be calibrated it should be possible to enter the calibration process.

Axis calibration process

The goal of axis calibration process is to establish the working region of an axis based on its extremal positions and specific center deadzone values.

The user is presented with the list of axes, with each axis having a presentation of it's current value that's updated in real-time. This way the user can modify the axis range and deadzone values and have those values applied immediately so the feedback is also immediate and evident from the current value presentation.

Handling unrecognized devices

The user might want to use a device that is not recognized as supported. Despite this the usage of the device would not be blocked, but it would not be possible to ensure the correct behavior of the device.

Presented along with the details of the unsupported device is a link that upon clicking stores the 'request for support' somewhere on the Web. The request would only contain the device information (USB ID, buttons and axes count, buttons and axes mapping) from which the correct mappings could be established and used to mark the device as supported with proper mappings assigned to it.

Auto-sending this information when the user connects an unrecognized device is not appropriate from the point of user privacy.

Goals and scope

• Give users a way to easily see the support status of their gamepads and joysticks, along with possible calibration and support request.

Concepts

Guidelines

Comments

• Need to consider issues like PS3 Game Pad, which connects via Bluetooth. As a user do I expect to see this under Bluetooth, or Game Pads? - Shane Marks
• Many Wireless gamepads (xbox 360/one and PS3/PS4 and their clones) have already LEDs identifying a controller. These work in current kernels users shouldn't have to identify which js number the controller they are trying to configure is when it has an identity that the user can see already. - Laurence Brown
• Advanced features like rumble/force feedback, tilt sensors, accelerometers should also be considered. In particular tilt sensors and accelerometers can make in game configuration difficult because of the constant output when trying to configure Axis. Rumble is difficult to test - Laurence Brown
• Features like battery level and signal strength monitoring in gnome would be useful. - Laurence Brown