Basically copied from the device's Listening approach.
While it's possible to have multiple clients searching at the same time it's a
niche case and the effort at fixing the race conditions that come from that is
likely not worth the effort.
Let's add multiple simultaneous clients when we have a real need for it.
TuhDevice.paired is set on every device update (RSSI changes!) and that sends
a GObject.notify() for the property. Filter those, otherwise
we're just spamming dbus with PropertiesChanged notify events even
though nothing has actually changed.
We likely get multiple 'udpated' notifications as the RSSI property changes,
all causing a Connect() on the device and an ugly error message (that we used
to catch and print). Make that error message prettier.
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
If the sender disappear, we should stop listening for incoming events.
We match the Start/StopListening() that way, but if a client forgets
to call StopListening() before leaving and some data are being retrieved,
it's not our problem.
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
We need to be able to selectively enable/disable listening mode per
device, and the Listening property needs to be updated.
The current approach uses a Listening property as a public state, and the
StartListening()/StopListening() calls to start/stop. The ListeningStopped
signal is just there to carry error codes.
The current design only allows for a single client to trigger listening,
anyone else will see -EAGAIN and has to wait for the property to update.
Remember the devices we are pairing and subscribe to the Manager.Devices
property changed notification. If a device moves from just existing to be part
of Manager.Devices it has been successfully paired.
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.
The coordinates are provided from the top-left position, but the sensor
is effectively turned. So on the Spark and the Slate, X goes down, and
Y is reversed and goes left.
If the index is not valid, a python exception was raised, and the dbus
message was left without and answer.
Coincidentally, this matches the documentation
I guess this code was tested with an existing config file only, because
I have the following:
DEBUG: tuhi.config: E0:61:C6:BF:14:4E: adding new config, uuid 8bbc6be4347a
Traceback (most recent call last):
File "./tuhi.py", line 153, in _on_uuid_updated
self.config.new_device(bluez_device.address, wacom_device.uuid)
File "tuhi/tuhi/config.py", line 89, in new_device
config['Device']['Address'] = address
File "/usr/lib64/python3.6/configparser.py", line 959, in __getitem__
raise KeyError(key)
KeyError: 'Device'
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.
Peter Hutterer