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
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)
Benjamin Tissoires