+/*
+ * TODO
+ * - Data acquisition works, but triggers either seem to not take effect,
+ * or the trigger position is not in the expected spot according to the
+ * user provided acquisition parameters. More research is required. The
+ * bitmasks for enable/level/edge as well as the magic 16bit values for
+ * position may need adjustment.
+ * - The trigger position logic assumes that capture ratio specs are in
+ * the range of 0-6%, which gets mapped to none/10%/50%/90%/+1W/+2W/+3W
+ * choices. This avoids issues with applications which lack support for
+ * non-contiguous discrete supported values, and values outside of the
+ * 0-100% range. This is considered acceptable, to avoid the necessity
+ * to extend common infrastructure to an unusual feature of a single
+ * device of limited popularity. Just needs to get communicated to users.
+ * - When a formula for the trigger position values in the SETUP packet
+ * is found, the driver may accept arbitrary values between 0-100%, but
+ * still could not express the "plus N windows" settings. Though that'd
+ * be a rather useful feature considering the very short memory depth.
+ * - The current implementation assumes externally provided Vdd, without
+ * which input levels won't get detected. A future implementation could
+ * optionally power Vdd from the PICkit2 itself, according to a user
+ * provided configuration value.
+ * - The current implementation silently accepts sample count limits beyond
+ * 1024, just won't provide more than 1024 samples to the session. A
+ * future implementation could cap the settings upon reception. Apps
+ * like PulseView may not be able to specify 1024, and pass 1000 or
+ * 2000 instead (the latter results in 1024 getting used).
+ * - The manual suggests that users can assign names to devices. The
+ * current implementation supports conn= specs with USB VID:PID pairs
+ * or bus/address numbers. A future implementation could scan for user
+ * assigned names as well (when the opcode to query the name was found).
+ * - The "attach kernel driver" support code probably should move to a
+ * common location, instead of getting repeated across several drivers.
+ * - Diagnostics may benefit from cleanup.
+ */
+