Wii Balance Board vs. bluez

Wii Balance Board vs. bluez

[Florian Echtler]

Hello everyone,

I'm having some issues getting the Wii Balance Board to work with a 
recent Linux Bluetooth stack (Ubuntu 12.04, Kernel 3.2, bluez-4.101).

After some minor patching [1], I've successfully paired the board with 
my machine. Automatic reconnect (when hitting the large front button) is 
also working.

However, the hid-wiimote driver, even the one I "backported" from kernel 
3.5, apparently doesn't really support the balance board so far. I do 
get 5 new device nodes as /dev/input/event*, but none of them actually 
report any data from the weight sensors.

Alternatively, I've tried the cwiid userspace library. This does work, 
however, I have to un-pair the board from bluetoothd first and put it 
into discoverable mode using the button on the bottom side, which is 
pretty inconvenient. If I keep the pairing active, the board will 
reconnect to bluetoothd itself and cwiid can't open a second L2CAP 
connection, AFAICT.

So, my two questions are:

- Is anybody currently working on integrating the balance board into 
hid-wiimote?

- Is there a way to retrieve the existing automatic connection from 
bluetoothd and pass it to a second userspace process (i.e., cwiid)?

Thanks!
Florian


[1] https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1049266
-- 
SENT FROM MY DEC VT50 TERMINAL

Re: Wii Balance Board vs. bluez

[David Herrmann]

Hi Florian

On Wed, Sep 12, 2012 at 10:50 PM, Florian Echtler <floe@butterbrot.org> wrote:
> Hello everyone,
>
> I'm having some issues getting the Wii Balance Board to work with a recent
> Linux Bluetooth stack (Ubuntu 12.04, Kernel 3.2, bluez-4.101).
>
> After some minor patching [1], I've successfully paired the board with my
> machine. Automatic reconnect (when hitting the large front button) is also
> working.

Awesome. Automatic reconnect was a horrible mess to get working under
Linux but great to hear it works for others, too.

> However, the hid-wiimote driver, even the one I "backported" from kernel
> 3.5, apparently doesn't really support the balance board so far. I do get 5
> new device nodes as /dev/input/event*, but none of them actually report any
> data from the weight sensors.

"backported"? Why would you backport the hid-wiimote driver? Or do you
mean "forwardport"? Anyway, the hid-wiimote driver does not have
support for the wii-balance board as I do not have access to them.
However, if you are willing to test it, I will send some patches which
will implement it.

> Alternatively, I've tried the cwiid userspace library. This does work,
> however, I have to un-pair the board from bluetoothd first and put it into
> discoverable mode using the button on the bottom side, which is pretty
> inconvenient. If I keep the pairing active, the board will reconnect to
> bluetoothd itself and cwiid can't open a second L2CAP connection, AFAICT.

Yes, cwiid includes support for it but it is horribly written and a
3rd party application which doesn't utilize the kernel HID or bluez
infrastructure.

> So, my two questions are:
>
> - Is anybody currently working on integrating the balance board into
> hid-wiimote?

I am maintaining the hid-wiimote driver, but I am not particularly
working on balance-board support, yet. I am willing to do that, though
;)

> - Is there a way to retrieve the existing automatic connection from
> bluetoothd and pass it to a second userspace process (i.e., cwiid)?

No. No way. This is why I have written hid-wiimote.

>
> [1] https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1049266

Ouh, I see. I will send a patch fixing this to the BlueZ mailing list.
I will put you on CC if you don't mind.

Thanks for the report!
David

Re: Wii Balance Board vs. bluez

[Florian Echtler]

David Herrmann <dh.herrmann@googlemail.com> wrote:

>"backported"? Why would you backport the hid-wiimote driver? Or do you
>mean "forwardport"? Anyway, the hid-wiimote driver does not have
>support for the wii-balance board as I do not have access to them.
By "backport", I just meant that I recompiled the driver from 3.5 for my 3.2 kernel :-)

>However, if you are willing to test it, I will send some patches which
>will implement it.
Absolutely, I'd be happy to test.

>Ouh, I see. I will send a patch fixing this to the BlueZ mailing list.
>I will put you on CC if you don't mind.
Thanks, I'll test this later today.

One additional question: it looks like this problem with the pairing is going
to pop up again with 3rd-party controllers, the new Wii U controller etc. 
Would it make sense to create a new PIN option which users can select 
explicitly? 

