<zmatt>
so, if I understand correctly, by default systemd-networkd will use a pseudo-random mac address derived from the system's machine_id and identification of the interface, so that default may be perfectly fine
<zmatt>
(for interfaces that do not have hardware-supplied or user-supplied mac address)
<rcn-ee>
zmatt, 'same' address as we used before, it's just a mess of random shell scripts, i'll clean it up for bullseye..
<zmatt>
if the mac address is set via the usb function configuration then I'm pretty sure systemd-networkd will not touch it (unless you explicitly override it using MACAddress, which would be a bad idea)
<zmatt>
(and that's also the only way you can configure the remote mac address afaik)
<rcn-ee>
I;ll nuke: #MACAddress= from usb0/usb1*.network it was more of placeholder..
<zmatt>
also, an argument could be made for setting update_config=1 in the wpa supplicant conf to open the possibility of making a friendly commandline tool for searching for and connecting to a wifi network (with update_config=0 it could still do that but it wouldn't be able to persist the settings)
<rcn-ee>
zmatt, perfect, i didn't know that.. i'll change that.. i've really never used wpa supplicant con
<zmatt>
I have some experience with scripting wpa_supplicant via dbus
<zmatt>
(though unfortunately the dbus interface of wpa_supplicant is quite terrible)
<rcn-ee>
zmatt, that would be helpful. ;) i kinda wish we could run this https://steveedson.co.uk/tools/wpa/ in a local server so users can directly edit it..
argonautx has joined #beagle
<zmatt>
that seems unnecessarily annoying to use, compared to doing a scan, showing a list to select from, asking for password if necessary, and reporting whether it was able to connect successfully
<rcn-ee>
something simple like that ^ would be nice.. ;)
<zmatt>
I've written an incomplete but functional nodejs library for wpa-supplicant (example usage: http://hastebin.com/arococewub.js ), but I'd need to ask my employer whether I can share it (and the dbus library it depends on)
<zmatt>
oh ew I just looked at its (fairly old) code... I now wish I hadn't done that, lol
<zmatt>
note btw that wpa_supplicant can also be configured fairly easily into AP mode
<zmatt>
(you don't need hostapd for simple applications)
<zmatt>
you should not have any mesa packages installed
<zmatt>
it'll just create conflicts
<zmatt>
the reason the .so library version number is different from what it's expecting is because what it's expecting is not compatible
<Guest1566>
so what is the proper way?
<zmatt>
so, I haven't tried on the am572x, but here's a post I wrote getting the 1.14 drivers working on am335x: https://groups.google.com/g/beagleboard/c/BEipC_SFjaE/m/zieEuZlfDwAJ though this is quite old (kernel 4.9) and I haven't updated my repos since 2017, at least it shows the ingredients
<zmatt>
but long story short, you need ti's libgbm
<Guest1566>
Thanks for the link. Well read it, but the end result I'm looking for is Qt on top of EGL.
<zmatt>
yeah that should just work
<zmatt>
once you have the libraries working
giort has joined #beagle
<zmatt>
(I had to patch qt5base to support the 16-bit framebuffer used on beaglebone black, but that problem doesn't exist on the bbai and I think qt5 has also been fixed anyway)
<Guest1566>
I forgot to start the server: /usr/bin/pvrsrvctl --start --no-module. Now elginfo works using my symlinkged gbm.
<Guest1566>
However, I want to address this missing libgbm.so.2
<zmatt>
I'm surprised it works at all but maybe eglinfo doesn't result in any actual calls to libgbm
<Guest1566>
The package I installed: http://repos.rcn-ee.com/debian buster/main armhf libgbm1 armhf 19.1.6-1rcnee2~buster+20200513
<zmatt>
their "Remove the unnecessary backends" sounds similar to my "remove unused crap"
<zmatt>
and they added some new feature
<rcn-ee>
"unnecessary" might be removing xorg support.. ;)
<zmatt>
it never had xorg support
<rcn-ee>
that too
<zmatt>
regardless, that wouldn't be at this layer
<zmatt>
this is lower-level
<zmatt>
Guest1566: using TI's repo is probably the best choice
<zmatt>
rcn-ee: uhhhhh
<zmatt>
rcn-ee: line 3 doesn't do anything... it consists of match rules with no actions
<zmatt>
also SUBSYSTEMS seems like a strange match criterium
<zmatt>
that KERNELS seems wrong
<rcn-ee>
i'd like to limit it to wl18xx_driver, added a new file to that gist..
<zmatt>
not sure why yours is wl18xx.3.auto, on my bbbw here it's wl18xx.0.auto
<rcn-ee>
5.10.59-ti-r18.2
<rcn-ee>
and the new sdhc driver after 5.5.x...
<zmatt>
why not match SUBSYSTEM=="net", ACTION=="add", KERNEL=="wlan0", DRIVERS=="wl18xx_driver" ?
<rcn-ee>
okay! that's why i asked .;)
<zmatt>
especially since otherwise your rule will also match on your newly created ap%n interface
<zmatt>
and I'd probably just write ap0 if matching specifically on wlan0 anyway
<zmatt>
you'll want those specific names anyway for the wpa_supplicant .service file
<rcn-ee>
okay, your last change tested on a two boards, wifi and non-wifi, next wpa settings. ;)
<zmatt>
hmm, though if you're not going to have ap0 on every target with wifi that would complicate things
<rcn-ee>
ap0 only showing up on wl18xx
<zmatt>
you'd want ap0 to be handled by a different service... which doesn't preclude using wpa_supplicant (a separate process thereof) though it would prevent dbus-controllability of that second service
<rcn-ee>
i need to match for wl18xx and brcmfmac.. wl18xx takes: "managed" brcmfmac takes "__ap"...
<zmatt>
ah so ap0 will exist either way, the rule is just different?
<rcn-ee>
zmatt, can we trigger wpa_supplicant from: /etc/systemd/network/wlan0.network ... if i enable it outright, it connects to wifi on a BBBW just fine, but on a non-wifi BBB we get to wait 2 minutes till wpa_supplicat times out..
<rcn-ee>
i could add a depend on /sys/class/net/wlan0 for: /etc/systemd/system/multi-user.target.wants/wpa_supplicant@wlan0.service but that might be "too" hackisth?
<Guest1566>
./OGLES2Water: error while loading shared libraries: libgbm.so.1
<Guest1566>
The libgbm I installed and compiled gave /usr/local/lib/libgbm.so.2.
<Guest1566>
The rcn libgbm1 package apparently is mesa. Though if I install it, the demo works.
<rcn-ee>
cool
<Guest1566>
Do I have a working set of libraries then?
<Guest1566>
So how do I get a working set of libraries for AM57xx?
otisolsen70 has quit [Ping timeout: 252 seconds]
<Guest1566>
My qt app no worky either:
<Guest1566>
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-debian'
<Guest1566>
Could not initialize egl display
<Guest1566>
Aborted
<zmatt>
do not have _any_ mesa packages installed
<zmatt>
you will get crashes
<zmatt>
(that includes the libgbm1 package)
<Guest1566>
No the problem this time is that qt packages install a whackload of stuff and one has overwritten one of the ti libs. I remember this problem from playing with the bbb back in June.
<Guest1566>
It probably is a mesa package too. I'll have to check my notes.
<zmatt>
back when I did this qt5 packages did not depend on mesa
<zmatt>
or
<zmatt>
oh
<zmatt>
wait
<zmatt>
they did, I created my own debian packages from the userspace libs
<zmatt>
which provided the necessary dependencies for things like qt5
<zmatt>
now I remember
<Guest1566>
Last time (on the am335x) when I installed the user mode libraries using the 1.14.3699939_k4.4 branch it put the libs under /usr/local/lib/arm-linux-gnueabihf and then putting that at the top of the ldconfig conf file meant it would pick the ti libs first.
<Guest1566>
However this time it appears the ti libs are installed under /usr/lib
GenTooMan has quit [Read error: No route to host]
GenTooMan has joined #beagle
<zmatt>
rcn-ee: oh earlier I forgot the most important bit for wpa_supplicant AP mode: having mode=2 in the network block. also apparently ap_scan=2 is not appropriate anymore for the nl80211 driver
<zmatt>
rcn-ee: and it turned out that setting up the access point via dbus instead of using a wpa_supplicant config file is also pretty easy: https://pastebin.com/L1tPEmQ1
<zmatt>
so, that service file is annoying anyway since it is designed for having a separate wpa_supplicant process per interface (which is not compatible with using dbus) and does not enable dbus
<zmatt>
yeah, and it's almost just as easy in C using libsystemd
<zmatt>
having the wlan0 device pull in wpa supplicant is indeed a good idea
<zmatt>
rcn-ee: that idea combined with a variant of my wpa_supplicant.service that sets up wlan0 using config file but also enables dbus: https://pastebin.com/W0VEJETU
<zmatt>
(and then ap0 could pull in a service that enables the access point via dbus)
<zmatt>
that way if ap0 never shows up, no problem
<rcn-ee>
dbus is the -O right?
<zmatt>
no
<zmatt>
-u is dbus
<rcn-ee>
ah!
<zmatt>
I'm not 100% sure what the story behind the -O is... I think it ensures the config file cannot mess with where the legacy control sockets are created
<zmatt>
it's been a while since I dug into this stuff
<zmatt>
debian ships with a wpa_supplicant.service file that's dbus-only (no config files) and a wpa_supplicant@.service template that's single-interface with config file and no dbus
<rcn-ee>
and then with nl80211 and not nl80211 in bullseye..
<zmatt>
no, don't use -u in the service template, that's a bad idea
<zmatt>
since a template can be enabled for multiple interfaces, but that creates a wpa_supplicant process per interface and you can't have two dbus-enabled wpa_supplicant processes running
<zmatt>
that's why I'm using (and suggesting) a custom wpa_supplicant.service
<rcn-ee>
okay nuked that.
<zmatt>
and I think nl80211 is the default
<zmatt>
probably
<rcn-ee>
for our wl18xx it is, the brcmfmac might not be... it's a mess..
<zmatt>
I'm also not specifying the driver in CreateInterface in my shell script (even though I could) and it seems to do the right thing
<zmatt>
brcmfmac seems to be nl80211 too based on a quick google?
<rcn-ee>
it must be old android or really old drivers now..
buzzmarshall has quit [Quit: Konversation terminated!]
buzzmarshall has joined #beagle
<rcn-ee>
zmatt, yeah this wlan0 config works perfect.. fire up a non-wifi, stick a usb-wifi, instantly connects to wlan0..
<rcn-ee>
this will be the default wlan0 location: /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
<rcn-ee>
i'll probally setup : /etc/wpa_supplicant/wpa_supplicant-ap0.conf for the ap..
<rcn-ee>
that should be easy for end users to quickly tweak for their network preferences..
<zmatt>
using a separate (non-dbus) process/service ?
<rcn-ee>
yeah, either a dbus or not, something easy..
<zmatt>
yeah, if separate processes are used (precluding having both dbus-controllable) then dbus control on wlan0 would be more useful than on ap0
<zmatt>
or instead of using dbus I guess a config util could also use the legacy control socket (used e.g. by wpa_cli), but I don't know how that works
ikarso has quit [Quit: Connection closed for inactivity]
<Guest1566>
Where can I find the correct libgbm1 source code for am57xx?
<zmatt>
some libraries will be looking for libgbm1 rather than libgbm2
<zmatt>
like, if you use standard debian packages for things like qt5
<zmatt>
a symlink should deal with that
<zmatt>
yeah that was the big annoyance with the version bump, it makes a hassle out of using precompiled binaries that were linked to libgbm.so.1
<zmatt>
looks like what I did back in 2017 was patch the libgbm library version from 2 back to 1 (in both libgbm itself and the sgx libraries that reference it)
<zmatt>
which is also gross, but I was too lazy to recompile qt5
<zmatt>
I wonder why I didn't use a symlink... maybe I'm overestimating the intelligence of the dynamic linker, maybe it won't recognize the fact that it's the same library and end up loading two copies of libgbm into memory, which would be bad
<Guest1566>
I'll try the simlink hack first I guess. I messed up my filesystem so I'm imaging a new card right now.