**** BEGIN LOGGING AT Tue Jan 05 03:01:24 2021 Jan 05 03:09:04 Is there a way to put a live stream on a display w/ the BBB attached? Jan 05 03:09:18 Outside of it being slow motion... Jan 05 03:09:25 Is there still a way? Jan 05 03:10:38 I am asking b/c I have this display, a BBGG, and the CapeDisplay works but I am not sure how to promote displays to the point where they will show up on the Display in question. Jan 05 03:11:25 Or...is that what the GPU is for? Jan 05 03:12:19 I can get a sign in screen and terminal for now. Would I just bring the running source to the fg. Jan 05 03:13:16 And...I guess make some rules for processes? Jan 05 03:14:50 For instance... Jan 05 03:14:51 OH. Jan 05 03:14:55 Nope. Jan 05 03:15:04 Well. Jan 05 03:20:51 Dang it. I will wait. After my day, sleep may be more...zzzzzz. Jan 05 03:47:40 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfc in position 184: invalid start byte <<< This is my error. I know it is almost 10:00. I am using pyinstaller w/ a pyqt app to run on a display. Jan 05 03:48:05 I am most likely going about it incorrectly. I will stay patient and read on. Chive! Jan 05 03:53:44 Dang it. "Could not connect to any X Display" Jan 05 03:53:51 Seven minutes! Jan 05 03:55:32 Send in rations! Jan 05 04:43:47 Can anyone suggest the best way to find a beaglebone developer for embedded linux systems - specifically with experience in motor controllers for a upcoming commercial appliance? Jan 05 09:14:44 set_: if you need to use a "pyqt app" which "could not connect to any X display" on BBB, but you simply need access to a display server for a basic traditional cursor-based shell for this app, you can consider whether llvmpipe 3D performance will be sufficient for your purpose Jan 05 09:18:29 this is possible and straightforward to achieve with BBB's HDMI output, i believe xserver-xorg-video-vesa is the debian package, however, glxgears performance for me on am3358 llvmpipe is ~10fps. if you do in fact want "a live stream on display" without it "being in slow motion", welllll... Jan 05 09:19:15 yes, this is indeed "what the GPU is for" - welcome to the club, get settled in with the text wall of progress we've made so far in debian 10 Jan 05 09:23:57 if you were in fact able to successfully cross compile the TI SGX DDK kernel module for a recent kernel that day, you may have luck doing so for the user space portion as well, an afaik as yet unconquered milestone which has so far confined me to an older kernel and ddk release Jan 05 14:35:08 if i was looking to register a pocketbeagle as a peripheral on usb1, what drivers need to be loaded/ how to get it to be recognized as an additional serial port? Jan 05 15:14:07 Konsgn: if it's enabled in DT with dr-mode="peripheral"; then you should be able to configure it as whatever kind of gadget you want via configfs Jan 05 15:16:26 as in like described here:https://elinux.org/images/e/ef/USB_Gadget_Configfs_API_0.pdf Jan 05 15:17:35 yeah, same as how usb0 is setup Jan 05 15:18:09 sweet, thank you! Jan 05 15:18:11 I don't know if the old legacy gadget drivers like g_serial can be used on a secondary gadget port... maybe there's some way to specify which gadget device to use, dunno Jan 05 15:22:12 looks like the legacy gadget drivers will just use the first gadget port that doesn't already have a driver Jan 05 15:24:43 (so a "modprobe g_serial" would also work, provided it's done after the usb0 gadget has been setup) Jan 05 15:25:56 hmmm. also i enabled debug on i2c, flooded my /var/log, and am now trying to recover it from uboot by at least turning off the custom dts. i am trying to: ext4load mmc 0 0x80000000 /boot/uEnv.txt 100, but it keeps not loading the file to memory. Jan 05 15:26:36 if there is already a g_serial, is there an option for modprobe to point it to usb1? Jan 05 15:26:42 lol, use dynamic debug at runtime, it's faster and more selective ;) Jan 05 15:27:01 no, but the default gadget on usb0 doesn't use g_serial Jan 05 15:27:04 haven't fully figured out how to do that. Jan 05 15:27:14 great, thank you! Jan 05 15:27:45 afaik you can't create two instances of a legacy gadget driver, at that point you'd really have to switch to configfs Jan 05 15:27:57 side story, tried out wsl2, was great but now my vbox doesnt work and i cant mount my ext4 sd on windows *facepalm Jan 05 15:28:55 and I don't think I've ever seen "ext4load" ... this is my notes on manually booting an image from u-boot: https://pastebin.com/As2U6zhi Jan 05 15:29:20 im trying to uncomment a line in my uEnv.txt Jan 05 15:29:22 (the comment on line 18 only applies to really ancient kernels, not 4.14 or later) Jan 05 15:29:42 hmm lemme try load Jan 05 15:30:02 I wouldn't suggest trying to edit a file via u-boot, just use u-boot to boot the system with appropriate settings instead Jan 05 15:30:26 after line 6 of my paste you can use setenv to override variables set by u-boot Jan 05 15:30:58 from uboot how would you examin and override the dts files loaded? Jan 05 15:31:19 ahh, think i see it. Jan 05 15:31:28 the default dtb is selected on line 2 Jan 05 15:31:45 then optionally overridden by line 6 (if dtb= is set in uEnv.txt) Jan 05 15:32:10 what about de-selecting dtbo? Jan 05 15:32:19 this script doesn't support dtbos Jan 05 15:33:28 crap, it seems somehow my uEnv.txt was written as 0 size. Jan 05 15:33:44 bah, damn running out of space while i was in a nano session Jan 05 15:34:17 nano does that? wow that sucks, vi would never Jan 05 15:35:06 (well, at least vim would normally not have that problem) Jan 05 15:35:21 yea, but nano is dead simple. Jan 05 15:35:53 yup, verified on my android device, uEnv is empty :( Jan 05 15:35:55 vim normally writes a new file and then moves it over the old one Jan 05 15:36:06 well, then you can skip lines 5-6 of my boot script ;) Jan 05 15:36:29 and you'll need to manually set uname_r at minimum Jan 05 15:37:18 I hope the other steps still work, this was probably last used with an u-boot from 2017 Jan 05 15:39:07 though the only step I'd be worried about is "run findfdt" .. but worst case you can just manually "setenv dtb am335x-pocketbeagle.dtb" Jan 05 15:40:19 be sure to avoid having external stuff connected if that might not agree with whatever the pinmux defaults are for the pocketbeagle (which iirc are generally not always gpio / high-impedance) Jan 05 15:41:34 yea, good call. thinking I may try to fix virtual box first, then recompile the kernel Jan 05 15:43:05 to disable your i2c debugging whatever? Jan 05 15:43:49 yup Jan 05 15:44:59 next time, maybe first see if dynamic debugging suffices... since it's controlled at runtime (or at worst by the kernel parameters) Jan 05 15:45:35 oh, and you ran out of space because of this? might want to disable logging to sd card anyway, it's not good for the lifetime of your sd card Jan 05 15:46:08 apt-get purge rsyslog is definitely one of the first things I do on a fresh image :P Jan 05 15:46:10 agreed. Jan 05 15:46:26 thats basically the rotating sys log right? Jan 05 15:46:57 rsyslog is a system logging daemon, kinda redundant with systemd-journald Jan 05 15:47:24 (the latter keeps a ram-only journal if /var/log/journal/ doesn't exist) Jan 05 15:48:56 rsyslogd, on a linux system that uses systemd, is basically just for the old farts who demand their system logs in text format in /var/log/ like they're used to and don't want to learn to use journalctl ;) Jan 05 16:11:49 phew, took me many reboots, joining the insider dev edition of windows, giving away all my websites browesed info to microsoft, 1 host computer system rollback, and 2 fixing the guest image to get back to a functional setup. wsl works okay, but without uSD card support it really just wasted my time. Jan 05 16:30:04 just verifying, am3358 is armhf right? Jan 05 16:30:24 it's a cortex-a8 Jan 05 16:33:48 but re: compiler is that gnueabihf or gnueabi Jan 05 16:34:03 the cpu doesn't care what you call the compiler Jan 05 16:34:33 but there are 2 seperate compilers. one has hard float support and the other doesnt as i understand Jan 05 16:34:57 arm would work on armhf system, it just wouldn't be as efficient...right? Jan 05 16:34:59 compilers can be configured in many different ways Jan 05 16:35:13 you're probably talking about debian packages Jan 05 16:35:32 yes, but does the cortex-a8 have hard float? Jan 05 16:35:33 which have naming conventions that are somewhat... peculiar Jan 05 16:36:33 the cpu has vfp and neon floating-point Jan 05 16:36:54 ye, seeing that, gunna compile the kernel with arm-hf Jan 05 16:44:16 Konsgn: for compiling what? Jan 05 16:44:18 oh the kernel Jan 05 16:44:25 the kernel doesn't care, it will override the default anyway Jan 05 16:44:25 the kernel doesn't care which compiler you use Jan 05 16:44:39 but do enable vfp and neon support in the kernel config Jan 05 16:45:11 haha jinx? thats what 20 char match? Jan 05 16:45:16 Thanks guys Jan 05 16:45:49 armhf in the toolchain name refers to the ABI and calling convention used for things like the compiler support library and libc Jan 05 16:46:37 if you don't link against any external or compiler-provided library (like, e.g., the kernel) then what ABI those libraries use is irrelevant Jan 05 16:47:26 compilers can also have different defaults for instruction set of generated code Jan 05 16:47:30 and neon/vfp in the kernel is kinda special anyway, so most kernel code is compiled without neon/vfp support Jan 05 16:47:52 yeah the defaults will be different too, but you can (and the kernel will) override those Jan 05 16:48:02 the kernel sets whatever flags it needs to get what it wants regardless of how the compiler was configured Jan 05 16:48:08 that indeed Jan 05 16:52:17 (fwiw the kernel is not armhf, it uses soft-float, to the extent it uses floats at all) Jan 05 16:52:38 fwiw? Jan 05 16:52:43 for what it's worth Jan 05 16:52:51 gothca Jan 05 16:53:03 which is not much, it's unimportant to your question ;P Jan 05 16:53:36 still interesting. wathching a linuxhint video it seemed to say floats were not used in kernel Jan 05 16:54:03 generally speaking they indeed aren't Jan 05 16:55:42 point in case: https://elixir.bootlin.com/linux/latest/source/kernel/acct.c#L388 Jan 05 17:02:58 I think use by neon/vfp in the kernel might be limited to assembly code Jan 05 17:03:03 *use of Jan 05 19:24:43 while browsing libraries, wondered if SDL2 on DRM/EGL is possible, and noticed a repository with support for many platforms and a page titled "SDL2 on BeagleBone Black". Well, it seems like he took one look at the SGX SDK and immediately gave up. thought it was pretty funny https://github.com/hbirchtree/coffeecutie/blob/master/README.BeagleBoneBlack.md Jan 05 19:25:54 also it seems like the wiki https://processors.wiki.ti.com/ has already gone down a few minutes ago, though it didn't say it was going down until the 15th. good thing i saved some of the pages already Jan 05 19:37:18 hmmm, what's a good method of debugging kernel stack traces? Jan 05 19:37:49 as in i'm apparently dividing by 0 in a driver. Jan 05 20:39:50 do structs defined in kernel c code need to be packed to expect them to be adjacent u32 values? Jan 05 22:00:43 misternumberone: I saw what you typed out. Thank you. I will stay patient and keep trying. Jan 05 22:04:25 So far, what I can figure out from the ti git repo, things got outdated in '15 from Imag. Tech. and things have changed since then. Jan 05 22:04:44 So...my errors when compiling, not cross-compiling, are this... Jan 05 22:05:08 cannot find KERNELDIR/Makefile Jan 05 22:05:24 it is looking for a makefile in that dir. that I export. Jan 05 22:06:10 So, export KERNELDIR=/whatever/my/kernel/dir/is Jan 05 22:06:37 After the kernel dir, I need a specific makefile there for gmake to read. Jan 05 22:23:44 It seems to work so far w/out the omap5-xxxx-linux. I got to install the base lib. w/ a root account and omap5-xxxx-um-linux. Jan 05 22:24:04 sudo -E make install Jan 05 22:24:10 That command did it. Jan 05 22:24:56 Now onto getting the LD_LIBRARY_PATH set for user libs. and Wayland libs. Jan 05 22:31:48 man...wayland does support xfce. Boo! Jan 05 22:59:02 Hello...here is the error from pvrsrvinit command: https://pastebin.com/dtXkmCkK Jan 05 22:59:36 Does one or two might know how I came across this issue or even better on how to solve it? Jan 05 23:00:29 I have xfce for my setup as of now. So, this might be an issue <<< I will set up plasma real quickly. Jan 05 23:12:12 set_ a sinking linear regulation scheme is a bit more complicated than an LDO. Jan 05 23:13:00 set_ it's technically a DC amplifier :D Jan 05 23:13:12 Oh. Jan 05 23:13:53 set_: that's what i get when there is a problem with the userspace binaries functioning or connecting to the kernel module Jan 05 23:14:11 Oh. Jan 05 23:15:03 There is a link somewhere I am missing. Jan 05 23:15:24 it only works for me so far when I use a very specific kernel, kernel module, and userspace binaries. if you don't have "omap5-xxxx-linux" but you do have the user mode binaries installed, you may be missing the kernel module Jan 05 23:16:14 Hmm. Where is this kernel module? Jan 05 23:16:34 xwayland or wayland? Jan 05 23:16:46 or one of the many? Jan 05 23:18:39 set_: when the kernel module (pvrsrvkm) and pvrsrvinit (user space daemon) are functioning correctly and access to DRM and OpenGLES 2.0 instructions should be possible, I see this in dmesg when everything is working. https://pastebin.com/raw/3xAjkhj1 Jan 05 23:19:36 Okay. Taint is usually not good. Jan 05 23:19:43 i'm creating a brief list for you describing the packages i'm using currently and their locations on the web Jan 05 23:19:53 No jokes. So, the kernel is in panic mode or something? Jan 05 23:20:04 misternumberone: omap5-sgx-ddk-linux Jan 05 23:20:06 Okay. Jan 05 23:20:36 taint is not a problem in general, in this case it's just a consequence of loading an out-of-tree kernel module (as the message says) Jan 05 23:20:47 Okay. Jan 05 23:21:06 misternumberone: it's kinda funny it's still named after omap5, when in fact the ddk no longer supports omap5 :/ Jan 05 23:22:02 zmatt: yeah in fact I actually see an "omap_linux" string in /proc/pvr/version which seemed odd Jan 05 23:24:14 It seems to work w/ an older version of OE and/or the arago filesystem. Jan 05 23:25:38 Or whatever OE turned into. Jan 05 23:26:27 misternumberone: that's PVR_BUILD_DIR, i.e. which build subdir (and consequently top-level makefile) was used to build the kernel module, i.e.: https://github.com/rcn-ee/ti-omap5-sgx-ddk-linux/tree/ti-img-sgx/1.14.3699939/k4.14/eurasia_km/eurasiacon/build/linux2/omap_linux Jan 05 23:26:43 Um...I think they call the linux distro Yocto. Jan 05 23:27:29 Anyway... Jan 05 23:29:43 I have been looking in those makefiles in that dir. /build/linux2/. Jan 05 23:30:13 Maybe one of them needs to be put where the kernel is located and another where the root dir. is located? Jan 05 23:30:20 There is no way to tell. Jan 05 23:30:37 misternumberone: it seems in the 1.17 driver they removed all other build target dirs other than "nohw_linux" (clearly a test target) and jz4780_linux (some chinese MIPS-based thing... maybe it's a reference/test platform for sgx? can't imagine any other reason to keep it) Jan 05 23:31:33 maybe toplevel.mk and core.mk in config/? Jan 05 23:31:57 zmatt: yes, in a slighty different version of the newer 1.17 version of the kernel space source tree, I similarly saw only the names of two TI ARM3 CPUs which were not AM335x Jan 05 23:32:15 set_: what on earth are you talking about Jan 05 23:32:26 misternumberone: hmm? Jan 05 23:32:41 set_: hold on list almost finished Jan 05 23:33:04 When you export KERNELDIR=/ and export DISCIMAGE=/, the compilation calls for makefiles to be located in the KERNELDIR=/ Jan 05 23:33:09 misternumberone: AM35xx (not ARM3 :P) is an omap3-derivative... that's the only TI part number starting with AM3 other than AM335x I know of Jan 05 23:34:07 misternumberone: OKay. NO issue. I will stay patient. Jan 05 23:34:49 I said gmake earlier and I meant kbuild. SOrry. Jan 05 23:36:46 misternumberone: not sure where you're seeing this though, the makefile in the 1.17 driver tests for $TARGET_PRODUCT being one of "ti335x" (= AM335x), "ti437x" (= AM437x), "jacinto6evm" (= AM57xx/DRA7xx), "omap5uevm" (= OMAP54xx), "ti654x" (= AM654x), "ti443x" (= omap443x), and "ti343x" (= OMAP343x) Jan 05 23:37:11 not sure why their choices for TARGET_PRODUCT are such a mess, lol Jan 05 23:37:51 misternumberone: I'm looking at https://github.com/rcn-ee/ti-omap5-sgx-ddk-linux/blob/ti-img-sgx/1.17.4948957/k4.19/eurasia_km/eurasiacon/build/linux2/omap_linux/Makefile Jan 05 23:39:01 zmatt: well I found a list of many TI CPUs, over a hundred, when searching for the names I saw, in which both were, as well as the AM335x, in completely different sections. set_ was the one who showed me these details. The names I saw were OMAP5430 and DRA7xx, within this versuion: omap5-sgx-ddk-linux-glsdk_7.04.00.03 Jan 05 23:39:42 I also noticed, @zmatt, /eurasia_km/eurasiacon/build/linux2/omap5430_linux && omap4430_linux. Jan 05 23:39:51 that's a really ancient driver I think? Jan 05 23:39:56 so that's what i've been referring to, it seems I just was looking at the wrong version, while AM335x is available in what you've linked Jan 05 23:40:29 '15 is the latest from Imag. Tech. Jan 05 23:40:52 no Jan 05 23:40:58 no? Jan 05 23:41:21 Are we discussing the GPU still and Imag. Tech. and TI instances here? Jan 05 23:41:33 you seem to be talking about the 1.9.11.2253347 driver Jan 05 23:41:55 Hmm. I saw the um-linux and -linux drivers. Jan 05 23:42:10 I will wait to see what you are all talking about now. Jan 05 23:42:18 omap5-sgx-ddk-linux is the kernel driver repository, omap5-sgx-ddk-um-linux the userspace libraries Jan 05 23:42:26 Okay. Jan 05 23:42:28 Understood. Jan 05 23:42:29 in both cases which branch you use matters a lot Jan 05 23:42:42 git.ti.com shows an older version. Jan 05 23:42:53 That versions is from Imag. Tech. Jan 05 23:42:55 as well as where you get it from, rcn's mirror on github is old Jan 05 23:43:09 no, git.ti.com has the latest versions, you're just looking at the wrong branch probably Jan 05 23:43:19 Hmm. Jan 05 23:43:21 Okay. Jan 05 23:43:58 so, git pull. Jan 05 23:44:02 Oh... Jan 05 23:44:12 the "master" branch hasn't been updated in forever and is still the 1.9 driver Jan 05 23:44:15 I see now. They have four month old updates but is that the release? Jan 05 23:44:20 Okay. Jan 05 23:44:21 Okay. Jan 05 23:45:03 Okay, I am outdated here. I will let you two chat about it while I check on some more ideas. Jan 05 23:45:24 there's also the 1.14.3699939 driver for kernels 4.1, 4.4, 4.19, and 4.14, and the 1.17.4948957 driver for kernels 4.14, 4.19, and 5.4 Jan 05 23:46:06 I see the 1.17 version. Jan 05 23:46:15 Right. Okay. Jan 05 23:47:28 (they're not strictly limited to those kernel versions, but usually getting the driver to work on a different kernel version requires some minor fixes, which has the downside of making you look at the source code of this driver, which makes you want to wash your eyes with bleach) Jan 05 23:47:47 Right. Jan 05 23:47:48 Okay. Jan 05 23:47:55 Bleach handy! Jan 05 23:55:22 So, I moved to 1.17 finally and away from master. Jan 05 23:55:32 Yikes. Jan 05 23:55:35 Let me try over. Jan 05 23:56:12 set_: https://pastebin.com/raw/NFtMPwZj is the first, most barebones process I use currently to access the SGX530 as quickly as possible. I have a filesystem cloned with just this and a few more things installed from which I restore when I break it. Jan 05 23:56:43 Oh. Okay. Jan 05 23:56:46 Thank you. Jan 05 23:57:07 I am not sure exactly how to use the yocto source OS in debian right now. Jan 05 23:57:19 It seems that 1.17 is for Yocto based distros. Jan 05 23:57:21 set_: I don't know what you're trying or why, but you probably shouldn't... there's been no report yet of anyone getting the 1.17 driver working on the BBB. it almost certainly _can_ work but requires investigation Jan 05 23:57:22 The first thing you should be aware of is that zmatt has created some dummy packages for libgbm which are intended to help prevent the package manager from installing the conflicting libgbm packages from the debian repos, the moment you try to install a number of other things Jan 05 23:57:51 Oh. Okay. Jan 05 23:57:57 misternumberone: my dummy libgbm depends on my userspace package though, so that's incompatible with using rcn's userspace packages Jan 05 23:57:59 Dummy packages. Nice. Jan 05 23:58:36 @zmatt: I like ideas and ideas lead to progress. Progress is better than ideas. That is all and that is the reasoning i have for continuation. Jan 05 23:59:03 misternumberone: looks like rcn also provides libgbm packages, except he kept the version bumb ("libgbm2") and uses an alternate name, which won't work since other packages explicitly depend on "libgbm" Jan 05 23:59:16 however to make them work for my setup, I edited the packages somewhat in a hacky way (removed the dependency references) which might not be what he'd recommend. Jan 05 23:59:39 misternumberone: so, if you're using the 1.14 driver, do my userspace packages not work? Jan 06 00:00:22 I think my workaround for the libgbm hell in the 1.14 drivers is probably still the best Jan 06 00:01:12 they might in fact, however, I began with copying as closely as possible the exact structure I observed in the existing debian 9 image that already has the driver installed Jan 06 00:01:17 and I have suitable Conflicts: to hopefully prevent conflicting packages to be installed Jan 06 00:01:40 and I had qt5 working, not merely some trivial tests Jan 06 00:02:26 it's still possible the package no longer works for whatever reason, and I do need to update them, but it sounds like mine might be worth a shot Jan 06 00:03:42 well I'm not sure if I've tried it yet in my current setup, so I will and i'll use it until something bad happens that doesn't with the rcn-ee userspace package. the file is sgx-ti335x-userspace-1.14.3699939_1.1.deb correct? Jan 06 00:04:13 it's the three sgx-*.deb files in here: https://liktaanjeneus.nl/sgx/ Jan 06 00:04:49 there's a circular dependency between sgx-ti335x-userspace-1.14.3699939_1.1.deb and sgx-libgbm.deb Jan 06 00:04:55 so they need to be installed at the same time Jan 06 00:05:10 (I'm not going to claim this package is nice or tidy :P) Jan 06 00:06:42 in fact the dependencies are weird as hell and I don't know why I did them like that, but I'm pretty sure I arrived at them through some painful learning experiences Jan 06 00:09:55 (you can also download the .debs and then use "dpkg -i --recursive DIRECTORY") Jan 06 00:10:26 iirc that somewhat sanely copes with the cross-dependencies Jan 06 00:20:29 i think it would work without doing that since i already had the dummy packages installed, but I purged everything anyway and installed it with your original unmodified packages Jan 06 00:21:11 one difference seems to be the systemd service is structured differently so it has to be started manually be default and can't be enabled the same way as the other one Jan 06 00:21:53 yeah just add an [Install] section with WantedBy=multi-user.target or something Jan 06 00:22:49 that's just for testing convenience though, if you eventually want your GUI to be a service that launches at boot (which is typical) then you'll need a dependency to ensure correct ordering Jan 06 00:22:58 which is probably why I didn't bother Jan 06 00:23:16 but importantly, your libgbm library file is named something else (libgbm.so.2) so if I want to use your version of this, I'll have to recompile all the tests and projects I'm working on and link them against that instead Jan 06 00:23:18 but it would have been polite to at least have the option Jan 06 00:23:25 it seems to work after recompilation though Jan 06 00:24:00 libgbm.so.1 you mean Jan 06 00:24:21 yes, sorry i mean the other one was named libgbm.so.2 Jan 06 00:24:29 and yes, that's the major thing I did: undo the v1 -> v2 version bumb of libgbm, since that creates a dependency hell Jan 06 00:24:37 since anything precompiled for debian expects libgbm.so.1 Jan 06 00:26:03 well I haven't been able to get anything "precompiled for debian" at least from the debian repos to work, long before libgbm becomes an issue Jan 06 00:26:11 note that the 1.17 drivers also backed out of the version bump, they include a libgbm.so.1 Jan 06 00:26:34 qt5 from debian worked for me... almost out of the box :P Jan 06 00:26:41 so i've just been manually patching/porting and compiling all the dependencies for things i'm trying to use from source Jan 06 00:27:01 but my patch should no longer be needed I think, iirc it was fixed upstream Jan 06 00:27:20 so in theory debian qt5 should work... might work... possibly Jan 06 00:27:35 it definitely won't work with "libgbm.so.2" Jan 06 00:28:07 and worse, if it pulls in mesa's libgbm1 while a libgbm2 from TI is installed at the same time, hilarity ensues Jan 06 00:28:13 and my hilarity I mean segfaults Jan 06 00:28:16 *by Jan 06 00:28:50 my dummy packages ensure anything that wants libgbm1 is happy Jan 06 00:31:23 i've witnessed that and had been manually working around it, but from your explanation, are you saying that could be why I've been unable to use libx11-6 ? you didn't mention any of this at the time Jan 06 00:31:59 no idea.. you can't really "use" libx11 anyway, but I don't understand why its presence could cause problems Jan 06 00:32:40 I've been directly working with sending OpenGLES 2.0 instructions through a DRM + EGL stack Jan 06 00:32:41 unless you have two libgbm versions installed and both get pulled in, then yeah it explains things Jan 06 00:33:06 libx11 seems to be a mandatory dependency for any Wayland display manager implementation Jan 06 00:34:00 it can help to run "ldd" on your program to see what shared libraries get pulled in, though it's better to just not have conflicting libraries installed at the same time (two versions of libgbm being a prime candidate when not using my patched versions) Jan 06 00:34:54 that sounds weird, but yeah I've also run into packages with a bogus dependency on x11 things even though they don't require it at runtime Jan 06 00:35:02 see also the remark in my package description ;P Jan 06 00:36:16 no at that time I manually verified that libx11 was not installing any libgbm from the debian repos. i started checking that every time since i discovered already that having any libgbm installed that isn't the ti fork breaks all the tests Jan 06 00:37:22 the issue is that libx11-dev is required to build any wayland display manager i've tried from source (they can't be used as-is from any debian repo anyway, they have to be manually patched/ported to work with this platform) Jan 06 00:39:03 at the very least with my .deb and the libgbm.so.1 it includes (and the libgbm1/libgbm-dev dummy packages to satisfy direct dependencies) you'll no longer need to worry about libgbm conflicts, and the probability of being able to use existing debian packages for things will have greatly increased Jan 06 00:39:33 it seems plausible you still won't be able to use weston directly, but like I've said before I have no wayland experience Jan 06 00:42:57 Under apt-cache list kernel... Jan 06 00:43:10 I found a ti-am335x for sgx modules. Jan 06 00:43:25 I was able to use qt5 with a patch to change the hardcoded XRGB8888 pixel format to a hardcoded RGB565 pixel format... I don't remember if we used HDMI or LVDS for that specific project, in the former case I could also have accepted the XRGB8888 pixelformat and used the hdmi framer to swap the red/blue channels but it would have been unnecessarily slow Jan 06 00:43:44 if I remember correctly, qt5 nowadays correctly detects pixel formats Jan 06 00:44:06 Now, I have no clue on how to install it or if the BBB even has options for it. Jan 06 00:48:41 yeah, I remember correctly. the qt5 version used in debian stretch does this rudeness: https://github.com/qt/qtbase/blob/5.7/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp#L135 Jan 06 00:48:56 contrast with the same function in the qt5 version used in debian buster: https://github.com/qt/qtbase/blob/5.11/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp#L151-L179 Jan 06 00:51:16 zmatt: thank you your package works better than the ones from rcn-ee.com because after installing it I am now able to have libx11-6 installed at the same time as tests and my projects as well working Jan 06 00:52:48 yay \o/ Jan 06 00:52:57 i manually verified in the filesystem that with the other setup it wasn't creating a situation with more than one libgbm installed, so it must have been what you said that libx11.so.6 expected a different libgbm, but couldn't find it and segfaulted for some reason. Jan 06 00:55:20 who knows... all I know is, I had good reasons to undo the libgbm version bump and patch the sgx userspace libs to use libgbm.so.1 instead of libgbm.so.2 ;-) Jan 06 00:55:33 your experience further confirms that Jan 06 00:59:38 Hmm. Jan 06 00:59:48 I do not have libgbm.so.1 or .2. Jan 06 01:00:01 How you, how you...how you all got dat? Jan 06 01:00:25 set_: why exactly are you trying to install the sgx libs? what use do you have for them? Jan 06 01:00:42 I have a couple pyqt apps I want to display. Jan 06 01:00:50 that doesn't require sgx Jan 06 01:00:53 Oh? Jan 06 01:00:57 On my display? Jan 06 01:00:58 just use the linuxfb backend Jan 06 01:01:04 Oh. Jan 06 01:01:06 Hmm. Jan 06 01:01:13 I asked that a couple days ago. Jan 06 01:01:24 almost certainly less hassle, might even be faster Jan 06 01:01:43 actually, are you discussing fg? Jan 06 01:01:49 linuxfb? Jan 06 01:01:57 no Jan 06 01:02:03 OH. Okay. Jan 06 01:02:32 but we're not really discussing qt5 either... I just mentioned it as example of what I struggled with (but did get working) a few years ago Jan 06 01:02:49 whereas misternumberone seems to be trying to get wayland working Jan 06 01:04:07 Nevertheless, do not fret. Jan 06 01:04:46 I will attempt something else at some point. Jan 06 01:05:12 perhaps Xorg will go the way of Xfree86 after it finishes wayland. Jan 06 01:05:20 :D Jan 06 01:08:26 "it finishes" ? I don't think Xorg has anything to do with wayland? Jan 06 01:08:29 maybe I'm wrong Jan 06 01:10:20 oh wow, I haven't really tracked wayland at all, didn't know that Debian has been using Wayland by default since buster Jan 06 01:10:29 interesting Jan 06 01:10:58 yes i use debian sid on a completely different computer and it has completely functional modern wayland stack Jan 06 01:11:21 Maybe that is why my Display started to work w/ the updated kernel and debian? Jan 06 01:11:33 It used to not work for some time... Jan 06 01:11:45 set_: we're not talking about the bbb here Jan 06 01:11:52 I understand. Jan 06 01:11:58 the bbb images do not include X11 nor Wayland Jan 06 01:11:58 it works extremely well even for apps intended for use with Xorg HOWEVER one bug out of the box at least in that case is that there are occasionally some minor graphical artifacts of a sort i don't ever see in a Xorg display Jan 06 01:12:02 Oh. Jan 06 01:12:05 Got it. Okay. Jan 06 01:12:30 misternumberone: that sounds "fun" to debug, lol Jan 06 01:14:06 yeah, barely ever happens maybe once every hour of use, so i'd have to spend a lot of time working to fix that most likely Jan 06 01:14:28 not using that system atm just working on BBB **** ENDING LOGGING AT Wed Jan 06 02:59:58 2021