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 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>
Drop pycairo by way of an environment variable, because we don't need it for
tuhi.
The way pygobject is setup it checks for setuptools during pip3 and then
complains that it's not there:
Collecting setuptools
Could not find a version that satisfies the requirement setuptools (from versions: )
No matching distribution found for setuptools
It's not actually needed since it has a fallback, but clearly... anyway.
Let's use the plain setup.py invocation, but with the right --prefix.
Of course that setup.py invocation doesn't work for the other packages,
so let's leave pip3 in place for those. Because how much worse would the world
be if this would just work...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This one now includes Python 3.7, so we don't need to do it build it
ourselves. Fix the kete path up for 3.7 as well so this works again.
And finally, fix the pip incovations, the current ones we have install into
/usr/ which is read-only. Use the pip3 command generated by the
flatpak-pip-generator as listed on http://docs.flatpak.org/en/latest/python.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tuhi/drawing.py:46: PyGIDeprecationWarning: GObject.property is deprecated;
use GObject.Property instead
@GObject.property
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No need to get triggered by BlueZDeviceManager when it finds any GATT
characteristic. The BlueZDevice just needs its 'ServicesResolved' and
can resolve the GATT characteristics itself.
This solves a FIXME.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
The object list returned by object managers get_objects() function is
not sorted. Though, we rely on objects being sorted by their object
path.
Replace the object managers get_objects() function with a variant
fixing that. Additionally, our variant makes it possible to filter
the returned object list by object path and interface.
Examples:
- get_objects():
/
/org/bluez
/org/bluez/hci0
/org/bluez/hci0/dev_00_00_00_00_00_00
/org/bluez/hci0/dev_00_00_00_00_00_00/service0000
/org/bluez/hci0/dev_00_00_00_00_00_00/service0000/char0000
/org/bluez/hci0/dev_00_00_00_00_00_00/service1111
/org/bluez/hci0/dev_00_00_00_00_00_00/service1111/char1111
/org/bluez/hci0/dev_FF_FF_FF_FF_FF_FF
/org/bluez/hci0/dev_FF_FF_FF_FF_FF_FF/serviceffff
/org/bluez/hci0/dev_FF_FF_FF_FF_FF_FF/serviceffff/charffff
- get_objects(interface='org.bluez.Adapter1'):
/org/bluez/hci0
- get_objects(interface='org.bluez.GattCharacteristic1'
base_path='/org/bluez/hci0/dev_00_00_00_00_00_00'):
/org/bluez/hci0/dev_00_00_00_00_00_00/service0000/char0000
/org/bluez/hci0/dev_00_00_00_00_00_00/service1111/char1111
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
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>
When starting from within the git directory, always use verbose mode. Because
you're debugging it, otherwise you wouldn't start from git.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer