Re: [PATCH 1/1] Input: xpad - update docs to reflect current state

[Daniel Dressler]

I'd love to make all controllers report as axises but doing so _will_
break stuff downstream. Not least of which being every game which uses
SDL2's controller configs:
https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt

Which is just about every-single major commercial proprietary game
which has been ported to linux in the past 2 years.

Now it should also be clear that adding extra axises will not break
those games. The SDL2 library should just ignore those axises.

Also, the module option "dpad_to_buttons" will only operate on unknown
devices. Users cannot use it to return to old behavior so we have to
get this right.

Daniel

2014-11-10 20:47 GMT+09:00 Thomaz de Oliveira dos Reis <thor27@xxxxxxxxx>:
> I totally agree that the behavior should be exactly the same in all
> XBOX gamepads. But In my opinion this should be mapped as axis only,
> since mapping for both could make a confusion in some games.
>
> If you need the axis to be buttons, you can set as a option while
> loading the module.
>
>
>
>
> 2014-11-10 6:06 GMT-02:00 Daniel Dressler <danieru.dressler@xxxxxxxxx>:
>> Thanks Jon
>>
>> I've sent a second version of the patch without the TODO list edits.
>>
>>
>> Now I would like to ask about a backwards compact issue related to this driver.
>>
>> Eons ago in patch 99de0912b [0] when support for the wireless 360
>> controllers were added the decision was made to map their Dpad to the
>> discrete buttons.
>>
>> There is reasonable justification for this behavior since the Dpad has
>> never functioned like an analog stick on Xbox hardware.
>>
>> Except support for wired 360 controllers had been added a year earlier
>> and used the opposite behavior. In fact the wireless 360 controllers
>> are the only controllers which use the dpad_to_button behavior.
>>
>> Original Xbox, wired Xbox 360, and all Xbox One controllers all expose
>> the dpad as a set of axises.
>>
>> This has caused pain for downstream developers. It means two
>> controllers  have wildly different behavior. Many developers have just
>> ignored the issue or suggested users unload xpand and use the userland
>> replacement. Even Arch's wiki suggests such [1]. Which to be honest is
>> all one can do. The xpad driver does not expose the information
>> developers need to even incorporate a workaround without nasty hacks.
>>
>> As a downstream developer I've been bitten by this twice. The first
>> time I didn't even know that wired vs wireless made a difference and I
>> was disturbed to learn the truth.
>>
>> So here is what I want to hear opinions on: should the wireless 360's
>> dpad be exposed as both axises _and_ buttons?
>>
>> [0]: https://github.com/torvalds/linux/commit/99de0912b when t
>> [1]: https://wiki.archlinux.org/index.php/joystick#Xbox_360_controllers
>>
>> Daniel
>>
>> 2014-11-08 3:48 GMT+09:00 Jonathan Corbet <corbet@xxxxxxx>:
>>> On Mon,  3 Nov 2014 17:53:06 +0900
>>> Daniel Dressler <danieru.dressler@xxxxxxxxx> wrote:
>>>
>>>> The last time this documentation was accurate was
>>>> just over 8 years ago. In this time we've added
>>>> support for two new generations of Xbox console
>>>> controllers and dozens of third-party controllers.
>>>>
>>>> This patch unifies terminology and makes it explicit
>>>> which model of controller a sentence refers to.
>>>
>>> So this seems like a useful update, and I was looking at pulling it into
>>> the docs tree.  But this hunk:
>>>
>>>> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
>>>> index 2ed7905..7e2e047 100644
>>>> --- a/drivers/input/joystick/xpad.c
>>>> +++ b/drivers/input/joystick/xpad.c
>>>> @@ -40,8 +40,8 @@
>>>>   *
>>>>   * TODO:
>>>>   *  - fine tune axes (especially trigger axes)
>>>> - *  - fix "analog" buttons (reported as digital now)
>>>> - *  - get rumble working
>>>> + *  - add original xbox rumble pack support
>>>> + *  - add xbox one rumble support
>>>>   *  - need USB IDs for other dance pads
>>>>   *
>>>>   * History:
>>>
>>> Seems like a different change that shouldn't be mixed up with the doc
>>> update.  Send me a version without that change and, in the absence
>>> of complaints, I'll apply it.
>>>
>>> Thanks,
>>>
>>> jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/