Warning: Can't synchronize with repository "(default)" (No changeset 96d22ec3fa3ef6de3ea8dc0d7d398adc9aa071cf in the repository). Look in the Trac log for more information.

Ticket #499 (new defect)

Opened 3 years ago

Last modified 3 years ago

Time gap between bluetooth resource request and bluez fully running

Reported by: pespin Owned by: mickey
Priority: major Milestone:
Component: cornucopia/fsodevice Version: milestone5.5
Keywords: resource bluetooth bluez Cc:

Description

Writing a bluetooth manager in C for the openmoko I arrived to this problem: There's a gap of time between the app receiving a response message from frameworkd after requsting Bluetooth resource and bluez actually start running.

I had a function in Bluetooth request callback which starts using bluez and sends a message to get the default adapter. However, it seems that as the function is immediatelly after the bluetooth request, bluez hasn't have time to start operating in dbus. As a consequence, the bluez method I call returns a null pointer to a reply message, and this dbus error:

Error: org.freedesktop.DBus.Error.ServiceUnknown? - The name org.bluez was not provided by any .service files.

According to mickey in irc: <mickey|XmasCold?> ok, i think i know what happens

<mickey|XmasCold?> FSO turns it on

<mickey|XmasCold?> then returns

<mickey|XmasCold?> however

<mickey|XmasCold?> bluetooth is a USB device on the FR

<mickey|XmasCold?> meaning it appears on the bus

<mickey|XmasCold?> gets enumerated

<mickey|XmasCold?> and registered by bluez

<mickey|XmasCold?> only some time after it's powered on

Some solutions I can think of:

  • replymessage from RequestResource?() message should only arrive when bluez is correctly running
  • add a signal to know when it is working?

Change History

comment:1 Changed 3 years ago by pespin

this might be of help when writing a patch for this bug: ​http://live.gnome.org/Vala/DBusClientSamples/Waiting

Note: See TracTickets for help on using tickets.