<d1b2>
<kretien> did scopehal ever get support for the cheap fx2 logic analyzers? I saw a post about it and some sigrok stuff but wasn't sure if it was complete
<azonenberg>
There is an open ticket on the tracker
<azonenberg>
nobody ever sat down to write a driver
<azonenberg>
no technical blockers i'm aware of
<Darius>
"it's just software"
<d1b2>
<kretien> that will have to be a project for another night
<d1b2>
<kretien> thanks
Degi has quit [Ping timeout: 264 seconds]
Degi_ has joined #scopehal
Degi_ is now known as Degi
<d1b2>
<azonenberg> Yep. The other thing is, we generally like to provide network transparency wherever possible so a lot of our drivers for usb-attached devices are implemented in the form of a server
<d1b2>
<azonenberg> that you can run on the computer plugged into the instrument, which may or may not be the one you run the GUI on
<d1b2>
<azonenberg> it gives a lot more flexibility in large lab environments. Not a hard requirement but it's generally preferable
<azonenberg>
Also, landing soon (I have draft code on my work laptop but it's not pushed yet as I had more to test and debug): support for instruments that append to / modify waveforms rather than creating a new waveform every trigger
<azonenberg>
this allows a "strip chart" style display where you append live streaming samples up to some cap or when you stop the acquisition
<azonenberg>
basically, every AcquireData() you push waveform data into a temporary staging buffer then you append that to the existing waveform object in PopPendingWaveform()
<azonenberg>
the trick is supporting both append mode and "make new waveform" mode in the same driver, and not breaking filters working on the data
<_whitenotifier-7>
[scopehal] azonenberg a9817c7 - Initial skeleton work on SocketCANAnalyzer
<_whitenotifier-5>
[scopehal] azonenberg 4e0c367 - Initial version of SocketCANAnalyzer works but only for a single acquisition worth of packets. No PacketDecoder output.
<_whitenotifier-7>
[scopehal] azonenberg 52ca58e - Merge branch 'master' of github.com:ngscopeclient/scopehal
<_whitenotifier-7>
[scopehal] ... and 2 more commits.
<d1b2>
<vipqualitypost> thanks for getting back to me. I guess I did not get the submodule correctly (I am not great with git... I just switched to your branch and ran git submodule init --update but maybe this was not enough). The only thing I can comment on from the installation docs is that you should mark that in the Vulkan installation, you need to select all available packages to install from the installer (or maybe only one or two, I don't know which
<d1b2>
ones), at first I only installed the main Vulkan driver and none of the extra things that are offered. It would build but the GUI would crash immediately. The other thing would be to add brew install cairomm@1.14 as an extra dependency. 1.18 did not work for me but it sounds like this will be removed anyway going forward.
<d1b2>
<david.rysk> can you do this: cd lib git status and paste the output?
<d1b2>
<david.rysk> And yes I'm working on correcting the instructions
<d1b2>
<vipqualitypost> >git status HEAD detached at 18c5cc32 Untracked files: (use "git add <file>..." to include in what will be committed) .DS_Store nothing added to commit but untracked files present (use "git add" to track)
<d1b2>
<david.rysk> @vipqualitypost do the following from within lib: git add myfork https://github.com/d235j/scopehal.git git fetch myfork git checkout cmake-cleanups
<d1b2>
<vipqualitypost> fatal: pathspec 'myfork' did not match any files
<d1b2>
<vegard_e> that should be remote add, not just add
<d1b2>
<david.rysk> that's 3 lines, you might have some wrapping going on
<d1b2>
<david.rysk> oops thanks @vegard_e
<d1b2>
<david.rysk> 🙂
<d1b2>
<vipqualitypost> CMake Error at CMakeLists.txt:132 (find_package): By not providing "FindVulkanHeaders.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "VulkanHeaders", but CMake did not find one. Could not find a package configuration file provided by "VulkanHeaders" with any of the following names: VulkanHeadersConfig.cmake vulkanheaders-config.cmake Add the installation
<d1b2>
prefix of "VulkanHeaders" to CMAKE_PREFIX_PATH or set "VulkanHeaders_DIR" to a directory containing one of the above files. If "VulkanHeaders" provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred!
<d1b2>
<vipqualitypost> After fetching/checkout I go back to build dir and just follow manual right?
<d1b2>
<david.rysk> @vipqualitypost the manual is outdated, I'm working on a PR but...
<d1b2>
<david.rysk> If you're using the Vulkan SDK, download it then source its build-env.sh script
<_whitenotifier-7>
[scopehal] azonenberg d56f998 - SocketCANAnalyer: end waveform after fixed timeout (currently 50ms) rather than waiting until socket timeout elapses which caused slow jerky updates
<d1b2>
<vipqualitypost> I have a working build, so it's no worry about getting things working for me unless you would like me to try things out as someone not-so-familiar with the project for feedback.
<d1b2>
<azonenberg> That's definitely valuable feedback. In general one of the big things we're working on in preparation for the v0.1 release is improving the new-user experience
<d1b2>
<david.rysk> Then wait a few days for me to finish this cleanup and for Homebrew to merge yet another PR 🙂
<d1b2>
<azonenberg> Generally making it easier to get your foot in the door without handholding from the devs
<d1b2>
<david.rysk> and upstream bugs
<d1b2>
<azonenberg> Those are in most cases still crashes or build problems
<d1b2>
<azonenberg> Just not our code's fault
<d1b2>
<azonenberg> Hey @esden @246tnt it doesn't look like i have permissions to change the channel topic
<d1b2>
<azonenberg> several of the URLs in the title are way out of date. Can you either give me perms to change it myself, or at least do a one-time update so it matches the IRC channel topic?
<d1b2>
<246tnt> I can change it but I can't give you permissions AFAICT.
<d1b2>
<246tnt> nm, I can give you permissions, you should have them now.
<d1b2>
<246tnt> (but I already edited title 😅 )
Kerr has joined #scopehal
<d1b2>
<azonenberg> Thanks
<_whitenotifier-5>
[scopehal-apps] azonenberg dd31d59 - PacketManager: refresh rows when removing history so we don't keep dangling pointers to deleted packets
<_whitenotifier-5>
[scopehal-apps] azonenberg 1580d98 - Initial support for drivers appending to, rather than replacing, the current waveform when acquiring data
<_whitenotifier-7>
[scopehal-apps] azonenberg c5f468d - EyeToneMap: fixed background showinge up as lowest color even if no hits
<d1b2>
<johnsel> azonenberg do you have a working plugin implementation yourself still?
<d1b2>
<johnsel> I'm running into an issue with the code not building because of an override that I can't really place
<azonenberg>
yes what is it
<d1b2>
<johnsel> sec, I forgot rebooting removed that cli history need to do a build now first
<d1b2>
<johnsel> which for some reason is a full build but that's an aside
<d1b2>
<vipqualitypost> Will do! please just ping me when you need something! As an aside- is it possible to build with support for hi-dpi screens? the UI looks somewhat crusty on a retina display. I know this is par for the course on gtk based UI but I don't think scopehal is using that so maybe it's possible? Also: is there a place that sets the default font sizes? I think 13 is humongous, I almost couldn't view any of the UI until I brought the sizes down
<d1b2>
to about 7 (matching most other windows on my device). maybe this looks different on windows/ linux?
<d1b2>
<david.rysk> so it doesn't use gtk anymore, it uses Dear Imgui to render into a vulkan window. There are bugs around HiDPI in Imgui that are being worked on
<d1b2>
<david.rysk> Yeah, 13 seems large, I'd default around 11
<d1b2>
<vipqualitypost> also, if you accidentally enter 700 instead of 7 for font size, it will crash immediately 😛
<d1b2>
<azonenberg> Lol ok yeah thats an issue. Its probably trying to allocate all the memory on your GPU and then some to hold rendered fonts
<d1b2>
<azonenberg> we should cap that to some sane value, file a github ticket and i'll work on it when i have time
<azonenberg>
every once in a while the waveform areas are autosized slightly too big to fit in the parent window
<azonenberg>
whcih spawns a scrollbar that sometimes tries to catch mouse wheel events
<azonenberg>
Apparently it's not as squished as I thought
<d1b2>
<vipqualitypost> i tried adjusting the main window with no luck, and I don't see any smaller controls to help get rid of the scrollbar on the single window
<azonenberg>
Yeah its not possible. that window should never scroll
<azonenberg>
the waveform plot autosizes to fit all of the plots in the top level window and should use all the space and no more
<azonenberg>
it's getting it wrong here
<d1b2>
<vipqualitypost> it seems consistent for me as in any created / generated waveform has the same problem, but I don't have any real instrument I can hook up for actual data, if those are handled differently.
<azonenberg>
Yeah it has nothing to do with the specific waveform. it's probably specific combinations of ont sizes and DPI or something that trigger it
<azonenberg>
basically the logic that figures out how big the plot should be to fit in the parent window is off by a couple of pixels
<azonenberg>
Try changing the delta in ./ngscopeclient/WaveformArea.cpp:536
<azonenberg>
make it maybe 10 pixels or so
<azonenberg>
its not a proper root cause but should save your annoyance until we find the real problem
bvernoux has quit [Quit: Leaving]
<d1b2>
<vipqualitypost> hmm.. it doesn't actually seem that delta reduces the size of the window, just the size of something else (axis?). Here is with a very exaggerated -= 300px, the total window is still fit too big, but the axis is reduced properly
<_whitenotifier-7>
[scopehal] azonenberg 52e9d64 - Merge pull request #852 from d235j/fix-ub-arm64 Fix undefined behavior due to casts from float to unsigned int