Created attachment 685 [details] Three screenshots showing steps to re-create bug This behavior has been confirmed on Windows 7, Windows 10, macOS Catalina (10.15), and Ubuntu 18.04 LTS using yesterday's nightly build. In order for this bug to be identified, the device must support more than one channel group. This has been verified with two OLS/SUMP-compatible hardware devices: HydraBus and JTAGulator. HydraBus has 16 channels (2 channel groups) and JTAGulator has 24 channels (3 channel groups). I haven't tried with non-OLS devices and don't have access to any. Having monitored the serial data between the PulseView client and our hardware (JTAGulator), we see that the channel enable/disable flags aren't updated to reflect the re-enabled groups. The attached screenshots show the PulseView display at each of the following steps: 1) My first capture with all three channel groups enabled by default returned the correct 0x82, 0x22 for the flags set (channels are disabled with bit = 1). 2) I then disabled channels 0-7 and did another capture. The data was correctly 0x82, 0x26. 3) When I re-enabled the channel group and did another scan, the flags sent remained at 0x82, 0x26 when they should be the original 0x82, 0x22. The re-enabled channels displayed on PulseView do not update and they remain LOW regardless of the actual state of those lines. The current remedy is to restart PulseView in order to capture all channels again.
Hello, thanks for your bug reports. Both devices you describe use the same driver, so this could also be a driver bug. I'll need to modify the demo driver to have 2+ logic channel groups in order to check whether this occurs there as well or not. My expectation is that the bug doesn't happen then, which then would prove that this is a driver bug.
Thanks for the quick response! I'm happy to do any additional testing you might need with the hardware I have available.
Changing category since this is most probably device driver specific not GUI initiated.
Can you please re-check with recent software (this nightly build)? See libsigrok c36a7d84ca36 which might have fixed this specific issue.
Thanks for your work on this. Sadly, the bug still exists in the nightly build. I'll try to monitor the serial data again between PulseView and the hardware to determine if the flags sent are now at least correct or if it remains as in my original bug report.
Might have been an overlap. Wrote comment 4 when the commit just happened. You could have grabbed a build perhaps that did not include the change yet?
Yes! I must have downloaded the nightly before it was rebuilt with the change. The version from today (Jan. 14, sha256sum: 0af8730a85531170230d62676ea0436c22a3bc2c4fb4671bebf1d477d691faed) fixes the bug! We can enable and disable the channel groups without a problem. We also verified that the serial data is now being returned properly. I'll mark this issue as resolved :)