HID joystick - Axis 11 non operational.

I have a strange bug, axis 11 does not appear to be working at all,
remains at -32768 all the time.

On the Sixaxis controller almost all the buttons are pressure sensitive,
and thus reported as axis as well as buttons. The 'faulty' axis is in the
middle of a descriptor group so I don't think the problem is with the
descriptor.

Hidraw0 logging shows that the gamepad is sending the correct data. Logs
from hidraw and jstest attached.

Axis 10 - Dpad-down
Axis 11 - Dpad-left
Axis 12 - L2 trigger

This fault is seen with Sixaxis and 3rd party wired controller. Tested
with 3.0rc1 kernel.

Is there any chance/place where userland could be misconfigured? Or where
should I look in the kernel?

Simon.

On Wed, 1 Jun 2011 15:25:02 -0400
simon@mungewell.org wrote:

I have a strange bug, axis 11 does not appear to be working at all,
remains at -32768 all the time.

On the Sixaxis controller almost all the buttons are pressure sensitive,
and thus reported as axis as well as buttons. The 'faulty' axis is in the
middle of a descriptor group so I don't think the problem is with the
descriptor.

Hidraw0 logging shows that the gamepad is sending the correct data. Logs
from hidraw and jstest attached.

Axis 10 - Dpad-down
Axis 11 - Dpad-left
Axis 12 - L2 trigger

I confirm that the axis for Dpad-left (usage->code == 0x2f IINM) of the
Sixaxis looks like it is not working. I too can see the data on hidraw
device but not on the joystick or even the event device, so it may be
below the joystick layer.

This fault is seen with Sixaxis and 3rd party wired controller. Tested
with 3.0rc1 kernel.

Simon when you say "3rd party wired controller" do you mean still
Sixaxis compatible?

Is there any chance/place where userland could be misconfigured? Or where
should I look in the kernel?

I took a quick look at hid-input.c thinking that something about
event bits could be wrong but haven't found anything so far.

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

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?

Simon when you say "3rd party wired controller" do you mean still
Sixaxis compatible?

INTEC TURBO SHOCK III WIRED CONTROLLER FOR PS3

http://www.thesource.ca/estore/product.aspx?language=en-CA&catalog=Online&category=PS3_Accessories&product=5816155

Shows up as the same USB ID, but does not have accelerometer/gyro (these
fields are always 0).
Simon.

On Fri, 3 Jun 2011 16:15:11 +0200
Antonio Ospite [off-list ref] wrote:

I confirm that the axis for Dpad-left (usage->code == 0x2f IINM) of the
Sixaxis looks like it is not working. I too can see the data on hidraw
device but not on the joystick or even the event device, so it may be
below the joystick layer.

OK found something: 0x2f is ABS_MT_SLOT,
http://lxr.linux.no/linux+*/include/linux/input.h#L773

And in input.c::input_handle_abs_event() this case is handled in a
special way:
http://lxr.linux.no/#linux+v2.6.39/drivers/input/input.c#L172

This little change improves thins a little bit, but the pressure event is
now reported twice, once with the actual value and once with 0, you can test
with:

 $ evtest /dev/input/eventX | \
   egrep -v 'code (0|1|2|5|48|49|50|51|52|53|54|55|56|57|58|58|59)|Report Sync'

Index: linux-2.6/drivers/input/input.c
===================================================================

--- linux-2.6.orig/drivers/input/input.c
+++ linux-2.6/drivers/input/input.c

@@ -169,7 +169,7 @@
        bool is_mt_event;
        int *pold;
 
-       if (code == ABS_MT_SLOT) {
+       if (code == ABS_MT_SLOT && dev->mtsize > 0) {
                /*
                 * "Stage" the event; we'll flush it later, when we
                 * get actual touch data.

@@ -210,6 +210,9 @@
                input_pass_event(dev, EV_ABS, ABS_MT_SLOT, dev->slot);
        }
 
+       if (code == 0x2f)
+               printk(KERN_DEBUG "%s: code: %08x handled value: %d\n", __func__, code, *pval);
+
        return INPUT_PASS_TO_HANDLERS;
 }

Otherwise we would need to remap the axis code to something more
meaningful by patching the HID descriptor, can this be done?

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

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?

On Sat, 4 Jun 2011 22:45:46 +0200
Antonio Ospite [off-list ref] wrote:

On Fri, 3 Jun 2011 16:15:11 +0200
Antonio Ospite [off-list ref] wrote:

quoted

I confirm that the axis for Dpad-left (usage->code == 0x2f IINM) of the
Sixaxis looks like it is not working. I too can see the data on hidraw
device but not on the joystick or even the event device, so it may be
below the joystick layer.

OK found something: 0x2f is ABS_MT_SLOT,
http://lxr.linux.no/linux+*/include/linux/input.h#L773

And in input.c::input_handle_abs_event() this case is handled in a
special way:
http://lxr.linux.no/#linux+v2.6.39/drivers/input/input.c#L172

This little change improves things a little bit, but the pressure event is
now reported twice, once with the actual value and once with 0, you can test
with:

 $ evtest /dev/input/eventX | \
   egrep -v 'code (0|1|2|5|48|49|50|51|52|53|54|55|56|57|58|58|59)|Report Sync'

The second ABS_MT_SLOT event is fired up here:
http://lxr.linux.no/#linux+v2.6.39/drivers/input/input.c#L210

when I get code == 0x30 (ABS_MT_TOUCH_MAJOR, I am still not sure
where from), with the following hack I can make axis 11 work again but I
have no idea if I am broking MultiTouch devices, anyone?

Index: linux-2.6/drivers/input/input.c
===================================================================

--- linux-2.6.orig/drivers/input/input.c
+++ linux-2.6/drivers/input/input.c

@@ -169,7 +169,7 @@
        bool is_mt_event;
        int *pold;
 
-       if (code == ABS_MT_SLOT) {
+       if (code == ABS_MT_SLOT && dev->mtsize > 0) {
                /*
                 * "Stage" the event; we'll flush it later, when we
                 * get actual touch data.

@@ -205,7 +205,8 @@
        }
 
        /* Flush pending "slot" event */
-       if (is_mt_event && dev->slot != input_abs_get_val(dev, ABS_MT_SLOT)) {
+       if (is_mt_event && dev->slot != input_abs_get_val(dev, ABS_MT_SLOT) &&
+           dev->mtsize > 0 ) {
                input_abs_set_val(dev, ABS_MT_SLOT, dev->slot);
                input_pass_event(dev, EV_ABS, ABS_MT_SLOT, dev->slot);
        }

Simon, if that works for you too, I can send an RFC patch out, but how should
we motivate it? The Sixaxis is sending out MT events even if it is not a MT
device...

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

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?

I'll try to find some time to test this...

when I get code == 0x30 (ABS_MT_TOUCH_MAJOR, I am still not sure
where from), with the following hack I can make axis 11 work again but I
have no idea if I am broking MultiTouch devices, anyone?

If the root of the problem is with the Sixaxis, can we not
re-allocate/re-map which HID events it produces so that the rest of the
system sees what it is expecting?

If this is likely to be a problem with other devices interfering with the
MultiTouch stuff then I guess we should fix it properly,
Simon.