00:00 <azonenberg> also things like pcap export are going to get pulled out of the protocol decode filters they're in now and become separate sink filters

20:08 <d1b2> <louis> @azonenberg so I'm screwing around inside the vendor code / libsigrock stuff for the dslabs scope, and wodering: do we want to be re-implementing these drivers, or do we want to be linking against libsigrock?

20:09 <azonenberg> I don't care how you do it on the bridge side as long as the libscopehal side stays free of anything GPL

20:10 <d1b2> <louis> the DSLabs application is a forked and hacked-up version of sigrock where they've removed all the hardware support except for their scope

20:11 <d1b2> <louis> but the libsigrock project upstream also has support for acquisition from a whole bunch of other devices, so a sigrock-api-level driver might mean some level of free support for those devices

20:19 <azonenberg> Yes. That is something i would certainly say is worth considering as a bridge

20:19 <azonenberg> also there's no C in "sigrok"

20:19 <azonenberg> as in "grok"

20:23 <azonenberg> Longer term if we have performance or other reasons in which we want to avoid using the sigrok driver for a given device at all, we can replace it

20:24 <azonenberg> but it seems like a good low-effort way to get a lot of cheap logic analyzers supported

20:26 <azonenberg> We have pending tickets for Saleae and cheap fx2 based LAs

20:26 <azonenberg> and a sigrok bridge would probably knock those out too