Florian
-- 
SENT FROM MY PDP-11

Re: Wii Balance Board vs. bluez

[David Herrmann]

Hi Florian

On Thu, Sep 13, 2012 at 7:59 AM, Florian Echtler <floe@butterbrot.org> wrote:
>
>
> David Herrmann <dh.herrmann@googlemail.com> wrote:
>>However, if you are willing to test it, I will send some patches which
>>will implement it.
> Absolutely, I'd be happy to test.

Please see the appended patch. You have to apply it to your kernel
tree and recompile the hid-wiimote driver. No other sources are
changed so you don't need to reboot or install the new kernel. Just
install the new hid-wiimote.ko module.

One of the 5 input devices should then report the wiimote weight
sensor data. (the input device with name "Wii Remote Balance Board").

>>Ouh, I see. I will send a patch fixing this to the BlueZ mailing list.
>>I will put you on CC if you don't mind.
> Thanks, I'll test this later today.
>
> One additional question: it looks like this problem with the pairing is going
> to pop up again with 3rd-party controllers, the new Wii U controller etc.
> Would it make sense to create a new PIN option which users can select
> explicitly?

No. First: there are very restrictive time-constraints on most of
these devices so user-input would be too slow. Second: The BlueZ
maintainers don't like this approach.

So just send an email to the linux-bluetooth mailing list and we will
add quirks to BlueZ so new devices will work, too.

Regards
David

Re: Wii Balance Board vs. bluez

[David Herrmann]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Thu, Sep 13, 2012 at 4:38 PM, David Herrmann
<dh.herrmann@googlemail.com> wrote:
> Hi Florian
>
> On Thu, Sep 13, 2012 at 7:59 AM, Florian Echtler <floe@butterbrot.org> wrote:
>>
>>
>> David Herrmann <dh.herrmann@googlemail.com> wrote:
>>>However, if you are willing to test it, I will send some patches which
>>>will implement it.
>> Absolutely, I'd be happy to test.
>
> Please see the appended patch. You have to apply it to your kernel
> tree and recompile the hid-wiimote driver. No other sources are
> changed so you don't need to reboot or install the new kernel. Just
> install the new hid-wiimote.ko module.
>
> One of the 5 input devices should then report the wiimote weight
> sensor data. (the input device with name "Wii Remote Balance Board").

Forgot to attach the patch... Here it is.

[-- Attachment #2: wiimote_balance_board.patch --]
[-- Type: application/octet-stream, Size: 3082 bytes --]

diff --git a/drivers/hid/hid-wiimote-ext.c b/drivers/hid/hid-wiimote-ext.c
index d37cd09..ae7c1b6 100644
--- a/drivers/hid/hid-wiimote-ext.c
+++ b/drivers/hid/hid-wiimote-ext.c
@@ -34,6 +34,7 @@ enum wiiext_type {
 	WIIEXT_NONE,		/* placeholder */
 	WIIEXT_CLASSIC,		/* Nintendo classic controller */
 	WIIEXT_NUNCHUCK,	/* Nintendo nunchuck controller */
+	WIIEXT_BALANCE_BOARD,	/* Nintendo balance board controller */
 };
 
 enum wiiext_keys {
@@ -151,6 +152,11 @@ static __u8 ext_read(struct wiimote_ext *ext)
 			type = WIIEXT_NUNCHUCK;
 		else if (rmem[0] == 0x01 && rmem[1] == 0x01)
 			type = WIIEXT_CLASSIC;
+		else if (rmem[0] == 0x04 && rmem[1] == 0x02)
+			type = WIIEXT_BALANCE_BOARD;
+		else
+			hid_info(ext->wdata->hdev, "Unknown extension device (%x%x)\n",
+				 rmem[0], rmem[1]);
 	}
 
 	wiimote_cmd_release(ext->wdata);
@@ -509,6 +515,48 @@ static void handler_classic(struct wiimote_ext *ext, const __u8 *payload)
 	input_sync(ext->input);
 }
 
