[RFC] [BUG?] Sixaxis Value Ranges

Hi,

The sixaxis accelerometers/gyroscope from the joystick interface use a
"flat" value that causes an input range of length ~128 of 1024 to be
mapped to zero.  This loses a lot of orientation information; for
example, it is possible to position the device diagonally such that
all three accelerometers are zero--meaning there is no force of
gravity.

I'm not sure if this warrants a bug report:  Is it the intended
behavior, or a bad side-effect of the default settings?

For demonstration purposes, the following is a patch that attempts to
set the "flat" and "fuzz" values, but it is not very clean.  These
values are reset to defaults AFTER the input_mapped function is
called, so it returns a negative value to bypass the rest of
hidinput_configure_usage().  (I am not very familiar with the input
subsystem, so maybe someone can suggest a more correct way to
accomplish this.)  It should at least allow you to see the difference
in reported values.

Thanks for any suggestions on the issue.

David

--- a/drivers/hid/hid-sony.c	2011-09-02 19:34:52.833614001 -0400
+++ b/drivers/hid/hid-sony.c	2011-09-06 20:49:04.576358380 -0400

@@ -209,6 +209,36 @@ static void sony_remove(struct hid_devic
 	kfree(hid_get_drvdata(hdev));
 }

+/*
+ * The default axis flat value for gamepads is [range length] >> 4 which, in
+ * the case of the 10-bit sixaxis accelerometers/gyroscope, loses too much
+ * information.
+ */
+static int sony_input_mapped(struct hid_device *hdev, struct hid_input *hi,
+			     struct hid_field *field, struct hid_usage *usage,
+			     unsigned long **bit, int *max)
+{
+	int a = field->logical_minimum;
+	int b = field->logical_maximum;
+
+	/* The 10-bit range identifies the accelerometers/gyroscope uniquely */
+	if (usage->hid == HID_GD_POINTER && a == 0x0000 && b == 0x03FF) {
+
+		/* This repeats hid-input.c code that had to be skipped */
+		set_bit(usage->type, hi->input->evbit);
+		while (usage->code <= *max && test_and_set_bit(usage->code, *bit))
+			usage->code = find_next_zero_bit(*bit, *max + 1, usage->code);
+
+		/* Specify a new fuzz and flat value */
+		input_set_abs_params(hi->input, usage->code, a, b, 4, 4);
+
+		/* Skip past the default post-mapping changes */
+		return -1;
+	}
+
+	return 0;
+}
+
 static const struct hid_device_id sony_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER),
 		.driver_data = SIXAXIS_CONTROLLER_USB },

@@ -228,7 +258,8 @@ static struct hid_driver sony_driver = {
 	.probe = sony_probe,
 	.remove = sony_remove,
 	.report_fixup = sony_report_fixup,
-	.raw_event = sony_raw_event
+	.raw_event = sony_raw_event,
+	.input_mapped = sony_input_mapped
 };

 static int __init sony_init(void)

The sixaxis accelerometers/gyroscope from the joystick interface use a
"flat" value that causes an input range of length ~128 of 1024 to be
mapped to zero.

Thanks for any suggestions on the issue.

Hi David,
Are you sure that the dead zone is being applied in the device itself, and
not by the '/dev/input/js0' system?

You can look directly at the streaming HID bytes hex(although I can't
remember how, someone here suggested a method a couple of months back) to
confirm this.

You could also try to completely disable the 'dead zone' on the joystick
sub-system.
Simon

You can look directly at the streaming HID bytes hex(although I can't
remember how, someone here suggested a method a couple of months back) to
confirm this.

from http://www.pabr.org/sixlinux/sixlinux.en.html#inop:

# hexdump -v -e '48/1 "%02x " "\n"' < /dev/hidraw1   # For kernels <  2.6.26
# hexdump -v -e '49/1 "%02x " "\n"' < /dev/hidraw1   # For kernels >= 2.6.26
00 00 00 00 00 74 7b 7c 7c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 02 ee 10 00 00 00 00 02 b2 77 01 81 02 05 01 ed 01 a4 00 02

Simon

Hi,

On Wed, Sep 7, 2011 at 2:48 PM,  [off-list ref] wrote:

Are you sure that the dead zone is being applied in the device itself, and
not by the '/dev/input/js0' system?

Sorry if I wasn't clear; it is /dev/input/jsX that loses data.
Reading /dev/hidrawX gives results across the entire 0x000-0x3FF range
as I would expect.

I had actually been reading /dev/hidrawX to get at this data without
issue until a few weeks ago when support was added to /dev/input/jsX.
This dead zone became apparent in my applications immediately after I
tried to switch.

You could also try to completely disable the 'dead zone' on the joystick
sub-system.

Are you referring to the JSIOCSCORR ioctl operation here?  Perhaps I
could use this directly in my applications to ensure the
accelerometers' values are more precise whenever they are run.  I
still think too much information is lost with the default setting and
new js_corr values should be considered for these axes, but the ioctl
call should solve the issue in my case.

Thanks for your suggestion.

David

On Thu, 8 Sep 2011 10:05:10 -0400
David Michael [off-list ref] wrote:

Hi,

On Wed, Sep 7, 2011 at 2:48 PM,  [off-list ref] wrote:

quoted

Are you sure that the dead zone is being applied in the device itself, and
not by the '/dev/input/js0' system?

Sorry if I wasn't clear; it is /dev/input/jsX that loses data.
Reading /dev/hidrawX gives results across the entire 0x000-0x3FF range
as I would expect.

I had actually been reading /dev/hidrawX to get at this data without
issue until a few weeks ago when support was added to /dev/input/jsX.
This dead zone became apparent in my applications immediately after I
tried to switch.

Long delay to look at that, sorry.

I verified the input event system was OK too with:
	$ evtest /dev/input/event7 | egrep 'code (59|60|61)'
All values up to 1023 are received.

quoted

You could also try to completely disable the 'dead zone' on the joystick
sub-system.

Are you referring to the JSIOCSCORR ioctl operation here?  Perhaps I
could use this directly in my applications to ensure the
accelerometers' values are more precise whenever they are run.  I
still think too much information is lost with the default setting and
new js_corr values should be considered for these axes, but the ioctl
call should solve the issue in my case.

So David, did you solve this way?
I read in Documentation/input/joystick-api.txt that JSIOCSCORR should
not be used in a normal programs, only in calibration software.
Then I tried jstest-gtk and I was able to get all the values via the
joystick device too setting minimum and maximum values respectively to
0 and 1023.

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?

Hi,

On Tue, Sep 20, 2011 at 6:57 AM, Antonio Ospite
[off-list ref] wrote:

So David, did you solve this way?
I read in Documentation/input/joystick-api.txt that JSIOCSCORR should
not be used in a normal programs, only in calibration software.

I haven't added any ioctl calls to my programs yet, but I still
consider it for the future.  They aren't being widely distributed
(mostly on other operating systems where alternative input devices are
used anyway), so I am content to monitor API changes to the
calibration settings and adjust them as needed.

Then I tried jstest-gtk and I was able to get all the values via the
joystick device too setting minimum and maximum values respectively to
0 and 1023.

Using jstest-gtk (and/or jscal) is where I settled for the time being,
although I would like to eventually have better precision "out of the
box", either by a calibration in my applications or changing the
default correction values directly in the driver (which I think is
justified in this case).

Thanks.

David