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 is only the framework for a new protocol handler that should simplify
adding, extending and debugging the actual protocol messages.
The summary is:
- each protocol interaction is a subclass of Msg() that handles the data sent
and received from the device.
- the list of messages for each device is stored in a dictionary the caller
initializes by providing the protocol version
- those messages are addressable via the Interactions enum through the
Protocol class
- the messages can be run via execute(), taking and setting the obvious
properties on the object
- actual communication is done via a single callback that takes/returns a
NordicData object for the request/reply.
So after the basic setup, the caller can do this:
p = Protocol(ProtocolVersion.INTUOS_PRO)
name = p.execute(Interactions.GET_NAME).name
p.execute(Interactions.SET_TIME, time.time())
This completely separates the protocol from the implementation where we want
the result of that exchange, ideally paving the way for better testing and
easier debugging of what's happening on the wire. Well, ether.
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>
For testing it's a lot easier to just provide a /tmp/ directory than having to
clear out the normal one that may contain useful drawings for debugging.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Regression introduced in e1a3675439
Where a device has no config entry, the e1a367 change would return early. This
is fine for devices previously seen and still lingering in the config but for
completely new devices, we'll never get past that KeyError.
Return to the old behaviour: where we don't have a stored UUID we continue
with the None UUID.
Fixes#148
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
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
If we want to integrate this with TuhiGui, we can't have multiple mainloops.
And there's nothing with Tuhi that needs it anyway, it's all about how it is
being called. Which means we can just move this to the main method.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This broke device initialization in some cases (not sure why it worked until
today though). Where a device is in register mode but the ManufacturerData has
not yet updated to the 4-byte string (i.e. a device previously known
normally), the device would now always call listen(). The firmware - in
register mode - would start initializing the connection though and get
rejected, leaving us with a device that cannot be registered.
This reverts commit a061240b11.
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.
This was getting stacked - once on init and once whenever we actually made a
connecting, resulting in the signal never getting disconnected properly and
some races because we tried to sync twice.
The whole "listen()" vs "listening" vs "connected" etc. is a bit of a mess and
should be reworked for a proper fix to this. But for now this will do.
This may fix#124
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>
This is what the dbusserver module does as well, so we end up with a weird
mismatch: to the base module the device is still known and unregistered on the
next search start. So when we see the bluez properties float past, we don't
add a new devices.
To the dbusserver the device is gone though and since we don't add it again in
the base module, we never send a signal for it.
Since there's a reasonable assumption that if we don't register the device, we
don't want it anyway, let's delete it from the base device list too.
This doesn't fix the issue of a device timing out while waiting for a button
press. That device will count as known until the next search stop. But at
least now we don't have to restart tuhi.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer