Commit Graph

6 Commits (73bc782a537ea9d1b80607725e044ec3e7b74321)

Author SHA1 Message Date
Peter Hutterer 73bc782a53 protocol: 0xec is simply the GATT selection for file transfers
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-14 07:37:30 +10:00
Peter Hutterer c39c20ede2 protocol: drop the UNKNOWN_B1 class
0xb1 is the SetMode command, the rest is just the argument for which mode we
want

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-08-14 07:37:30 +10:00
Peter Hutterer 5e4ab89f41 Drop the semi-duplicate separate Protocol class
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>
2019-08-14 07:37:30 +10:00
Peter Hutterer b34f8794e4 wacom: switch registering the device to the new protocol handling
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>
2019-08-14 07:37:30 +10:00
Peter Hutterer 6e20faa737 protocol: add a timeout argument to the new protocol handlers
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>
2019-08-14 07:37:30 +10:00
Peter Hutterer a817d10cc7 protocol: start a new attempt at handling the protocol
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>
2019-08-14 07:37:30 +10:00