Re: About the PS3 Sixaxis linux driver

Re: About the PS3 Sixaxis linux driver

[Benjamin Tissoires]

Hi Marc,

(adding in CC the linux-input mailing list)

Regarding your problem I vaguely remember something about not having duplicated axis with the buttons. My memory is rather confuse about this, so I may be wrong (but others on the list may have a fresher memory).
Other than that, if only one axis is not working, then it is definitively a bug...

I'll try to add this to my todo list, but I can not guarantee anything soon. If someone else can confirm and fix this, I'll be happy.

Cheers,
Benjamin

----- Original Message -----
From: "case" <case@corpsmoderne.net>
To: "Benjamin Tissoires" <benjamin.tissoires@redhat.com>
Sent: Friday, October 25, 2013 8:52:14 AM
Subject: About the PS3 Sixaxis linux driver

Hello Benjamin,

I'm mailing you because it seems you're one of the kernel developers
the most involved with the hid-sony.c driver lately, with which I think
I've an issue. If you feel like I'm mailing the wrong person,
I apologize, and would be glad if you could point me to the right
person.

I'm a game developer experimenting with the sixaxis for a while, and
I've a big issue with the current state of the driver:

On the sixaxis all the buttons (except select and start) are mapped
as buttons but also as axis, which is pretty rad. That was working great
in 2010 when I started to experiment with the sixaxis but in more
recent versions of the kernel, one the the buttons has lost his axis.
It's the left button the the D-PAD, witch is only mapped as button 7
(up is button 4 and axis 8, right is button 5 axis 9, bottom is button
6 axis 10).

This is quite inconsistent and makes impossible to rely on the axis for
all the D-PAD buttons.

Again, this bug wasn't there in 2.6.32 . I noticed it for the first time
in 3.5.x . I'm currently running 3.11.0 and this bug is still here.

As my experience with kernel hacking is minimal I'm not even sure
the problem lies in hid-sony, but that's where my investigations lead
me.

Thank you to have taken the time to read my mail, I hope it will help
to fix this issue, and again, sorry if you're not the right person to
write to.

Regards,
-- 
Marc Planard

Re: About the PS3 Sixaxis linux driver

[simon]

> Hi Marc,
>
> (adding in CC the linux-input mailing list)
>
> Regarding your problem I vaguely remember something about not having
> duplicated axis with the buttons. My memory is rather confuse about this,
> so I may be wrong (but others on the list may have a fresher memory).
> Other than that, if only one axis is not working, then it is definitively
> a bug...
>
> I'll try to add this to my todo list, but I can not guarantee anything
> soon. If someone else can confirm and fix this, I'll be happy.

There was something a couple of years ago with the multi-touch stuff
screening out HID reports for the D-Pad axis.

http://comments.gmane.org/gmane.linux.kernel.input/19632

Don't know the current situation,
Simon

Re: About the PS3 Sixaxis linux driver

[Antonio Ospite]

On Mon, 4 Nov 2013 15:37:30 -0500 (EST)
Benjamin Tissoires <btissoir@redhat.com> wrote:

> Hi Marc,
> 
> (adding in CC the linux-input mailing list)
> 
> Regarding your problem I vaguely remember something about not having duplicated axis with the buttons. My memory is rather confuse about this, so I may be wrong (but others on the list may have a fresher memory).
> Other than that, if only one axis is not working, then it is definitively a bug...
>

The problem with the left D-PAD should be the one I talk about here:
http://www.spinics.net/lists/linux-input/msg16881.html

Basically the keycode is a multi-touch one and it gets discarded being
the device not a MT one.

I was told the hack I came up with is not OK for mainline, but people
can apply it locally for the time being.

> I'll try to add this to my todo list, but I can not guarantee anything soon. If someone else can confirm and fix this, I'll be happy.
>

Will remapping just the faulty keycode be enough?

Actually I intended to rewrite the whole HID descriptor and add a sane
mapping for all the buttons (maybe following the Gamepad API and
even using the new ABS_ACCEL_* and ABS_GYRO_* events from David
Hermann).

I may try to do some work along these lines myself in the next weeks
but I cannot promise an ETA either.

Marc, if you need the latest BlueZ patches for pairing the sixaxis for
BT operation just let me know.

Ciao,
   Antonio

