Commit Graph

581 Commits

Author SHA1 Message Date
Peter Hutterer 59ab21a5e8 kete: add the 'listen' command
Doesn't do anything but start/stop listening but hey, that's what it says on
the box
2018-01-23 14:22:33 +10:00
Benjamin Tissoires a51663342f dbus: keep track of the senders of the StartListening() method
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.
2018-01-23 14:22:33 +10:00
Benjamin Tissoires e3fff4015a implement a basic Start/StopListening
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
2018-01-23 14:22:33 +10:00
Benjamin Tissoires 0e6d82dd14 README: document the new listening process
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.
2018-01-23 14:22:33 +10:00
Peter Hutterer 010c651d6f dbus: add a __repr__ for the TuhiDBusDevice
And remove a now obsolete debugging statement, this was just put there to
debug the PropertyChanged code
2018-01-23 14:22:33 +10:00
Peter Hutterer e5d3da5590 kete: default to 'list' if we don't have a subcommand 2018-01-23 09:05:17 +10:00
Peter Hutterer fc81356d25 kete: don't return self from __exit__
This supresses any exceptions we get during the handling. Just continue and
let the stack deal with the exception (if any)
2018-01-23 09:03:10 +10:00
Peter Hutterer e974ca17cc kete: use a Devices property changed as indicator for success
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.
2018-01-22 17:14:37 +10:00
Peter Hutterer d3192dc070 dbus: Send out a PropertyChanged event when a device is paired
Just updating the array isn't enough, we need to bubble up the property
change and then manually send the PropertyChanged event
2018-01-22 17:14:37 +10:00
Peter Hutterer daac6e6d96 dbus: drop the "paired" flag from create_device
We can get this from the device now
2018-01-22 17:14:37 +10:00
Peter Hutterer ec87503209 tuhi: keep a reference to the Tuhi dbus device in the TuhiDevice
Because we need to notify it when we have paired so the daemon can update
2018-01-22 17:14:37 +10:00
Peter Hutterer 645c7577fe config: use uppercase 'UUID' in debug message 2018-01-22 17:14:37 +10:00
Peter Hutterer e21f04bb8b Add tuhi-kete as a CLI interface to tuhi 2018-01-22 17:14:33 +10:00
Peter Hutterer a2fd3cd8d1 dbus: on StartSearch(), emit PairableDevice signals for already known devices
If we created a device before StartSearch was called, we need to manually
send the signal to make sure the client sees it.
2018-01-22 15:25:34 +10:00
Peter Hutterer 0b7f756ba0 dbus: add the device's Address to the introspection XML
Code was already there, but the XML was missing the address
2018-01-22 15:24:56 +10:00
Benjamin Tissoires 56dc8741dc defer the creation of the wacom device object
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.
2018-01-22 15:24:56 +10:00
Benjamin Tissoires 3e5ef6c939 ble: remove the duplicate events filter
So we get more chances of capturing the advertisement from the device
if it is rather static.
2018-01-22 15:24:56 +10:00
Benjamin Tissoires 380518d0c7 ble: keep track of Start/StopDiscovery
discovery-stopped may call stop_discovery() if there
is no client listening, resulting in an infinite loop
2018-01-22 15:24:26 +10:00
Benjamin Tissoires f4e35df67d tuhi: merge _on_bluez_device_added with _on_bluez_device_updated
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.
2018-01-22 15:23:05 +10:00
Benjamin Tissoires 36b9b1cbb7 README: add note about the sensor orientation
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.
2018-01-20 12:37:50 +10:00
Benjamin Tissoires f6d09d7086 dbus: fix timeout error if the index is invalid
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
2018-01-20 12:37:50 +10:00
Benjamin Tissoires 1b73de68b2 config: make sure we create the config file properly
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'
2018-01-20 12:37:50 +10:00
Benjamin Tissoires fda5d7f132 update the paired property on uuid change
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.
2018-01-20 12:37:50 +10:00
Benjamin Tissoires c79ffbd12c do not create more than one DBus object per bluetooth device
When the device is in pairing mode, it will send several properties
updates, and tuhi will attempt to create a second DBus object.

This is not good.
2018-01-20 12:37:50 +10:00
Peter Hutterer 4ee07a18b6 Hook up UUID changes to be written in the config file
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.
2018-01-19 16:17:44 +10:00
Peter Hutterer 0deb5f8e49 Add an extra log message when it's time to call Pair()
Otherwise it looks like we just sit here and do nothing
2018-01-19 16:17:44 +10:00
Peter Hutterer 8e50421f2e wacom: generate the uuid on pairing
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2018-01-19 16:17:44 +10:00
Peter Hutterer 76449bf608 config: add a basic storage backend
$XDG_DATA_HOME/tuhi/<mac address>/settings.ini

And that file contains a [Device] section with two entries, address and uuid.
2018-01-19 16:17:44 +10:00
Peter Hutterer 5f9766cb71 ble: catch and ignore the InProgress error when we're already listening 2018-01-19 13:45:32 +10:00
Peter Hutterer d4405cc1ef Hook up a ButtonPressRequired signal
When the nordic communication requires us to notify the user to press the
button, emit a signal and pass that up.
2018-01-19 13:40:26 +10:00
Peter Hutterer aa1a5e6689 Revamp the pairing process and rename to Search
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
2018-01-19 13:40:26 +10:00
Peter Hutterer f6519016f9 wacom: rename the register* calls to pair* calls
Because that's what we call them everywhere else
2018-01-19 13:40:26 +10:00
Peter Hutterer 81033c3139 wacom: drop the multiple definitions of SMARTPAD_UUID
Let's use deadbeef for now until we have the generation code in place.
2018-01-19 13:40:26 +10:00
Benjamin Tissoires 06e8d69e9d Implement pairing of a new device
This includes the new pairing code for the Spark which is slightly different
to the one from the Slate
2018-01-19 13:40:26 +10:00
Peter Hutterer aa1820e21c Send out the PairableDevice signal when we have a device 2018-01-19 11:15:12 +10:00
Benjamin Tissoires c073ff2f06 ignore Wacom devices that are in pairing mode
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>
2018-01-19 11:08:16 +10:00
Peter Hutterer 43b1c4057c dbus: implement StartPairing/StopPairing on the manager
Triggers a StartDiscovery()/StopDiscovery() on the bluetooth adapters, but
with a fixed timeout of 30s.
2018-01-19 11:07:25 +10:00
Peter Hutterer 3871fc1d58 README: document the future pairing methods 2018-01-18 10:49:10 +10:00
Benjamin Tissoires 0d82afd690 WIP remove automatic connect of the devices
This creates an infinite loop on the Slate, as the device accepts the
following connect right after the disconnect
2018-01-17 15:21:14 +01:00
Peter Hutterer 5f5ce71aef dbus: properly return from Listen()
If we don't do the dbus dance for returning a value here, we get a timeout
eventually.
2018-01-17 13:41:35 +01:00
Peter Hutterer f9756a71ce Add commandline arguments to enable verbose mode
Create a logger hierarchy, that way we only need to set the root logger to
DEBUG and the rest goes along with it.
2018-01-17 13:41:35 +01:00
Benjamin Tissoires 8a81b1c245 Make sure we retrieve the data atomically
Ignore any requests to sync the device while the previous sync is still
ongoing. This should be the exception anyway, we shouldn't get another
"connected" signal from the device while we're syncing.
2018-01-17 13:41:35 +01:00
Benjamin Tissoires f88a5b2222 wacom: disconnect when we have finished retrieving the data
There is no point keeping the connection alive just to drain the battery.
2018-01-17 13:41:35 +01:00
Peter Hutterer dde2ad4b46 ble: use ServicesResolved for the connected signal 2018-01-17 13:41:35 +01:00
Benjamin Tissoires f30f47d454 wacom: fix from_bytes little/big endianness
Looks like they are all the wrong way but the time_offset one.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
2018-01-17 13:41:35 +01:00
Peter Hutterer 1841508c33 Pass the timestamps to the json file 2018-01-15 16:15:35 +10:00
Peter Hutterer 3a23610e08 Connect the WacomDevice drawings to the TuhiDrawings
And fixing a few issues with pressure, etc. on the way
2018-01-15 16:15:35 +10:00
Peter Hutterer cf68ebc9ce tuhi: create a TuhiDevice as glue object between front and backends 2018-01-15 16:15:33 +10:00
Peter Hutterer b7ce16fd38 dbus: remove the now-obsolete main() method 2018-01-15 16:14:19 +10:00
Peter Hutterer f293ef6e14 dbus: use the logging class too 2018-01-15 16:14:11 +10:00