02:02 <zmatt> 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

02:03 <zmatt> Guest15: but the qt5 problem isn't related to drm device numbering anyway since it never opened any

02:04 <zmatt> Guest15: and -a doesn't affect selection of a drm device, it affects which monitor(s) to use on that drm device

02:04 <zmatt> (for kmscube)

03:13 <zmatt> Guest15: here's an example of how to list drm devices that support modesetting (kms): https://pastebin.com/PVnPQRTP

03:15 <zmatt> example output on my bbx15: https://pastebin.com/raw/g3qtZSUK

03:17 <Guest15> In the end it was necessary to tell Qt which device to use. Just like kmscube. Well via diferent mechanism.

03:17 <zmatt> ok, annoying

03:17 <zmatt> like, it really isn't that hard to scan for it, as my code shows

03:21 <zmatt> 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

03:36 <Guest15> 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.

03:36 <zmatt> sounds good!

05:42 <Guest15> One of the things I had to do was

05:42 <Guest15> export QT_QPA_EGLFS_INTEGRATION=egl_kms

05:42 <Guest15> export QT_QPA_EGLFS_KMS_CONFIG=/root/test.cfg

05:43 <Guest15> in that config I specify the device: "device": "/dev/dri/by-path/platform-omapdrm.0-card",

05:43 <Guest15> but I get this error: qt.qpa.egldeviceintegration: Failed to load EGL device integration "egl_kms"

05:43 <Guest15> and yet everything appears to work.

05:44 <Guest15> export QT_QPA_EGLFS_ALWAYS_SET_MODE=1

05:44 <Guest15> was required to actually make everything work.

05:45 <Guest15> apparently it should be in /etc/default/qt or something

05:45 <Guest15> https://stackoverflow.com/questions/64731435/problem-when-deploying-qt-app-on-raspberry-pi-4-could-not-queue-drm-page-flip-o

07:08 <Guest15> 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.

07:35 <Guest15> zmatt: strace of running OGLES2Water here: https://pastebin.com/Kw6bgYFt

07:35 <Guest15> I don't see anything wrong, but it's not even trying to open /dev/dri/card0.

13:28 <giort> 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?

13:28 <zmatt> no and no

13:29 <zmatt> there are several ways

13:29 <giort> Okay, can u point me to resources about programming the PRU using C?

13:29 <zmatt> including two different kernel drivers

13:30 <zmatt> the original way to program pru was using the "pasm" assembler

13:32 <zmatt> 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)

13:32 <zmatt> and pasm has some nice features atypical of assembly, like structs

13:32 <giort> So the pasm is the *recommended* way?

13:33 <zmatt> later TI also created a C/C++ compiler toolchain for pru

13:33 <zmatt> which also has its own assembler, which is however not quite compatible with pru and less human-friendly

13:33 <zmatt> *not quite compatible with pasm

13:34 <zmatt> 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

13:35 <zmatt> but still, not every application needs cycle-accurate timing, and many people find it easier to use

13:36 <zmatt> 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

13:37 <giort> what is the command for the compiler on the BB? I have the newest image.

13:38 <zmatt> 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 ...

13:38 <zmatt> ...clpru (the compiler toolchain)

13:42 <zmatt> 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 ...

13:42 <zmatt> ...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)

13:42 <zmatt> oh and the command is clpru, its invocation is not similar to gcc

13:43 <zmatt> 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

13:44 <zmatt> (switching the driver can be done via the uboot_overlay_pru variable in /boot/uEnv.txt )

13:47 <zmatt> so overall your choices are: pasm + libprussdrv, pasm + py-uio, clpru + py-uio, clpru + remoteproc

13:48 <giort> okay, thanks for all the info!

13:48 <zmatt> 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

20:35 <kveremitz> zmatt: you should publish a FAQ :P