+static void handler_balance_board(struct wiimote_ext *ext, const __u8 *payload)
+{
+	__s16 tr, br, tl, bl;
+
+	/*   Byte |  8  7  6  5  4  3  2  1  |
+	 *   -----+--------------------------+
+	 *    1   |    Top Right <15:8>      |
+	 *    2   |    Top Right  <7:0>      |
+	 *   -----+--------------------------+
+	 *    3   | Bottom Right <15:8>      |
+	 *    4   | Bottom Right  <7:0>      |
+	 *   -----+--------------------------+
+	 *    5   |     Top Left <15:8>      |
+	 *    6   |     Top Left  <7:0>      |
+	 *   -----+--------------------------+
+	 *    7   |  Bottom Left <15:8>      |
+	 *    8   |  Bottom Left  <7:0>      |
+	 *   -----+--------------------------+
+	 *
+	 * These values represent the weight-measurements of the Wii-balance
+	 * board with 16bit precision.
+	 *
+	 * The balance-board is never reported interleaved with motionp.
+	 */
+
+	tr = payload[0] << 8;
+	tr |= payload[1];
+	br = payload[2] << 8;
+	br |= payload[3];
+	tl = payload[4] << 8;
+	tl |= payload[5];
+	bl = payload[6] << 8;
+	bl |= payload[7];
+
+	input_report_abs(ext->input, ABS_HAT0X, tl);
+	input_report_abs(ext->input, ABS_HAT0Y, tr);
+	input_report_abs(ext->input, ABS_HAT1X, bl);
+	input_report_abs(ext->input, ABS_HAT1Y, br);
+
+	input_sync(ext->input);
+}
+
 /* call this with state.lock spinlock held */
 void wiiext_handle(struct wiimote_data *wdata, const __u8 *payload)
 {
@@ -523,6 +571,8 @@ void wiiext_handle(struct wiimote_data *wdata, const __u8 *payload)
 		handler_nunchuck(ext, payload);
 	} else if (ext->ext_type == WIIEXT_CLASSIC) {
 		handler_classic(ext, payload);
+	} else if (ext->ext_type == WIIEXT_BALANCE_BOARD) {
+		handler_balance_board(ext, payload);
 	}
 }
 
