Thanks Martin and … good news for MacOS users. Last week I have been working on porting LXI tools to MacOS and I am 99% done (some discussion in progress with one of the GTK4 lead developer as there is some bugs in GTK itself). I will most likely release it this weekend. I will do a merge request on your GitHub on Wednesday to fix some issues and replace avahi by a mdns wrapper library for full compatibility with all OSes if you are ok with that.
@raspberrypi:~ $ lxi --version
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
lxi v2.0
Quote@raspberrypi:~ $ lxi --version
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
lxi v2.0
Can anyone point me in the right direction to fix this?
$ lxi-tools.lxi-gui
$ lxi-tools.lxi
The lxi-tools v1 is dead, long live the lxi-tools v2!
Quote@raspberrypi:~ $ lxi --version
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
lxi v2.0
Can anyone point me in the right direction to fix this?
glib-compile-resources --target=lxi_gui-resources.c --generate-source lxi_gui.gresource.xml --c-name=lxi_gui
cp data/io.github.lxi-tools.lxi-gui.gschema.xml /usr/local/share/glib-2.0/schemas
glib-compile-schemas /usr/local/share/glib-2.0/schemas
Pull request done on lxi-tools and liblxi for macOS compatibility.
Many thanks for this fantastic tool!
May I give some feedback?
LXI-tools was able to discover 5 devices (Rigol DS1054Z, Siglent SDS2104x plus, Siglent SSA 3021X Plus, Rigol DG1022Z and Rigol DP832, all "hacked" into their more capable versions (e.g. The SSA 3021X plus now thinks its is a SVA1032X) but funnily enough the only device that isn't liberated doesn't show up when running lxi discover, a Rigol DM3068. It is reachable though when I run lxi benchmark -a <IP address>. I'm happy to help out if you want me to help make it discoverable.
More pressing thing, I tried to run LXI-tools V2 on Kali, Ubuntu and Raspberry pi OS. Kali and Rpi don't have the V2 yet, Ubuntu does but when I try to run lxi-gui it gives an error that it can not connect to a screen. I installed V2 on Rpi via snap but also there you get the error that lxi-gui can not start due to a x-window error. I'm posting this from a Mac so can not post the precise error but will try in a separate post.
BTW, building from source on Kali is painful...
I don't know if it's the bug or how the LXI tools work, but just a remark about the DM3068 and the VXI protocol.
The DM3068 can not be accessed when using device flags at e.g. 'device_write'. I had used the flag 'WaitLock' and the communication was denied. The Rigol DG4000 with old firmware also gives an error message on the screen. Without device flags everything works without problems.
Which discovery method are you using? Default or mDNS? See lxi-gui preferences
P.S. I can't run lxi-gui atm due to the error described above. Serials replaced by xxxx's
Unfortunately I can't easily distribute a flatpak of lxi-tools in places like flathub.org
The reason is that they do not allow my application ID to reflect my true reverse DNS domain. It is mostly for policy reasons and not so much technical ones. It's all very silly.
Unfortunately I can't easily distribute a flatpak of lxi-tools in places like flathub.org
The reason is that they do not allow my application ID to reflect my true reverse DNS domain. It is mostly for policy reasons and not so much technical ones. It's all very silly.
What craziness is that? I thought the whole idea of borrowing the reverse DNS d-bus concept was to get unique names/addresses. Can't you just use a made up name then? Now I haven't created any flatpaks (only rpms), so I'm not that familiar with their requirements.
Many distros prefer flatpak over snap nowadays, snap has become almost a Ubuntu thing only (Canonical always try to do their own race and eventually gives up and uses what everybody else does). I certainly prefer flatpaks over snaps, any day.
The issue is that I'm using an application ID true to my reverse DNS name, "io.github.lxi-tools.lxi-gui" but it is strongly recommended to not use hyphens in the app ID to avoid some exotic conflicting DBus use case. Flathub is enforcing this notation. Meaning it will have to look like this "io.github.lxi_tools.lxi-gui". I know this is a small detail but it really bugs me because it looks silly and everything works perfectly as it is. I can't believe that the DBus guys did not account for this situation considering they choose to base everything on the reverse DNS notation so why not make it ACCURATE!
Ah, yes, I remember now. But this doesn't really matter. AFAIK, the name is only used to identify the flatpak application, so hasn't any connection to a real DNS whatsoever.
I haven't been using snaps lately, but its true that flatpaks are aimed for GUI applications. My personal opinion is that cmd line tools are best coming from the distro repository. I see that lxi-tools are included in Fedora (very nice), but I expect it to take a while as usual before latest version is available.
The GUI works nicely, thanks!
Here's a screenshot of Siglent SDS1204X-E.
Just another comment about the reverse DNS name thing. This is a Freedesktop.org specification, so it isn't really flatpak that requires the strict naming thing, they just follow the specification.
Edit. But well, you could debate why they had to choose the whole naming scheme.