**** BEGIN LOGGING AT Wed Sep 22 02:59:57 2021 Sep 22 08:28:08 hi Sep 22 09:48:56 hi Sep 22 09:50:15 Can i connect Mini PCIe or PCIe x1 to Beagle bone x15 expansion Sep 22 09:57:06 hi Sep 22 09:58:48 If anyone know, please comment Sep 22 10:08:29 Can i connect Mini PCIe or PCIe x1 to Beagle bone x15 expansion slot Sep 22 10:26:10 Ok bye Sep 22 14:49:13 zmatt, when you have a chance, your thoughts on: https://gist.github.com/RobertCNelson/a62af1fa83ab51cb722c501080bb9e95 (systemd-networkd defaults) Sep 22 15:07:10 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 Sep 22 15:07:48 (for interfaces that do not have hardware-supplied or user-supplied mac address) Sep 22 15:07:49 zmatt, 'same' address as we used before, it's just a mess of random shell scripts, i'll clean it up for bullseye.. Sep 22 15:09:03 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) Sep 22 15:09:41 (and that's also the only way you can configure the remote mac address afaik) Sep 22 15:10:51 So, i'm working on that usb stack still, the old script that setup's the dual interfaces is here: https://github.com/rcn-ee/repos/blob/master/bb-usb-gadgets/suite/bullseye/debian/bb-start-acm-ncm-rndis-old-gadget (we can specify both mac address on either side of the usb interface) Sep 22 15:11:30 yeah, and doing it there is certainly better than doing it in a .network file Sep 22 15:11:39 I really want to use the *.scheme file: https://github.com/rcn-ee/repos/blob/master/bb-usb-gadgets/suite/bullseye/debian/bbb-acm-ncm-rndis.scheme but OS descriptos is broken on Windows 10 at the moment.. (this can also set the mac address on both sides..) Sep 22 15:12:36 I;ll nuke: #MACAddress= from usb0/usb1*.network it was more of placeholder.. Sep 22 15:13:41 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) Sep 22 15:14:22 zmatt, perfect, i didn't know that.. i'll change that.. i've really never used wpa supplicant con Sep 22 15:15:01 I have some experience with scripting wpa_supplicant via dbus Sep 22 15:16:06 mac address gone: https://github.com/rcn-ee/repos/commit/649be0716705052142254d9e73759fbd54ce345f Sep 22 15:16:53 (though unfortunately the dbus interface of wpa_supplicant is quite terrible) Sep 22 15:17:10 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.. Sep 22 15:18:04 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 Sep 22 15:19:21 something simple like that ^ would be nice.. ;) Sep 22 15:19:52 update_config=1 is pushed: https://github.com/rcn-ee/repos/commit/c128616d7141d320e296c65a7fbd6a61bde77a08 Sep 22 15:30:43 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) Sep 22 15:36:58 oh ew I just looked at its (fairly old) code... I now wish I hadn't done that, lol Sep 22 15:40:55 note btw that wpa_supplicant can also be configured fairly easily into AP mode Sep 22 15:41:15 (you don't need hostapd for simple applications) Sep 22 16:02:10 zmatt, i'm testing https://hackaday.io/project/162164/instructions?page=2 much simpler them my old mess. Sep 22 16:03:30 yeah using an udev rule to create the interface is a good idea, although it should match on KERNEL=="wlan0", not KERNEL=="wlan*" Sep 22 16:03:43 and on the "wl1835" module... Sep 22 16:04:07 our bbai "cypress" needs a different mode.. but yeah, short and simple AP enablement.. Sep 22 16:04:11 and like I said, you don't need hostapd, wpa_supplicant can do the job Sep 22 16:11:45 hmm, how did multiple interface configuration work without using dbus... Sep 22 16:13:22 oh right that requires a custom service file that specifies the config file per interface, *sigh* Sep 22 16:14:35 I think AP mode using wpa_supplicant is something like this: https://pastebin.com/cm6LEgtt Sep 22 16:15:32 I'll give that a shot, that would make things very simple for users to configure Sep 22 16:18:31 https://pastebin.com/W0VEJETU this is what I did Sep 22 17:44:05 hey guys, just a heads up, I updated the uboot loader and it fixed the problem with P8.03 not showing up in /dev/gpio Sep 22 17:44:08 thanks for the help! Sep 22 19:40:16 beaglebone ai graphics drivers? Are they available anywhere? Sep 22 19:40:28 Guest1566, 2d or 3d? Sep 22 19:42:02 3d, the powervr drivers Sep 22 19:43:32 Guest1566, https://git.ti.com/gitweb?p=graphics/omap5-sgx-ddk-um-linux.git;a=summary Sep 22 19:47:55 are they available in binary form via apt-get like on the beaglebone black? Sep 22 19:48:11 Guest1566, i never converted them.. Sep 22 19:49:49 Guest1566, the "deb" just basicliy ran the default Makefile: https://github.com/rcn-ee/repos/blob/master/ti-sgx-ti33x-ddk-um/suite/stretch/debian/rules#L6-L7 Sep 22 19:50:06 and copied these files over: https://github.com/rcn-ee/repos/blob/master/ti-sgx-ti33x-ddk-um/suite/stretch/debian/install Sep 22 19:53:50 Guest1566, jacinto6evm is build name for the bbai in that Makefile.. Sep 22 20:02:50 Okay thanks. Those are the usermode drivers, how do I get the kernel mode driver? pvrsrvkm.ko I think Sep 22 20:03:38 As I recall on the beaglebone black, matching up the right user mode and kernel mode drivers was painful. Sep 22 20:03:45 kernel module is pre-installed. ;) Sep 22 20:03:54 are you using our debian image? Sep 22 20:05:02 otherwise they are here: https://git.ti.com/gitweb?p=graphics/omap5-sgx-ddk-um-linux.git;a=summary Sep 22 20:05:23 BeagleBoard.org Debian Buster IoT TIDL Image 2020-04-06 Sep 22 20:05:56 debian@beaglebone:~$ lsmod | grep pvr Sep 22 20:05:57 debian@beaglebone:~$ dmesg | grep -i pvr Sep 22 20:05:57 debian@beaglebone:~$ Sep 22 20:06:04 not preinstalled on this version? Sep 22 20:06:32 "update_kernel.sh" auto installs the sgx module... Sep 22 20:07:43 apt install ti-sgx-jacinto6evm-modules-`uname -r` Sep 22 20:07:48 should install it.. Sep 22 20:25:21 Okay had to depmod -a after installing the package to be able to modprobe the module. Now to get the user mode drivers working... Sep 22 20:25:26 After git clone git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.gi what branch to I check out? Sep 22 20:32:49 which kernel v4.14. or v4.19? Sep 22 20:33:07 4.14.108-ti-r131 Sep 22 20:33:15 either or, I can switch to 4.19 Sep 22 20:33:35 1.14.3699939 Sep 22 20:33:50 4.19 was 1.17.4948957 Sep 22 20:35:08 i'd try: ti-img-sgx/rocko/1.14.3699939 first Sep 22 20:35:35 This repo has lots of those branches: Sep 22 20:35:37 remotes/origin/infoadas/1.14.3699939/k4.4 Sep 22 20:35:38 remotes/origin/infoadas/1.14.3699939/next Sep 22 20:35:38 remotes/origin/ti-img-sgx/1.14.3699939 Sep 22 20:35:39 remotes/origin/ti-img-sgx/1.14.3699939_k4.4 Sep 22 20:35:39 remotes/origin/ti-img-sgx/1.14.3699939_k4.4_vision_sdk Sep 22 20:35:40 remotes/origin/ti-img-sgx/morty/1.14.3699939 Sep 22 20:35:40 remotes/origin/ti-img-sgx/rocko/1.14.3699939 Sep 22 20:35:55 remotes/origin/ti-img-sgx/rocko/1.14.3699939 Sep 22 20:35:55 I'll try rocko first, but is there any rhyme or reason to the strange naming? Sep 22 20:36:07 rocko = yocto release cycle.. Sep 22 20:36:17 Guest1566: https://wiki.yoctoproject.org/wiki/Releases Sep 22 20:36:18 1.14.3699939 is a random img drop.. Sep 22 20:37:15 I'm guessing the 3699939 is like an svn commit number or something like that Sep 22 20:44:14 Thanks for the info. running eglinfo has errors though. I had to do the following first: Sep 22 20:44:21 apt-get install libgbm1 Sep 22 20:44:27 ln -s /usr/lib/arm-linux-gnueabihf/libgbm.so.1 /usr/lib/arm-linux-gnueabihf/libgbm.so.2 Sep 22 20:44:54 that's a recipe for misery Sep 22 20:45:11 Which in particular? Sep 22 20:45:24 you should not have any mesa packages installed Sep 22 20:45:33 it'll just create conflicts Sep 22 20:45:50 the reason the .so library version number is different from what it's expecting is because what it's expecting is not compatible Sep 22 20:46:26 so what is the proper way? Sep 22 20:49:24 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 Sep 22 20:50:08 but long story short, you need ti's libgbm Sep 22 20:52:48 Thanks for the link. Well read it, but the end result I'm looking for is Qt on top of EGL. Sep 22 20:53:10 yeah that should just work Sep 22 20:53:19 once you have the libraries working Sep 22 20:55:00 (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) Sep 22 20:57:21 I forgot to start the server: /usr/bin/pvrsrvctl --start --no-module. Now elginfo works using my symlinkged gbm. Sep 22 20:57:40 However, I want to address this missing libgbm.so.2 Sep 22 20:58:38 I'm surprised it works at all but maybe eglinfo doesn't result in any actual calls to libgbm Sep 22 20:59:35 The package I installed: http://repos.rcn-ee.com/debian buster/main armhf libgbm1 armhf 19.1.6-1rcnee2~buster+20200513 Sep 22 20:59:44 Is not correct? Sep 22 21:00:02 Do I need to build https://github.com/mvduin/libgbm/ instead? Sep 22 21:00:13 hmm, oh it's a libgbm built by rcn rather than the mesa one? Sep 22 21:01:18 Seems to be. Sep 22 21:02:38 Guest1566: it might be better to just use TI's rather than my forks thereof which haven't been updated in years Sep 22 21:03:01 Guest1566, our hacked version should work.. Sep 22 21:03:10 it doesn't have the right .so version though Sep 22 21:03:53 I have a vague recollection that TI switched back to using so.1 for the 1.17 drivers? I might misremember though Sep 22 21:04:12 anyway, if this is a TI libgbm then it might works fine with a symlink Sep 22 21:04:26 ian debugged it.. Sep 22 21:05:00 err damnit... i only built it for stretch.. Sep 22 21:05:05 https://github.com/rcn-ee/repos/tree/master/ti-libgbm2 Sep 22 21:05:18 so what's that package he installed? Sep 22 21:05:27 mesa's version.. Sep 22 21:05:36 libgbm head is meas.. Sep 22 21:05:56 How do I get the right libgbm2 then? Sep 22 21:06:16 you could try mine Sep 22 21:06:31 since you're using the same driver version as I used back in 2017 Sep 22 21:06:35 here's ti version... https://git.ti.com/gitweb?p=glsdk/libgbm.git;a=summary Sep 22 21:06:39 or that Sep 22 21:06:47 zmatt, probally has build fixes.. Sep 22 21:07:46 looks like TI has two new commits since my fork Sep 22 21:08:00 zmatt, am i doing this right... https://gist.github.com/RobertCNelson/4d2fbc3abc41640066361daca1576a8e match my KERNELS and DRIVERS and it'll leave everything else alone? Sep 22 21:08:04 their "Remove the unnecessary backends" sounds similar to my "remove unused crap" Sep 22 21:08:17 and they added some new feature Sep 22 21:08:22 "unnecessary" might be removing xorg support.. ;) Sep 22 21:08:29 it never had xorg support Sep 22 21:08:39 that too Sep 22 21:08:40 regardless, that wouldn't be at this layer Sep 22 21:08:43 this is lower-level Sep 22 21:09:11 Guest1566: using TI's repo is probably the best choice Sep 22 21:09:34 rcn-ee: uhhhhh Sep 22 21:09:56 rcn-ee: line 3 doesn't do anything... it consists of match rules with no actions Sep 22 21:10:19 also SUBSYSTEMS seems like a strange match criterium Sep 22 21:11:23 that KERNELS seems wrong Sep 22 21:11:52 i'd like to limit it to wl18xx_driver, added a new file to that gist.. Sep 22 21:12:18 not sure why yours is wl18xx.3.auto, on my bbbw here it's wl18xx.0.auto Sep 22 21:12:32 5.10.59-ti-r18.2 Sep 22 21:12:40 and the new sdhc driver after 5.5.x... Sep 22 21:12:46 why not match SUBSYSTEM=="net", ACTION=="add", KERNEL=="wlan0", DRIVERS=="wl18xx_driver" ? Sep 22 21:13:13 okay! that's why i asked .;) Sep 22 21:13:49 especially since otherwise your rule will also match on your newly created ap%n interface Sep 22 21:15:25 and I'd probably just write ap0 if matching specifically on wlan0 anyway Sep 22 21:15:47 you'll want those specific names anyway for the wpa_supplicant .service file Sep 22 21:17:54 okay, your last change tested on a two boards, wifi and non-wifi, next wpa settings. ;) Sep 22 21:18:02 hmm, though if you're not going to have ap0 on every target with wifi that would complicate things Sep 22 21:18:12 ap0 only showing up on wl18xx Sep 22 21:19:28 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 Sep 22 21:20:03 i need to match for wl18xx and brcmfmac.. wl18xx takes: "managed" brcmfmac takes "__ap"... Sep 22 21:20:18 ah so ap0 will exist either way, the rule is just different? Sep 22 21:21:05 exactly, just one variable.. i'm trying to specify the config option like you did with: https://github.com/beagleboard/customizations/blob/master/etc/udev/rules.d/86-remoteproc-noroot.rules Sep 22 21:21:22 So compiling that ti libgbm repo works with eglinfo. How would I *really* test it though? Sep 22 21:21:34 kmscube (ti's branch thereof) Sep 22 21:22:31 Guest1566, IMG's demo's should work too.. Sep 22 21:23:05 I vaguely recall at least one of those having never worked for me Sep 22 21:23:06 Guest1566, they put this together: https://university.imgtec.com/fun-with-beagle-gpu/ Sep 22 21:44:00 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.. Sep 22 21:50:12 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? Sep 22 21:53:56 ./OGLES2Water: error while loading shared libraries: libgbm.so.1 Sep 22 21:54:25 The libgbm I installed and compiled gave /usr/local/lib/libgbm.so.2. Sep 22 21:56:45 The rcn libgbm1 package apparently is mesa. Though if I install it, the demo works. Sep 22 21:56:58 cool Sep 22 22:01:05 Do I have a working set of libraries then? Sep 22 22:02:22 for the AM57xx no... Sep 22 22:02:33 my am335x one is here: https://beagleboard.org/latest-images Sep 22 22:03:47 So how do I get a working set of libraries for AM57xx? Sep 22 22:22:26 My qt app no worky either: Sep 22 22:22:30 QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-debian' Sep 22 22:22:30 Could not initialize egl display Sep 22 22:22:31 Aborted Sep 22 22:22:54 do not have _any_ mesa packages installed Sep 22 22:22:59 you will get crashes Sep 22 22:24:00 (that includes the libgbm1 package) Sep 22 22:25:07 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. Sep 22 22:25:54 It probably is a mesa package too. I'll have to check my notes. Sep 22 22:26:25 back when I did this qt5 packages did not depend on mesa Sep 22 22:26:30 or Sep 22 22:26:31 oh Sep 22 22:26:33 wait Sep 22 22:26:42 they did, I created my own debian packages from the userspace libs Sep 22 22:26:53 which provided the necessary dependencies for things like qt5 Sep 22 22:27:01 now I remember Sep 22 22:30:40 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. Sep 22 22:31:01 However this time it appears the ti libs are installed under /usr/lib Sep 22 22:45:13 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 Sep 22 22:45:58 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 Sep 22 22:46:32 ah perfect.. Sep 22 22:46:49 so i found a workaround for non-wifi devies: https://bbs.archlinux.org/viewtopic.php?pid=1711186#p1711186 Sep 22 22:47:08 patch "wpa" right now with: https://paste.debian.net/1212888/ Sep 22 22:48:18 that's crazy, not much needed for dbus.. Sep 22 22:48:38 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 Sep 22 22:49:46 yeah, and it's almost just as easy in C using libsystemd Sep 22 22:54:10 having the wlan0 device pull in wpa supplicant is indeed a good idea Sep 22 22:58:40 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 Sep 22 22:59:10 (and then ap0 could pull in a service that enables the access point via dbus) Sep 22 22:59:30 that way if ap0 never shows up, no problem Sep 22 23:01:06 dbus is the -O right? Sep 22 23:01:10 no Sep 22 23:01:13 -u is dbus Sep 22 23:01:18 ah! Sep 22 23:01:49 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 Sep 22 23:02:02 it's been a while since I dug into this stuff Sep 22 23:02:12 and wpa2.9 didn't have that enabled.. Sep 22 23:02:23 ? Sep 22 23:03:04 So this is with dbus added.. https://paste.debian.net/1212890/ Sep 22 23:03:27 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 Sep 22 23:03:48 and then with nl80211 and not nl80211 in bullseye.. Sep 22 23:04:06 no, don't use -u in the service template, that's a bad idea Sep 22 23:04:40 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 Sep 22 23:05:10 that's why I'm using (and suggesting) a custom wpa_supplicant.service Sep 22 23:06:06 okay nuked that. Sep 22 23:06:45 and I think nl80211 is the default Sep 22 23:07:10 probably Sep 22 23:07:32 for our wl18xx it is, the brcmfmac might not be... it's a mess.. Sep 22 23:07:53 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 Sep 22 23:09:15 brcmfmac seems to be nl80211 too based on a quick google? Sep 22 23:10:13 it must be old android or really old drivers now.. Sep 22 23:56:12 zmatt, yeah this wlan0 config works perfect.. fire up a non-wifi, stick a usb-wifi, instantly connects to wlan0.. Sep 22 23:56:49 this will be the default wlan0 location: /etc/wpa_supplicant/wpa_supplicant-wlan0.conf Sep 22 23:57:02 i'll probally setup : /etc/wpa_supplicant/wpa_supplicant-ap0.conf for the ap.. Sep 22 23:57:22 that should be easy for end users to quickly tweak for their network preferences.. Sep 22 23:57:42 using a separate (non-dbus) process/service ? Sep 22 23:58:45 yeah, either a dbus or not, something easy.. Sep 22 23:59:54 yeah, if separate processes are used (precluding having both dbus-controllable) then dbus control on wlan0 would be more useful than on ap0 Sep 23 00:04:06 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 Sep 23 00:50:48 Where can I find the correct libgbm1 source code for am57xx? Sep 23 00:51:24 22:05 < rcn-ee> https://github.com/rcn-ee/repos/tree/master/ti-libgbm2 Sep 23 00:51:43 oh right Sep 23 00:51:56 some libraries will be looking for libgbm1 rather than libgbm2 Sep 23 00:52:20 like, if you use standard debian packages for things like qt5 Sep 23 00:52:26 a symlink should deal with that Sep 23 00:53:48 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 Sep 23 00:55:38 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) Sep 23 00:56:27 which is also gross, but I was too lazy to recompile qt5 Sep 23 00:57:40 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 Sep 23 00:59:11 I'll try the simlink hack first I guess. I messed up my filesystem so I'm imaging a new card right now. Sep 23 01:00:02 another trick possible to creating an empty libgbm.so.1 that just pulls in libgbm.so.2 as dependency Sep 23 01:00:25 *is creating Sep 23 01:00:37 Well previously I was using a symlink the other way, linking to a mesa library unknowingly Sep 23 01:00:40 And that worked. Sep 23 01:01:19 Well that worked *if* those things all stayed in /usr/lib/arm-linux-gnueabihf/ Sep 23 01:01:56 define "worked" ? since what you're saying doesn't really make sense, mesa libgbm is most definitely incompatible with the sgx libraries Sep 23 01:02:31 I mean worked. I could run all the OGLES demos and my Qt application also worked. They ran without issue. Sep 23 01:03:18 and you weren't accidently using mesa egl (software rendering) ? Sep 23 01:12:42 How would I have known? Sep 23 01:12:58 Really there were two cases: Sep 23 01:13:20 First eglinfo worked. Then I installed Qt from apt and eglinfo no longer worked. Sep 23 01:13:39 Second eglinfo worked. Then I installed Qt from apt and eglinfo still worked. Sep 23 01:14:30 this information is much too vague to be useful Sep 23 01:14:55 Between case 1 and case 2 I applied the ldconfig "fix" so for me it was pretty clear Sep 23 01:15:32 Well clear that elginfo still worked. Does eglinfo work with mesa egl? Sep 23 01:15:43 of course Sep 23 01:15:59 well, I'd assume so? Sep 23 01:16:27 Well I guess that's all useless info ;p Sep 23 01:16:27 I should probably refrain from making firm statements given that it's been ages since I dug into this stuff :P Sep 23 01:17:20 I know I don't want anything mesa, but I can't stop apt from installing it and I'm not ready to repackage Qt just yet. Sep 23 01:18:12 If I knew which files belonged to mesa, then I could delete them after the packages are installed. Sep 23 01:18:17 so I didn't touch the qt packaging, rather I packaged the sgx libs and ti's libgbm such that they satisfied the dependencies of the qt packages (and conflicted with mesa's libraries thus making sure that having both installed was simply impossible) Sep 23 01:21:56 Oh. That's a better approach. How? Sep 23 01:25:21 I'd need to dig it up again... basically just stick the files together with some metadata into a directory and use dpkg-deb to build a package from it Sep 23 01:27:55 yes, but what metadata exactly ;) Earlier you said it confliced with mesa libs so just copy that metadata so it looks like the same package? Sep 23 01:28:15 copy the metadata from the mesa libs I meant Sep 23 01:28:39 no, you don't imitate the mesa package Sep 23 01:28:39 specifically libgbm1? Sep 23 01:28:52 libgbm is the only one that does need to be imitated since it's a real package and not a virtual one Sep 23 01:29:32 or at least that's how it was Sep 23 01:29:41 not sure if that's still the case Sep 23 01:30:05 potentially a better solution is using the newer drivers since I have a vague recollection that TI improved the situation Sep 23 01:31:27 I should really try to find a moment to see about getting the current drivers working and packaged and put the packaging metadata/scripts on github... but I generally have too many things I want to do :P Sep 23 01:31:52 I understand completely ;) Sep 23 01:33:14 hmm looks like libgles1 was virtual in debian stretch but is a real package (providing a "vendor-neutral dispatch layer") since buster Sep 23 01:36:20 You might as well be speaking Greek right now. I don't understand debian packaging all that well. Sep 23 01:38:46 this is that layer: https://gitlab.freedesktop.org/glvnd/libglvnd Sep 23 01:45:12 the problem with libgbm is nicely illustrated by the description of the official libgbm package: "It provides a mechanism for allocating buffers for graphics rendering tied to Mesa. Sep 23 01:45:19 _tied to Mesa_ Sep 23 01:45:50 ti's libgbm has the same purpose and API, but is tied to the sgx libraries Sep 23 01:47:52 so applications that link against libgbm are essentially tied to mesa specifically, which is a bit annoying Sep 23 01:48:09 I see. But ti versioned their libgbm as .2 Sep 23 01:48:25 yeah not sure why they did that, and they actually reverted that in the 1.17 drivers Sep 23 01:49:04 Interesting. So the right fix is to symlink .1 as .2 then ;) Sep 23 01:49:09 if you compile your system from source (like e.g. yocto does) then it doesn't matter since your programs will link to whichever version of the shared library is present at link-time Sep 23 01:49:32 I don't know what exactly the consequence is of symlinking like that Sep 23 01:49:33 We don't use yocto. We bootstrap debian. Sep 23 01:49:36 I know Sep 23 01:49:54 but TI's sdk does use yocto, so they didn't run into any problems as a result of bumping the libgbm version Sep 23 01:50:05 bastards Sep 23 01:50:19 but I'm guessing they got complaints hence rolled it back to .1 :) Sep 23 01:51:02 Well it would then conflict with the other .1 so back to the same problem symlink or no. Sep 23 01:51:09 ? Sep 23 01:51:23 the other .1 should not be installed Sep 23 01:51:34 It gets pulled in with Qt. Sep 23 01:51:49 which therefore needs to be prevented Sep 23 01:52:42 Right which means faking a libgbm package, but that only works if one is truly using egl only. Sep 23 01:52:43 but I can't spend more time on this right now, I need to go Sep 23 01:53:00 Well thanks for all the help. It's gotten me going at least. Sep 23 01:53:10 not sure what you mean by "truly using egl only" Sep 23 01:53:47 I don't understand what mesa is, but if there's any other reason to use it on the beaglebone that's all I was thinking. Sep 23 01:53:50 faking the packages definitely works, although as long as you're using the 1.14 drivers the libgbm version issue also needs to be solved (and I don't know if a symlink works correctly, I suspect it may not) Sep 23 01:54:03 mesa is an opengl implementation Sep 23 01:54:16 https://mesa.freedesktop.org/ Sep 23 01:54:35 Yeah, but ti provides opengl? Sep 23 01:54:46 Guest1566, IMG doesn't provide "opengl"... Sep 23 01:54:58 opengl is a standardized API Sep 23 01:55:08 They give us OpenGL ES... Sep 23 01:55:17 and ES2 Sep 23 01:55:41 When you just say opengl.. The "desktop" OpenGL is no where in that... Sep 23 01:56:00 yeah it's egl, gles, gles2 Sep 23 01:56:03 not gl as such Sep 23 01:56:19 I guess what I'm saying is that ti provides the libraries that any program can use so no need for mesa? Sep 23 01:56:40 Guest1566, in our case.. Mesa is a backup "software" rendering.. Sep 23 01:56:46 they implement the same api Sep 23 01:57:10 rcn-ee: well you can't have both installed at the same time in a sane way Sep 23 01:57:38 exactly, when accelerated calls are used thru EGL IMG would be used.. call and OpenGL , mesa will load.. Sep 23 01:58:12 I'd strongly advise against having any mesa library on your system if you want the sgx libraries to work Sep 23 01:58:34 Most users fire up glxgears on a BBB and like, yes OpenGL works... (thru mesa..) With the EGL we have from IMG, it's framebuffer or the old QT egl... somethign name.. Sep 23 01:58:50 old? Sep 23 01:59:17 "EGLFS" Sep 23 01:59:43 i say old, didn't qt drop that? Sep 23 01:59:51 that's a qt5 platform backend layered on egl Sep 23 01:59:52 no Sep 23 02:00:00 what would replace it? Sep 23 02:01:45 commit history of the eglfs backend shows active development and improvement: https://github.com/qt/qtbase/commits/dev/src/plugins/platforms/eglfs Sep 23 02:03:54 yeah i can't find what it was.. probally an even older backend.. Sep 23 02:04:21 qt5 also has a linuxfb backend, but that obviously doesn't involve egl/gles in any way Sep 23 02:05:11 oddly I don't think they have a "2d" (non-egl/gles) backend that uses the modern drm api instead of linuxfb Sep 23 02:06:58 actually it seems the linuxfb backend uses the drm api now? Sep 23 02:07:42 (and by "now" I apparently mean "since 2016" ... https://github.com/qt/qtbase/commit/1f81ba45eeb1a0d233bb2515c048da8743c91f6f ) **** ENDING LOGGING AT Thu Sep 23 02:59:57 2021