[bluez/bluez] eb58dc: monitor/analyze: Free the channel latency plots

[bluez/bluez] eb58dc: monitor/analyze: Free the channel latency plots

[Luiz Augusto von Dentz]

  Branch: refs/heads/1168850
  Home:   https://github.com/bluez/bluez
  Commit: eb58dc5a596c20fc25e231ea4e1f9c6864d87894
      https://github.com/bluez/bluez/commit/eb58dc5a596c20fc25e231ea4e1f9c6864d87894
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-09-18 (Fri, 18 Sep 2026)

  Changed paths:
    M monitor/analyze.c
    M monitor/l2cap.c

  Log Message:
  -----------
  monitor/analyze: Free the channel latency plots

A channel keeps a plot of its latencies for as long as it exists, but
destroying one frees only the channel itself, leaking both plots and
everything queued on them. A connection already frees its own.

Assisted-by: opencode:claude-opus-5


  Commit: aa11d08cb772d525a9910d68609e6ddf10efd8c0
      https://github.com/bluez/bluez/commit/aa11d08cb772d525a9910d68609e6ddf10efd8c0
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-09-18 (Fri, 18 Sep 2026)

  Changed paths:
    M monitor/analyze.c

  Log Message:
  -----------
  monitor/l2cap: Report the channel latency deviation

The channel latency is reported as a range and a moving average, while
the two latency lines either side of it also report the standard
deviation, which is what tells a channel that is consistently slow apart
from one that is unstable.

Report it here as well, so that all three read the same way:

  Channel Latency: 108 msec (48-108 msec ~79 msec +/- 27 msec)

Assisted-by: opencode:claude-opus-5


  Commit: 773b112f38de3725722f46b28f44c06072457b66
      https://github.com/bluez/bluez/commit/773b112f38de3725722f46b28f44c06072457b66
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-09-18 (Fri, 18 Sep 2026)

  Changed paths:
    M monitor/analyze.c

  Log Message:
  -----------
  monitor/analyze: Drop a trailing space before a newline

The count of control messages is printed with a space between the text
and the newline, which puts a stray character at the end of the line.

Assisted-by: opencode:claude-opus-5


  Commit: 310db2a397ba99861a940407662bf6e8331eefe2
      https://github.com/bluez/bluez/commit/310db2a397ba99861a940407662bf6e8331eefe2
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-09-18 (Fri, 18 Sep 2026)

  Changed paths:
    M monitor/analyze.c
    M monitor/avctp.c
    M monitor/control.c
    M monitor/display.c
    M monitor/display.h
    M monitor/l2cap.c
    M monitor/lmp.c
    M monitor/main.c
    M monitor/packet.c
    M monitor/rfcomm.c
    M tools/l2test.c

  Log Message:
  -----------
  monitor: Route the decoding output through a single function

The decoding output is written straight to stdout, partly through the
print_indent() macro and partly through some 167 direct printf() calls,
several of which build a single line across multiple calls. There is no
point at which the output of a frame can be observed as a whole.

Send all of it through display_printf(), which writes to a redirectable
stream, so that a caller can capture a frame and decide what to do with
it rather than having it go straight to the terminal. Capturing at the
stream level keeps the partially built lines working without having to
find and restructure them.

This is a pure redirection and the output is unchanged. The messages
jlink emits while connecting are left alone, as they are not part of the
decoding.

l2test uses the printing helpers from the header without linking the
monitor, so it gains its own display_printf() next to the use_color() it
already defines for the same reason.

Assisted-by: opencode:claude-opus-5


  Commit: ea58ac3a07c51605abcd358a133ff3c87dc1b014
      https://github.com/bluez/bluez/commit/ea58ac3a07c51605abcd358a133ff3c87dc1b014
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-09-18 (Fri, 18 Sep 2026)

  Changed paths:
    M Makefile.tools
    M monitor/control.c
    A monitor/find.c
    A monitor/find.h
    M monitor/main.c

  Log Message:
  -----------
  monitor: Separate the frames for a pager reading records

A frame spans several lines, so a pager that works on records rather than
lines has no way of telling where one ends. Feeding a trace to fzf with
--read0 makes the whole of it a single entry, and without --read0 each
line becomes an entry of its own, so searching finds the line reporting
an error without the header saying which controller, handle and time it
belongs to.

