For data packets other than basic motion/pressure strokes, add a PacketHandler
that can deal with that particular packet. Those handlers are part of the
class declaration, when we instantiate a protocol we pull them all into a
packet_handlers list and go through them. The first one to return True is
considered the right handler and we expect something has been done with the
packet.
This patch includes the handlers for the end-of-stroke and end-of-sequence
packets, the rest to be added later.
Instad of carrying around a lot of parameters, move this into a class with
properties. Eventually we can subclass that one for the special opcodes (or
something...)
Makes end-of-stroke handling easier, we can call seal() on the current stroke
and it'll make drawing.current_stroke() None, which is something we can deal
with.
Now that we got the basics running and reliable, this debug message is mostly
just noise, especially when in an office with lots of bluetooth devices
around. Comment it out, to be enabled when necessary.
On the Intuos Pro at least we sometimes get events that are all relative at
first and it can take several events for us to have all three values as
absolute. This is likely a parsing error on our side, but meanwhile don't
write the data until we have at least one known value for all three axes.
And because the SVG writer isn't happy with empty strokes, add a seal()
function to the drawing to purge empty strokes.
Fixed#92 or at least works around it
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
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