]> sigrok.org Git - libsigrok.git/commit
hantek-dso: eliminate the "forced trigger" option value
authorGerhard Sittig <redacted>
Mon, 27 Nov 2023 18:12:11 +0000 (19:12 +0100)
committerGerhard Sittig <redacted>
Mon, 27 Nov 2023 18:55:37 +0000 (19:55 +0100)
commit5f50d6da1bc5cc5b48fdc6d4f1775313e97fb1d2
treed56e43be83ff53a7e2c5eb82753d655423432276
parentc78fa9cf9416260e018c131f72e9115302deba7f
hantek-dso: eliminate the "forced trigger" option value

Commit c93f113879a0 introduced a hack on top of an unfortunate choice.
It seems counter intuitive to open code a default trigger source on an
arbitrary channel, and have users override it with the "forced" value
to _not_ use a trigger.

The normal approach would be to specify a trigger when a trigger should
be used, and to not specify a trigger when no trigger should be used.

Eliminate the "forced" choice in the trigger_sources[] list. Start with
a not-set value. Accept when a value is specified (a "genuine" choice).
Don't bother adding support to "un-set" the previously specified choice.

This leaves the intuitive support for trigger specs that shall be used,
and only uses triggers when they were specified. Does not provide means
to "un-set" an earlier specified trigger config as the implementation
did before the 2023-09 change, which would be the 2021-02 status.

If the approach implemented here should be considered undesirable, then
a "none" option value should be introduced, something that much better
communicates to users what's happening and what the consequence of a
config choice would be.

This commit also adjusts the "ugh" code path which differed from the
"capture empty" code path. Fixes a resource leak in the config set path.
The "set trigger source" and "set trigger and samplerate" commands don't
agree on the phrase for the trigger source in the wire format. But have
been doing that before the forced trigger introduction, behaviour
remains unchanged here.
src/hardware/hantek-dso/api.c
src/hardware/hantek-dso/protocol.c