**** BEGIN LOGGING AT Fri Oct 01 02:59:56 2021 Oct 01 03:02:12 Guest15: dunno, but kmscube's logic to find displays is completely different from that of qt5 so investigating one is not particularly useful to find out how to get the other working Oct 01 03:03:34 Guest15: but the qt5 problem isn't related to drm device numbering anyway since it never opened any Oct 01 03:04:48 Guest15: and -a doesn't affect selection of a drm device, it affects which monitor(s) to use on that drm device Oct 01 03:04:52 (for kmscube) Oct 01 04:13:15 Guest15: here's an example of how to list drm devices that support modesetting (kms): https://pastebin.com/PVnPQRTP Oct 01 04:15:09 example output on my bbx15: https://pastebin.com/raw/g3qtZSUK Oct 01 04:17:04 In the end it was necessary to tell Qt which device to use. Just like kmscube. Well via diferent mechanism. Oct 01 04:17:14 ok, annoying Oct 01 04:17:25 like, it really isn't that hard to scan for it, as my code shows Oct 01 04:21:06 if you do manually specify a path, be sure to use the symlink in /dev/dri/by-path/ since that should hopefully be stable, avoid hardcoding a /dev/dri/card* path since those are arbitrary and may vary depending on kernel version, dt, lunar phase, etc Oct 01 04:36:29 yup, using the by-path. There was also another problem that prevented it working. I'd like to put a working 'recipe' together since the one for the 1.14 drivers doesn't even remotely apply. Oct 01 04:36:44 sounds good! Oct 01 06:42:16 One of the things I had to do was Oct 01 06:42:19 export QT_QPA_EGLFS_INTEGRATION=egl_kms Oct 01 06:42:24 export QT_QPA_EGLFS_KMS_CONFIG=/root/test.cfg Oct 01 06:43:03 in that config I specify the device: "device": "/dev/dri/by-path/platform-omapdrm.0-card", Oct 01 06:43:21 but I get this error: qt.qpa.egldeviceintegration: Failed to load EGL device integration "egl_kms" Oct 01 06:43:28 and yet everything appears to work. Oct 01 06:44:03 export QT_QPA_EGLFS_ALWAYS_SET_MODE=1 Oct 01 06:44:11 was required to actually make everything work. Oct 01 06:45:15 apparently it should be in /etc/default/qt or something Oct 01 06:45:23 https://stackoverflow.com/questions/64731435/problem-when-deploying-qt-app-on-raspberry-pi-4-could-not-queue-drm-page-flip-o **** BEGIN LOGGING AT Fri Oct 01 07:03:39 2021 Oct 01 08:08:58 Also, I modified the dts file to disable the bb2d device. That allowed platform-omapdrm.0-card -> ../card0. This allows kmscube to work without any arguments, but the img-pvr-demos still don't work. Oct 01 08:35:10 zmatt: strace of running OGLES2Water here: https://pastebin.com/Kw6bgYFt Oct 01 08:35:24 I don't see anything wrong, but it's not even trying to open /dev/dri/card0. Oct 01 14:28:29 hey everyone. Im trying to get started with the BBB PRU development. Is it correct, that the PRU can only be programmed in assembly and using the CCStudio from TI? Oct 01 14:28:42 no and no Oct 01 14:29:09 there are several ways Oct 01 14:29:12 Okay, can u point me to resources about programming the PRU using C? Oct 01 14:29:24 including two different kernel drivers Oct 01 14:30:06 the original way to program pru was using the "pasm" assembler Oct 01 14:32:03 the pru instruction set was designed for assembly programming by humans since that's the only way to fully take advantage of pru's deterministic timing (e.g. to create custom external hardware interfaces using gpio in software) Oct 01 14:32:23 and pasm has some nice features atypical of assembly, like structs Oct 01 14:32:43 So the pasm is the *recommended* way? Oct 01 14:33:05 later TI also created a C/C++ compiler toolchain for pru Oct 01 14:33:31 which also has its own assembler, which is however not quite compatible with pru and less human-friendly Oct 01 14:33:38 *not quite compatible with pasm Oct 01 14:34:33 the code quality of the C/C++ compiler is also not that great, partly because the pru instruction set was never designed to be targeted by a C compiler (e.g. it has no signed integer comparison), partly because the compiler is just not very smart Oct 01 14:35:19 but still, not every application needs cycle-accurate timing, and many people find it easier to use Oct 01 14:36:11 you don't need ccstudio to use the toolchain, the compiler is available as separate download and is preinstalled on the beaglebone if you're running a not-too-ancient image Oct 01 14:37:12 what is the command for the compiler on the BB? I have the newest image. Oct 01 14:38:48 like I mentioned there are two kernel drivers: the older uio-pruss gives userspace direct access to the PRU subsystem and has it handle everything. for code loading there's an old crusty C library (libprussdrv) which only supports raw binaries produced by pasm and my py-uio python library ( https://github.com/mvduin/py-uio ) which supports both raw pasm binaries as well as ELF executables produced by ... Oct 01 14:38:54 ...clpru (the compiler toolchain) Oct 01 14:42:00 the newer remoteproc-pru has the kernel perform code loading, which only supports ELF executables (no pasm binaries) and gives userspace extremely limited access. this is now the "official" way to use pru but functionally it is much more limited than uio-pruss. the "preferred" way for userspace to interact with PRU when using remoteproc-pru is rpmsg, which is a bloated overcomplicated messaging ... Oct 01 14:42:06 ...protocol that's terrible for performance (and destroys any hope of determinism), causing people to use ugly workarounds like directly poking pru subsystem memory via /dev/mem, at which point it would have been saner to stick with uio-pruss which allows one to do so a bit more safely (and without requiring root privileges) Oct 01 14:42:21 oh and the command is clpru, its invocation is not similar to gcc Oct 01 14:43:44 my py-uio project (which, as the name implies, only supports the uio driver and not remoteproc) includes two examples in C compiled with clpru: https://github.com/mvduin/py-uio/tree/master/pru-examples/fw-c Oct 01 14:44:32 (switching the driver can be done via the uboot_overlay_pru variable in /boot/uEnv.txt ) Oct 01 14:47:18 so overall your choices are: pasm + libprussdrv, pasm + py-uio, clpru + py-uio, clpru + remoteproc Oct 01 14:48:44 okay, thanks for all the info! Oct 01 14:48:57 I hope this info dump helps to get you started, I'll be around later if you have more questions, but I need to go now for a bit Oct 01 21:35:48 zmatt: you should publish a FAQ :P **** ENDING LOGGING AT Sat Oct 02 02:59:57 2021