14:15 <baettig> Hi, I am trying to connect my Keysight oscilloscope (linux fedora, I am trying 'agilent', usbtmc, /dev/usbtmc0

14:16 <baettig> I am getting 'Failed to connect to instrument using connection string DSOX:agilent:usbtmc:/dev/usbtmc0'

14:17 <baettig> Does anyone have a hint on how to connect? (also under windows, I didn't manage to connect to the scope at work, there I tried the windows path USB\VID_0957&PID_179A to the same error.

14:45 <electronic_eel> baettig: does your scope have ethernet and did you try that?

14:46 <baettig> ah I figured it out:

14:46 <electronic_eel> getting it connected via ethernet is a lot easier in my experience. once that works, you could do further work to get usb to work too

14:46 <baettig> crw-------. 1 root root 180, 176 Nov 14 15:02 /dev/usbtmc0

14:46 <electronic_eel> ah, ok, permissions

14:46 <baettig> sudo chmod 777 /dev/usbtmc0

14:46 <baettig> now it's working

14:47 <baettig> under linux

14:48 <electronic_eel> did you compile it yourself for fedora or did you use my copr repo?

14:48 <baettig> For windows, I might ask this week when I'm back at the office. (There was something strange, at first it didn't want to start saying it's missing the libfft2 so 0 9 0 file.

14:48 <baettig> After two reboots and three unrelated opening/closing of the terminal it started up. strange

14:49 <baettig> I compiled it myself following the pdf on github

14:50 <electronic_eel> if you want to, you can take a look at https://copr.fedorainfracloud.org/coprs/electroniceel/scopehal/

14:51 <electronic_eel> even if you compile scopehal yourself, you might want to get the dependencies like ffts from there

14:53 <azonenberg> Hmm, we should probably improve the error reporting there if we fail to open the TMC device

14:53 <azonenberg> let me file a ticket

14:54 <_whitenotifier-1> [scopehal] azonenberg opened issue #518: USBTMC: better error reporting if we fail to open a device - https://git.io/J1JR3

14:55 <_whitenotifier-1> [scopehal] azonenberg labeled issue #518: USBTMC: better error reporting if we fail to open a device - https://git.io/J1JR3

14:56 <baettig> Thank you very much! https://twitter.com/pbaettig/status/1458731958620631044

14:56 <baettig> That was at work. Windows is always ... special ...

14:57 <baettig> Ahh, thank you very much for your answer there, @azonenberg!

14:57 <azonenberg> Yeah. I don't know if anyone has ever implemented usbtmc support on Windows

14:58 <azonenberg> ok yeah it's very much linux only, expecting to use a usbtmc character device

14:59 <baettig> Need to find if I still have a dsoxlan pcb and a magjack in a drawer somewhere. Hope nobody at the company minds :D

15:00 <_whitenotifier-1> [scopehal] azonenberg labeled issue #519: Windows support for USBTMC transport - https://git.io/J1J0i

15:00 <_whitenotifier-1> [scopehal] azonenberg opened issue #519: Windows support for USBTMC transport - https://git.io/J1J0i

15:12 <baettig_> oops, I needed to restart my computer, it totally froze... (Thinkpad 13 Gen2 i7-7500U and intel integrated graphics. Might not be up to the task)

15:12 <azonenberg> Might be a shader bug. i strongly suspect there's one hiding in the code somewhere

15:12 <azonenberg> but have yet to find it

15:12 <azonenberg> every once in a while i see a GPU hang on some systems, seems to not affect others

15:12 <azonenberg> guessing certain drivers handle the buggy code better than others

15:13 <baettig_> If there's anything I can do to help to track it down, let me know

15:14 <azonenberg> I'm actually exploring a complete rewrite of the renderer using OpenCL instead of compute shaders

15:14 <azonenberg> this will enable support for a broader range of systems and more importantly let me use some debug tools that don't exist for compute shaders, at least in the nvidia opengl ecosystem

15:14 <azonenberg> Just a matter of having time to sit down and work on ti

15:17 <electronic_eel> hmm, but wouldn't it also mean that you need opencl for glscopeclient to run?

15:19 <electronic_eel> at least with my amd gpu i can currently use glscopeclient with just the open source drivers. that was a major point for me buying that card. but opencl needs some binary only stuff, so i have been avoiding it

15:20 <baettig_> crw-------. 1 root root 180, 176 Nov 14 16:19 /dev/usbtmc0

15:20 <baettig_> apparently fedora doesn't keep permissions ls -lart /dev/usbtmc0

15:20 <electronic_eel> baettig_: you should create a udev rule for it if you want it to stay over reconnects/reboots

15:20 <baettig_> hmm I think I need to add /dev/usbtmc0 to some group.. how and which

15:21 <electronic_eel> you mean plugdev? that is a thing of the past that is sometimes just still available due to compatibility reasons

15:22 <azonenberg> electronic_eel: My plan is to support both renderers side by side, at least for now

15:22 <baettig_> ah how do I do that? my academic days where I was on linux all the time are a few years back :D

15:22 <azonenberg> we need opencl to get accelerated rendering on macos because osx doesnt have gl 4.3 support

15:22 <azonenberg> and if i find a bug in the CL version of the renderer, with any luck i can port the fix to the GL version

15:22 <azonenberg> more importantly thoguh, there are software opencl implementations

15:22 <electronic_eel> baettig_: you need to create a udev rule with TAG+="uaccess" in it. that automatically gives access to a locally logged in user

15:23 <azonenberg> which would enable us to fall back to software rendering on systems without a good GPU

15:23 <azonenberg> like virtual machines

15:23 <electronic_eel> baettig_: take something like this for example: https://github.com/GlasgowEmbedded/glasgow/blob/main/config/99-glasgow.rules and adapt the usb vendor and product id

15:24 <electronic_eel> baettig_: then copy the resulting file to /etc/udev/rules.d

15:25 <azonenberg> electronic_eel: basically, right now the compute shader requirement is the #1 reason i find people can't run glscopeclient

15:25 <azonenberg> it woudl greatly expand the potential userbase if we could get rid of that

15:26 <azonenberg> and more importantly i could use oclgrind, a valgrind-like tool for opencl, to find bad pointers in the GPU kernels

15:26 <electronic_eel> yeah, i get that. a software-only implementation would be really nice. would also allow testing from CI and so on

15:26 <azonenberg> that's the thing, if i do it in CL it would give us both acceleration and software fallback

15:26 <azonenberg> And yes, it would enable CI etc too

15:27 <azonenberg> we already have opencl support for accelerating a bunch of filter blocks

15:27 <azonenberg> so most of the groundwork is there

15:29 <baettig_> SUBSYSTEM=="usb", ATTRS{idVendor}=="2a8d", ATTRS{idProduct}=="1768", \

15:29 <baettig_> MODE="0660", GROUP="plugdev", TAG+="uaccess"

15:29 <baettig_> so I changed vendor and id to my lsusb output of the scope and now I'll copy the resulting file and reboot

15:38 <baettig_> I'll need to read up on udev :)

16:05 <_whitenotifier-1> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/J1JHE

16:05 <_whitenotifier-1> [scopehal] azonenberg b874d03 - AlignedAllocator: ensure allocations are a multiple of alignment since some runtimes are picky about that

16:05 <_whitenotifier-1> [scopehal] azonenberg 803b617 - EyePattern: fixed possible underflow if pixels had negative Y coordinate

16:05 <_whitenotifier-1> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J1JHV

16:05 <_whitenotifier-1> [scopehal-apps] azonenberg 8870962 - Updated submodules