@@ -551,6 +601,11 @@ static ssize_t wiiext_show(struct device *dev, struct device_attribute *attr,
 			return sprintf(buf, "motionp+classic\n");
 		else
 			return sprintf(buf, "classic\n");
+	} else if (type == WIIEXT_BALANCE_BOARD) {
+		if (motionp)
+			return sprintf(buf, "motionp+balanceboard\n");
+		else
+			return sprintf(buf, "balanceboard\n");
 	} else {
 		if (motionp)
 			return sprintf(buf, "motionp\n");

Re: Wii Balance Board vs. bluez

[Florian Echtler]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

On 13.09.2012 16:39, David Herrmann wrote:
>> Please see the appended patch. You have to apply it to your kernel
>> tree and recompile the hid-wiimote driver. No other sources are
>> changed so you don't need to reboot or install the new kernel. Just
>> install the new hid-wiimote.ko module.
>>
>> One of the 5 input devices should then report the wiimote weight
>> sensor data. (the input device with name "Wii Remote Balance Board").
> Forgot to attach the patch... Here it is.
Awesome - works as expected, weight sensor data can be read from one of 
the event devices.

I've attached an additional patch on top of yours to also read the 
calibration data (24 bytes at address 0xa40024). Calibration data is 
applied in handler_balance_board, resulting values are in units of 10 
grams. Although this looks correct to me, I'm not getting any events 
with my patch applied - I suspect some connection to the min/max input 
values. Do you have any ideas what's wrong?

Florian
-- 
SENT FROM MY DEC VT50 TERMINAL

[-- Attachment #2: balance_calibration.patch --]
[-- Type: text/x-patch, Size: 3806 bytes --]

diff -u a/hid-wiimote-ext.c b/hid-wiimote-ext.c
--- a/hid-wiimote-ext.c	2012-09-13 21:04:01.600494774 +0200
+++ b/hid-wiimote-ext.c	2012-09-13 23:30:57.416209821 +0200
@@ -28,6 +28,7 @@
 	bool mp_plugged;
 	bool motionp;
 	__u8 ext_type;
+	__u16 calib[4][3];
 };
 
 enum wiiext_type {
@@ -127,6 +128,7 @@
 static __u8 ext_read(struct wiimote_ext *ext)
 {
 	ssize_t ret;
+	__u8 buf[24];
 	__u8 rmem[2], wmem;
 	__u8 type = WIIEXT_NONE;
 
@@ -159,6 +161,29 @@
 				 rmem[0], rmem[1]);
 	}
 
+	/* get balance board calibration */
+	if (type == WIIEXT_BALANCE_BOARD) {
+
+		ret = wiimote_cmd_read(ext->wdata, 0xa40024, buf, 24);
+		if (ret != 24)
+			type = WIIEXT_NONE;
+
+		ext->calib[0][0] = ((__u16)buf[ 0]<<8 | (__u16)buf[ 1]);
+		ext->calib[1][0] = ((__u16)buf[ 2]<<8 | (__u16)buf[ 3]);
+		ext->calib[2][0] = ((__u16)buf[ 4]<<8 | (__u16)buf[ 5]);
+		ext->calib[3][0] = ((__u16)buf[ 6]<<8 | (__u16)buf[ 7]);
+
+		ext->calib[0][1] = ((__u16)buf[ 8]<<8 | (__u16)buf[ 9]);
+		ext->calib[1][1] = ((__u16)buf[10]<<8 | (__u16)buf[11]);
+		ext->calib[2][1] = ((__u16)buf[12]<<8 | (__u16)buf[13]);
+		ext->calib[3][1] = ((__u16)buf[14]<<8 | (__u16)buf[15]);
+
+		ext->calib[0][2] = ((__u16)buf[16]<<8 | (__u16)buf[17]);
+		ext->calib[1][2] = ((__u16)buf[18]<<8 | (__u16)buf[19]);
+		ext->calib[2][2] = ((__u16)buf[20]<<8 | (__u16)buf[21]);
+		ext->calib[3][2] = ((__u16)buf[22]<<8 | (__u16)buf[23]);
+	}
+
 	wiimote_cmd_release(ext->wdata);
 
 	return type;
@@ -517,7 +542,9 @@
 
 static void handler_balance_board(struct wiimote_ext *ext, const __u8 *payload)
 {
-	__s16 tr, br, tl, bl;
+	__s16 val[4]; /*tr, br, tl, bl;*/
+	unsigned long tmp;
+	__u8 i;
 
 	/*   Byte |  8  7  6  5  4  3  2  1  |
 	 *   -----+--------------------------+
@@ -540,19 +567,28 @@
 	 * The balance-board is never reported interleaved with motionp.
 	 */
 
-	tr = payload[0] << 8;
-	tr |= payload[1];
-	br = payload[2] << 8;
-	br |= payload[3];
-	tl = payload[4] << 8;
-	tl |= payload[5];
-	bl = payload[6] << 8;
-	bl |= payload[7];
-
-	input_report_abs(ext->input, ABS_HAT0X, tl);
-	input_report_abs(ext->input, ABS_HAT0Y, tr);
-	input_report_abs(ext->input, ABS_HAT1X, bl);
-	input_report_abs(ext->input, ABS_HAT1Y, br);
+	val[0]  = payload[0] << 8;
+	val[0] |= payload[1];
+	val[1]  = payload[2] << 8;
+	val[1] |= payload[3];
+	val[2]  = payload[4] << 8;
+	val[2] |= payload[5];
+	val[3]  = payload[6] << 8;
+	val[3] |= payload[7];
+
+	/* apply calibration data */
+	for( i = 0; i < 4; i++ ) {
+		if (val[i] < ext->calib[i][1])
+			tmp = 1700 * (val[i] - ext->calib[i][0]) / (ext->calib[i][1] - ext->calib[i][0]);
+		else
+			tmp = 1700 * (val[i] - ext->calib[i][1]) / (ext->calib[i][2] - ext->calib[i][1]) + 1700;
+		val[i] = tmp;
+	}
+
+	input_report_abs(ext->input, ABS_HAT0X, val[0]);
+	input_report_abs(ext->input, ABS_HAT0Y, val[1]);
+	input_report_abs(ext->input, ABS_HAT1X, val[2]);
+	input_report_abs(ext->input, ABS_HAT1Y, val[3]);
 
 	input_sync(ext->input);
 }
@@ -707,10 +743,10 @@
 	set_bit(ABS_HAT2Y, ext->input->absbit);
 	set_bit(ABS_HAT3X, ext->input->absbit);
 	set_bit(ABS_HAT3Y, ext->input->absbit);
-	input_set_abs_params(ext->input, ABS_HAT0X, -120, 120, 2, 4);
-	input_set_abs_params(ext->input, ABS_HAT0Y, -120, 120, 2, 4);
-	input_set_abs_params(ext->input, ABS_HAT1X, -30, 30, 1, 1);
-	input_set_abs_params(ext->input, ABS_HAT1Y, -30, 30, 1, 1);
+	input_set_abs_params(ext->input, ABS_HAT0X, -20000, 20000, 2, 4);
+	input_set_abs_params(ext->input, ABS_HAT0Y, -20000, 20000, 2, 4);
+	input_set_abs_params(ext->input, ABS_HAT1X, -20000, 20000, 1, 1);
+	input_set_abs_params(ext->input, ABS_HAT1Y, -20000, 20000, 1, 1);
 	input_set_abs_params(ext->input, ABS_HAT2X, -30, 30, 1, 1);
 	input_set_abs_params(ext->input, ABS_HAT2Y, -30, 30, 1, 1);
 	input_set_abs_params(ext->input, ABS_HAT3X, -30, 30, 1, 1);

Re: Wii Balance Board vs. bluez

[David Herrmann]

Hi Florian

On Thu, Sep 13, 2012 at 2:35 PM, Florian Echtler <floe@butterbrot.org> wrote:
> On 13.09.2012 16:39, David Herrmann wrote:
>>>
>>> Please see the appended patch. You have to apply it to your kernel
>>> tree and recompile the hid-wiimote driver. No other sources are
>>> changed so you don't need to reboot or install the new kernel. Just
>>> install the new hid-wiimote.ko module.
>>>
>>> One of the 5 input devices should then report the wiimote weight
>>> sensor data. (the input device with name "Wii Remote Balance Board").
>>
>> Forgot to attach the patch... Here it is.
>
> Awesome - works as expected, weight sensor data can be read from one of the
> event devices.

Good to hear. I hate writing drivers for devices I don't have...
Thanks for testing!

> I've attached an additional patch on top of yours to also read the
> calibration data (24 bytes at address 0xa40024). Calibration data is applied
> in handler_balance_board, resulting values are in units of 10 grams.
> Although this looks correct to me, I'm not getting any events with my patch
> applied - I suspect some connection to the min/max input values. Do you have
> any ideas what's wrong?

Ah, yeah I forgot to change the min/max values of ABS_HAT**. I will
fix that. The calibration data looks also nice. I have no idea what
went wrong, but you should definitely initialize it to some sane value
and fallback to this if you cannot read the data from the device. I
would also like to split this into two patches. The first one without
calibration and the second one applies the calibration data.

I will try to resend these this afternoon, otherwise, I will not have
time until Sunday afternoon. Sorry.

Thanks for the efforts!
David

Re: Wii Balance Board vs. bluez

[Florian Echtler]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

Hello David,

On 14.09.2012 11:02, David Herrmann wrote:
> On Thu, Sep 13, 2012 at 2:35 PM, Florian Echtler <floe@butterbrot.org> wrote:
>> I've attached an additional patch on top of yours to also read the
>> calibration data (24 bytes at address 0xa40024). Calibration data is applied
>> in handler_balance_board, resulting values are in units of 10 grams.
>> Although this looks correct to me, I'm not getting any events with my patch
>> applied - I suspect some connection to the min/max input values. Do you have
>> any ideas what's wrong?
> Ah, yeah I forgot to change the min/max values of ABS_HAT**. I will
> fix that. The calibration data looks also nice. I have no idea what
> went wrong, but you should definitely initialize it to some sane value
> and fallback to this if you cannot read the data from the device. I
> would also like to split this into two patches. The first one without
> calibration and the second one applies the calibration data.
> I will try to resend these this afternoon, otherwise, I will not have
> time until Sunday afternoon. Sorry.
never mind - I tested my patch again and noticed that the driver wasn't 
able to read all 24 calibration bytes in one go, which was the root 
cause for not getting any data (I am simply disabling the extension when 
not getting proper calibration data).

I fixed this by doing two reads of 12 bytes each instead. I've also 
fixed some signedness issues with the data calculation - I've attached 
the updated version, which I think should now be ready for integration.

Can you submit both patches to the list when you get around to it (and 
have tested it yourself)?

Many thanks!
Florian
-- 
SENT FROM MY DEC VT50 TERMINAL

[-- Attachment #2: balance_calibration_v2.patch --]
[-- Type: text/x-patch, Size: 2742 bytes --]

diff -u a/hid-wiimote-ext.c b/hid-wiimote-ext.c
--- a/hid-wiimote-ext.c	2012-09-13 21:04:01.600494774 +0200
+++ b/hid-wiimote-ext.c	2012-09-15 17:21:57.292848979 +0200
@@ -28,6 +28,7 @@
 	bool mp_plugged;
 	bool motionp;
 	__u8 ext_type;
+	__u16 calib[4][3];
 };
 
 enum wiiext_type {
@@ -127,6 +128,7 @@
 static __u8 ext_read(struct wiimote_ext *ext)
 {
 	ssize_t ret;
+	__u8 buf[24], i, j, offs = 0;
 	__u8 rmem[2], wmem;
 	__u8 type = WIIEXT_NONE;
 
@@ -159,6 +161,28 @@
 				 rmem[0], rmem[1]);
 	}
 
+	/* get balance board calibration */
+	if (type == WIIEXT_BALANCE_BOARD) {
+
+		/* retrieve 24 bytes of calibration data */
+		/* read requests > 16 do not work => read in two batches */
+		ret  = wiimote_cmd_read(ext->wdata, 0xa40024   , buf   , 12);
+		ret += wiimote_cmd_read(ext->wdata, 0xa40024+12, buf+12, 12);
+
+		/* failed to read calibration data => disable balance board */
+		if (ret != 24)
+			type = WIIEXT_NONE;
+
+		for ( i = 0; i < 3; i++ ) {
+			for ( j = 0 ; j < 4 ; j++ ) {
+				ext->calib[j][i] = ((__u16)buf[offs]<<8 | (__u16)buf[offs+1]);
+				offs += 2;
+				/* printk("calib[%d][%d] = %d\n",j,i,ext->calib[j][i]); */
+			}
+		}
+
+	}
+
 	wiimote_cmd_release(ext->wdata);
 
 	return type;
@@ -517,7 +541,8 @@
 
 static void handler_balance_board(struct wiimote_ext *ext, const __u8 *payload)
 {
-	__s16 tr, br, tl, bl;
+	__s32 tmp, val[4]; /* tr, br, tl, bl */
+	__u8 i;
 
 	/*   Byte |  8  7  6  5  4  3  2  1  |
 	 *   -----+--------------------------+
@@ -540,19 +565,24 @@
 	 * The balance-board is never reported interleaved with motionp.
 	 */
 
-	tr = payload[0] << 8;
-	tr |= payload[1];
-	br = payload[2] << 8;
-	br |= payload[3];
-	tl = payload[4] << 8;
-	tl |= payload[5];
-	bl = payload[6] << 8;
-	bl |= payload[7];
-
-	input_report_abs(ext->input, ABS_HAT0X, tl);
-	input_report_abs(ext->input, ABS_HAT0Y, tr);
-	input_report_abs(ext->input, ABS_HAT1X, bl);
-	input_report_abs(ext->input, ABS_HAT1Y, br);
+	val[0] = (__u16)payload[0] << 8 | (__u16)payload[1];
+	val[1] = (__u16)payload[2] << 8 | (__u16)payload[3];
+	val[2] = (__u16)payload[4] << 8 | (__u16)payload[5];
+	val[3] = (__u16)payload[6] << 8 | (__u16)payload[7];
+
+	/* apply calibration data */
+	for ( i = 0; i < 4; i++ ) {
+		if (val[i] < ext->calib[i][1])
+			tmp = (1700 * (__s32)(val[i] - ext->calib[i][0])) / (__s32)(ext->calib[i][1] - ext->calib[i][0]);
+		else
+			tmp = (1700 * (__s32)(val[i] - ext->calib[i][1])) / (__s32)(ext->calib[i][2] - ext->calib[i][1]) + 1700;
+		val[i] = tmp;
+	}
+
+	input_report_abs(ext->input, ABS_HAT0X, val[0]);
+	input_report_abs(ext->input, ABS_HAT0Y, val[1]);
+	input_report_abs(ext->input, ABS_HAT1X, val[2]);
+	input_report_abs(ext->input, ABS_HAT1Y, val[3]);
 
 	input_sync(ext->input);
 }

Re: Wii Balance Board vs. bluez

[David Herrmann]

Hi Florian

On Sat, Sep 15, 2012 at 5:31 PM, Florian Echtler <floe@butterbrot.org> wrote:
> Hello David,
>
>
> On 14.09.2012 11:02, David Herrmann wrote:
>>
>> On Thu, Sep 13, 2012 at 2:35 PM, Florian Echtler <floe@butterbrot.org>
>> wrote:
>>>
>>> I've attached an additional patch on top of yours to also read the
>>> calibration data (24 bytes at address 0xa40024). Calibration data is
>>> applied
>>> in handler_balance_board, resulting values are in units of 10 grams.
>>> Although this looks correct to me, I'm not getting any events with my
>>> patch
>>> applied - I suspect some connection to the min/max input values. Do you
>>> have
>>> any ideas what's wrong?
>>
>> Ah, yeah I forgot to change the min/max values of ABS_HAT**. I will
>> fix that. The calibration data looks also nice. I have no idea what
>> went wrong, but you should definitely initialize it to some sane value
>> and fallback to this if you cannot read the data from the device. I
>> would also like to split this into two patches. The first one without
>> calibration and the second one applies the calibration data.
>> I will try to resend these this afternoon, otherwise, I will not have
>> time until Sunday afternoon. Sorry.
>
> never mind - I tested my patch again and noticed that the driver wasn't able
> to read all 24 calibration bytes in one go, which was the root cause for not
> getting any data (I am simply disabling the extension when not getting
> proper calibration data).
>
> I fixed this by doing two reads of 12 bytes each instead. I've also fixed
> some signedness issues with the data calculation - I've attached the updated
> version, which I think should now be ready for integration.
>
> Can you submit both patches to the list when you get around to it (and have
> tested it yourself)?

Thanks! I have both patches ready for submission. However, could you
actually tell me in what range data is submitted? As I said, I cannot
test these patches. But looking at the code, you get 16bit per value
raw input. You then calculate the per-kg value and multiply it by
17kg. So I guess you fill up the whole 16bit?

Your second patch does not adjust the MIN/MAX values for the ABS_HATXY
values and I am just looking for good values here.

Thanks
David

Re: Wii Balance Board vs. bluez

[David Herrmann]

Hi Florian

On Mon, Sep 17, 2012 at 11:47 AM, David Herrmann
<dh.herrmann@googlemail.com> wrote:
> Thanks! I have both patches ready for submission. However, could you
> actually tell me in what range data is submitted? As I said, I cannot
> test these patches. But looking at the code, you get 16bit per value
> raw input. You then calculate the per-kg value and multiply it by
> 17kg. So I guess you fill up the whole 16bit?
>
> Your second patch does not adjust the MIN/MAX values for the ABS_HATXY
> values and I am just looking for good values here.

I just noticed these values aren't forced by the input core so I've
just sent the patches to the linux-input ML and put you into CC.
Please respond to them with your signed-off-by and tested-by lines as
I noted in the comment below each commit-message.

Thanks a lot for your work here!
If you're working on any userspace programs, I would interested to
hear about it. Also feel free to use github.com/dvdhrm/xwiimote for
easier communications with the kernel driver. Although, this project
is still TODO ;)
David

