**** BEGIN LOGGING AT Thu Sep 23 02:59:57 2021 Sep 23 04:46:40 hi Sep 23 04:47:20 i buy stuff and use it for things Sep 23 04:47:31 and like, i guess i get excited about it and stuff Sep 23 04:47:34 so Sep 23 12:43:37 vd: A while back you asked what is ldo3. It is the regulator for the adc on the am335x. Sep 23 14:43:17 not just the adc, it's the main 1.8v regulator (I answered that already a bit ago) Sep 23 20:05:07 @zmatt @rcn_ee Just wanted to report back that my Qt app is working on top of eglfs on the beaglebone ai. However, the issue with libgbm.1 remains. I put all the ti libs (both libgbm and the user mode libs) into /usr/local/lib/arm-linux-gnueabihf and that's at the top of /etc/ld.so.conf.d/arm-linux-gnueabihf.conf. This puts the ti libs first in Sep 23 20:05:07 the library search order so the right library always gets used, except for libgbm.1. I tried making a symlink to libgbm.2, but lddconfig doesn't 'see' the symlink (rightfully so). The solution then is to compile ti's libgbm as both libgbm.1 and libgbm.2. I think... Sep 23 20:05:55 no you don't want two copies of the library loaded in Sep 23 20:06:02 that is a recipe for crashes Sep 23 20:06:18 most likely Sep 23 20:07:03 maybe it would work since iirc libgbm is mostly a shim, but there's no reason to find out Sep 23 20:08:04 though if you say you have it working somehow, what issue remains exactly? Sep 23 20:08:21 like, I'm not quite clear on that Sep 23 20:09:12 or rather, I'm not really clear how exactly you have it working Sep 23 20:11:51 If there are two copies of the same library what's the issue? Don't the functions get suffixed with the version of the library? Sep 23 20:12:02 they don't Sep 23 20:12:30 by default, all symbols from all shared libraries loaded into an application (along with those of the application itself) get dumped into a single namespace Sep 23 20:12:58 in case of conflicts, it will simply use whichever comes first in the load-order Sep 23 20:13:47 So if it's the same copy of the library, sounds like the conflict will resolve itself? Sep 23 20:14:13 I know the real answer here is to recompile Qt. Sep 23 20:14:40 it may or it may not, I've absolutely seen crashes due to multiple copies of shared state, but whether that will happen in practice will depend on details Sep 23 20:17:51 recompiling everything that might reference libgbm seems like an act of desperation and wouldn't be my solution tbh Sep 23 20:19:40 gcc -shared -Xlinker -soname=libgbm.so.1 -o libgbm.so.1 -L/usr/local/lib -lgbm Sep 23 20:19:59 that would create a libgbm.so.1 that simply pulls in libgbm.so.2 Sep 23 20:20:39 (assuming /usr/local/lib/libgbm.so is a symlink to libgbm.so.2) Sep 23 20:40:53 Unfortunately ldconfig is still picking up the wrong libgbm.so.1 Sep 23 20:40:55 root@beaglebone:/usr/local/lib/arm-linux-gnueabihf# ldconfig -p | grep libgbm Sep 23 20:40:56 libgbm.so.2 (libc6,hard-float) => /usr/local/lib/arm-linux-gnueabihf/libgbm.so.2 Sep 23 20:40:56 libgbm.so.1 (libc6,hard-float) => /usr/local/lib/arm-linux-gnueabihf/libgbm.so.1 Sep 23 20:40:57 libgbm.so.1 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libgbm.so.1 Sep 23 20:40:57 libgbm.so (libc6,hard-float) => /usr/local/lib/arm-linux-gnueabihf/libgbm.so Sep 23 20:41:56 this seems fine? it finds the one in /usr/local first Sep 23 20:42:31 But there are two entires? Shouldn't ldconfig show me the ones it will actually use? Sep 23 20:42:51 evidently it reports everything it found Sep 23 20:43:22 regardless of one shadowing the other Sep 23 20:43:53 Is there a way to see which library a running binary is using? Sep 23 20:44:26 ldd /path/to/program Sep 23 20:44:41 running one... there's a way to do that too I think Sep 23 20:46:05 ls -l /proc/$PID/map_files/ (where $PID is the pid of the program you want to examine) shows all files mapped into the program's address space, including shared libraries Sep 23 20:48:01 so to just list shared libraries: readlink /proc/$PID/map_files/* | grep -P '\.so(\.\d+)*$' | sort -u Sep 23 20:51:16 ldd is reporting the correct library on the binary and seems like the correct library being used: Sep 23 20:51:19 root@beaglebone:~# readlink /proc/3694/map_files/* | grep libgbm | sort -u Sep 23 20:52:29 So this guarantees no mesa libraries are being used, correct? Sep 23 20:53:00 Ooops, for some reason it didn't paste everything. Sep 23 20:53:02 don't try to paste multi-line output into chat, it doesn't work (or when it does, it's spammy) Sep 23 20:53:36 /usr/local/lib/arm-linux-gnueabihf/libgbm.so.1 Sep 23 20:53:43 /usr/local/lib/arm-linux-gnueabihf/libgbm.so.2.0.0 Sep 23 20:53:54 yep that's fine Sep 23 20:54:02 since that libgbm.so.1 is empty Sep 23 20:55:17 So the issue here is that some binaries (like the imagetec ones) depend on both libgbm.1 and libgbm.2, meanwhile the Qt libs depend only on libgbm.2 it seems. Sep 23 20:55:36 the sgx libs depend on libgbm.so.2 Sep 23 20:55:53 any dependency on libgbm from a debian package will be libgbm.so.1 Sep 23 20:57:40 direct dependency on libgbm.so.1 is quite rare i think Sep 23 20:58:20 Ah, that's what's happening then beause libgbm.so points to libgbm.so.2. Sep 23 20:59:50 qt5's eglfs depends on libgbm.so.1 Sep 23 21:00:14 (or rather, depends on libgbm, hence the debian packaged qt5 depends on libgbm.so.1) Sep 23 21:02:03 Erm... My qt app is telling me: Sep 23 21:02:05 libgbm.so.2 => /usr/local/lib/arm-linux-gnueabihf/libgbm.so.2 (0xb5402000) Sep 23 21:02:20 with ldd. It's using the eglfs backend. Sep 23 21:02:52 that'll be pulling in via indirect dependency, presumably via egl/gles Sep 23 21:03:23 the libgbm.so.1 dependency comes from libqeglfs-kms-integration.so which is loaded at runtime hence ldd doesn't know about it Sep 23 21:04:32 ### QT Environment Variables ### Sep 23 21:04:32 export QT_QPA_PLATFORM=eglfs Sep 23 21:04:33 export QT_QPA_EGLFS_INTEGRATION=non Sep 23 21:05:34 pretty sure "none" is not valid Sep 23 21:06:12 but you know now how to list all shared libraries loaded at runtime so you can easily check Sep 23 21:06:56 https://doc.qt.io/qt-5/embedded-linux.html Sep 23 21:07:13 yes I read it Sep 23 21:07:43 Then I won't paste the part where it says None means no plugin loaded. Sep 23 21:07:44 none applies to qt5 custom-built for some specific boards Sep 23 21:08:02 it's a bit vague about which exactly Sep 23 21:08:48 maybe I'm wrong Sep 23 21:08:51 unset QT_QPA_EGLFS_INTEGRATION Sep 23 21:08:56 root@beaglebone:~/qml-test2# ./qml-test2 Sep 23 21:08:57 QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' Sep 23 21:08:58 failed to load module: /usr/local/lib/gbm/gbm_pvr.so: cannot open shared object file: No such file or directory Sep 23 21:08:58 Could not create GBM device () Sep 23 21:08:58 Could not open DRM device Sep 23 21:08:59 Aborted Sep 23 21:09:07 hmm Sep 23 21:09:41 and if you set it to eglfs_kms ? Sep 23 21:10:04 it might be trying to use X11 Sep 23 21:10:13 Same result. Sep 23 21:10:24 root@beaglebone:~/qml-test2# ./qml-test2 Sep 23 21:10:24 QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' Sep 23 21:10:25 qt.qpa.egldeviceintegration: Failed to load EGL device integration "elgfs_kms" Sep 23 21:10:25 failed to load module: /usr/local/lib/gbm/gbm_pvr.so: cannot open shared object file: No such file or directory Sep 23 21:10:26 Could not create GBM device () Sep 23 21:10:26 Could not open DRM device Sep 23 21:10:27 Aborted Sep 23 21:10:50 you did a typo Sep 23 21:10:57 elgfs_kms instead of eglfs_kms Sep 23 21:11:56 Sorry about that. Sep 23 21:12:03 root@beaglebone:~/qml-test2# export QT_QPA_EGLFS_INTEGRATION=eglfs_kms Sep 23 21:12:04 root@beaglebone:~/qml-test2# ./qml-test2 Sep 23 21:12:04 QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' Sep 23 21:12:05 failed to load module: /usr/local/lib/gbm/gbm_pvr.so: cannot open shared object file: No such file or directory Sep 23 21:12:05 Could not create GBM device () Sep 23 21:12:06 Could not open DRM device Sep 23 21:12:06 Aborted Sep 23 21:12:22 curious, okay then I'm not sure how libgbm.so.1 is getting pulled in Sep 23 21:12:36 there's probably some other qt5 component that pulls it in Sep 23 21:13:24 libgbm.so.1 is not getting pulled in from what I can tell though Sep 23 21:13:40 earlier you showed it was Sep 23 21:13:43 Just on OGLESWater does it get pulled in Sep 23 21:13:47 21:53 < Guest15> /usr/local/lib/arm-linux-gnueabihf/libgbm.so.1 Sep 23 21:14:03 Right. My apologies if I wasn't clear. Sep 23 21:14:39 When I run ldd or look at /proc/$PID/map_files, only libgbm.so.2 appears for my Qt app. Sep 23 21:14:42 so then that's why it worked without the symlink: libgbm.so.1 wasn't getting pulled in Sep 23 21:14:56 without the shim or symlink or anything else I mean Sep 23 21:15:26 Yes. I didn't realise that OGLESWater has that strict dependency on libgbm.so.1 probably because it's not a debian package. Sep 23 21:15:49 that sentence makes no sense Sep 23 21:16:06 any debian package that depends on libgbm depends specifically on libgbm.so.1 Sep 23 21:16:21 But Qt is a debian package? Sep 23 21:16:32 the only thing that depends on libgbm.so.2 is TI's sgx libraries Sep 23 21:16:42 qt doesn't depend on libgbm directly Sep 23 21:16:56 (except for the eglfs_kms integration, which depends on libgbm.so.1) Sep 23 21:18:22 Are there any other debian packages that depend on libgbm.so.1? How can I find out? Sep 23 21:18:34 apt-cache rdepends libgbm1 Sep 23 21:20:40 kmscube package depends on libgbm1. After installing and running: Sep 23 21:20:47 kmscube: symbol lookup error: kmscube: undefined symbol: gbm_bo_unmap Sep 23 21:21:33 https://git.ti.com/gitweb?p=glsdk/kmscube.git;a=summary Sep 23 21:22:42 So it's expected then that programs with dependency on libgbm1 won't work? Sep 23 21:22:47 yep Sep 23 21:22:52 or maybe they do Sep 23 21:22:55 who knows Sep 23 21:23:18 depends on whether they use functionality that doesn't exist in TI's fork of libgbm Sep 23 21:23:37 I'm under the impression that libgbm.so.1 and libgbm.so.2 implement the same api? Sep 23 21:23:51 mostly yes, but I guess mesa added stuff Sep 23 21:25:33 So we're back to the real problem. For my usecase, I'm fine using only qt. But for anyone else wanting to use ti's libgbm as a replacement they're screwed. Sep 23 21:26:57 depends on what libgbm functionality they use Sep 23 21:27:18 most of the API is the same, mesa just added more stuff over time Sep 23 21:28:45 such as gbm_bo_map/gbm_bo_unmap Sep 23 21:29:33 So if I were to remove the libgbm.so.1 shim library and let the system use mesa's libgbm.so.1 the result would be software rendering, but otherwise no ill effects? Sep 23 21:29:47 no the result would almost certainly be crashes Sep 23 21:30:04 libgbm has no way to affect what rendering is used Sep 23 21:30:27 and you'd end up using a mix of symbols from the two libgbms Sep 23 21:31:19 in effect, passing the struct gbm_device* from one library to another library where that internal struct has different contents Sep 23 21:31:32 So no guarantee that ti's libgbm will be a direct replacement for debian packages. Sep 23 21:31:58 it's just an older version of the api Sep 23 21:32:27 Right, but for any newbie trying to get their 3d accelerated video working there's not out of box solution. Sep 23 21:32:48 those people generally has no reason to directly use libgbm Sep 23 21:33:11 Right, but here I am trying to use Qt... Sep 23 21:33:17 point in case: your qt5 application doesn't use it directly, nor does any part of qt5 except specifically the eglfs_kms library Sep 23 21:33:21 right, and that works now Sep 23 21:33:29 but not out of box Sep 23 21:35:01 not sure what your point is... especially since the main thing you've done is installed the sgx libs and TI's libgbm into /usr/local and configured it into the search dirs for the dynamic linker Sep 23 21:35:17 (you could also install it into a random directory and use LD_LIBRARY_PATH probably) Sep 23 21:36:03 my point is only that a new user who buys a beagbone because acclerated graphics is advertised gets into a world of hurt trying to make it work. Sep 23 21:36:04 creating the libgbm.so.1 with my trick turned out unnecessary for your use-case Sep 23 21:36:25 it's advertised? Sep 23 21:36:47 hmm Sep 23 21:37:33 Only that it has "Dual-core PowerVR® SGX544™ 3D GPU". There's no indication you can't use it. Sep 23 21:37:40 yeah I think those are just meant as hardware specs rather than listing stuff that works out of the box but I agree that's misleading Sep 23 21:38:02 the gpu has unfortunately always been a hassle Sep 23 21:38:15 (on every TI SoC afaik) Sep 23 21:39:01 Yes I struggled for awhile with beaglebone black. I was hoping I could use what I learned here to improve the situation somehow. Sep 23 21:44:56 I think the least worst case might be to have rcn-ee libgbm1 package provide both libgbm.so.1 and libgbm.so.2 using the trick you suggested. Sep 23 21:45:15 the libgbm1 package is mesa Sep 23 21:45:58 Well mesa and ti can't coexist. Sep 23 21:46:05 correct Sep 23 21:48:01 So why can't ti replace mesa? It won't work everywhere, but at least you don't get the mixed library situation. Sep 23 21:50:07 Or is the real fix libglvnd? Sep 23 21:52:16 I'd need to test if a Provides: declaration works for non-virtual packages, I seem to recall it didn't but that might be different now Sep 23 21:53:00 if it doesn't then there's no real fix possible other than providing manually installed debian packages or a special separate repo Sep 23 21:53:15 since the package would have to be named libgbm1 to satisfy the dependency from qt5 Sep 23 21:53:32 which would break things for everyone using mesa (intentionally or not), including everyone using X11 Sep 23 21:54:34 Only if X11 is using parts of the api not implemented. But even still shouldn't the priority then be to patch ti libgbm? It doesn't sound like it does a whole lot other than buffer creation? Sep 23 21:55:10 no, it would break X11 period Sep 23 21:56:05 actually I have no idea what would happen... it would use the buffer allocation routines from the sgx libraries Sep 23 21:56:22 at the very least it would add a hard dependency on the sgx libraries, while there are definitely people who don't want them on their system Sep 23 21:56:29 (because closed-source) Sep 23 21:58:13 But *if* the apis were compatible, how the memory was allocated shouldn't matter. Sep 23 21:58:53 not sure that's true, I don't know enough about how libgbm works in mesa vs the sgx libs Sep 23 21:58:59 regardless, the api isn't compatible Sep 23 21:59:25 and it would still break anything that uses mesa functionality not available in the sgx libs Sep 23 21:59:28 such as opengl Sep 23 21:59:43 (since sgx is only opengl ES and opengl ES2) Sep 23 22:00:27 and anything that tries to use any flavor of opengl on x11 in general Sep 23 22:02:29 Right. So the bottom line is that sgx libs don't provide a direct replacement for mesa. Sep 23 22:02:40 correct Sep 23 22:06:08 If that's the case, then naming libgbm.so.2 that way was not a bad thing. The system can still work with libgbm.so.1 (from mesa). Qt on top of eglfs works fine with libgbm.so.2. Or do I have it wrong? Sep 23 22:07:17 until both libgbms accidently get loaded into one application and it crashes Sep 23 22:08:01 and "the system" can't work with mesa's libgbm since it is designed to work with mesa, not with the sgx libs Sep 23 22:08:14 which won't be found if they're shadowed by the sgx libs Sep 23 22:08:46 *mesa's libs won't be found Sep 23 22:08:50 Right, but in that case, LD_LIBRARY_PATH should be used with Qt. Sep 23 22:09:04 that could be a solution Sep 23 22:09:15 The ti libs should NOT be installed into the standard libraries Sep 23 22:10:09 well, that's your opinion... I wouldn't want mesa installed on a bbb Sep 23 22:10:40 The ti libs can only be used with select programs though. Debian packages depend on mesa. Sep 23 22:11:17 almost none do Sep 23 22:12:04 and this also doesn't really matter, in the rare case I'd want to use opengl on a BBB, I certainly wouldn't want to use software rendering Sep 23 22:12:30 so anything that doesn't work with the sgx libs would simply be "doesn't run, too bad" for me Sep 23 22:13:07 there's no perfect solution here Sep 23 22:13:11 Right, but you know what you're doing... The average user doesn't. Sep 23 22:13:14 just different compromises Sep 23 22:13:26 the average user uses the BBB headless Sep 23 22:13:36 or uses mesa Sep 23 22:13:58 That's my point. Sep 23 22:14:21 given the restrictions of using the sgx libs, that's never going to change Sep 23 22:14:23 Somewhere the compromises should be documented so the user can decide what to do. Sep 23 22:14:30 would be nice yes Sep 23 22:14:36 the process can certainly be made easier Sep 23 22:14:51 it's just something few people care about hence little effort has been put into it Sep 23 22:15:26 Well I'm happy to try to write something up, but honestly I don't know enough to get it right. Sep 23 23:44:50 Oh. Sep 23 23:45:37 @zmatt: I just saw your 1.8v regulator notification of the answer. Anyway, GenTooMan: https://www.hackster.io/news/miniature-light-tracking-beam-robot-6020b229a453 Sep 23 23:45:40 No MCU! Sep 23 23:45:48 teeny motors! Sep 24 01:55:27 @zmatt: What else is handled at 1.8v on the BBB (am335x)? Sep 24 01:57:42 Is there other circuitry that baffles youngin' types like me on the BBB that the ldo3 is dispersing 1.8v to/from? **** ENDING LOGGING AT Fri Sep 24 02:59:56 2021