The prefix (4 bytes on the spark/slate) is some data that we don't know yet.
It *could* be the size of a tablet/drawing in LE byte order: 14434x29794
although that doesn't quite match the Intuos Pro data where the prefix is
different.
Either way, having this be an opcode of 0x3800 was probably just coincidence.
Let's skip over the header normally and assume that once we have a prefix, we
have a drawing. This opcode never occurs a second time within the same
drawing.
The Intuos Pro has a different prefix, we'll need to override this. Dropping
the comment about the 8bt, on the intuos pro the prefix is nonsensical so
let's not leave a false lead there.
On the Spark, the 0xc9 CRC comes almost immediately after the 0xc8
end-of-sequence. This causes a race condition where sometimes we process the
0xc8 before the 0xc9 arrives, other times the 0xc9 overwrites the current
nordic_answer value before we get to it - triggering an unexpected opcode
exception.
Fix this by appending the nordic answer and only ever pulling off enough to
satisfy the current request.
Fixes#90
we want to be able to open uhid, so we need root access.
Root access is bad, so we fork the process, and then immediately drop
the privileges to talk to the dbus dameon (or to create one).
Python doesn't really like minus signs in file names, especially
when you start importing the modules. Rename kete from tuhi-kete.py
to kete.py so it makes it easier to have other scripts in the tools
folder to borrow code from kete.
The 'searching' notification was only emitted when it goes to stop, which
means we do not get notifications when it starts.
This makes SearchStopped signal redundant for the generic case, but allows
to get notifications if the search failed to start.
Rest is just making sure we have the same handling of events in Listener
and Searcher.
If stop() is called more than once, we might try to disconnect the
signals more than once, which raises some errors.
Better having one central place that handles the disconnect properly.
A device isn't registered or not, it's merely in a *state* of being
registering or not. Pass the current mode down to the TuhiDevice instead of a
boolean for 'registered'. The 'registered' gobject property is left in-place
for now, the dbus server needs it.
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'
Peter Hutterer