You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to see support for a specific hardware feature
I'd like to see support for a specific software feature
Is your feature request related to a problem? Please describe.
I would like to play single-player games with someone who isn't the most familiar with gaming, and doesn't have the fastest reaction times. Normally, I can use two controllers (one for the other player, one for me) so that the other player can use their controller to play through normal-paced parts of a game, while I 'take over' with my controller in the more demanding parts.
Some single-player games support this out of the box, taking input from two controllers simultaneously, or 'auto-switching' between them. However, some games (such as L.A. Noire) only allow input from one connected controller -- usually the first one it detects -- and no others. So while Controller 1 can interact with the game as you would expect, Controller 2 cannot interact with the game at all (even though all its inputs can be read as normal through evtest).
Describe the solution you'd like
It would be nice to see an implementation of Microsoft's "Xbox Controller Assist" -- also known as "Xbox Copilot" -- on Linux. This is a feature a user on Windows can enable through the Xbox Accessories app, that maps the inputs of multiple physical gamepads into one logical gamepad. This way, multiple physical controllers can interact with a game that only accepts one and only one controller, as the game just reads the inputs of one logical controller merged from all the "copilot enabled" physical controllers.
The way this works is:
Buttons (i.e., ABXY, d-pad, bumpers, etc.) take an "inclusive or" approach.
E.g., if the A button on either Controller 1 or Controller 2 is being pressed, the A button is pressed on the "merged" controller. This is true regardless of any other inputs being done at the same time on either controller.
Joysticks (i.e., LS and RS) on the "merged" controller take the sum of the X/Y co-ordinates for the joysticks of each physical controller, such that -100% <= p <= 100% where p is a percentage value for an X or Y co-ordinate.
E.g., if the X co-ordinate of LS on Controller 1 is at 50% (halfway to the right), and the X co-ordinate of LS on Controller 2 is at 25% (a quarter towards the right), the X co-ordinate of LS on the "merged" controller is 75% (three-quarters to the right).
If the X co-ordinate of LS on Controller 1 is at 50% (halfway to the right), and the X co-ordinate of controller 2 is at -50% (halfway to the left), the X co-ordinate of LS on the "merged" controller is 0% (not being moved -- the two inputs have essentially cancelled each other out).
If the X co-ordinate of LS on Controller 1 is at -75% (three quarters to the left), and the X co-ordinate of LS on Controller 2 is at -50% (halfway to the left), the X co-ordinate of LS on the "merged" controller is -100% (fully to the left), as -100% and 100% are the min/max values respectively for a given co-ordinate.
The above examples are also true for the Y co-ordinate and RS.
Trigger pressure values on the "merged" controller are based on the highest trigger pressure values of any of the "copilot enabled" controllers.
E.g., if LT is 50% pressed on Controller 1, and LT is 25% pressed on Controller 2, LT is 50% pressed on the "merged" controller.
Haptic feedback is sent to all "copilot enabled" controllers at the same time.
Describe alternatives you've considered
I have tried using Steam Input to see if games recognise multiple controllers as one that way -- games still detect them as seperate unfortunately.
I've seen some suggestions online that say to rebind the 2nd controller's inputs to keyboard/mouse presses. This seems like a very hacky solution and would cause problems like games constantly switching between showing controller button prompts and keyboard/mouse prompts, even though both players are only using controllers. Joystick and trigger inputs would also not be as fine on the "keyboard emulator" controller, and only one controller would get haptic feedback.
I can obviously just pass one controller between me and the other player, though this is a bit awkward and breaks the flow of gameplay.
The only real solution (for now) is just to play certain games on Windows if I want this functionality, as I don't believe it's possible to get this "copilot"-like behaviour on Linux yet.
The text was updated successfully, but these errors were encountered:
Thank you for the very detailed description, especially how the inputs are merged. Very well done.
I think it makes most sense to implement this in user-space because doing this at the kernel level will become very very difficult or even impossible if games use the hidraw method (which xpadneo currently disables anyways).
I'm actually planning to do a user-space part for xpadneo but this may be some time in the future. Your description helps me proper plan the abstractions so your feature request could later be added easily.
This could also allow for an easy migration from desk to couch, e.g. if you use a wired controller at the desk but a wireless controller at the couch, as you pointed out some games to support only one controller. Merging both would allow to just use any of them as any time. I really like this idea beyond what the pure assist-feature does.
Version of xpadneo
0.9.6 (via the AUR)
Controller Model
Connection mode
Describe your feature request
Is your feature request related to a problem? Please describe.
I would like to play single-player games with someone who isn't the most familiar with gaming, and doesn't have the fastest reaction times. Normally, I can use two controllers (one for the other player, one for me) so that the other player can use their controller to play through normal-paced parts of a game, while I 'take over' with my controller in the more demanding parts.
Some single-player games support this out of the box, taking input from two controllers simultaneously, or 'auto-switching' between them. However, some games (such as L.A. Noire) only allow input from one connected controller -- usually the first one it detects -- and no others. So while Controller 1 can interact with the game as you would expect, Controller 2 cannot interact with the game at all (even though all its inputs can be read as normal through
evtest
).Describe the solution you'd like
It would be nice to see an implementation of Microsoft's "Xbox Controller Assist" -- also known as "Xbox Copilot" -- on Linux. This is a feature a user on Windows can enable through the Xbox Accessories app, that maps the inputs of multiple physical gamepads into one logical gamepad. This way, multiple physical controllers can interact with a game that only accepts one and only one controller, as the game just reads the inputs of one logical controller merged from all the "copilot enabled" physical controllers.
The way this works is:
-100% <= p <= 100%
wherep
is a percentage value for an X or Y co-ordinate.Describe alternatives you've considered
I have tried using Steam Input to see if games recognise multiple controllers as one that way -- games still detect them as seperate unfortunately.
I've seen some suggestions online that say to rebind the 2nd controller's inputs to keyboard/mouse presses. This seems like a very hacky solution and would cause problems like games constantly switching between showing controller button prompts and keyboard/mouse prompts, even though both players are only using controllers. Joystick and trigger inputs would also not be as fine on the "keyboard emulator" controller, and only one controller would get haptic feedback.
I can obviously just pass one controller between me and the other player, though this is a bit awkward and breaks the flow of gameplay.
The only real solution (for now) is just to play certain games on Windows if I want this functionality, as I don't believe it's possible to get this "copilot"-like behaviour on Linux yet.
The text was updated successfully, but these errors were encountered: