[amin005]

Six commits from getting a PGL12-revision DSLogic Plus working headlessly. Each
builds on its own, and the whole branch is verified on hardware.

Happy to split this into separate PRs if you would rather review the device
support, the trigger work and the UX changes independently — the commits are
already cut along those lines.

Device support (closes #11)

patches: add DSLogic Plus / U2Basic PGL12-2 device profiles

A DSLogic Plus with PID 0x0034 is not detected: the pinned submodule's
profile table stops at 0x0030. The submodule already ships the bitstream
the 0x0034 profile refers to — DSView/res/DSLogicPlus-pgl12-2.bin is
byte-identical (blob ce921c35) to the one in DSView master — so only the table
entry is missing and no submodule bump is needed. A bump would pull in 94 files
and ~8 months of unrelated churn to fix a lookup table; this is 55 additive
lines.

patches: security check pass is not an error

DSView logs the successful security-check branch with sr_err(). It is gated
on CAPS_FEATURE_SECURITY, which the PGL12 profiles set, so affected boards
print three spurious error lines per capture that survive any log-level setting.

Triggers

feat(sys): bind ds_log_level and ds_trigger_* from the DSView runtime
feat(capture): simple trigger support

The runtime exports a complete simple-trigger API and none of it was reachable.
This wires it through:

--trigger 0=r,1=1     0 low, 1 high, r rising, f falling, c either, x don't care
                      channels may be written 0 or D0
--trigger-position N  percent of the buffer kept from before the trigger

Two review notes:

• The trigger is programmed where the two capture-preparation paths converge,
  just before start_collect(). Putting it in apply_capture_config() silently
  skips every capture that passes device options, because those go through
  apply_device_options() instead. That failure mode is indistinguishable from
  a trigger that does not work, and it cost me a debugging cycle.
• libsigrok4DSL keeps trigger state in a process global, so apply always resets
  first.

A trigger naming a channel --channels does not enable is rejected up front,
since the device cannot trigger on a channel it is not sampling.

Usability

feat(cli): quiet the native logger by default, add --log-level

Every command printed 14 lines of scan chatter to stderr. libsigrok4DSL defaults
to info and nothing lowered it. Now defaults to warn, with --log-level to
raise it. The level must be set between loading the library and init() — the
scan happens inside init(), so setting it afterwards suppresses nothing.

feat(cli): surface unsupported devices, coerced settings, and size the wait

• devices list returned empty + exit 0 whether nothing was plugged in or an
  unsupported DreamSourceLab device was present. The native scan logs the skip
  at info, so quieting the logger hid the only clue. The bus is now probed
  separately (Linux/sysfs) and the difference reported with a non-zero exit. An
  empty bus still exits 0.
• The device silently overrides settings it cannot meet — internal-test turns
  a requested 1 MHz into 100 MHz. Mismatches are now reported on stderr and in a
  warnings array. Buffer alignment (200000 → 200704) is within a 1% tolerance
  and stays quiet, because a warning that always fires is one nobody reads.
• --wait-timeout-ms defaulted to a flat 10 s, which aborts large captures
  mid-flight. Default 0 now derives it from sample rate and limit.

Verification

Hardware: DSLogic Plus 2a0e:0034 (PGL12), Ubuntu 24.04, rustc 1.98.1.
Stimulus: a Trion T20 FPGA driving known UART / SPI / I2C / counter patterns.

• cargo test --workspace: 285 passed, 0 failed
• Every commit compiles independently (checked in a separate worktree)
• Capture decodes correctly through sigrok's decoders: UART Hello LA!\r\n,
  SPI MOSI A5 3C 00 FF / MISO 5A C3 FF 00, I2C Start, Addr 42, ACK, DE, ACK, AD, ACK, Stop, and the device's internal test pattern as an exact
  binary counter
• Trigger, against a UART source emitting one frame per ~10 ms captured in a
  2 ms window: untriggered caught the frame in 1 of 5 runs; --trigger 1=r
  caught it in 3 of 3 with correct framing
• The unsupported-device diagnostic was verified by reverting the profile patch
  and rebuilding, which reproduces the original empty-list failure and now
  reports devices_present_but_unsupported with exit 1

Known limitation

feat(sys) binds both the trigger and log-level symbols in one commit. My
additions to bridge_runtime.c are textually interleaved and cannot be split by
hunk; separating them means editing the C file rather than re-staging. Say the
word if you want that split.

[seasonyuu]

Review findings

I found two issues worth addressing:

[P1] Clean up the capture session when trigger setup fails

crates/dsview-core/src/lib.rs:2673 calls apply_trigger() after the device has been opened, streaming VCD has started, and acquisition callbacks have been registered. If any trigger FFI call fails, the ? return bypasses the cleanup path below, so callbacks and the temporary streaming output can remain active. Please handle this error like a start failure by calling session.cleanup(&self.runtime, true) and aborting streaming VCD before returning.

[P2] Report coercions for all device options

crates/dsview-cli/src/main.rs:3054-3092 only compares sample rate, sample limit, enabled channels, and channel mode. CaptureDeviceOptionSnapshot also contains operation_mode_id, stop_option_id, threshold_volts, and filter_id; coercions in those fields are currently silent. The PR description says setting mismatches are reported on stderr and in warnings, so these fields should be compared too (with an appropriate float comparison for threshold voltage).

The new trigger parsing/programming path also has no focused tests for parsing, position validation, or cleanup on FFI failure. cargo test --workspace could not complete in this environment because pkg-config --cflags glib-2.0 is unavailable.

I found no separate repository standards violations.