Skip to contentSkip to conversation

bfusb 1.1 firmware loading and rc-scripts

DISCUSSION Matthias Thomae 2 participants 4 messages Sep 15, 2003 – Sep 17, 2003 1 message not in the archive Bluetooth drivers

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw

Hello Marcel, list,

since upgrading from bfusb 1.0 to 1.1 I have problems creating bluetooth connections at system start form the rc-scripts on a debian/unstable system, such as PAN or CMTP connections.

I think this is because the old bfusb version was returning only when the firmware has finished loading into the dongle (which takes a few seconds), whereas the new version returns immediately and loads the firmware in the background. Is this correct? When putting "sleep 10" in one of the rc scripts, it works as before.

Is there a way to detect when the firmware loading is finished, or would you consider to change back to the old behaviour?

Regards.
Matthias

#2 lore raw

Hallo Matthias,

Quoted 9 lines

since upgrading from bfusb 1.0 to 1.1 I have problems creating bluetooth connections at system start form the rc-scripts on a debian/unstable system, such as PAN or CMTP connections.

I think this is because the old bfusb version was returning only when the firmware has finished loading into the dongle (which takes a few seconds), whereas the new version returns immediately and loads the firmware in the background. Is this correct? When putting "sleep 10" in one of the rc scripts, it works as before.

the firmware loading routine is the same and blocks until the firmware is loading. The only difference is where the firmware file comes from.

Quoted 2 lines

Is there a way to detect when the firmware loading is finished, or would you consider to change back to the old behaviour?

The current driver is working fine and the firmware loading is finished, when the HCI device is created.

Regards

Marcel

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

#3 lore raw

Hi Marcel,

Quoted 7 lines · Marcel Holtmann
Quoted 3 lines

firmware in the background. Is this correct? When putting "sleep 10" in one of the rc scripts, it works as before.

the firmware loading routine is the same and blocks until the firmware is loading. The only difference is where the firmware file comes from.

I see. Then it must be some other change I did which causes the different behaviour...

Quoted 6 lines
Quoted 3 lines

Is there a way to detect when the firmware loading is finished, or would you consider to change back to the old behaviour?

The current driver is working fine and the firmware loading is finished,

I wasn't meaning to imply that the driver didn't work fine, it even works *very* fine for me :)

Quoted 3 lines

when the HCI device is created.

Ok, then the rc-scripts might need to wait until the hci device is up?
Or would you rather handle this through a daemon which has a --persist option like pand? Edd, what do you think?

Regards.
Matthias

#4 lore raw

Hi Matthias,

Quoted 3 lines

Ok, then the rc-scripts might need to wait until the hci device is up? Or would you rather handle this through a daemon which has a --persist option like pand?

if you really need it, what about bluetooth.agent ;)

Regards

Marcel

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users