Re: Wii Balance Board vs. bluez

[Florian Echtler]

Hi David,

On 17.09.2012 11:47, David Herrmann wrote:
> On Sat, Sep 15, 2012 at 5:31 PM, Florian Echtler <floe@butterbrot.org> wrote:
>> never mind - I tested my patch again and noticed that the driver wasn't able
>> to read all 24 calibration bytes in one go, which was the root cause for not
>> getting any data (I am simply disabling the extension when not getting
>> proper calibration data).
> Thanks! I have both patches ready for submission. However, could you
> actually tell me in what range data is submitted? As I said, I cannot
> test these patches. But looking at the code, you get 16bit per value
> raw input. You then calculate the per-kg value and multiply it by
> 17kg. So I guess you fill up the whole 16bit?
> Your second patch does not adjust the MIN/MAX values for the ABS_HATXY
> values and I am just looking for good values here.
OK, I see - the advertised maximum weight for the balance board is 150 
kg. In theory, that would mean that every one of the 4 sensors can take 
up to 150 kg (if a very heavy person is standing on one foot right in 
the corner), which would translate to an absolute maximum value of 
15000. In "unweighted" state, my balance board reports slightly negative 
values for some sensors, so a minimum of perhaps -500 would be appropriate.

Thanks for integrating my patch!

Florian
-- 
SENT FROM MY PDP-11