An 'event' boolean is less than obvious ('is-event' may be better). This
signalled the difference between a device-added during Manager startup and the
device-added at runtime (i.e. device goes online).
We don't need that differentiation. The manager adds all existing devices
immediately after connnect_to_bluez(). All we have to do is run through the
device list, add them locally and then subscribe to the signal.
This keeps the is-event confusion within one file only instead of spreading it
across two and an internal API. And we can re-name it to hotplugged.
Calling listen on an unregistered device currently triggers a register on the
device. This can happen when the device has been registered but the
ManufacturerData has not yet been updated.
Disentangle this by only calling the right function based on what we're trying
to get. This also requires that the connected/disconnected signals are only
handled when we're actually trying to do something with them.
Fixes#79 (multiple patches required)
Previously, we set self._mode and used that to determine what connection to
attempt. This can sometimes lead to a device attempting to register in
response to a listen() request (and vice versa).
Make this dependent on the caller arguments only. So when listen() is
requested do exactly that and generate the right exception if the device is in
the wrong mode.
Fixes#79 (multiple patches required)
We only ever used it in conjunction with vendor_id, so we can just make this a
normal property and send GObject notifies when it changes. This allows us to
listen for the MD to change when it finished registration.
[BT: do not add the second indirection by calling vendor_id]
Fold register_connection into register_device and (with comments) handle the
spark and slate here. This makes it easier to handle the Intuos Pro paper
later.
During the first attempt to register, we might not know before hand
the protocol of the device. Have a special class for it, and then
instantiate the correct protocol before continuing.
This makes the 'Protocol' entry in the config file mandatory
The Slate is more recent than the Spark. We better have the Spark as a
base class that we will never touch again and make the Slate depend on it.
When adding the Intuos Paper, we should make it a subclass of the Slate,
as the 2 protocols are similar.
The Intuos Pro Paper is close enough to the Slate but with some
subtleties. Instead of having a bunch of ifs, let's have nice subclasses
for the differences in the protocol.
We are already handling 2 protocols, one for the Spark, and one for
the Slate. That's one too many, and given that there are some subtleties
in the Intuos Pro Paper (see #56), we better start splitting the protocol
from the interface, so we can have different protocols for different
devices instead of having a bunch of 'ifs'
The Intuos Paper uses a different one, because of course it does.
The 'company ID' from the Paper will be added while adding support for it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This isn't something we need in the daemon, it depends too much on what the
client expects so let the client save this data and handle the rotation
accordingly.
Note that the sensor in Sparks and Slates is in landscape format, i.e. every
picture is 90 deg rotated from what you'd expect.
Fixes#33 (wontfix)
Instead of failing with a syntax error on format strings, actually bail out
instead. Likewise for setup.py, require 3.6 and add this to the classifiers
too while we're there.
Related to #71
"pair" is alrady taken by Bluetooth and since we have a bluetooth device here,
it can cause confusion. Use "register" instead, with an explanation in the
README for the more paranoid of us.
Fixes#67
While running the app in flatpak, there are a few deprecation warnings
coming in:
PyGIDeprecationWarning: GObject.SIGNAL_RUN_FIRST is deprecated;
use GObject.SignalFlags.RUN_FIRST instead
PyGIDeprecationWarning: GObject.property is deprecated;
use GObject.Property instead
PyGIDeprecationWarning: GObject.MainLoop is deprecated;
use GLib.MainLoop instead
If a client requested both listen and search, on listen off on the device,
the discovery was stopped too which lead to some unbalanced state in
the client.
Tuhi is not a permanent storage for drawings, this needs to be handled by the
client(s). To make sure no-one is tempted to use it as permanent storage,
always delete all but the last 10 drawings on startup.
Fixes#45
Spark is the past, Slate is the future.
Spark seems to have its own protocol, while the Slate and the Folio are
supposed to have the same firmware. We should probably make Spark the
exception than the other way around.
Relying on the name is a bad idea because:
- the Wacom Inkspace app asks the user to change the name of the device
on pairing
- the FW should be slightly the same between generations (Folio and Slate
vs Intuos Pro Paper edition vs Spark)
It appears the Spark doesn't have the "Mysterious characteristics"
mentioned here. And this characteristics seems to send a wacom-like
protocol when pairing to the device or from time to time.
Attempt to differentiate between the Spark and the rest based on that
so we can hope to support the Folio too, and maybe the Intuos Pro Paper
Edition.
Let's the developers of tuhi to consume more energy in their monitor
to light up more pixel when displaying single quotes whereas double
quotes.
It also makes the whole bit more uniform.
Fixes#32
And let us handle the local time zone conversions in the client, because
having timestamps in localtime in the daemon is confusing and error-prone (how
is the client supposed to know what localtime was?)
fix ca82af78de ("tuhi: handle cold-plugged devices").
The point of deciding whether a device was in the pairing mode was actually
ignored when building the list of available devices.
As we're planning to cache the data locally, the timestamps are a
unique-enough way that makes it possible to access a specific drawing.
And this way we can also delete some drawings without all other indices
shifting around.
Fixes#16
If we're losing the bus name (i.e. we can't get it on startup) there really
isn't much we can do other than fail miserably. But in passing signals around
we can't do exceptions, so we have to move the mainloop to Tuhi so we can
quit() it on error.
Fixes#25
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
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'
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.
./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>
It didn't make quite sense to have y before x, and with some inverted
x value. The sensors are designed in the landscape mode, and the rotation
needs to be determined in the software.
Implement an orientation parameter to WacomDevice so we always have
normal X and Y
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It's better to have a full log on one line. However, flake8 now complains.
I am not that happy with this situation, we should figure out a way
to selectively disable the length check for logger messages only.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
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