> Cheers,
> Benjamin
> 
> ----- Original Message -----
> From: "case" <case@corpsmoderne.net>
> To: "Benjamin Tissoires" <benjamin.tissoires@redhat.com>
> Sent: Friday, October 25, 2013 8:52:14 AM
> Subject: About the PS3 Sixaxis linux driver
> 
> Hello Benjamin,
> 
> I'm mailing you because it seems you're one of the kernel developers
> the most involved with the hid-sony.c driver lately, with which I think
> I've an issue. If you feel like I'm mailing the wrong person,
> I apologize, and would be glad if you could point me to the right
> person.
> 
> I'm a game developer experimenting with the sixaxis for a while, and
> I've a big issue with the current state of the driver:
> 
> On the sixaxis all the buttons (except select and start) are mapped
> as buttons but also as axis, which is pretty rad. That was working great
> in 2010 when I started to experiment with the sixaxis but in more
> recent versions of the kernel, one the the buttons has lost his axis.
> It's the left button the the D-PAD, witch is only mapped as button 7
> (up is button 4 and axis 8, right is button 5 axis 9, bottom is button
> 6 axis 10).
>
> This is quite inconsistent and makes impossible to rely on the axis for
> all the D-PAD buttons.
> 
> Again, this bug wasn't there in 2.6.32 . I noticed it for the first time
> in 3.5.x . I'm currently running 3.11.0 and this bug is still here.
> 
> As my experience with kernel hacking is minimal I'm not even sure
> the problem lies in hid-sony, but that's where my investigations lead
> me.
> 
> Thank you to have taken the time to read my mail, I hope it will help
> to fix this issue, and again, sorry if you're not the right person to
> write to.
> 
> Regards,
> -- 
> Marc Planard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: About the PS3 Sixaxis linux driver

[simon]

> Actually I intended to rewrite the whole HID descriptor and add a sane
> mapping for all the buttons (maybe following the Gamepad API and
> even using the new ABS_ACCEL_* and ABS_GYRO_* events from David
> Hermann).

I think that the root of the problem here is simply the large number of
axis, and that the keycodes start at 'axis-x' then overflow into/past the
MultiTouch keycode.

This problem is going to be a more common one as HID drivers present more
buttons/axis.

We did some patching here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-sony.c?id=refs/tags/v3.12#n301
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/hid/hid-sony.c?id=61ab44bebdefab296487e7cd723a634849278827

Do we need to fix this is the HID descriptor, or in 'hid-sony' input stuff?

Do you have example of another driver to copy?
Simon

Re: About the PS3 Sixaxis linux driver

[Antonio Ospite]

On Mon, 4 Nov 2013 16:40:29 -0500
simon@mungewell.org wrote:

Hi Simon, sorry for the delay on this one.
 
> > Actually I intended to rewrite the whole HID descriptor and add a sane
> > mapping for all the buttons (maybe following the Gamepad API and
> > even using the new ABS_ACCEL_* and ABS_GYRO_* events from David
> > Hermann).
> 
> I think that the root of the problem here is simply the large number of
> axis, and that the keycodes start at 'axis-x' then overflow into/past the
> MultiTouch keycode.
>

Yes, and the code that maps HID usages to event keycodes also comes into
play I guess.

> This problem is going to be a more common one as HID drivers present more
> buttons/axis.
> 
> We did some patching here:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-sony.c?id=refs/tags/v3.12#n301
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/hid/hid-sony.c?id=61ab44bebdefab296487e7cd723a634849278827
> 
> Do we need to fix this is the HID descriptor, or in 'hid-sony' input stuff?

I think both:

  1. adjust the HID descriptor into something that can be more easily
     remapped;

  2. remap the keycodes in hid-sony to those of the gamepad API, because
     AFAICT that can't be achieved by solely deciding HID usage codes in
     the descriptor.

> Do you have example of another driver to copy?

I am doing some work already in this direction, on the lines of what we
did for the ps3remote in hid-sony, but it needs some input bits not
merged yet, I'll send an RFC as soon as this becomes more easily
testable.

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: About the PS3 Sixaxis linux driver

[Benjamin Tissoires]

Hi guys,

I forgot to say that:
- IMO, the approach raised in 2011 by Antonio[1] was the correct one:
the multitouch protocol introduced a regression with devices providing
large axis number, so we should fix this in input core, not on a per
device basis.
- I'll send an update to this patch later this week.
- I don't think remapping the PS3 axis now will make into upstream
(backward compatibility), but this is only my own opinion
- I have discussed this with the Xinput maintainer, and he also would
like to get the information from the kernel when the ABS_MT axis are
used as ABS_MT or ABS_MISC, so I'll also add a property in this way.

Cheers,
Benjamin

[1] http://www.spinics.net/lists/linux-input/msg16881.html

On 16/11/13 12:06, Antonio Ospite wrote:
> On Mon, 4 Nov 2013 16:40:29 -0500
> simon@mungewell.org wrote:
> 
> Hi Simon, sorry for the delay on this one.
>  
>>> Actually I intended to rewrite the whole HID descriptor and add a sane
>>> mapping for all the buttons (maybe following the Gamepad API and
>>> even using the new ABS_ACCEL_* and ABS_GYRO_* events from David
>>> Hermann).
>>
>> I think that the root of the problem here is simply the large number of
>> axis, and that the keycodes start at 'axis-x' then overflow into/past the
>> MultiTouch keycode.
>>
> 
> Yes, and the code that maps HID usages to event keycodes also comes into
> play I guess.
> 
>> This problem is going to be a more common one as HID drivers present more
>> buttons/axis.
>>
>> We did some patching here:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-sony.c?id=refs/tags/v3.12#n301
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/hid/hid-sony.c?id=61ab44bebdefab296487e7cd723a634849278827
>>
>> Do we need to fix this is the HID descriptor, or in 'hid-sony' input stuff?
> 
> I think both:
> 
>   1. adjust the HID descriptor into something that can be more easily
>      remapped;
> 
>   2. remap the keycodes in hid-sony to those of the gamepad API, because
>      AFAICT that can't be achieved by solely deciding HID usage codes in
>      the descriptor.
> 
>> Do you have example of another driver to copy?
> 
> I am doing some work already in this direction, on the lines of what we
> did for the ps3remote in hid-sony, but it needs some input bits not
> merged yet, I'll send an RFC as soon as this becomes more easily
> testable.
> 
> Regards,
>    Antonio
> 