Separate the frames with a NUL when the pager is going to read records,
which is asked for either by --print0 or by --read0 already being in
PAGER:

  $ PAGER='fzf --read0' btmon -r hcidump.log
  $ btmon -r hcidump.log --print0 | fzf --read0

Nothing is separated unless it was asked for, so the output is unchanged
for a pager reading lines, which would otherwise show the separator as a
stray character between the frames.

Assisted-by: opencode:claude-opus-5


  Commit: 204c5e05a7d1aaea517208d5112c9444eaa991c6
      https://github.com/bluez/bluez/commit/204c5e05a7d1aaea517208d5112c9444eaa991c6
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-09-18 (Fri, 18 Sep 2026)

  Changed paths:
    M monitor/find.c
    M monitor/find.h
    M monitor/main.c

  Log Message:
  -----------
  monitor: Hand the captured frames to the pager on Ctrl-R

Looking for something in a running capture means stopping it and reading
back the log, losing whatever would have arrived meanwhile, or scrolling
the terminal by hand while the trace keeps moving.

Collect the frames as they are printed and hand them to the pager on
Ctrl-R, in the manner of the shell. The capture keeps running underneath,
and closing the pager returns to it, printing whatever arrived while it
was up so that the trace on the terminal has no gap.

The capture is never paused for this. Anything not read in time is
dropped by the kernel, so the pager runs on its own and is only checked
for having closed, rather than being waited for.

The frames are handed over as a file rather than through a pipe, so that
filling it cannot block the monitor and cost the capture any packets,
separated as they are elsewhere when the pager is going to read records.

Frames are only collected when the output is a terminal, so a capture
that is piped or redirected behaves exactly as it always has. The
terminal is switched to reading keys as they are typed, but signals are
left enabled so that Ctrl-C still interrupts the capture as before.

A capture runs for as long as it is left running, so the frames are held
in a ring and the oldest are dropped once it is full.

Assisted-by: opencode:claude-opus-5


  Commit: 026ca0f098664488812f2400fa320c5e44a87392
      https://github.com/bluez/bluez/commit/026ca0f098664488812f2400fa320c5e44a87392
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-09-18 (Fri, 18 Sep 2026)

  Changed paths:
    M doc/btmon.rst

  Log Message:
  -----------
  doc/btmon: Document searching the frames

Describe how the frames are separated for a pager reading records, how the
ones seen so far are handed to the pager while capturing, and that they
are only collected when the output is a terminal.

Assisted-by: opencode:claude-opus-5


  Commit: 0351467e112d4c7915dfe007299d05e27b2621e5
      https://github.com/bluez/bluez/commit/0351467e112d4c7915dfe007299d05e27b2621e5
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-09-18 (Fri, 18 Sep 2026)

  Changed paths:
    M monitor/display.c
    M monitor/display.h
    M monitor/find.c
    M monitor/find.h
    M monitor/main.c

  Log Message:
  -----------
  monitor: Prefer fzf as the pager when one is not set

A trace is a poor fit for a plain pager. Every frame spans several lines
and what identifies one is spread between its header and its contents, so
finding something means paging through by hand.

Use fzf when PAGER is not set and it is installed, asking it for whole
frames, for the colours to be rendered rather than shown as escape
sequences, and for the most recent frame first:

  fzf --ansi --read0 --tac

PAGER is still honoured when set, and setting it to cat or leaving it
empty still turns the pager off. The choice is shared with the frames
seen so far being handed over while capturing, so both arrive at the same
pager.

Frames are separated only when a pager that reads records is going to
read them, so redirected output and a pager that reads lines are both
left exactly as they were.

Assisted-by: opencode:claude-opus-5


  Commit: 6eb44fd8c89b30a08b61bd437b2d6572a436353e
      https://github.com/bluez/bluez/commit/6eb44fd8c89b30a08b61bd437b2d6572a436353e
  Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  Date:   2026-09-18 (Fri, 18 Sep 2026)

  Changed paths:
    M doc/btmon.rst

  Log Message:
  -----------
  doc/btmon: Document the pager choice

Describe that fzf is used when PAGER is not set, the options it is given,
and that it needs --ansi to render the colours when named explicitly.

Assisted-by: opencode:claude-opus-5


Compare: https://github.com/bluez/bluez/compare/eb58dc5a596c%5E...6eb44fd8c89b

To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications