Just to confirm, this new device reads like other xpad devices from the
outside, so the GPD Win 2 device has the same index values as other 360
controllers. For context, here's the GPD Win 2 SDL_GameController entry...
https://github.com/gabomdq/SDL_GameControllerDB/blob/d797cd5ea477695e2a34f77a1823eafca66f773f/gamecontrollerdb.txt#L256
... vs. the 360 Controller entry:
https://github.com/gabomdq/SDL_GameControllerDB/blob/d797cd5ea477695e2a34f77a1823eafca66f773f/gamecontrollerdb.txt#L400
Whether or not the mapping is correct below SDL, I'll have to defer to
someone else, as I have no idea!
-Ethan
On 05/31/2018 01:44 PM, Cameron Gutman wrote:
On 05/31/2018 10:10 AM, Dmitry Torokhov wrote:
Hi Ethan,
- stable@ to BCC
On Thu, May 31, 2018 at 5:12 AM, Ethan Lee <flibitijibibo@xxxxxxxxx> wrote:
Aaand right as I send these I see git-send-email auto-CC'd stable directly
again. Sorry!
-Ethan
On 05/31/2018 08:10 AM, flibitijibibo@xxxxxxxxx wrote:
From: Ethan Lee <flibitijibibo@xxxxxxxxx>
GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp
Tested on a unit from the first production run sent to Indiegogo backers
So I understand that adding this new VID/PID pair to the xpad driver
makes controller recognize the device,
but the button/axis mapping is not what it should be. Does it mean
that the mapping is different from other xpad controllers, or the
mapping that we are using is messed up for all/most of them?
If I'm understanding correctly, the mapping is "correct" in that it
matches what other xpad devices use, but xpad's mapping in general
is a bit weird, like using BTN_TRIGGER_HAPPY instead of BTN_DPAD.
I think that is actually a minor issue now after we started reporting
d-pads as buttons and axes on Xbox 360 wireless gamepads. The only
devices that would still need to use BTN_TRIGGER_HAPPY are dancepads,
and applications supporting those are likely very flexible with their
mappings already.
It looks like the mapping we use is quite a mess, I wonder if we could
not bite the bullet and unify it so it follows
Documentation/input/gamepad.rst... I would make users update their
existing configs, but the new installations would be more sensible.
Just a thought... Or you could tell me that nobody pays attention to
what kernel sends and everyone remaps anyway...
Did you see anything else wrong with the mapping besides the dpad?
Signed-off-by: Ethan Lee <flibitijibibo@xxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 06e9650b3b30..a89b81b35932 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -123,6 +123,7 @@ static const struct xpad_device {
u8 mapping;
u8 xtype;
} xpad_device[] = {
+ { 0x0079, 0x18d4, "GPD Win 2 Controller", 0, XTYPE_XBOX360 },
{ 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX },
{ 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX },
{ 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX
},
@@ -409,6 +410,7 @@ static const signed short xpad_abs_triggers[] = {
static const struct usb_device_id xpad_table[] = {
{ USB_INTERFACE_INFO('X', 'B', 0) }, /* X-Box USB-IF not
approved class */
+ XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 Controller */
XPAD_XBOX360_VENDOR(0x044f), /* Thrustmaster X-Box 360
controllers */
XPAD_XBOX360_VENDOR(0x045e), /* Microsoft X-Box 360
controllers */
XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft X-Box One
controllers */
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
