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
Hi David,
On 17.09.2012 11:47, David Herrmann wrote:
> On Sat, Sep 15, 2012 at 5:31 PM, Florian Echtler <[email protected]> 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
Hi Florian
On Mon, Sep 17, 2012 at 11:47 AM, David Herrmann
<[email protected]> 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
Hi Florian
On Sat, Sep 15, 2012 at 5:31 PM, Florian Echtler <[email protected]> wrote:
> Hello David,
>
>
> On 14.09.2012 11:02, David Herrmann wrote:
>>
>> On Thu, Sep 13, 2012 at 2:35 PM, Florian Echtler <[email protected]>
>> 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
Hello David,
On 14.09.2012 11:02, David Herrmann wrote:
> On Thu, Sep 13, 2012 at 2:35 PM, Florian Echtler <[email protected]> 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
Hi Florian
On Thu, Sep 13, 2012 at 2:35 PM, Florian Echtler <[email protected]> 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
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
On Thu, Sep 13, 2012 at 4:38 PM, David Herrmann
<[email protected]> wrote:
> Hi Florian
>
> On Thu, Sep 13, 2012 at 7:59 AM, Florian Echtler <[email protected]> wrote:
>>
>>
>> David Herrmann <[email protected]> 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.
Hi Florian
On Thu, Sep 13, 2012 at 7:59 AM, Florian Echtler <[email protected]> wrote:
>
>
> David Herrmann <[email protected]> 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
David Herrmann <[email protected]> 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
Hi Florian
On Wed, Sep 12, 2012 at 10:50 PM, Florian Echtler <[email protected]> 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