Skip to content

v0.1.16

Latest

Choose a tag to compare

@github-actions github-actions released this 17 Oct 07:09
· 2 commits to main since this release

Following the mouse across a swap, properly this time

Everything here is the cable/dongle swap path and the battery reading
that hangs off it. @f-o-o-g-s timed four rounds of it on a Pulsar X3 with
the 1K dongle and found each of these; none of it could be reproduced
here, where the only mouse has neither a sibling nor a battery (#11, #21).

  • The mouse's own battery report is taken as it arrives. The Fusion2 mice
    volunteer 05 07 <charging> <percent> 01 unasked, which carries both
    fields get_power() goes and reads. It sits alongside the minute poll
    rather than replacing it.
  • A connection change is noticed in a few hundred milliseconds instead of
    up to a minute. The event listener asks the bus when its node goes, and
    a swap check follows if its own device has left. Measured at 348-352 ms
    from the node disappearing to the other half being adopted, against 96
    seconds before.
  • The battery state file no longer describes the half that left. It used
    to sit there claiming "84%, charging" for a minute and a half after the
    cable came out; it is removed when a device is adopted and written again
    from the new half's own reading.
  • The first read after a swap is retried. A mouse that has just changed
    connection often is not ready for it - sometimes the battery read
    alone, sometimes the very first command - and the whole read is
    repeated up to three times, 1.5 s apart, rather than leaving the tray
    blank until the next poll. Both retries stop there: a mouse that is
    simply asleep is left to the poll.
  • A shared dongle is asked which mouse it carries while it is still
    plugged in, and remembered. Without that, pulling the dongle out and
    putting the cable into the same socket left nothing to ask, and the app
    sat on the missing dongle until it came back.
  • Windows thrown away for a swap take their event listeners with them.
    destroy() does not emit close-request, so each swap leaked a thread and
    an open hidraw fd; so did an Input Test dialog, which GTK leaves on
    screen when its parent is destroyed.

Full Changelog: v0.1.15...v0.1.16