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.
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>
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.
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.
./tuhi/ble.py:14:1: F401 'sys' imported but unused
./tuhi/ble.py:15:1: F401 'enum.Enum' imported but unused
./tuhi/ble.py:16:1: F401 'gi.repository.GLib' imported but unused
./tuhi/ble.py:26:1: E302 expected 2 blank lines, found 1
./tuhi/ble.py:81:1: W293 blank line contains whitespace
./tuhi/ble.py:84:13: E126 continuation line over-indented for hanging indent
./tuhi/ble.py:85:17: E131 continuation line unaligned for hanging indent
./tuhi/ble.py:203:39: F821 undefined name 'WACOM_CHRC_LIVE_PEN_DATA_UUID'
./tuhi/ble.py:204:38: E128 continuation line under-indented for visual indent
./tuhi/ble.py:205:39: F821 undefined name 'WACOM_OFFLINE_CHRC_PEN_DATA_UUID'
./tuhi/ble.py:206:38: E128 continuation line under-indented for visual indent
./tuhi/ble.py:207:39: F821 undefined name 'NORDIC_UART_CHRC_RX_UUID'
./tuhi/ble.py:208:38: E128 continuation line under-indented for visual indent
./tuhi/ble.py:232:1: E302 expected 2 blank lines, found 1
./tuhi/ble.py:240:13: E126 continuation line over-indented for hanging indent
./tuhi/ble.py:241:17: E131 continuation line unaligned for hanging indent
./tuhi/ble.py:250:21: E126 continuation line over-indented for hanging indent
./tuhi/ble.py:263:43: W291 trailing whitespace
./tuhi/ble.py:272:72: W291 trailing whitespace
./tuhi/ble.py:310:1: W391 blank line at end of file
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
./tuhi/dbusserver.py:55:1: E302 expected 2 blank lines, found 1
./tuhi/dbusserver.py:75:17: E126 continuation line over-indented for hanging indent
./tuhi/dbusserver.py:77:29: E203 whitespace before ':'
./tuhi/dbusserver.py:155:13: E126 continuation line over-indented for hanging indent
./tuhi/dbusserver.py:156:17: E131 continuation line unaligned for hanging indent
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
tuhi/wacom.py:18:1: F401 'sys' imported but unused
tuhi/wacom.py:22:1: F401 'tuhi.dbusserver.TuhiDBusServer' imported but unused
tuhi/wacom.py:23:1: F401 'tuhi.ble.BlueZDeviceManager' imported but unused
tuhi/wacom.py:52:1: E302 expected 2 blank lines, found 1
tuhi/wacom.py:140:13: E126 continuation line over-indented for hanging indent
tuhi/wacom.py:141:17: E131 continuation line unaligned for hanging indent
tuhi/wacom.py:592:1: W391 blank line at end of file
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Benjamin Tissoires