<dingwat>
azonenberg: minor stumbling block while following the GettingStarted for Fedora, I think libhidapi-dev should be "hidapi-devel" on Fedora
<azonenberg>
dingwat: send PR to scopehal-docs?
<dingwat>
azonenberg: roger. I wasn't sure if that was correct but now the build has finished so I think that is an accurate description. No other issues with the Fedora build, but pretty rough behaviour with ngscopeclient on this high-DPI laptop (Fedora 42 with GNOME), GUI is too large and the mouse position doesn't match the cursor
<dingwat>
Will investigate further
<azonenberg>
yeah there are various dpi bugs we need to poke at
<azonenberg>
every time i think we got them all another one pops up loil
<dingwat>
azonenberg: unsure where things are at with Tektronix HSI, but I have an MSO58B in the lab, so if there's anything I can test, please let me know. I tried connecting (driver: tektronix.hsi, transport: lan) and ngscopeclient crashes with a "Persistent bad IDN response, giving up". Not sure if that's my fault or the scope's fault...
<dingwat>
(and I do have "High Speed Interface" enabled, on the default port of 5000)
<d1b2>
<azonenberg> So the tek HSI driver needs a bridge server, i'll have to check where it is. it can't talk directly to the grpc
<d1b2>
<azonenberg> we never got it fully working
<dingwat>
ah ok
<d1b2>
<azonenberg> the tek firmware is super unstable and HSI just gives you slightly faster waveform download
<d1b2>
<azonenberg> it still uses scpi for the control plane
<azonenberg>
And their SCPI is super unstable
<dingwat>
:(
<azonenberg>
the scope kept crashing on me and i basically lost interest
<dingwat>
well, when our support guy comes by I'll complain
<azonenberg>
if somebody wants to put more time into it, i'm all ears
<dingwat>
I'll experiment more with the regular driver and see how unstable it is
<azonenberg>
get that working first and only then think about HSI
<dingwat>
roger dodger
<azonenberg>
because if it's not stable - and it probably won't be - HSI won't improve things
<azonenberg>
any time you trigger an error code it would lock up for several seconds, not send any response to the command you had sent
<azonenberg>
then desync the request/response stream
<azonenberg>
the stack is stateful
<azonenberg>
if you crash or the firwmare derps at some point
<azonenberg>
you can send a request and get a reply from a previous command sent by a different socket
<azonenberg>
it preserves stack state across connect/disconnect cycles its nuts
<dingwat>
ugh
<dingwat>
well, I'm happy to complain lol
<dingwat>
I already have a list
<azonenberg>
lol
<azonenberg>
i mean, if you want to take over maintainership of the tek driver
<dingwat>
can't get remote web view to show up for some reason
<azonenberg>
nobody is actively working on it right now
<azonenberg>
i got sick of it, and tek wanted the demo scope back
<dingwat>
I'll see if I can contribute, but I worry my coding skills aren't up to snuff