AFAIK the current implementation is also lacking on ways to relay the device limitations from the driver to the user, ie. max sample rate with the selected amount of channels, max sample depth for non-streaming devices.
On Wed, 15 Oct 2025, Ladislav Laska wrote: > That makes a complete sense and would allow to decouple the device > drivers. I've personally written some munin plugins and while the > complexity is nowhere near what sigrok needs, it would make sense. > > The API calls would have to be translated somehow. If anybody would want > to go through this effort, I'd like to see a TCP/IP support too (we > could then run the driver on some single board computer and connect > remotely). Or maybe I'm talking nonsense and there is a better way of > doing that. Just pushing my ideas out there :-) > > Cheest, > Ladislav > > > On Wed, Oct 15, 2025 at 10:50:06AM +0200, Steve Schnepp wrote: > > Actually, I specifically asked because I wanted to see if I could > > write a generic stdin/stdout driver that could simply move that > > heavy-lifting in "user space" as an external process written in > > whatever language. > > Much like what libfuse is to filesystems. > > > > Rationale : I'm coming from the munin monitoring system where every > > plugin is a full standalone executable that can be a shell script, > > python or C, depending on the need. > > > > Cheers, > > -- > > Steve Schnepp > > -- > S pozdravem Ladislav "Krakonoš" Láska http://www.krakonos.org/ > > > _______________________________________________ > sigrok-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > -- This message may contain traces of Truth. _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
