Hi, 2015-08-12 17:44 GMT+02:00 Joel Holdsworth <j...@airwebreathe.org.uk>: > Hi Hubert, > > Sorry for the delay in getting back to you. That sounds like a bug - we > could use a shared lock if we have no other way, but it sounds like > signal_from_channel maybe holding onto its lock longer than it needs to. > For example if that function sends an event to the UI thread, but is > holding the lock while waiting for the event to complete, this would > prevent the UI thread from getting through paintEvent and processing the > evening.
That solution works well enough for me, and I'm not proficient enough in C++ to debug it further. > > With regard to oscilloscope modes. Yes this would be very welcome. > > However, looping sample_thread_proc probably isn't the right way to do it. Indeed, that's why I said "experimenting" ;-). > libsigrok does have support for actual oscilloscopes. It signals the > start/end of a new sweep by SR_DF_FRAME_BEGIN/END. I suppose that's what SR_CONF_CONTINUOUS is for. However, I don't understand how it is supposed to be activated. It is a SR_T_UINT64 property, yet I have not found its value used anywhere in libsigrok (and I was expecting a SR_T_BOOL). In sigrok-cli, the continuous option is only used to disable buffering. > At the moment PV doesn't handle these - but it could and should. > > Now for devices that don't support continuous-sweeping, we can emulate > that in software. Now the question is where should this functionality > go? Should it be in PulseView? I think not, because this is > functionality other clients can use. Should it go in the drivers? In > many cases yes, I would say, but would the sweep emulation have to be > duplicated across many drivers? Would it go in libsigrok's core somehow? > I don't know. > > It would be good to have a discussion with use_ and biot on the #sigrok > IRC channel. > > The other issue is that painting needs work to improve speed. It would > be good to bring back some OpenGL painting. But also the various > painting/data storage algorithms need to be revisited. > > Joel Our aim is to have a working demo for LinuxCon in october. My priority is to get a working GUI with adjustable time and amplitude division, and a way to display a point's coordinates. The current GUI is very limited for analog data, so I was considering to use a plotting library like QWT. I am going on holidays for 1 week, I will be available to discuss the matter on my return. Best regards, Hubert > On 05/08/15 10:35, Hubert Chaumette wrote: >> Hi, >> >> I am experimenting on a continuous oscilloscope-like mode for >> PulseView (I basically added a loop in sample_thread_proc), and I >> encounter a deadlock on pv::Session::signals_mutex_. >> It appears both pv::view::Viewport::paintEvent (main UI thread) and >> pv::Session::signal_from_channel (sampling thread) try to acquire the >> mutex exclusively. >> >> The deadlock disappears when replacing lock_guard by shared_lock in >> signal_from_channel. So, is exclusive access to pv::Session::signals_ >> necessary there? >> >> Best regards, >> >> Hubert Chaumette ------------------------------------------------------------------------------ _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
