[RFC,BUG?] Sixaxis Value Ranges

Commit Message

David Michael Sept. 7, 2011, 4:50 p.m. UTC

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


--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

[e-mail] Sept. 7, 2011, 6:48 p.m. UTC | #1

> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[e-mail] Sept. 7, 2011, 6:58 p.m. UTC | #2

> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David Michael Sept. 8, 2011, 2:05 p.m. UTC | #3

Hi,

On Wed, Sep 7, 2011 at 2:48 PM,  <[e-mail]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

--- 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)