<d1b2>
<edgetriggered> That change does make it start reliably. Thanks a lot, particularly since I am blissfully unaware of everything related to 3D graphics and this would have taken me significantly longer to track down, if at all.
<azonenberg>
Yeah i only know about it because somebody else hit the same issue a while ago
<azonenberg>
but never upstreamed a workaround
<azonenberg>
(root cause is a Mesa bug)
<azonenberg>
I'll have an automatic workaround for you to test shortly that should check the driver and enable that workaround for you
<azonenberg>
without having to do any code patching
<d1b2>
<tnt> Yeah, I hit that too but since my card isn't officially supported I figured this was part of the "unsuported-ness" ...
<azonenberg>
yeah we should probably open a bug report against Mesa at some point
<_whitenotifier-9>
[scopehal-apps] azonenberg d9b3f8c - Added workaround to diasable vkSetDebugUtilsObjectNameEXT for VkSurfaceKHR objects on Intel Mesa (segfault due to upstream driver bug)
<_whitenotifier-9>
[scopehal-apps] azonenberg 5dff40f - VulkanWindow: vkSetDebugUtilsObjectNameEXT workaround is now enabled for all Mesa drivers not just Intel
<d1b2>
<edgetriggered> Looks great! > Vulkan driver is Intel Mesa. Disabling vkSetDebugUtilsObjectNameEXT on VkSurfaceKHR objects to work around driver bug.
<azonenberg>
Excellent. I updated it one more time to expand the workaround to all Mesa per some feedback from tavy
<azonenberg>
(apparently this affects more than just Intel)
<d1b2>
<edgetriggered> I noticed that the RTA4004 instrument driver downloads include an rsrtx driver component and the source files indicate: "Rohde&Schwarz RTM20xx Digital Oscilloscope instrument driver"
<d1b2>
<edgetriggered> So this must be the old platform?
<azonenberg>
yes it probably is
<azonenberg>
@louis i think knows R&S more than I do
<azonenberg>
i have a bunch of R&S multimeters and power supplies (ex Hameg) but none of their scopes
<azonenberg>
he wrote the RTO6 driver
<d1b2>
<edgetriggered> Is "rs" considered the old bit-rotted version? I tried to establish a connection through lxi and it reported "ERROR: Couldn't connect to VXI-11 device" before segfaulting. I can try to get this working again with my scope.
nelgau has quit []
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 248 seconds]
Degi_ is now known as Degi
<azonenberg>
edgetriggered: i believe so, yes
<azonenberg>
it's quite old and has not been maintained in a while. Feel free to work on it
<azonenberg>
the first questions is whether you're using VXI-11 or raw SCPI over TCP socket as the connection
<azonenberg>
(and whether the scope is properly set up as a server, etc)
<d1b2>
<edgetriggered> I didn't see much in the way of setup on the scope, but it was discoverable from lxi-gui and I can issue some commands and take screenshots successfully. Doesn't seem to support the mandatory SCPI commands for some reason.
<d1b2>
<edgetriggered> I tried again using rs/lan and it did detect some options fields and try to display a waveform, so that's something!
<azonenberg>
Sounds like that's a more promising option than
<azonenberg>
time to dig up the programming manual and start poking at it i guess
<azonenberg>
if it was able to ID the scope and talk at all, you've got somewhere
<azonenberg>
You can add --debug --trace SCPISocketTransport if you want to log all scpi traffic to stdout
<azonenberg>
again that driver has not been touched in quite some time, fsedano was working on it ... circa 2021 i think?
<azonenberg>
(check git history, dont trust my memory on that)
<azonenberg>
but i can tell you it's been a long time
<d1b2>
<edgetriggered> Good to know, thanks. Is there a driver that's a particularly good reference in case things need to be restructured?
<azonenberg>
LeCroy is kind of the flagship driver in terms of being one that implements most of the supported feature set and is fast and stable, it's my daily driver
<azonenberg>
but it's large since it has so many features and supports so many variations of scopes
<azonenberg>
Pico is a much more bare bones driver but it uses our dual socket interface to talk to a bridge server, sine the scope itself is only USB and has no network interface
<azonenberg>
anyway, i think now that we have scalar support i'm going to start looking at adding measurement support to ngscopeclient at some point
<azonenberg>
i.e. displaying scalars somewhere in the viewport
<azonenberg>
i think it might make sense to just have measurements be a separate window