Wiimote discover problem

I'm running Suse 10.2 on an AMD64 (bluez-libs 3.7-14.1-x86-64) cwiid is cwiid-0.5.03

I have the symptoms of this problem:

$ wmdemo/wmdemo 
Put Wiimote in discoverable mode now (press 1+2)...
0:Error opening control channel
Unable to connect to wiimote

If I run wmgui, I get the same error. If I supply the bdaddr on the command line, it works. Perhaps interesting is that if I disconnect in wmgui once it has connected and then reconnect from the menu, it works.

Other info:

$ lswm -al
Put Bluetooth devices in discoverable mode now...
00:1A:E9:3C:C7:1E 0x002504 Nintendo RVL-CNT-01

I'll be happy to do whatever I can to help resolve this issue.

Cheers, Dave

It appears what is happening in at least some of the problem machines is that libcwiid sends a name request to the potential Wiimote devices (as determined by their Bluetooth device class), and that the baseband connection created to handle the name request is hanging around for awhile, blocking any other connection attempts.

Marcel's (the BlueZ guy) suggestion was to increase the timeout on the name request. I don't really understand why that would help, but then I don't care to understand BlueZ internals right now, so I'll take his word for it. This value has been doubled (to 10 seconds) in /branches/dev. If you're interested in helping resolve this, I'll be glad to work with you on it - just check out the code and let me know how it works, and we'll go from there.

Other solution possibilities include eliminating the name check (How many other devices share the Wiimote's bluetooth class?), and retrying the connection. These should be implemented as flags and options rather than default behaviors.

Replying to dsmith:

I'have try the dev branch but nothing is changed here: same problem same symptoms.

You may try playing with the timeout parameter to hci_remote_name (libcwiid/bluetooth.c, line 126). Try higher and lower values - maybe as low as 100, up to 100000. I don't really understand how larger values could affect it, as the whole search and connection process takes place in less than 10 seconds (the current value), but it's worth a try.

I tried playing with the timeout a little, also without result. Looking at the code, I decided to try a sledgehammer, so in wiimote/connect.c I added a delay:

        /* If BDADDR_ANY is given, find available wiimote */
        if (bacmp(bdaddr, BDADDR_ANY) == 0) {
                if (wiimote_find_wiimote(bdaddr, 2)) {
                        goto ERR_HND;
                }
sleep(1);
        }

That fixes it :)

I'm guessing that things take some time to settle down after hci_close_dev(sock) is called in wiimote/bluetooth.c but really I've no idea what's going on

HTH, Dave

This solution do the trick!!! It worked also for me.

It is a sledgehammer solution, as you put it, but as long as this problem has been around, I'll take whatever works. I'll commit it, hopefully tonight.

Thanks!

done r126

I'm going to leave the ticket open in case a better fix comes along, although I imagine the real fix is a bluez patch.

Mine has been working almost flawlessly, up until about a few mins ago. I have been pretty much coding solid for a day or two, and if the Socket connect error (control channel) came up ( which it did once or twice ) i would just unplug and replug my bluetooth adapter. But now it has stopped working completely, i get that error no matter what. I even went into connect.c, added more of a delay, and still nothing. Really sad. Btw, congrats, I found cwiid had been added to the openSuse repositories, i am very glad about this :D

This is odd.. My wmgui is working fine, but my app is failing to connect.

printf("Connecting...\n");
char reset_bdaddr = 0;

if (bacmp(&m_bdaddr, BDADDR_ANY) == 0) 
{
  reset_bdaddr = 1;
}
if ((m_wiiMote = cwiid_open(&m_bdaddr, CWIID_FLAG_MESG_IFC)) == NULL) 
{
  printf("Unable to connect\n");
}
else if ( cwiid_set_mesg_callback( m_wiiMote, &CallBack ) ) 
{
  printf("Error setting callback\n");
  if (cwiid_close(m_wiiMote)) 
  {
    // Do Nothing
  }
  m_wiiMote = NULL;
}

It fails in cwiid_open() If i were to pass in an address with m_bdaddr, would that help? Let me check

:DG

I added in the following line

m_bdaddr = *BDADDR_ANY;

after

if (bacmp(&m_bdaddr, BDADDR_ANY) == 0) 
{
  reset_bdaddr = 1;
}

and its fine. I must have stupidly deleted it somehow. Altho I'm certain it didn't seem to need that before. Oh well, my bad

:DG

I think this is because hci_read() fails in retreiving the friendly device name [this happens on the Nokia N800/N810 too under OS2008 - not sure if it's a bug in BlueZ].

I've used DBus methods to successfully query friendly names.