David Herrmann wrote:
> The Nintendo Wii Remote requires the destination bluetooth address
> as pincode.
according to my my tests they require the source address, ie the host
adapter's address
> + /* Nintendo Wii Remote uses destination address as PIN */
better to document in that comment if it works when pressing the red
button or the 1+2 buttons
I tested your 3 patches against bluez git 4.91-32-gd7f412e and
gnome-bluetooth 2.32 but they didn't work for me for 2 reasons:
1) can't get vid/pid so when the remote is unknown the
read_device_id() call in your code fails to get vid/pid and the
specific pin is never tried; the same happens after a failed pairing
when the /var/lib/bluetooth/*/did file contains a line this:
00:1F:C5:25:36:87 FFFF 0000 0000 0000
2) the source vs destination address I mentioned above
It works for me if I manually edit that line with the values read from
another wiimote's line:
00:1F:C5:25:36:87 0002 057E 0306 0600
and if I change dba to sba here
> memcpy(pinbuf, dba, 6);
how can I help you to debug these issues?
BTW pairing also works when I use the test code mentioned in
https://bugzilla.gnome.org/show_bug.cgi?id=603845#c6
--
Daniele Forsi
On Wed, 2011-04-06 at 19:55 +0200, David Herrmann wrote:
<snip>
> Exactly.
>
> I prefer my solution with dba over sba because it allows to pair the wiimote
> without opening the backside. The only issue left with the patches is the
> VID/PID thing. It works perfectly for me when I delete the device with
> gnome-bluetooth and add the wiimote as new device.
gnome-bluetooth just calls RemoveDevice() which won't remove cached SDP
records, resolved name, etc. for the device. Best open
up /var/lib/bluetooth files with a text editor, and remove everything
related to your Wiimote for testing.
(or you can just nuke the directory if you don't care about pairing your
other devices again).
> It would be interesting to know from a bluez dev or gnome-bluetooth dev whether
> the SDP records are always retrieved before trying to connect to a remote
> device or whether we need to do this manually.
The ordering of this is done by bluetoothd, and I'm pretty certain that
the SDP records are only updated *after* pairing, as some devices might
refuse to answer SDP requests from unpaired devices.
But at that point we should already have a name for it cached (at least
with gnome-bluetooth, which waits for the name to be resolved to allow
you to go through the next steps).
On Wed, Apr 6, 2011 at 4:31 PM, Bastien Nocera <[email protected]> wrote:
> On Wed, 2011-04-06 at 16:05 +0200, Daniele Forsi wrote:
>> 2011/4/6 David Herrmann:
>>
>> > Please try both methods: sync button and 1+2 buttons and report which
>> > method works
>> > with which PIN. As I mentioned above all my Wiimotes work with source-addr plus
>> > red-sync-button and dest-addr plus 1+2 buttons.
>>
>> now I understand, you're right, such explaination would be useful as a
>> comment in the code even if only one method is implemented
>> I can confirm that your code works unmodified for me too if I press
>> 1+2 (after I manually fix the issue I still have with vid/pid), and it
>> also works after modifying it to use source-addr and pressing the sync
>> button
>>
>> > If there is a valid PnP record maybe some bluez Dev could elaborate whether
>> > VID/PID values are guaranteed to be available when pairing is started.
>>
>> I have two original remotes from December 2008 and different one from
>> December 2010 and their SDP records are identical:
>>
>> Service RecHandle: 0x0
>> Service Class ID List:
>> ? "SDP Server" (0x1000)
>> Protocol Descriptor List:
>> ? "L2CAP" (0x0100)
>> ? ? PSM: 1
>> ? "SDP" (0x0001)
>> Language Base Attr List:
>> ? code_ISO639: 0x656e
>> ? encoding: ? ?0x6a
>> ? base_offset: 0x100
>> Profile Descriptor List:
>> ? "" (0x0100)
>> ? ? Version: 0x0100
>>
>> Service Name: Nintendo RVL-CNT-01
>> Service Description: Nintendo RVL-CNT-01
>> Service Provider: Nintendo
>> Service RecHandle: 0x10000
>> Service Class ID List:
>> ? "Human Interface Device" (0x1124)
>> Protocol Descriptor List:
>> ? "L2CAP" (0x0100)
>> ? ? PSM: 17
>> ? "HIDP" (0x0011)
>> Language Base Attr List:
>> ? code_ISO639: 0x656e
>> ? encoding: ? ?0x6a
>> ? base_offset: 0x100
>> Profile Descriptor List:
>> ? "Human Interface Device" (0x1124)
>> ? ? Version: 0x0100
>>
>> Service RecHandle: 0x10001
>> Service Class ID List:
>> ? "PnP Information" (0x1200)
>> Protocol Descriptor List:
>> ? "L2CAP" (0x0100)
>> ? ? PSM: 1
>> ? "SDP" (0x0001)
>> Profile Descriptor List:
>> ? "PnP Information" (0x1200)
>> ? ? Version: 0x0100
>>
>> > I couldn't figure out when autoreconnection is established, reliably. Pairing
>> > the wiimote works sometimes, but not always and I didn't figure out how to
>> > reset the internal cache of reconnection addresses.
>>
>> if you have dangerous ideas I'm willing to sacrifice for the good of
>> science :-) my remote that doesn't work well
>>
>> > If this works for you, could you run the example code at:
>> > http://goo.gl/axeqd
>> > on the new /dev/hidrawX device which is created for the wiimote?
>>
>> it kind of works, but it seems I'm running an older kernel
>> (2.6.35-28-generic #49-Ubuntu):
>> $ sudo ./hid-example /dev/hidraw0
>> Report Descriptor Size: 218
>> Report Descriptor:
>> 5 1 9 5 a1 1 85 10 15 0 26 ff 0 75 8 95 1 6 0 ff 9 1 91 0 85 11 95 1 9
>> 1 91 0 85 12 95 2 9 1 91 0 85 13 95 1 9 1 91 0 85 14 95 1 9 1 91 0 85
>> 15 95 1 9 1 91 0 85 16 95 15 9 1 91 0 85 17 95 6 9 1 91 0 85 18 95 15
>> 9 1 91 0 85 19 95 1 9 1 91 0 85 1a 95 1 9 1 91 0 85 20 95 6 9 1 81 0
>> 85 21 95 15 9 1 81 0 85 22 95 4 9 1 81 0 85 30 95 2 9 1 81 0 85 31 95
>> 5 9 1 81 0 85 32 95 a 9 1 81 0 85 33 95 11 9 1 81 0 85 34 95 15 9 1 81
>> 0 85 35 95 15 9 1 81 0 85 36 95 15 9 1 81 0 85 37 95 15 9 1 81 0 85 3d
>> 95 15 9 1 81 0 85 3e 95 15 9 1 81 0 85 3f 95 15 9 1 81 0 c0 0
>>
>> Raw Name: Nintendo RVL-CNT-01
>> Raw Phys: 00:1F:81:00:01:00
>> Raw Info:
>> ? ? ? bustype: 5 (Bluetooth)
>> ? ? ? vendor: 0x057e
>> ? ? ? product: 0x0306
>> HIDIOCSFEATURE: Invalid argument
>> HIDIOCGFEATURE: Invalid argument
>> write() wrote 2 bytes
>> read: Resource temporarily unavailable
>>
>> > If you have ideas how to support both, sba and dba via some new DBUS
>> > interface, I would be glad to hear about it.
>>
>> using a binary pin seems to solve this problem and the pin could be
>> constructed by the agent based on user choice (and the agent can use
>> the binary pin interface also for plain strings)
>> I understand that constructing the pin in bluez would make it
>> available to all agents but then how do we ask the user for which
>> method to use?
>>
>> you know better than me, but supporting dba doesn't seem a strict
>> requirement to me because pairing with 1+2 already worked for me with
>> gnome-bluetooth 2.32 and bluez-4.69; the config file has this
>> explaination:
>
> The whole point of this is of actually pairing the Wiimote so that when
> turned on, the Wiimote connects to the computer. If you need to press
> any buttons other than the power one, then it's not working.
Exactly.
I prefer my solution with dba over sba because it allows to pair the wiimote
without opening the backside. The only issue left with the patches is the
VID/PID thing. It works perfectly for me when I delete the device with
gnome-bluetooth and add the wiimote as new device.
It would be interesting to know from a bluez dev or gnome-bluetooth dev whether
the SDP records are always retrieved before trying to connect to a remote
device or whether we need to do this manually.
On Wed, 2011-04-06 at 16:05 +0200, Daniele Forsi wrote:
> 2011/4/6 David Herrmann:
>
> > Please try both methods: sync button and 1+2 buttons and report which
> > method works
> > with which PIN. As I mentioned above all my Wiimotes work with source-addr plus
> > red-sync-button and dest-addr plus 1+2 buttons.
>
> now I understand, you're right, such explaination would be useful as a
> comment in the code even if only one method is implemented
> I can confirm that your code works unmodified for me too if I press
> 1+2 (after I manually fix the issue I still have with vid/pid), and it
> also works after modifying it to use source-addr and pressing the sync
> button
>
> > If there is a valid PnP record maybe some bluez Dev could elaborate whether
> > VID/PID values are guaranteed to be available when pairing is started.
>
> I have two original remotes from December 2008 and different one from
> December 2010 and their SDP records are identical:
>
> Service RecHandle: 0x0
> Service Class ID List:
> "SDP Server" (0x1000)
> Protocol Descriptor List:
> "L2CAP" (0x0100)
> PSM: 1
> "SDP" (0x0001)
> Language Base Attr List:
> code_ISO639: 0x656e
> encoding: 0x6a
> base_offset: 0x100
> Profile Descriptor List:
> "" (0x0100)
> Version: 0x0100
>
> Service Name: Nintendo RVL-CNT-01
> Service Description: Nintendo RVL-CNT-01
> Service Provider: Nintendo
> Service RecHandle: 0x10000
> Service Class ID List:
> "Human Interface Device" (0x1124)
> Protocol Descriptor List:
> "L2CAP" (0x0100)
> PSM: 17
> "HIDP" (0x0011)
> Language Base Attr List:
> code_ISO639: 0x656e
> encoding: 0x6a
> base_offset: 0x100
> Profile Descriptor List:
> "Human Interface Device" (0x1124)
> Version: 0x0100
>
> Service RecHandle: 0x10001
> Service Class ID List:
> "PnP Information" (0x1200)
> Protocol Descriptor List:
> "L2CAP" (0x0100)
> PSM: 1
> "SDP" (0x0001)
> Profile Descriptor List:
> "PnP Information" (0x1200)
> Version: 0x0100
>
> > I couldn't figure out when autoreconnection is established, reliably. Pairing
> > the wiimote works sometimes, but not always and I didn't figure out how to
> > reset the internal cache of reconnection addresses.
>
> if you have dangerous ideas I'm willing to sacrifice for the good of
> science :-) my remote that doesn't work well
>
> > If this works for you, could you run the example code at:
> > http://goo.gl/axeqd
> > on the new /dev/hidrawX device which is created for the wiimote?
>
> it kind of works, but it seems I'm running an older kernel
> (2.6.35-28-generic #49-Ubuntu):
> $ sudo ./hid-example /dev/hidraw0
> Report Descriptor Size: 218
> Report Descriptor:
> 5 1 9 5 a1 1 85 10 15 0 26 ff 0 75 8 95 1 6 0 ff 9 1 91 0 85 11 95 1 9
> 1 91 0 85 12 95 2 9 1 91 0 85 13 95 1 9 1 91 0 85 14 95 1 9 1 91 0 85
> 15 95 1 9 1 91 0 85 16 95 15 9 1 91 0 85 17 95 6 9 1 91 0 85 18 95 15
> 9 1 91 0 85 19 95 1 9 1 91 0 85 1a 95 1 9 1 91 0 85 20 95 6 9 1 81 0
> 85 21 95 15 9 1 81 0 85 22 95 4 9 1 81 0 85 30 95 2 9 1 81 0 85 31 95
> 5 9 1 81 0 85 32 95 a 9 1 81 0 85 33 95 11 9 1 81 0 85 34 95 15 9 1 81
> 0 85 35 95 15 9 1 81 0 85 36 95 15 9 1 81 0 85 37 95 15 9 1 81 0 85 3d
> 95 15 9 1 81 0 85 3e 95 15 9 1 81 0 85 3f 95 15 9 1 81 0 c0 0
>
> Raw Name: Nintendo RVL-CNT-01
> Raw Phys: 00:1F:81:00:01:00
> Raw Info:
> bustype: 5 (Bluetooth)
> vendor: 0x057e
> product: 0x0306
> HIDIOCSFEATURE: Invalid argument
> HIDIOCGFEATURE: Invalid argument
> write() wrote 2 bytes
> read: Resource temporarily unavailable
>
> > If you have ideas how to support both, sba and dba via some new DBUS
> > interface, I would be glad to hear about it.
>
> using a binary pin seems to solve this problem and the pin could be
> constructed by the agent based on user choice (and the agent can use
> the binary pin interface also for plain strings)
> I understand that constructing the pin in bluez would make it
> available to all agents but then how do we ask the user for which
> method to use?
>
> you know better than me, but supporting dba doesn't seem a strict
> requirement to me because pairing with 1+2 already worked for me with
> gnome-bluetooth 2.32 and bluez-4.69; the config file has this
> explaination:
The whole point of this is of actually pairing the Wiimote so that when
turned on, the Wiimote connects to the computer. If you need to press
any buttons other than the power one, then it's not working.
> The special NULL pin means that the devices will not be paired, but
> connected to and marked as trusted. This is for devices such as mice
> and joypads where there is no encryption
> I don't understand the details but this means that CreateDevice is
> used instead of CreatePairedDevice
The special NULL means that you would have needed to make the Wiimote
discoverable (through pressing 1/2) before it was usable.
2011/4/6 David Herrmann:
> Please try both methods: sync button and 1+2 buttons and report which
> method works
> with which PIN. As I mentioned above all my Wiimotes work with source-addr plus
> red-sync-button and dest-addr plus 1+2 buttons.
now I understand, you're right, such explaination would be useful as a
comment in the code even if only one method is implemented
I can confirm that your code works unmodified for me too if I press
1+2 (after I manually fix the issue I still have with vid/pid), and it
also works after modifying it to use source-addr and pressing the sync
button
> If there is a valid PnP record maybe some bluez Dev could elaborate whether
> VID/PID values are guaranteed to be available when pairing is started.
I have two original remotes from December 2008 and different one from
December 2010 and their SDP records are identical:
Service RecHandle: 0x0
Service Class ID List:
"SDP Server" (0x1000)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 1
"SDP" (0x0001)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"" (0x0100)
Version: 0x0100
Service Name: Nintendo RVL-CNT-01
Service Description: Nintendo RVL-CNT-01
Service Provider: Nintendo
Service RecHandle: 0x10000
Service Class ID List:
"Human Interface Device" (0x1124)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 17
"HIDP" (0x0011)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Human Interface Device" (0x1124)
Version: 0x0100
Service RecHandle: 0x10001
Service Class ID List:
"PnP Information" (0x1200)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 1
"SDP" (0x0001)
Profile Descriptor List:
"PnP Information" (0x1200)
Version: 0x0100
> I couldn't figure out when autoreconnection is established, reliably. Pairing
> the wiimote works sometimes, but not always and I didn't figure out how to
> reset the internal cache of reconnection addresses.
if you have dangerous ideas I'm willing to sacrifice for the good of
science :-) my remote that doesn't work well
> If this works for you, could you run the example code at:
> http://goo.gl/axeqd
> on the new /dev/hidrawX device which is created for the wiimote?
it kind of works, but it seems I'm running an older kernel
(2.6.35-28-generic #49-Ubuntu):
$ sudo ./hid-example /dev/hidraw0
Report Descriptor Size: 218
Report Descriptor:
5 1 9 5 a1 1 85 10 15 0 26 ff 0 75 8 95 1 6 0 ff 9 1 91 0 85 11 95 1 9
1 91 0 85 12 95 2 9 1 91 0 85 13 95 1 9 1 91 0 85 14 95 1 9 1 91 0 85
15 95 1 9 1 91 0 85 16 95 15 9 1 91 0 85 17 95 6 9 1 91 0 85 18 95 15
9 1 91 0 85 19 95 1 9 1 91 0 85 1a 95 1 9 1 91 0 85 20 95 6 9 1 81 0
85 21 95 15 9 1 81 0 85 22 95 4 9 1 81 0 85 30 95 2 9 1 81 0 85 31 95
5 9 1 81 0 85 32 95 a 9 1 81 0 85 33 95 11 9 1 81 0 85 34 95 15 9 1 81
0 85 35 95 15 9 1 81 0 85 36 95 15 9 1 81 0 85 37 95 15 9 1 81 0 85 3d
95 15 9 1 81 0 85 3e 95 15 9 1 81 0 85 3f 95 15 9 1 81 0 c0 0
Raw Name: Nintendo RVL-CNT-01
Raw Phys: 00:1F:81:00:01:00
Raw Info:
bustype: 5 (Bluetooth)
vendor: 0x057e
product: 0x0306
HIDIOCSFEATURE: Invalid argument
HIDIOCGFEATURE: Invalid argument
write() wrote 2 bytes
read: Resource temporarily unavailable
> If you have ideas how to support both, sba and dba via some new DBUS
> interface, I would be glad to hear about it.
using a binary pin seems to solve this problem and the pin could be
constructed by the agent based on user choice (and the agent can use
the binary pin interface also for plain strings)
I understand that constructing the pin in bluez would make it
available to all agents but then how do we ask the user for which
method to use?
you know better than me, but supporting dba doesn't seem a strict
requirement to me because pairing with 1+2 already worked for me with
gnome-bluetooth 2.32 and bluez-4.69; the config file has this
explaination:
The special NULL pin means that the devices will not be paired, but
connected to and marked as trusted. This is for devices such as mice
and joypads where there is no encryption
I don't understand the details but this means that CreateDevice is
used instead of CreatePairedDevice
--
Daniele Forsi
On Wed, Apr 6, 2011 at 12:04 PM, Daniele Forsi <[email protected]> wrote:
>> The Nintendo Wii Remote requires the destination bluetooth address
>> as pincode.
>
> according to my my tests they require the source address, ie the host
> adapter's address
>
>> + ? ? ? ? ? ? /* Nintendo Wii Remote uses destination address as PIN */
>
> better to document in that comment if it works when pressing the red
> button or the 1+2 buttons
Pressing 1+2 buttons requires the destination address, pressing the sync
button requires the source address. Since the 1+2 buttons technique is the
more easy way I decided to implement this way first, however, the bluez
daemon needs input from the user-agent to decide which method to use finally.
The Wii decides which PIN to use depending whether the red-sync button on the
Wii (yes, on the wii, not the wiimote) or the "connection" button in
the Wii-menu is used.
The latter one uses destination address, the first one source address.
I couldn't figure out when autoreconnection is established, reliably. Pairing
the wiimote works sometimes, but not always and I didn't figure out how to
reset the internal cache of reconnection addresses. My wiimote also saves up
to 3 addresses which it can reconnect to in an unreliable way and so I sometimes
end up with my wiimote starting the Wii instead of reconnecing to my
PC. However,
this issue may be solved later.
>
> I tested your 3 patches against bluez git 4.91-32-gd7f412e and
> gnome-bluetooth 2.32 but they didn't work for me for 2 reasons:
> 1) can't get vid/pid so when the remote is unknown the
> read_device_id() call in your code fails to get vid/pid and the
> specific pin is never tried; the same happens after a failed pairing
> when the /var/lib/bluetooth/*/did file contains a line this:
> 00:1F:C5:25:36:87 FFFF 0000 0000 0000
All my Wiimotes have a PnP SDP record which is fetched by the SDP code
inside bluez so VID/PID should be available. Could you test using
sdptool whether there is a valid PnP record in your wiimote? If there is
no PnP record with VID/PID information it would be useful to know how
old your wiimote is. I have 3 different wiimotes, one about 2 years old,
one 1 year old and one new WiimotePlus which is about 1/2 year old and
all of them have the same PnP record so I assumed all wiimotes have this
PnP record.
If there is a valid PnP record maybe some bluez Dev could elaborate whether
VID/PID values are guaranteed to be available when pairing is started. All
my tests worked and there was always a valid VID/PID when pairing was done.
> 2) the source vs destination address I mentioned above
Please try both methods: sync button and 1+2 buttons and report which
method works
with which PIN. As I mentioned above all my Wiimotes work with source-addr plus
red-sync-button and dest-addr plus 1+2 buttons.
>
> It works for me if I manually edit that line with the values read from
> another wiimote's line:
> 00:1F:C5:25:36:87 0002 057E 0306 0600
> and if I change dba to sba here
>> ? ? ? ? ? ? ? ? ? ? ? memcpy(pinbuf, dba, 6);
>
> how can I help you to debug these issues?
>
> BTW pairing also works when I use the test code mentioned in
> https://bugzilla.gnome.org/show_bug.cgi?id=603845#c6
This patch simply forces the source address as PIN for every device. If this
works for you, could you run the example code at:
http://goo.gl/axeqd
on the new /dev/hidrawX device which is created for the wiimote? HIDRAW support
must be enabled in the kernel of course.
This should give you VID/PID information and the HID descriptor table.
Git-url for this is: http://goo.gl/odnwd
> --
> Daniele Forsi
Thanks for helping. I think if we could figure out how to reliably get
the VID/PID
values we can change the PIN to sda to support all devices. Patch 1
and 2 of my series
might be applied anyway to allow binary pins. This would also allow to
extend the
DBUS agent interface.
If you have ideas how to support both, sba and dba via some new DBUS
interface, I would
be glad to hear about it.
David