We can hook into the ProtocolVersion here, so let's de-duplicate this.
Should be backwards-compatible for config files but new config files will have
the uppercase name written now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is still a bit awkward because the communication of the spark especially
is so strange. It sends a (rejected) uuid, then a single command to register
that UUID. The Slate and the IntuosPro are more sensible, they seem to have a
special message to register a UUID - that one either fails or succeeds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The default timeout is too short for registering a button, let's control this
from the message.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is an in-situ replacement of the old functionality vs the new one,
resulting in a bit of duplication. Now that the Protocol takes care of the
device-specifics most of our functions look identical. This will be fixed in a
follow-up commit.
Missing from the conversion here is the initial register handling (too
convoluted right now) and the parsing of the pen data.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This function doesn't process the data beyond the logging required. It simply
sends the request and returns the reply, whatever that is.
Currently unused, this is prep work for later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have more data than our packet [1], let's not return the whole data
array. Slice it to size instead.
[1] this never happens with the current code, we don't work asynchronously
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
we don't need the same-ish check twice, we can just pop our non-list into a
list an go from there.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This requires adjusting the svg conversion in kete as well, afaict the 1000
range there was chosen because it's (almost) the midpoint of the Bamboo series
with 2048 pressure grades. So let's use half of 0x10000 instead, which is
approximately 0x8000 as the crow flies.
Fixes#142
No functional change, it just uses a dict now to pick the protocol class which
makes it *slightly* easier to read.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of just doing a single log line, let's log this to a yaml file so we
have a permanent record of the interactions with the device for bug reports.
Propagated whenever we start talking to the device (and then again when we
stop). The purpose of this signal is merely that a UI can show e.g. a progress
bar while we're talking to the device to ensure the user something is
happening.
Fixes#138
Virtually all the commands we have that don't have a specific opcode expect
0xb3. Since that's the general ACK command, we can default to that and make
everything else the exception.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
b3 01 00 seems to be a generic "I'm happy" and the few others we've seen
are errors. So let's encode that and reconsider if it turns out to be false.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
we already are keeping a record of the x,y and p. So we are trying
to duplicate the effort by using new_rel.
The problem is that some reports have relative coordinates but absolute
pressure data. Which means we are missing the pressure change as it has
a relative value of 0.
By trusting the wacom internal state, we can have the json data that
matches it completely.
It can easily take more than 5 seconds when reading the data. The current
timeout just cuts the connection while it is still reading.
We *could* just remove the timeout here as the device will gracefully
send us a 0xc8 opcode with a blank CRC if we shut the device down while
retrieving the data.
However, better being on the safe side and keep a timeout, but restart it
if we are still getting pen data during the timeout.
Fixes#91
When using the live mode on the Slate, the bloc note actually hampers
the pen and prevents it to address all of the pixels on the screen.
Add some artificial boundaries that roughly match the primary design
of the device.
The Intuos Pro has a clip where you put a regular sheet of paper, so there
is no point restraining the active surface.
Fixes#88
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.
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
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)
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'
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)
"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
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.
Peter Hutterer