<d1b2>
<TiltMeSenpai> it looks like dslogic deleted their autoconf files a couple months ago and figuring out how to build their libsigrok fork is proving to be notably painful
<d1b2>
<TiltMeSenpai> and I'm wondering whether building their fork is gonna be more or less painful than modifying that project to just build against upstream sigrok
<d1b2>
<louis> Their libsigrok fork is a total cluster of hacked-on code, including a bunch of random globals that totally skip the libsigrok abstractions
<d1b2>
<louis> So in theory it's possible, and would probably be cleaner? but it would be a ton of work to tease apart whatever is going on with their driver
<d1b2>
<TiltMeSenpai> I'd rather fight CPP code than CPP build tools but I'm weird like that
<d1b2>
<TiltMeSenpai> noted, I'll fork the bridge and PR if/when I get it to run lol
<d1b2>
<louis> What issue are you hitting? I haven't updated my copy of libsigrok4DSL in months... did it change out from under the bridge?
<d1b2>
<louis> I didn't think the bridge application had any dependency except insofar as requiring an installed copy of libsigrok4DSL
<d1b2>
<TiltMeSenpai> I tried to roll back but it fails to detect GLEW if I do that
<d1b2>
<TiltMeSenpai> what commit hash did you build against? I can try do that instead
<d1b2>
<louis> I appear to be on the dev-tai branch commit 3914467d588ad9cf23a30b88f0ac3cc210542ec3
<d1b2>
<TiltMeSenpai> and if that works it might be worth throwing in "This has been tested with libsigrok4DSL hash ..." or some other instructions along those lines, DSLogic is 😠 with their source code
<d1b2>
<louis> It's been long enough though that I have to admit I'm not sure why I'm on that branch?
<d1b2>
<TiltMeSenpai> oh no sorry it was failing to find glibconfig.h
<d1b2>
<TiltMeSenpai> though that might not be the DSLogic libsigrok that's borked?
<d1b2>
<louis> send me a snapshot of a build failure?
<d1b2>
<TiltMeSenpai> make all-recursive Making all in hardware Making all in demo CC libsigrok4DSL_hw_demo_la-demo.lo In file included from /usr/include/glib-2.0/glib/galloca.h:32, from /usr/include/glib-2.0/glib.h:30, from demo.h:24, from demo.c:23: /usr/include/glib-2.0/glib/gtypes.h:32:10: fatal error: glibconfig.h: No such file or directory 32 | #include <glibconfig.h> |
<d1b2>
<louis> huh. that looks more like something is wrong with your glib install than a libsigrok4DSL error to me
<d1b2>
<TiltMeSenpai> yeah
<d1b2>
<TiltMeSenpai> "use pkgconfig to add gcc arguments" ok internet, I know that this works but it's not particularly helpful to me at the moment
<Degi>
I guess by adding $(pkg-config --libs <your libraries>) and $(pkg-config --clfags <your libraries) to it maybe
<d1b2>
<TiltMeSenpai> I just hand-patched the Makefile to make it behave itself
<d1b2>
<TiltMeSenpai> now I'm having fun figuring out how to install libudev without breaking my entire system, but that's not a DSLogic problem, thanks
<d1b2>
<TiltMeSenpai> ok we've now built everything and glscopeclient segfaults because it doesn't recognize the DSLogic Plus
<d1b2>
<TiltMeSenpai> which isn't at "using a DSLogic Plus with glscopeclient" but is progress, so 🎉
<d1b2>
<louis> No promises, but good chance it will Just Work™ if you add diff diff --git a/scopehal/DSLabsOscilloscope.cpp b/scopehal/DSLabsOscilloscope.cpp index ad84693..ae83407 100644 --- a/scopehal/DSLabsOscilloscope.cpp +++ b/scopehal/DSLabsOscilloscope.cpp @@ -200,6 +200,14 @@ void DSLabsOscilloscope::IdentifyHardware() m_digitalChannelCount = 0; } + else if (m_model == "DSLogic Plus") + { + m_series = DSLOGIC_PLUS; +
<d1b2>
<TiltMeSenpai> ok, it passes an initial sniff test but I was consistently getting crashes just by tossing a 100khz square wave at it
<d1b2>
<TiltMeSenpai> TBD if that's related to any of the fucky shit I did
<d1b2>
<TiltMeSenpai> also the UART wasn't decoding right, almost like there's some timebase differences between the DSLogic Plus and other variants, I'll also try chase that down when I have more time/motivation