**** BEGIN LOGGING AT Sun Apr 12 03:00:14 2020
Apr 12 04:09:49 <pradan[m]> Anyone configured the DSPs and EVEs onboard the BeagleBone AI or x15 ? ...using OpenCL ?
Apr 12 04:10:02 <pradan[m]> * Without TIDL
Apr 12 07:19:24 <jfsimon1981> Hi
Apr 12 07:19:39 <jfsimon1981> Which question was answered set_ ? I did'nt understand.
Apr 12 07:20:14 <jfsimon1981> I installed openbsd 6.6 it'sworknig well.
Apr 12 07:20:37 <jfsimon1981> I noted an error in manual all Leds are on gpio1. That's all.
Apr 12 07:22:05 <zmatt> jfsimon1981: they are indeed, so if documentation says otherwise then that's indeed an error in the documentation
Apr 12 07:23:02 <zmatt> jfsimon1981: if you want a detailed pin list of the BBB, see the "BBB" tab of https://goo.gl/Jkcg0w
Apr 12 08:45:21 <jfsimon1981> Yep the manual says LEDs 2/3/4 are on GPIO 2 which is a man page mistake.
Apr 12 08:46:00 <jfsimon1981> I found it yesterday starting with man page instructions to program the GPIO in OpenBSD and discoverd they did not function thus checking in the wiring diagrams. Corrected.
Apr 12 08:46:12 <jfsimon1981> Thanks for the link
Apr 12 08:47:55 <zmatt> jfsimon1981: which doc are you referring to exactly though?  Table 8 on page 67 of the current BBB system reference manual (rev C.1) has the correct identification
Apr 12 08:53:43 <jfsimon1981> Indeed I had downloded an ancient manual, checking to send you the link, the Wiki in the BBB website has a correct man.
Apr 12 08:54:02 <jfsimon1981> So the present manual is good.
Apr 12 08:56:34 <zmatt> btw, I don't know if openbsd supports powering off the board yet, but if it does... I hope someone made sure that it sets the "OFF" bit in the pmic to ensure it goes into proper "OFF" mode (all supplies off) rather than "SLEEP" mode (most supplies off) since the latter is Bad(tm) and may result in hardware damage
Apr 12 08:59:59 <jfsimon1981> Was a Rev A manual, indeed rev C manual is correct.
Apr 12 09:00:32 <jfsimon1981> The power off is not supported
Apr 12 09:00:36 <jfsimon1981> Thanks for the tips
Apr 12 09:01:19 <jfsimon1981> What's bad tm ?
Apr 12 09:03:55 <jfsimon1981> (Man version A.5.4 corrected the typo).
Apr 12 10:10:58 <jfsimon1981> OpenBSD works quite differently from Linux, the port I/O needs to be mapped at boot time before changing secure level to user. Then input/ouput are set and can't be updated.
Apr 12 10:11:48 <zmatt> on linux the usage of gpios (or pins in general) is normally declared in the DT
Apr 12 10:13:11 <zmatt> being able to entirely reconfigure the pins at runtime is a custom patch by beagleboard.org to ease experimentation
Apr 12 10:16:54 <zmatt> the nicer way (although it still uses the a custom driver "gpio-of-helper") is to declare gpios (including name, whether they're active-low or active-high, whether they're bidirectional, (initial) direction and initial level (for outputs)) in DT, like this: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi
Apr 12 10:17:51 <zmatt> and then use an udev rule to setup privileges (user/group) and create named symlinks, so software doesn't need to know or care which gpios these are exactly: https://pastebin.com/YKW7Wcqu
Apr 12 10:21:13 <zmatt> this is for generic gpios.  for gpios used as leds one would typically use the gpio-leds driver, which allows the leds to be configured to be triggered by the kernel on various forms of activity (e.g. cpu activity, eMMC access, SD card access)
Apr 12 10:24:51 <jfsimon1981> I recognize the Linux version in your pastebin, thanks for explaining,
Apr 12 19:02:12 * deepankarmaithan sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/qUvMTZoavBQjoturmWXITaHF >
Apr 12 19:27:39 <zmatt> deepankarmaithan: this is my understanding of its truth table, expressed in pseudocode: https://pastebin.com/pdvVQKDk
Apr 12 19:28:38 <deepankarmaithan> thanks alot
Apr 12 19:29:41 <deepankarmaithan> This is what i needed :)
Apr 12 19:30:19 <zmatt> (I'm viewing Q and IO as 8-bit quantities and S as 2-bit quantity, with S0 = bit 0 of S, Q1 = bit 1 of Q, etc)
Apr 12 19:30:59 <MattB0ne> ok I broke my packages
Apr 12 19:31:04 <MattB0ne> how do I fix
Apr 12 19:31:12 <zmatt> note also that what the datasheet calls "shift right" is actually a shift-left (<<) and vice versa
Apr 12 19:31:21 <MattB0ne> all the sudden getting unmet dependencies
Apr 12 19:31:42 <MattB0ne> I should of left well enough alone
Apr 12 19:31:58 <MattB0ne> I was install more armhf packages
Apr 12 19:32:16 <MattB0ne> then all the sudden they were conlficting with my regular packages
Apr 12 19:32:19 <MattB0ne> and here I am
Apr 12 19:32:40 <deepankarmaithan> zmatt:  I will study it with your input and some more inside details that i found . Will get back soon
Apr 12 19:32:42 <zmatt> MattB0ne: "something is wrong!  how do I fix?"  is not going to get you any useful feedback.  explain what you did exactly and share the full error you're getting (via a paste service like pastebin.com, don't paste long errors into chat obviously)
Apr 12 19:33:03 <MattB0ne> I am getting to it
Apr 12 19:33:06 <MattB0ne> https://pastebin.com/97iWc7y8
Apr 12 19:33:13 <MattB0ne> I call that a circle jerk
Apr 12 19:33:44 <zmatt> you're getting this on a beaglebone?  holy shit how did you break things this badly
Apr 12 19:33:51 <MattB0ne> I lost access to my arm-linux-gnueabihf-g++
Apr 12 19:33:58 <MattB0ne> this is my laptop
Apr 12 19:34:01 <zmatt> ahh
Apr 12 19:34:04 <MattB0ne> and I am not sure how I pulled it off
Apr 12 19:34:15 <MattB0ne> i was just installing using apt
Apr 12 19:34:25 <MattB0ne> is there like a flush command
Apr 12 19:34:33 <zmatt> why do you have cpp-8:armhf installed?
Apr 12 19:34:46 <MattB0ne> cross compile
Apr 12 19:34:47 <zmatt> (or at least, why does it want to install it)
Apr 12 19:35:16 <zmatt> no, cpp-8 is part of a native toolchain compiled for arm, not part of a cross-toolchain
Apr 12 19:35:21 <zmatt> cpp-8:armhf I mean
Apr 12 19:35:23 <MattB0ne> I had cross compile working with linuxfb but I got greedy and was going for egl
Apr 12 19:36:12 <MattB0ne> I think i was trying to install a mesa:armhf
Apr 12 19:36:33 <zmatt> there's no package by that name
Apr 12 19:36:34 <zmatt> be precise
Apr 12 19:37:10 <MattB0ne> its hard to retrace since I was jamming so much in
Apr 12 19:37:13 <MattB0ne> libegl1-mesa:armhf
Apr 12 19:37:16 <zmatt> you can find a history of apt activities in /var/log/apt/history.log
Apr 12 19:37:16 <MattB0ne> was one though
Apr 12 19:39:22 <zmatt> also, this just looks like whatever install you requested makes no sense hence can't proceed.  that's not the same as having "broken" your packages, that might apply if you're getting errors like these on trying to upgrade or if you're not able to install anything anymore
Apr 12 19:39:25 <MattB0ne> https://pastebin.com/yF3aNJY8
Apr 12 19:39:27 <MattB0ne> was my log
Apr 12 19:39:46 <MattB0ne> was cramming a lot of crap in
Apr 12 19:40:07 <MattB0ne> on 4/11
Apr 12 19:40:39 <zmatt> the last three installs are all nonsense
Apr 12 19:40:42 <zmatt> none of those make sense
Apr 12 19:41:01 <MattB0ne> can I undo those
Apr 12 19:41:09 <zmatt> and all three removed a ton of important packages
Apr 12 19:41:13 <zmatt> which is something apt will have told you
Apr 12 19:41:18 <zmatt> and you still said "yes" to it
Apr 12 19:41:44 <zmatt> well, the last one didn't remove anything since it was never performed, but the previous two did
Apr 12 19:42:00 <MattB0ne> i trusted apt blindly
Apr 12 19:42:10 <zmatt> no, apt trusts *you* blindly
Apr 12 19:42:13 <MattB0ne> which appears to be a big mistake since I broke
Apr 12 19:42:16 <MattB0ne> lol
Apr 12 19:42:20 <MattB0ne> well apt should no better
Apr 12 19:42:25 <zmatt> no it shouldn't
Apr 12 19:42:38 <MattB0ne> they need a noob mode for apt
Apr 12 19:42:45 <zmatt> you asked for something really weird, it tried the best it could, and asked you whether this was really what you wanted
Apr 12 19:43:00 <zmatt> if installing a package results in removal of other packages due to conflicts, you should pay attention
Apr 12 19:43:48 <zmatt> looks like it even removed your nvidia graphics driver... be glad your laptop still boots (assuming it does)
Apr 12 19:44:03 <MattB0ne> so basically I can get away with just removing those packages
Apr 12 19:44:32 <MattB0ne> why would it cross over though they are separate architectures amd vs armhf
Apr 12 19:45:00 <MattB0ne> I thought having both side be side would be benign
Apr 12 19:45:12 <zmatt> you can't have two versions of the same program installed at the same time
Apr 12 19:45:13 <MattB0ne> well I havent restarted
Apr 12 19:45:36 <MattB0ne> so the :armhf part does not make it different enough
Apr 12 19:46:20 <zmatt> nope, multiarch does not apply to programs (since it doesn't make sense for programs), only for libraries
Apr 12 19:47:00 <MattB0ne> ahhhh got you
Apr 12 19:47:08 <zmatt> remove: binutils:armhf binutils-arm-linux-gnueabihf:armhf binutils-common:armhf
Apr 12 19:48:16 <MattB0ne> it given me dependency failure on a removal?!?!?
Apr 12 19:48:58 <zmatt> again, share full command and full output.  just "dependency failure" is not useful information
Apr 12 19:49:43 <MattB0ne> https://pastebin.com/eabebKV6
Apr 12 19:50:16 <zmatt> when asking for help, it's your responsibility to provide adequate information for people to be able to help you.   we're not sitting next to you, we can't look over at your screen to see what's going wrong
Apr 12 19:50:47 <zmatt> oh god the last install did partially proceed for some reason /o\
Apr 12 19:52:18 <MattB0ne> '=(
Apr 12 19:52:48 <zmatt> okay, let's try to fix this with increasing amounts of force...  hold on
Apr 12 19:52:53 <MattB0ne> lol
Apr 12 19:52:55 <MattB0ne> ok
Apr 12 19:53:40 <zmatt> sudo apt remove binutils-arm-linux-gnueabihf:armhf binutils-common:armhf binutils:armhf cpp-8:armhf cpp:armhf g++-8:armhf gcc-8:armhf libbinutils:armhf libcc1-0:armhf libisl19:armhf libmpc3:armhf libmpfr6:armhf
Apr 12 19:55:41 <MattB0ne> that worked
Apr 12 19:55:41 <zmatt> oh wow, really don't reboot, if that last command did in fact proceed to some extent, your system is most likely completely broken right now
Apr 12 19:55:52 <zmatt> (the last install you did earlier I mean)
Apr 12 19:56:07 <zmatt> okay, now we'll have to install some stuff again that got removed
Apr 12 19:56:43 <zmatt> unfortunately I can't really tell which packages used to be automatically installed and which were manually installed... lemme see if there's a way to find that info in logs
Apr 12 19:58:39 <zmatt> hmm not very easily it seems
Apr 12 19:59:58 <MattB0ne> could I just try and put back what was removed
Apr 12 20:00:09 <MattB0ne> in those last three installs
Apr 12 20:00:16 <zmatt> yeah but you usually want to avoid manually installing packages that were automatically installed
Apr 12 20:00:22 <zmatt> that could cause problems in the future
Apr 12 20:00:33 <zmatt> so just hold on please
Apr 12 20:01:13 <MattB0ne> ok
Apr 12 20:04:02 <zmatt> let's start with:  sudo apt install xorg nvidia-driver linux-headers-amd64 acpi-support build-essential
Apr 12 20:05:54 <zmatt> after that, please share the new log entries added to /var/log/apt/history.log
Apr 12 20:07:39 <zmatt> actually, you'll also want:  crossbuild-essential-armhf libcups2-dev libcups2-dev:armhf   since you had those installed
Apr 12 20:08:22 <zmatt> and after *that* I want your history.log
Apr 12 20:08:32 <zmatt> to see if there's anything still missing
Apr 12 20:11:28 <MattB0ne> https://pastebin.com/tA2NzbvX
Apr 12 20:11:46 <zmatt> btw you said you were "going for egl" .. you'll only want that if you intend to use the gpu (the powervr sgx530).   while cross-building for that should definitely be possible, it'll be a fair bit more hassle and it explicitly does _not_ involve any mesa libraries
Apr 12 20:12:25 <MattB0ne> ok
Apr 12 20:14:03 <zmatt> oh, apt is configured to automatically install "recommended" packages (not just dependencies), which is why it installed more than was previously removed
Apr 12 20:14:38 <zmatt> e.g. acpi-fakekey wasn't installed previously, but it's recommended by acpi-support (which *was* installed previously)
Apr 12 20:17:40 <zmatt> if you want your system to be the same as it was you can remove:  acpi-fakekey libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl libcupsfilters-dev
Apr 12 20:18:10 <zmatt> (these are all "recommended" by packages you just installed, but are not required)
Apr 12 20:18:31 <zmatt> or you can trust the recommendations and leave them installed, your call
Apr 12 20:19:00 <zmatt> (I generally don't automatically install recommendations, but I do pay attention to them and try to judge for myself whether I want them)
Apr 12 20:19:35 <MattB0ne> I will pay attention to that going forward
Apr 12 20:19:51 <MattB0ne> I have a fair amount of items that apt is saying are no longer used
Apr 12 20:20:06 <MattB0ne> can I trust apt in that regard?
Apr 12 20:21:20 <zmatt> it means those packages were automatically installed (as dependencies/recommendations of other packages) but now they are no longer (directly or indirectly) required or recommended by any manually-installed packages
Apr 12 20:21:32 <zmatt> so "apt autoremove" would remove them
Apr 12 20:21:58 <zmatt> usually this happens after removing packages, or sometimes after upgrading packages
Apr 12 20:22:24 <zmatt> if these recommendations are new (since today) then maybe share them via pastebin so I can take a look
Apr 12 20:22:46 <zmatt> eh, if that message is new I mean
Apr 12 20:24:00 <zmatt> the main thing to check here is whether perhaps some of those packages, although originally installed automatically, and now things you use directly or otherwise explicitly want to have
Apr 12 20:24:23 <MattB0ne> https://pastebin.com/VFB8Em2z
Apr 12 20:26:20 <zmatt> and this is new?  none of those packages were installed yesterday so I'd assume you've been seeing this for longer than just today
Apr 12 20:28:40 <MattB0ne> yeah
Apr 12 20:28:41 <zmatt> most of this looks completely unrelated to anything done recently
Apr 12 20:28:52 <MattB0ne> I just never cleared it
Apr 12 20:28:58 <MattB0ne> but nothing like the present
Apr 12 20:29:04 <MattB0ne> for some house cleaning
Apr 12 20:30:20 <MattB0ne> so some parting questions gcc vs gcc-8
Apr 12 20:30:48 <zmatt> yeah "gcc" is the default gcc, which will depend on a specific version like gcc-8
Apr 12 20:31:55 <zmatt> different major versions of gcc are packaged separately to allow having multiple major versions of gcc installed at the same time (with the version in the name of the executables, e.g. "gcc-8", "g++-8", etc)
Apr 12 20:32:22 <zmatt> whereas only one of those can be default (i.e. invokable as plain "gcc" or "g++")
Apr 12 20:33:58 <MattB0ne> i understand
Apr 12 20:36:27 <zmatt> so the "gcc" package consists almost entirely of symlinks: https://pastebin.com/fmSF27TK  (the exceptions being two shell scripts, their manpages, and one package metadata file)
Apr 12 20:37:40 <MattB0ne> and one more for the road. So I have qtcreator working well and I can compile for beagle on my laptop.(that is how I got into the package mess in the first place). One minor grievance is that when Qtcreator tries to run the program i cannot use the touch screen. If I ssh onto the beagle and run the program I can use the touch screen. Same call
Apr 12 20:37:40 <MattB0ne> parameters. How does beagle treat the two methods differently
Apr 12 20:38:22 <zmatt> I have no idea how qtcreator runs programs so that's hard to say
Apr 12 20:38:41 <zmatt> something about environment variables would be the most obvious candidate
Apr 12 20:40:38 <MattB0ne> I saw something about that but I find their documentation above my head
Apr 12 20:41:03 <MattB0ne> for now I just have a terminal window open
Apr 12 20:41:42 <MattB0ne> so no biggie
Apr 12 20:41:43 <MattB0ne> eventually I may want to know why
Apr 12 20:41:44 <MattB0ne> I am still on the fence on what I should learn. I am leaning towards qt because it is c++ based and I need to get better at that anyway
Apr 12 20:41:52 <MattB0ne> I kinda like qt creator
Apr 12 20:45:23 <MattB0ne> zmatt: I did see this on the instances where I do not have touch capability
Apr 12 20:45:24 <MattB0ne> Failed to open tty (Permission denied)
Apr 12 20:45:49 <MattB0ne> and to get touch to work when I am ssh'ed into the bbb
Apr 12 20:45:51 <MattB0ne> I need sudo
Apr 12 20:45:56 <MattB0ne> then everything works
Apr 12 20:46:02 <MattB0ne> so its is like a permissions issue
Apr 12 20:46:32 <MattB0ne> could I just give my id like chmod 777 or something over the device files
Apr 12 20:50:14 <zmatt> using sudo is a bad idea obviously
Apr 12 20:50:29 <zmatt> I remember the tty issue, I don't see why it would need access to the tty though
Apr 12 20:50:52 <zmatt> but that shouldn't have anything to do with input regardless
Apr 12 20:51:33 <zmatt> is this with QT_QPA_FB_DRM=1 or not?  (I asked that last time but never got a reply on whether it worked with it)
Apr 12 20:52:28 <zmatt> and if you're not using QT_QPA_FB_DRM=1 then you may want to try linuxfb:nographicsmodeswitch (but I've mentioned this before too)
Apr 12 20:54:34 <zmatt> btw you'll want to set NAutoVTs=0 and ReserveVT=0 in /etc/systemd/logind.conf to ensure no getty gets spawned
Apr 12 21:00:18 <zmatt> if it really needs access to /dev/tty1 even with QT_QPA_FB_DRM=1 or nographicsmodeswitch then some permissions fix will be needed... eventually when your application runs as a startup service it can simply be associated with tty1 using its service file I think, but that doesn't help when you just want to run the program manually for debugging
Apr 12 21:00:23 <MattB0ne> do I need to restart the board to have the login stuff take effect or log out and log back in
Apr 12 21:00:56 <MattB0ne> I have been running with QT_QPA_FB_DRM=1
Apr 12 21:01:00 <zmatt> logging out/in via ssh is irrelevant for it... rebooting is probably easiest
Apr 12 21:02:56 <zmatt> but it sounds to me like the tty error is not a real problem, if it doesn't prevent your program from starting
Apr 12 21:03:02 <MattB0ne> so it was commented out but those two variables NAutoVTs=0 and ReserveVT=0 had values of 6
Apr 12 21:03:08 <MattB0ne> what does 0 for that mean
Apr 12 21:03:35 <zmatt> 6 is the default indeed, 0 disables the functions
Apr 12 21:04:31 <zmatt> since you almost certainly don't want a getty (a "login:" prompt on screen) on an embedded system
Apr 12 21:05:53 <MattB0ne> yeah I was wondering about that
Apr 12 21:06:04 <MattB0ne> before I run anything the cape just has that default message stuff
Apr 12 21:06:56 <zmatt> yeah getting startup crap on screen (instead of just on the serial console) is something that can definitely be suppressed
Apr 12 21:07:17 <zmatt> but it's been a while since I've done that
Apr 12 21:07:23 <zmatt> so I can't really remember the details
Apr 12 21:07:40 <MattB0ne> no biggie
Apr 12 21:07:43 <zmatt> anyway, as for your touch input issues... weird, I think the debian user should normally have access to all the relevant event input devices
Apr 12 21:07:47 <MattB0ne> you have been a life saver already today
Apr 12 21:08:04 <MattB0ne> I will eventually need to puzzle that out to take sudo off
Apr 12 21:08:11 <zmatt> yes you shouldn't run with sudo
Apr 12 21:08:14 <zmatt> absolutely not
Apr 12 21:08:24 <MattB0ne> i figured
Apr 12 21:08:35 <MattB0ne> but that does suggest permission though right?
Apr 12 21:09:06 <MattB0ne> I do get this when I run as root QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Apr 12 21:09:22 <MattB0ne> but the program works
Apr 12 21:10:41 <zmatt> it does, so one thing you can try it running it with   strace -f -o strace.log -e trace=file -Z ./your-program
Apr 12 21:10:45 <MattB0ne> I googled it and stack overflow had something about preserving vraibles
Apr 12 21:10:49 <zmatt> just don't run it as root
Apr 12 21:10:52 <zmatt> please
Apr 12 21:11:03 <zmatt> it's usually not too hard to figure out permission issues
Apr 12 21:11:43 <zmatt> the command I just gave will create a file named strace.log showing all file-operation commands that failed
Apr 12 21:12:32 <zmatt> so you may find enlightening results if you search for lines that contain /dev/ and EPERM
Apr 12 21:12:38 <MattB0ne> strace.log https://pastebin.com/u0zjmTtY
Apr 12 21:13:03 <MattB0ne> yeah it is big let me grep it
Apr 12 21:13:04 <zmatt> this looks like you used -z instead of -Z
Apr 12 21:13:24 <zmatt> also it's definitely not the whole file
Apr 12 21:13:46 <zmatt> (-z only shows successful calls, -Z only failed calls... we're interested in the failed ones)
Apr 12 21:14:47 <MattB0ne> I do not have a -Z https://pastebin.com/0NDHKHSw
Apr 12 21:15:01 <MattB0ne> that is the output of strace -h
Apr 12 21:15:44 <zmatt> oh maybe it was recently added... well then just omit it
Apr 12 21:16:12 <zmatt> and then maybe:   grep '/dev/.* EPERM' strace.log
Apr 12 21:16:25 <zmatt> or EACCES sorry
Apr 12 21:18:04 <MattB0ne> four entries https://pastebin.com/RjdEyyd5
Apr 12 21:18:27 <zmatt> ls -l /dev/input/event[01]
Apr 12 21:19:21 <MattB0ne> https://pastebin.com/HyxUv9dn
Apr 12 21:19:52 <zmatt> huh, user debian is not in the "input" group?  you can confrim with:  id -nG
Apr 12 21:21:32 <MattB0ne> https://pastebin.com/NgKKhBVy
Apr 12 21:21:39 <MattB0ne> i claim innocense on this one
Apr 12 21:21:57 <zmatt> lol, pretty much every group on earth... except input
Apr 12 21:22:02 <MattB0ne> innocence*
Apr 12 21:22:13 <zmatt> well, easy enough to fix:  sudo adduser debian input
Apr 12 21:22:17 <zmatt> then log out and back in
Apr 12 21:23:20 <MattB0ne> WOOOHOOOO
Apr 12 21:23:24 <MattB0ne> works no sudo
Apr 12 21:23:28 <MattB0ne> in business
Apr 12 21:23:31 <MattB0ne> thank you sir
Apr 12 21:23:53 <MattB0ne> even works from QT
Apr 12 21:23:58 <MattB0ne> qtcreator
Apr 12 21:24:08 <MattB0ne> i wonder why the default install does not give access
Apr 12 21:24:12 <zmatt> accident
Apr 12 21:24:23 <zmatt> lemme check if it's still the case on the new image
Apr 12 21:24:58 <MattB0ne> this was the bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz
Apr 12 21:25:08 <zmatt> ok
Apr 12 21:28:23 <zmatt> filed bug report
Apr 12 22:02:49 <deepankarmaithan> zmatt:  on the chip there are two mode selector pins. in the pseudo code there is just one S
Apr 12 22:03:24 <zmatt> 21:30 <@zmatt> (I'm viewing Q and IO as 8-bit quantities and S as 2-bit quantity, with S0 = bit 0 of S, Q1 = bit 1 of Q, etc)
Apr 12 22:04:08 <zmatt> note how my code tests whether S is 0, 1, 2, or 3
Apr 12 22:04:45 <MattB0ne> Cool
Apr 12 22:07:11 <deepankarmaithan> got it
Apr 12 22:08:21 <MattB0ne> how can I install tilcdc
Apr 12 22:08:33 <zmatt> MattB0ne: that question makes no sense
Apr 12 22:08:41 <MattB0ne> https://pastebin.com/u8isP0qG
Apr 12 22:09:06 <MattB0ne> being greedy again
Apr 12 22:09:16 <zmatt> you're trying to use eglfs with the wrong libraries (mesa instead of the powervr libraries)
Apr 12 22:10:09 <MattB0ne> how do you know I am using mesa
Apr 12 22:10:17 <MattB0ne> from that pastebin?
Apr 12 22:10:21 <zmatt> yes
Apr 12 22:10:25 <MattB0ne> crystal ball magic
Apr 12 22:10:34 <zmatt> that error message is from mesa's libgbm
Apr 12 22:11:00 <MattB0ne> so what package gives me the powervr libraries
Apr 12 22:12:02 <zmatt> (also, /usr/lib/x86_64-linux-gnu/dri/ is where mesa installs its drivers)
Apr 12 22:13:41 <zmatt> I don't think rcn has built any packages for those, just the modules
Apr 12 22:14:46 <zmatt> I've built (kinda hacky) packages for them when I last did anything with gui on the bbb, but that's quite a while ago: https://liktaanjeneus.nl/sgx/
Apr 12 22:14:55 <zmatt> maybe they still work, maybe they don't
Apr 12 22:15:55 <zmatt> (the perl script to patch qt5 will almost certainly no longer work, but hopefully such a patch is no longer necessary)
Apr 12 22:17:51 <zmatt> note that installing these libs requires removing mesa first
Apr 12 22:19:10 <zmatt> you should also make sure you have the sgx modules package installed for your kernel:  sudo apt install ti-sgx-ti335x-modules-$(uname -r)
Apr 12 22:25:27 <deepankarmaithan> zmatt:   I also studied the internals of shift register to understad it better through this really nice video. Since you are the focal point of all the questions in the community , thought should share with you. may be this could help someone else too.  here is the link  https://www.youtube.com/watch?v=AEGzpMlOsvc
Apr 12 22:26:19 <zmatt> I'm not a repository of links
Apr 12 22:27:05 <zmatt> if people want to learn more about shift registers, they can search the internet.  there's no doubt plenty of information about them
Apr 12 22:27:13 <deepankarmaithan> hahha. ok.
Apr 12 22:36:02 <MattB0ne> zmatt you are a repository of knowledge though =D
Apr 12 22:36:59 <MattB0ne> I think I am gonna stay put with just linuxfb and save eglfs for another day
Apr 12 22:37:17 <MattB0ne> the switching out the mesa drivers seems a bit rough
Apr 12 22:38:14 <zmatt> well you're not really using mesa right now anyway
Apr 12 22:38:51 <zmatt> only I think some qt library has a dependency on them, which is also satisfied by my package (assuming things haven't changed too much since I made those packages), so the dependency problem is just temporary
Apr 12 22:39:26 <zmatt> but yeah, if linuxfb works well enough for you then you should probably consider sticking to it
Apr 12 22:39:41 <zmatt> iirc, using eglfs with the gpu was actually slower than using linuxfb with no gpu
Apr 12 22:40:14 <zmatt> because qt basically still did all the widget drawing on the cpu and used the gpu only for final compositing
Apr 12 22:41:58 <zmatt> (maybe it would speed things up if you use qtquick, dunno)
Apr 12 22:42:11 <MattB0ne> yeah I do not know either add that to the pile
Apr 12 22:42:13 <MattB0ne> i am learning
Apr 12 22:42:20 <MattB0ne> thanks for doing what you do though
Apr 12 22:42:36 <MattB0ne> set_ provides the laughs and you provide the knowledge
Apr 12 23:44:38 <set_> I know stuff at times, sort of.
**** ENDING LOGGING AT Mon Apr 13 02:59:57 2020