<xzcvczx>
yeah building it is a freaking nightmware
<azonenberg>
Hence why i suggested just shipping the blobs
<azonenberg>
As long as they're in a separate subdirectory and clearly identified as GPL I don't see an issue
<xzcvczx>
were you still thinking of bridging it to tcp?
<azonenberg>
Hmmm
<xzcvczx>
well do you think bridging it to tcp is the best choice
<azonenberg>
That's a good question
<xzcvczx>
as we were talking about the hantek last time i think this came up
<azonenberg>
Native libusb would work fine but in my lab i often am sitting across the building from the machine that the scope/LA is hooked to
<azonenberg>
It probably wouldn't be a bad idea to write a bridge
<azonenberg>
Idea: maybe we could refactor the dual socket protocol from the pico driver to a new base class
<azonenberg>
then have pico and the fx2la dsrivers derive from that class and include model specific extensions?
<azonenberg>
How about you start by writing a libusb based fx2la driver that is a native scopehal device
<azonenberg>
I think long term what i'm going to want to do is write a socket server that bridges a libscopehal Oscilloscope object to a common socket protocol
<azonenberg>
this would allow you to provide tcp remoting to any instrument connected via libscopehal even if it lacks an ethernet port
<azonenberg>
We might even fold the pico code into that one day?
<xzcvczx>
do we wnat to cleanroom the fx2la protocol?
<azonenberg>
I think it should be OK to read the fx2la source, just don't copy anything from the sigrok host side
<azonenberg>
i.e. dont look at libsigrok code for it
<xzcvczx>
fx2lafw you mean (just fyi for hte firmware)
<azonenberg>
Correct
<xzcvczx>
lol i think you have pretty much the exact model of clone as one of the ones i have
<xzcvczx>
except i didn't get the completely crappy test hooks that you did
<azonenberg>
Well i didn't get it intending to *use* it :p
<azonenberg>
I got it as a test subject for driver development and no more
<xzcvczx>
is yours mini-b or micro-b?
<azonenberg>
Dont know, i dont even think i ever plugged it in
<azonenberg>
it's been sitting on a shelf waiting for me to find time to work on it
<xzcvczx>
fair enough
<xzcvczx>
oh nvm picture shows its mini
<xzcvczx>
i was looking at the LA rather than the cable but the cable is clearly mini
<azonenberg>
ah ok
<azonenberg>
Ok so... summarizing the pending blockers for v0.1 right now
<azonenberg>
Six tickets (14% of total across scopehal and scopehal-apps) are related to the scopesession file format
<azonenberg>
Three (7%) are build system/packaging
<azonenberg>
Eleven (25%) are driver related, of which two are LeCroy and three are Pico
<azonenberg>
Four (9%) re protocol decode related
<azonenberg>
Seven (16%) are UI related
<azonenberg>
Another four (9%) file import/export related
<azonenberg>
and then the other nine (20%) are miscellaneous
<xzcvczx>
i think for hte fx2lafw i might just go straight for doing mso for it
<azonenberg>
you have a scope with mso hardware that uses fx2la?
<xzcvczx>
the hantek i have does the oscope side
<xzcvczx>
and the la side, just can't do it at the same time
<azonenberg>
wait you can use either scope and la via usb, but not both?
<azonenberg>
scope or*
<xzcvczx>
yes
<xzcvczx>
hardware switch
<azonenberg>
if thats not an awful design i don't know what is, lol
<xzcvczx>
well if you only need one or the other
<xzcvczx>
so i guess its not mso, but i was more meaning that i can do both the oscope side of fx2la and the la side
<azonenberg>
oh the hantek uses fx2lafw for the scope interface too?
<xzcvczx>
yes
<azonenberg>
Perfect. Go for it then
<azonenberg>
Which Hantek is it?
<xzcvczx>
6022bl in my case
<xzcvczx>
the 6022be is the oscope only one
<azonenberg>
How similar is that to the MSO5074?
<xzcvczx>
not at all iirc
<azonenberg>
ah ok we had a ticket for that. I'll leave that open and not marked for v0.1 then
<xzcvczx>
i dont think the mso5074 is even bsaed on fx2
<azonenberg>
ah, i see
<d1b2>
<Darius> hmm cmake found yaml-cpp but it isn't telling the makefile where it found it
<xzcvczx>
azonenberg: any recommendation of a good mso implementation to look at?
<azonenberg>
xzcvczx: LeCroy is the most complete one that I know of
<xzcvczx>
ok thank you
<azonenberg>
or Tek MSO6
<azonenberg>
The LeCroy driver code is a bit ugly because of the vbscript and the fact that their logic analyzer waveforms are literally xml
<azonenberg>
I wish i was kidding\
<d1b2>
<Darius> @azonenberg BTW I built glscopeclient on OSX
<xzcvczx>
>_< vbscript? ummmm are you sure its not a virus?
<d1b2>
<Darius> then I get the "Your graphics card or driver does not appear to support OpenGL 4.2"
<d1b2>
<Darius> not too surprising I suppose
<azonenberg>
No
<azonenberg>
xzcvczx: LeCroy's internal driver model is all Windows COM
<azonenberg>
They have bridges from some of the more frequently used commands to SCPI
<azonenberg>
but to access anything at all obscure, you usually end up using the VBS SCPI command that literally executes a line of vbscript
<azonenberg>
to poke the COM object
<azonenberg>
It's actually a halfway decent object oriented API, just a really clunky way of accessing it remotely
<xzcvczx>
fair enough
<azonenberg>
darius: Nice, that's a good start at least
<azonenberg>
It would not surprise me if libscopehal headless works on osx at that point
<azonenberg>
Getting the GUI working is a different story of course
<azonenberg>
But it's starting to look like compute shaders might be the only blocker
_whitenotifier-1 has joined #scopehal
<_whitenotifier-1>
[scopehal-apps] azonenberg opened issue #344: Look into alternate (OpenCL based?) renderers so we can support OSX - https://git.io/JsTk7
<_whitenotifier-1>
[scopehal-apps] azonenberg labeled issue #344: Look into alternate (OpenCL based?) renderers so we can support OSX - https://git.io/JsTk7
<_whitenotifier-1>
[scopehal-apps] azonenberg edited issue #344: Look into alternate (OpenCL based?) compute shader equivalents so we can support OSX - https://git.io/JsTk7
<xzcvczx>
darius: did you end up building it with opencl support?
<xzcvczx>
darius: and was it gcc or clang in the end?
<xzcvczx>
darius: and was it the libc++ vs stdlibc++ think that i saw earlier?
<d1b2>
<Darius> no OpenCL support - OSX doesn't have C++ bindings 🥺
<d1b2>
<Darius> I used clang because glibmm was built with it otherwise there were missing symbols
<azonenberg>
So we need to figure out how we can do accelerated waveform rendering on osx then
<azonenberg>
if both compute shaders and c++ opencl are out
<xzcvczx>
metal of course :)
<azonenberg>
Are the khronos C++ bindings for opencl something that actually needs OS support?
<azonenberg>
can we just install them seaprately?
<azonenberg>
i seem to recall they're just a wrapper around the C API
<d1b2>
<Darius> If I hack out the OGL 4.2 check it then complains about GL_ARB_arrays_of_arrays, GL_ARB_compute_shader, GL_ARB_shader_storage_buffer_object, GL_ARB_vertex_array_object, GL_EXT_blend_equation_separate, and GL_EXT_framebuffer_object
<azonenberg>
darius: array of arrays and shader storage buffer object are only used in the compute shaders i think, so if we avoid compute shaders they're not needed
Famine_ has joined #scopehal
<azonenberg>
no VAO or FBO is a little surprising, what GL version is it reporting?
<azonenberg>
the separate blend equation i might be able to work around
<d1b2>
<zyp> it should support 4.1
<d1b2>
<Darius> dunno about the version sorry
<d1b2>
<Darius> how do I tell?
* xzcvczx
is sorta glad to not be at fault for making azonenberg rejigger the opengl to work this time
<d1b2>
<zyp> I'd also appreciate macos support
<azonenberg>
zyp: my understanding was that apple silicon did 4.1 and most other osx was stuck on 3.3
<d1b2>
<zyp> hmm, I'm not sure
<azonenberg>
i think the M1 is the only thing with 4.1, is that what you have?
<d1b2>
<zyp> hmm, is glxinfo supposed to show highest supported? if so this is not very promising: OpenGL version string: 2.1 NVIDIA-12.0.23 355.11.10.50.10.103
<azonenberg>
zyp: wow that is older than i thought
<azonenberg>
I think apple silicon support is the first reasonable OSX target for us. Older might be possible but should not be the priority
<d1b2>
<zyp> they killed off nvidia support some years back though
<azonenberg>
I think the path should be linux ARM -> apple silicon -> possibly other osx
<d1b2>
<zyp> I'm running a nine year old hackintosh
<azonenberg>
yeah good luck on that lol
<xzcvczx>
darius: haha so many of your changes are pretty much exactly the changes i made to the letter :)
<d1b2>
<zyp> been working well so far 🙂
<d1b2>
<Darius> hah OK
<azonenberg>
darius, xzcvczx: ok so, as far as BSD goes, some of those changes look like they might break other stuff
<xzcvczx>
but yeah my bad i hadn't gotten around to throwing them at azonenberg
<d1b2>
<Darius> I have a Radeon Pro 560X
<xzcvczx>
azonenberg: like which?
<azonenberg>
e.g. omp.h is required for various openmp apis on linux
<xzcvczx>
oh i didn't need to ditch omp.h on bsd
<d1b2>
<Darius> I removed omp where it was not needed
<azonenberg>
Oh you only removed if it wasnt used
<azonenberg>
ok thats fine then
<azonenberg>
xzcvczx: anyway if you can come up with a set of patches to get it to build and run on bsd without breaking linux or windows, by all means send 'em my way
<azonenberg>
let me actually file a ticket for that so i have something
<d1b2>
<Darius> the -mavx is needed for Clang, not BSD per se
<xzcvczx>
azonenberg: well are you going to merge that diff from darius?
<xzcvczx>
as thats most of them
<azonenberg>
Not as is
<xzcvczx>
fair enough
<azonenberg>
I also want a github PR rather than a raw diff if possible
<azonenberg>
sine i can link it to tickets etc
<_whitenotifier-1>
[scopehal] azonenberg opened issue #474: BSD build support - https://git.io/JsTtr
<azonenberg>
All you need to do is add a bit of code in MockOscilloscope::LoadCSV() around line 379 that does a stat() on the file, or equivalent on windows, to get the file mod timestamp
<azonenberg>
and then set timestamp to that
<azonenberg>
fs can probably be zero unless the filesystem has sub-second timestamp resolution
<azonenberg>
(doing the same in LoadWAV() wouldn't hurt either)
<xzcvczx>
is a timestamp from mtime really a great idea?
<xzcvczx>
if you copy a bunch of files at the same time they will all end up with the same timestamp potentially leading to confusion unless there is a warning
<xzcvczx>
theoretically at least
<azonenberg>
xzcvczx: It's better than january 1970
<azonenberg>
Which is what it does right now if there's no timestamp in the file header comment
<azonenberg>
(if one is present, it should be used in preferenec to the mod time)
<azonenberg>
In the absence of anything else, mtime is the best information we have
<bvernoux>
I suspect the issue is #include <gtkmm.h> is declared in Graph.h & glscopeclient.h ...
* xzcvczx
forces the dunst cap on azonenberg for returning a bool from main
<azonenberg>
when did i do that? must be a mistake
<xzcvczx>
usbcsv:92
<azonenberg>
usbcsv is a test/demo tool codysseus did a lot of the work on iirc
<azonenberg>
it was just a demo of headless libscopehal usage i wrote and he modified
<azonenberg>
that might not even be my code
<xzcvczx>
oh my bad
<azonenberg>
But it's certainly not something critical to the project , it's been essentially unmaintained
<xzcvczx>
well clang complains at it
<xzcvczx>
do you care about any of those pastebinned warnings?
<azonenberg>
Looking
<azonenberg>
The cast alignment issues are all over the place and are just the nature of parsing raw binary data. For the time being glscopeclient just won't run on anything that mandates alignment
<azonenberg>
But i think at least a few are false positives
<azonenberg>
as far as the edge type stuff i think those are... there's not a good way to add new members to an enum in a derived class
<azonenberg>
i'm not sure if we can find a way to make that better
<xzcvczx>
fair enough
<azonenberg>
I mean if somebody wants to try, go for it
<xzcvczx>
why would we want to take that honour away from you
<noopwafel>
time for my next PR, "squash compiler warnings by replacing all enums with #defines"
* xzcvczx
changes all noopwafel's PRs to NOP
<azonenberg>
Also he's not in the channel but @GyrosGeier is interested in working on getting debian packaging made
<_whitenotifier-1>
[scopehal] xzcvczx opened pull request #477: change system includes to SYSTEM to hide their warnings - https://git.io/JsTx0
<xzcvczx>
you are going to get a bunch of the change system includes as they need to go to each of the repos
<xzcvczx>
azonenberg: ah yeah sorry clang does have it to, thats how i found out about it
<_whitenotifier-1>
[scopehal-apps] xzcvczx forked the repository - https://git.io/J3dDr
<_whitenotifier-1>
[scopehal-apps] xzcvczx opened pull request #346: change system includes to SYSTEM to hide their warnings - https://git.io/JskvJ
<_whitenotifier-1>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JskJU
<_whitenotifier-1>
[scopehal] xzcvczx 3d7dfc5 - change system includes to SYSTEM to hide their warnings
<_whitenotifier-1>
[scopehal] azonenberg eac3c7d - Merge pull request #477 from xzcvczx/system-includes change system includes to SYSTEM to hide their warnings
<_whitenotifier-1>
[scopehal] azonenberg closed pull request #477: change system includes to SYSTEM to hide their warnings - https://git.io/JsTx0
<_whitenotifier-1>
[scopehal] azonenberg 0df41ae - Merge branch 'master' of github.com:azonenberg/scopehal
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±16] https://git.io/JskJu
<_whitenotifier-1>
[scopehal-apps] xzcvczx fa93c2e - change system includes to SYSTEM to hide their warnings
<_whitenotifier-1>
[scopehal-apps] azonenberg 9c3c5eb - Merge pull request #346 from xzcvczx/system-includes change system includes to SYSTEM to hide their warnings
<_whitenotifier-1>
[scopehal-apps] azonenberg closed pull request #346: change system includes to SYSTEM to hide their warnings - https://git.io/JskvJ
<xzcvczx>
thank you
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JskJw
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg>
xzcvczx: did you not pull latest submodules?
<GyrosGeier>
xzcvczx, that's a quadcore, yes
<azonenberg>
git config submodule.recurse true
<GyrosGeier>
it compiles FPGAs twice as fast as my ten-core server CPU from 2017
<azonenberg>
if you don't set that, it will keep biting you :p
<xzcvczx>
oh foozeball
<xzcvczx>
my bad azonenberg thank you
<_whitenotifier-1>
[scopehal] xzcvczx opened pull request #478: add . to the search path for locals builds that dont have readlink - https://git.io/JskVk
<xzcvczx>
feel free to reject that one azonenberg
<azonenberg>
Yeah I'm gonna say no. Is requiring users to have /proc enabled for development that big a deal?
<_whitenotifier-1>
[scopehal] azonenberg closed pull request #478: add . to the search path for locals builds that dont have readlink - https://git.io/JskVk
<GyrosGeier>
might break chroot builds
<GyrosGeier>
we'll see what happens on Debian autobuilders
<GyrosGeier>
I need to package ffts first, it seems
<GyrosGeier>
everything else should be there
<xzcvczx>
azonenberg: what about a env var?
<azonenberg>
GyrosGeier: yeah we are probably going to end up forking and adopting ffts
<azonenberg>
it seems to be abandonware but fftw is GPL which is wrong-way compatible with our BSD license
<azonenberg>
ffts was the only viable option i could find that was permissively licensed
<azonenberg>
Right now we're using the last released version which works but hasnt been updated in years and i think adding AVX support would make it quite a bit faster
bvernoux has joined #scopehal
<xzcvczx>
azonenberg: would you be opposed to passing argv[0] to DriverStaticInit/InitSearchPaths?
<azonenberg>
xzcvczx: That's actually what i was starting to think of
<azonenberg>
Maybe InitSearchPaths should be pulled out of DriverStaticInit
<xzcvczx>
realpath?
<azonenberg>
and called separately by glscopeclient startup
<azonenberg>
(and any other derived apps)
<azonenberg>
then pass the path there
<azonenberg>
We can make a single global init function latr
<azonenberg>
but it's not part of driver init
<xzcvczx>
it would make sense
<azonenberg>
Go ahead and do that then
<azonenberg>
Seems the cleanest solution
<xzcvczx>
that aint happening tonight
<xzcvczx>
i will get the rest of my forrest of commits pushed that i have done so far
<azonenberg>
No rush
<azonenberg>
Ok
<azonenberg>
I need to get ready for $dayjob stuff anyway
<azonenberg>
GyrosGeier: BTW you may see references to catch2 in the build scripts and documentation, you can turn off testing at cmake time and its not required
<azonenberg>
i forget if thats in the unstable or experimental repos but it's not in stable
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JskHw
<_whitenotifier-1>
[scopehal] azonenberg 0c22ea0 - Ethernet100BaseTDecoder: added early-outs so we don't descramble the entire waveform if the sync offset is wrong. Massive (order of magnitude) speedups.
<xzcvczx>
and wow the speedup by OMP_WAIT...=PASSIVE is impressive
<azonenberg>
Yes, without it ends up busywaiting and oversubscribing cpu cores etc
<azonenberg>
unfortunately there's no way to set it via APIs
<azonenberg>
it has to be in the user's environment and is non-default
<azonenberg>
my plan is to eventually detect it, setenv, and exec self
<azonenberg>
if you wanna send a patch for that, go for it
<azonenberg>
That is afaik the only way to force the environment to be correct
<azonenberg>
since openmp reads it prior to main() in libc startup code
<xzcvczx>
haha i think i already have enough stuff in my queue
<azonenberg>
Lol well that goes for anyone else here too :p