When bluez restarts (or the tuhi daemon restarts), the values we have
in the bluez device's field ManufacturerData are quite not accurate.
When bluez restarts they are empty, and if the last time we saw the
device was for the pairing process, the device will still be marked
as in the pairing mode.
So we should mark the cold-plug sequence differently from the hot-plug
one, and we should be more confident in the current configuration we
have stored to export the currently known devices over dbus.
Fixes#13
This implements the ListeningStopped signal (especially the EAGAIN if we're
already listening) but does not yet actually trigger the listening on the
device.
There is still no timeout, and no signal gets emitted.
The current way of testing this is:
- call StartListening() on the DBus device
- start discovery on the adapter by some other mean
- press the button on the device -> the sync will happen
- call StopDiscovery()
- press the button on the device -> the sync will *not* happen
If bluez is restarted, the services are not resolved.
If the data has not been connected, the manufacturerData might be
correctly set, but the services are still not resolved, meaning that
we can not start listening on the various GATT characteristics.
Defer the creation of the wacom device object after connect, when
we are sure the services are resolved.
This allows to create the device even if the conditions were not met
while starting up tuhi (if bluez considers the device still in
pairing mode).
This will also allow us to retrieve the button presses from the devices,
as they are triggering a BLE advertisement.
When the uuid changes, it means the device just has been paired.
We should therefore update the paired property or a subsequent connect
to retrieve the data will result in an attempt to pair to the device.
Make the uuid property a GObject.Property so we can listen to it. Notify about
the uuid change at the end of the pairing process, then write that value into
the device's config file.
The previous process had a problem: the device object didn't exist until after
pairing was complete. But to pair we need some user interaction (press button
on device) and thus the ability to send notifications from the device to the
dbus client at the right time. This wasn't possible with the previous
approach.
The new approach:
* renames Start/StopPairing to Start/StopSearch to indicate we're just
searching, not pairing in the manager
* creates a org.freedesktop.tuhi1.Device object when a suitable device is
found. That object is not in Manager.Devices, it's "hidden" unless you know
the object path.
* Sends a PairableDevice signal with the new device's object path
* Requires the client to call Pair() on the device
* If the timeout expires without pairing, the device is removed again
When the device is in pairing mode (blinking blue), the manufacturer
data contains less than 7 fields. We should ignore those devices
as we are not supposed to pull pen data out of them.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Previously we created a new instance on every connected signal. We should
instead create the device once and then just re-start the sync process when
we get the connected data.
bus_own_name is asynchronous, so we first need to send a signal back and then
we can start connecting to the devices. Otherwise we'll have to implement a
queue which would be a lot harder than just waiting.
Peter Hutterer