Re: About the PS3 Sixaxis linux driver

[Antonio Ospite]

On Mon, 18 Nov 2013 10:38:42 -0500
Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:

> Hi guys,
> 
> I forgot to say that:
> - IMO, the approach raised in 2011 by Antonio[1] was the correct one:
> the multitouch protocol introduced a regression with devices providing
> large axis number, so we should fix this in input core, not on a per
> device basis.
> - I'll send an update to this patch later this week.

Thanks.

> - I don't think remapping the PS3 axis now will make into upstream
> (backward compatibility), but this is only my own opinion

What do other people think? I was going to motivate the change of
keycodes with the fact that the device was not fully functional for a
long time, but if you fix it in input core this argument does not hold
anymore :)

It would have been a good excuse to have a user of the full gamepad
API and of a good part of the motion-tracking API, but I won't push
this too hard.

> - I have discussed this with the Xinput maintainer, and he also would
> like to get the information from the kernel when the ABS_MT axis are
> used as ABS_MT or ABS_MISC, so I'll also add a property in this way.
> 

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: About the PS3 Sixaxis linux driver

[Benjamin Tissoires]

On 18/11/13 11:25, Antonio Ospite wrote:
> On Mon, 18 Nov 2013 10:38:42 -0500
> Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
> 
>> Hi guys,
>>
>> I forgot to say that:
>> - IMO, the approach raised in 2011 by Antonio[1] was the correct one:
>> the multitouch protocol introduced a regression with devices providing
>> large axis number, so we should fix this in input core, not on a per
>> device basis.
>> - I'll send an update to this patch later this week.
> 
> Thanks.
> 
>> - I don't think remapping the PS3 axis now will make into upstream
>> (backward compatibility), but this is only my own opinion
> 
> What do other people think? I was going to motivate the change of
> keycodes with the fact that the device was not fully functional for a
> long time, but if you fix it in input core this argument does not hold
> anymore :)

Just FYI, I mentioned this because there already has been 2 or 3 threads
regarding bad uses of keycodes/axis for gamepads (WII, XBox, and PS3
IIRC), and the result was always "we do not break user space".
Personally, I have nothing against mapping the correct axis :)

> 
> It would have been a good excuse to have a user of the full gamepad
> API and of a good part of the motion-tracking API, but I won't push
> this too hard.

There are some initiatives in the user space to fix those kernel
problems. libinputmapper (find one of David Herrmann's post) and
libevdev (on Freedesktop) are some good candidates.

Cheers,
Benjamin

Re: About the PS3 Sixaxis linux driver

[Marc]

Thanks a lot Benjamin (and everyone) to handle this.

Just to let you know, I've updated from 3.5 to 3.11
(basically, from stock ubuntu-12.04 to stock ubuntu-13.10)
and the bug is still there.

On 11/04/2013 10:18 PM, Antonio Ospite wrote:
> The problem with the left D-PAD should be the one I talk about here:
> http://www.spinics.net/lists/linux-input/msg16881.html

I'll try that as soon as possible, but as you noted, it's not a viable
solution for the long term...

> Marc, if you need the latest BlueZ patches for pairing the sixaxis for
> BT operation just let me know.

I forgot to say I've only tested through tethered USB. I'm not even
sure to have a functioning BT host :) but thanks for the proposal.

On 11/04/2013 10:40 PM, simon@mungewell.org wrote:
 > We did some patching here:
 > 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-sony.c?id=refs/tags/v3.12#n301
 > 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/hid/hid-sony.c?id=61ab44bebdefab296487e7cd723a634849278827

The kernel I'm currently running (ubuntu-saucy) includes this patch.
Also, I'm not very good at this, but I've made a diff of the last
version of hid-sony.c and the version currently in ubuntu-saucy (3.11) :
the changes are minimal and can't have fixed the bug (see bellow).

$ diff hid-sony.c ~/ubuntu-saucy/drivers/hid/hid-sony.c
631c631
< 	sc = devm_kzalloc(&hdev->dev, sizeof(*sc), GFP_KERNEL);
---
 > 	sc = kzalloc(sizeof(*sc), GFP_KERNEL);
643c643
< 		return ret;
---
 > 		goto err_free;
656c656
< 		return ret;
---
 > 		goto err_free;
675a676,677
 > err_free:
 > 	kfree(sc);
686a689
 > 	kfree(sc);


-- 
Marc