00:00 <zmatt> the usual suspect

00:00 <zmatt> fortunately dtc always provides helpful diagnostics, like TOKEN ERROR or something ;D

00:00 <jkridner> rebooting

00:01 <jkridner> gack. I must be missing the right symlink udev rule---or the driver didn't load.

00:02 <jkridner> hmmm... nothing 'uio' in dmesg

00:02 <zmatt> has the driver even been built? CONFIG_UIO_PDRV_GENIRQ

00:03 <jkridner> CONFIG_UIO=m CONFIG_UIO_PDRV_GENIRQ is not set

00:04 <zmatt> well there ya go

04:59 <ds2> hmmmm

05:48 <Guest5432> whether Beaglebone supports Python and matlab codes for audio signal processing?

19:22 <RMoll> Hey all, I've been struggling to get the SGX/PVR drivers running with LXQT installed. Anytime libgbm.so.2 shows up in my /usr/lib/, lightdm doesn't start correctly. If I remove it, pvr fails to load. Thoughts?

19:25 <zmatt> the sgx drivers are incompatible with x11

19:26 <zmatt> they're also a pain to get working in general, but you're not going to get them working with lightdm at all

19:27 <RMoll> Oh.. Ok. Then to clarify my understanding, is the LXQT image of debian stretch hardware accelerated? We've been trying to run some gui apps ad I feel like we are not able to use the GPU

19:28 <zmatt> no, since the gpu does not support x11

19:28 <zmatt> (or rather, the gpu drivers)

19:28 <RMoll> Oh.. Ok. Then to clarify my understanding, is the LXQT image of debian stretch hardware accelerated? We've been trying to run some gui apps and I feel like we are not able to use the GPU

19:28 <RMoll> (sorry for the double post)

19:28 <zmatt> also, debian stretch is extremely ancient

19:28 <zmatt> and obsolete/unmaintained

19:29 <RMoll> I agree that its pretty dated, however, the recommended image from "latest images" is OMAP3/DM3730 Debian 9.5 2018-10-07 4GB SD LXQT

19:30 <zmatt> ohh, for the old beagleboard

19:30 <RMoll> TI_AM335x_BeagleBone_Black

19:30 <zmatt> beaglebone black isn't omap3

19:31 <zmatt> the beaglebone black uses an AM3358

19:31 <RMoll> oh, right, i meant Debian 9.9 2019-08-03 4GB SD LXQT

19:31 <zmatt> the latest recommended image for which is the AM3358 Debian 10.3 2020-04-06 4GB SD IoT

19:32 <zmatt> (or generally its eMMC flasher equivalent, AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher )

19:32 <zmatt> note that the IoT image doesn't include a GUI, since almost nobody uses one on a beaglebone

19:32 <RMoll> I was having issues getting any sort of graphics working on the buster images, maybe I missed something

19:33 <zmatt> the AM335x is targeted at industrial applications and has very limited graphics capabilities, mostly intended just for simple touchscreen interfaces

19:34 <RMoll> which is exactly what my company uses them for. I'm trying to get them away from the old unmaintained qt-over-vnc touch interface that they hacked together for debian 7

19:34 <zmatt> qt5 can run directly on the framebuffer, without x11

19:35 <zmatt> with gpu (eglfs backend) or without (linuxfb backend)

19:35 <RMoll> is https://elinux.org/BeagleBoneBlack/SGX_%2B_Qt_EGLFS_%2B_Weston compatible with the buster images?

19:36 <RMoll> I felt i had problems trying to get a framebuffer/kmscube running

19:36 <zmatt> I know there are people who have things working, but I don't know if they've been kind enough to do any sort of write-up

19:37 <zmatt> that wiki page looks outdated to me

19:38 <RMoll> it's really about all I've found on how to get sgx/pvr running correctly, but again, I'm not sure

19:38 <RMoll> and it gets close, but it feels like something is missing

19:39 <zmatt> rcn-ee: I forgot, are the sgx userspace libs packaged nowadays?

19:39 <zmatt> I know the kernel drivers are

19:42 <zmatt> RMoll: sorry, I haven't done anything with graphics on the bbb for many many years, so I don't really have any uptodate guidance

19:43 <zmatt> I know the gpu can be made to work

19:43 <RMoll> All good, the insights you've provided about the gpu drivers already answered many of my questions

19:43 <zmatt> but it may also be worth evaluating qt5 with the linuxfb backend

19:44 <RMoll> in general, if kmscube runs, then gpu accel is working?

19:44 <zmatt> iirc, back when I did, the linuxfb backend (without gpu) actually resulted in faster execution than the eglfs backend (with gpu). we ended up using eglfs anyway because the linuxfb backend back then didn't support double-buffering hence caused noticable flickering, but I think that's been fixed nowadays

19:45 <zmatt> (iirc qt5's "linuxfb" backend these days actually supports using dri/kms instead of the legacy fbdev kernel interface)

19:47 <zmatt> unless you actually *need* opengl es/es2, e.g. for 3d rendering, then you'll obviously want to get the gpu working

19:48 <RMoll> we wanted to see if we could get .NET 5+ to run targetting the framebuffer or drm, from https://github.com/AvaloniaUI/Avalonia. Might be too uch to ask from the bbg it sounds like

19:49 <RMoll> I do have it able to run outputting directly to the FB, but we were unsure about input performance since X server tends to take care of mouse inputs

19:50 <zmatt> not sure what you mean, obviously inputs will be faster / more efficient *without* an extra middle-man like x11

19:52 <RMoll> We couldn't test touch inputs because once we lose access to X, we can't seem to provide human input to the application

19:53 <zmatt> sounds like some kind of configuration issue, or a permissions issue... make sure the user running the application (presumably the "debian" user") is a member of the "input" group

19:53 <zmatt> which can be fixed by doing "sudo adduser debian input" and then logging out and back in

19:53 <RMoll> good idea, i'll check

19:56 <RMoll> ls