wminput blocks bluetooth mouse/kb from connecting

[jackflap]

I've configured wminput to launch in daemon mode on session login. However, whenever I do this, my bluetooth keyboard/mouse take significantly longer to establish a connection when used.

When wminput isn't running in the background, it takes no more than 3 seconds for both the kb and mouse to establish a connection when pressing a key/button. When it is running, it can tak 10+ seconds for each device to establish a connection.

It seems to me that wminput is locking up my bluetooth dongle in some way, making it much more difficult for other devices to connect.

Tested in Ubuntu 7.10 and 8.10.

[nickishappy]

Bluetooth 1.2 can transmit at up to 1 Mbit/s, while bluetooth 2.0 adapters can transmit at up to 3 Mbit/s (theoretical.) I would be interested in how much of this bandwidth is used by wminput and the wiimote in general. I have experienced similar behaviors with my other bluetooth devices having a noticeable slowdown when I'm running wminput.

I will see if there is a way to test bluetooth bandwidth later this week. I would like to know how much bandwidth the wiimote takes and if they have a 1.2 or 2.0 bluetooth radio.

I think low bandwidth is what might be causing the issue, making the connection with your mouse and keyboard take longer. For now I recommend having wminput start after your keyboard and mouse are connected. If you have a Bluetooth 1.2 adapter (or earlier) upgrading to an adapter that is 2.0 compliant might help as well.

I'll do some research and testing and post my findings here.

[jackflap]

That'd be a great stat to see. Let me know what you find out.

If you need any help with testing, let me know.

Also, am definitely using 2.0 bluetooth adapter. Problem with starting wminput after kb/mouse connects is that once they sleep, it just happens again. Might have to find a way to stop them from sleeping (I think it's in hidd), but it's pretty harsh on the batteries.

[jackflap]

I've been reading up on this, and the problem lies with the function wminput uses to scan for nearby active bluetooth devices.

wminput in daemon mode is based around calling the bluez function hci_inquiry() with a timeout of 2 seconds repeatedly until a device is found. It turns out that hci_inquiry() is a device-locking function, and locks up the bluetooth adapter while scanning which is preventing other devices from connecting.

See  http://osdir.com/ml/bluez.user/2003-10/msg00200.html for more info.

My current solution is to reduce the timeout to 1 second, and stick a 3-second sleep between each hci_inquiry() call.

My bluetooth kb/mouse seem to connect perfectly normally now, no noticeable delay any more (when before, they would occasionally never re-connect altogether until wminput was killed). Also, it doesn't seem to affect the time it takes for my wiimote to connect after pressing 1+2, so I can't see any problems with the solution.

I've attached a patch containing the fix if you're happy to apply it.

[dsmith]

I'd like to apply your concept, but down in the libcwiid is the wrong place to do it - if the problem is in the wminput daemon loop, we should wait there. Trouble is, I can't find where hci_inquiry would be called repeatedly from there - can you point me to a line number?

[jackflap]

I know there's a main loop in wminput/main.c, but the fix can't be applied there how bluetooth.c is currently written.

If wminput is run with the wait_forever flag, the first time it calls cwiid_find_wiimote, it goes into a perpetual loop and waits indefinitely for a wiimote to connect. See below where this happens (bluetooth.c, line 179):

while ((bdinfo_count = cwiid_get_bdinfo_array(-1, 2, 1, &bdinfo, 0))

== 0);

While it's looping indefinitely, it blocks the bluetooth adapter from doing anything else. This is where my last patch makes a change.

Removing the cwiid_get_bdinfo_array() call from the while() loop and calling it once, I think would cause it to fall back to the main loop in main.c, and we could put the sleep there. I could write&test patches to do this if you would like.

However, there's another issue. hci_inquiry() is still blocking, so putting a sleep in between every call doesn't completely solve the problem. For instance, streaming music over a2dp will cut out for 1 second every time hci_inquiry() is called (every 3 seconds if my patch is applied). Ideally, a purely non-blocking hci_inquiry() needs to be written from scratch.

I've been looking around on how to do this, and emailed linux-bluetooth, and the only way I think I can manage it, is to use the d-bus api. I think it's too far beyond me to do it with the lower-level bluetooth libs. Would you be interested in accepting a patch for a new hci_inquiry() function built using the d-bus api (i.e. dbus.h, dbus-glib.h, glib-object.h) or should I stick with the sleep?

Let me know.

[nickishappy]

if you can fix the problem then give it a shot. If you add dependencies then make sure you do adequate testing before submitting a patch to make it easier on dsmith. I don't have time right now to work on this.

If you can make it work better not using sleep give it a shot. Just my 2 cents.

[bascorp]

 телефоны цена