+ * Text forms that may be worth supporting:
+ * - Simple forms, mere numbers, optional base specs. These are easiest
+ * to implement with existing common conversion helpers.
+ * triggerpattern=<value>[/<mask>]
+ * triggerpattern=255
+ * triggerpattern=45054
+ * triggerpattern=0xaffe
+ * triggerpattern=0xa0f0/0xf0f0
+ * triggerpattern=0b1010111111111110/0x7ffe
+ * - Alternative bit pattern form, including wildcards in a single value.
+ * This cannot use common conversion support, needs special handling.
+ * triggerpattern=0b1010xxxx1111xxx0
+ * This is most similar to SR_CONF_TRIGGER_PATTERN as hameg-hmo uses
+ * it. Passes the app's spec via SCPI to the device. See section 2.3.5
+ * "Pattern trigger" and :TRIG:A:PATT:SOUR in the Hameg document.
+ * - Prefixed form to tell the above variants apart, and support both of
+ * them at the same time. Additional optional separator for long digit
+ * runs, and edge support in the form which lists individual bits (not
+ * useful for dec/hex formats).
+ * triggerpattern=value=45054
+ * triggerpattern=value=0b1010111111111110
+ * triggerpattern=value=0xa0f0,mask=0xf0f0
+ * triggerpattern=bits=1010-xxxx-1111-xxxx
+ * triggerpattern=bits=0010-r100
+ *
+ * TODO Check this set of processing rules for completeness/correctness.
+ * - Do implement the prefixed format which covers most use cases, _and_
+ * should be usable from CLI and GUI environments.
+ * - Default to 'bits=' prefix if none was found (and only accept one
+ * single key/value pair in that case with the default key).
+ * - Accept dash and space separators in the 'bits=' value. Stick with
+ * mere unseparated values for value and mask, use common conversion.
+ * This results in transparent dec/bin/oct/hex support. Underscores?
+ * - Accept 0/1 binary digits in 'bits=', as well as r/f/e edge specs.
+ * - Only use --trigger (struct sr_trigger) when SR_CONF_TRIGGER_PATTERN
+ * is absent? Or always accept --trigger in addition to the data pattern
+ * spec? Then only accept edge specs from --trigger, since data pattern
+ * was most importantly motivated by address/data bus inspection?
+ * - TODO Consider edge=<pin><slope> as an optional additional spec in
+ * the value= and mask= group? Does that help make exclusive support
+ * for either --trigger or -c triggerpattern acceptable?
+ * triggerpattern=value=0xa0f0,mask=0xb0f0,edge=15r
+ * triggerpattern=bits=1r10-xxxx-1111-xxxx
+ * triggerpattern=1r10-xxxx-1111-xxxx
+ * - *Any* input spec regardless of format and origin must end up in the
+ * 'struct sigma_trigger' internal presentation used by this driver.
+ * It's desirable to have sigma_convert_trigger() do all the parsing,
+ * and constraint checking in a central location.