**** BEGIN LOGGING AT Mon Oct 14 02:59:57 2019 Oct 14 03:00:08 Thanks! Oct 14 03:00:59 https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black is a good site for setting up. Oct 14 03:02:32 Maybe your dtbo file has the HDMI enablement file(s) in it. Let me check on my BBB. Oct 14 03:03:55 am437x-gp-evm-hdmi.dtb is what I found. Oct 14 03:04:21 on my BBB, this file, is what i think controls the HDMI but I am most likely incorrect. Oct 14 03:04:44 The reason I think I am incorrect is this: am437x is not am335x. Oct 14 03:04:54 But...who knows? Oct 14 03:05:12 koz_: Do you know how to set up dtbo files on your BBB? Oct 14 03:05:21 well, there and back? Oct 14 03:05:43 set_: No, I don't. I don't have that .dtb in my dtbs directory. Oct 14 03:06:04 Let me paste what I have. Oct 14 03:06:17 Okay. Let me see if I can find it again. Aw! Oct 14 03:06:32 https://pastebin.com/8X7ZfJRW Oct 14 03:07:32 I am sure we can find the .dtbo file. Oct 14 03:07:34 But... Oct 14 03:08:01 We need to put in the correct commands to set up the .dtb from the .dtbo file. Oct 14 03:08:04 Does that make sense? Oct 14 03:08:23 Sorta? I'm using a prebuilt image, so I have no idea what they did, or didn't, include. Oct 14 03:09:20 oh. Yea. That site I showed you, the digikey site, has instructions to build your own but they have Debian and Ubuntu only. Oct 14 03:10:10 You might be able to get away w/ trying the OS you want where there are installation instructions for putting in the Debian/Ubuntu distros. Oct 14 03:12:49 OK, thanks. I'll try and ask in my distro's IRC channel again. Oct 14 03:14:27 No issue. Oct 14 03:15:02 I am looking up how to change the .dtbo to a .dtb again but they use uboot overlays. I am not completely sure how that affects things or if it is of any concern w/ your images. Oct 14 03:37:51 koz_: Are you still using device tree stuff. If so, this may be useful. Oct 14 03:38:25 What may be useful? Oct 14 03:38:36 dtc -@ -I dts -O dtb -o 1st.dtbo 1st-overlay.dts. This should make use for your overlay since it is open source on github. Oct 14 03:39:19 What overlay are you using? Oct 14 03:40:44 set_: I don't know what you mean. I got the image and instructions from the Installation section here: https://archlinuxarm.org/platforms/armv7/ti/beaglebone-black Oct 14 03:41:21 oh. Oct 14 03:41:29 Let me look real quickly. Oct 14 03:42:37 So, that worked and now you have a full-fledge image on your board? Oct 14 03:42:41 Nice! Oct 14 03:42:57 Now, I am sure since it is so old, device tree overlays were still used. Oct 14 03:43:15 I wanted to type something earlier. Oct 14 03:43:21 This is not a one-nighter for me. Oct 14 03:43:23 Yeah, it works for everything, except HDMI lol. Oct 14 03:43:28 oh. Oct 14 03:43:30 Okay. Oct 14 03:43:46 I would need to research and ask a ton of questions. I am willing but I have odd hours. Oct 14 03:44:19 koz_: I can help but you are going to need to set up everything yourself. That is what the installation page is about. Oct 14 03:45:21 set_: I can definitely set all this up. I've built a cross-compiler before, so this isn't news to me. Oct 14 03:45:43 Okay. Oct 14 03:46:09 I just think that uboot overlays is not used and that the other overlays are used. Oct 14 03:46:15 So, here goes. Oct 14 03:47:02 History...at some point, bbb.io people turned on the other overlays and use uboot overlays. For whatever reason, it is done. Oct 14 03:47:26 What exactly is a u-boot overlay? Oct 14 03:47:31 I've never heard of these before today. Oct 14 03:47:39 Oh. Please hold. Oct 14 03:48:24 https://forum.digikey.com/t/all-beaglebone-varients-u-boot-overlays/26 may help. Oct 14 03:48:42 Thanks, will read. Oct 14 03:49:53 koz_: Please hold. Let me put together something. Oct 14 03:52:47 Thanks! I appreciate you taking the time - I'm learning lots of cool and useful things in this process. Oct 14 03:53:01 (you helped me fix and understand an unrelated issue on another SBC already) Oct 14 03:53:26 Hey. Oct 14 03:53:36 No issue. I should just download the image and do it. Oct 14 03:53:43 Come back one day. Oct 14 03:53:51 I should/might get to it. Oct 14 03:54:07 set_: No worries - I've got a bouncer, so I'm always on here. Just message me if/when you get to it. Oct 14 03:54:18 Otay! Oct 14 03:54:41 Arch Linux. Yikes but sounds like an endeavor. Oct 14 03:54:54 I will definitely try it. Oct 14 03:55:53 Let me know what you find. Oct 14 03:55:59 Yep. Oct 14 07:57:20 i'm running ubuntu 10, on a bbg. I'm using AWS greengrass, which is periodicaly polling some i2c degvices Oct 14 07:57:40 it runs nicely for a while, but i'm getting some odd failures. Oct 14 07:57:42 OSError: [Errno 16] Device or resource busy Oct 14 08:00:59 mrpackethead: Did you check your i2c signals with a scope? Oct 14 08:01:15 yeah, they seem ok. Oct 14 08:01:39 i'm only getting this error perhaps once in 5-7 days Oct 14 08:07:36 not that I know anything, but that sounds like an EMC problem Oct 14 08:08:07 is this paired with an error in the kernel log? Oct 14 08:08:48 a spike on SDA can easily lock up the i2c controller state machine Oct 14 08:09:08 so noise pickup is definitely a concern Oct 14 08:09:55 does the bus have pull-ups of adequate strength? Oct 14 08:15:18 i've got some groove sensors Oct 14 08:20:33 zmatt, nothing obvious in the kernal log Oct 14 08:21:18 mrpackethead: no line prefixed with i2c? Oct 14 08:21:24 no.. Oct 14 08:21:31 that's odd, if it were an i2c bus error I'd expect a kernel message about it Oct 14 08:22:09 could it be an issue with the driver for the specific device you're using, or does it happen with multiple different devices? Oct 14 08:22:18 i've only tested it with the one Oct 14 08:22:36 these are hung on bits of wire.. Oct 14 08:22:40 its less than 'ideal' Oct 14 08:22:53 groove kit.. very quick to bolt stuff together Oct 14 08:23:08 then my guess would be it's either a hardware issue or a software issue Oct 14 08:23:12 ;) Oct 14 08:23:54 I'm reading from an HP206C Oct 14 08:24:16 zmatt, i'm goign with it being an issue Oct 14 08:24:19 :-) Oct 14 08:24:50 I'm running a beaglebone black from an old laptop running Win7 via PUTTY. It's worked for several years but suddenly I find that I can set up the Putty screen but I can't log onto Debian. Any ideas? Oct 14 08:31:40 when you say, via putty, are you SSH'ing to it over ethernet, or using a serial connection, or a usb connection Oct 14 08:37:11 zmatt, what would i expect to see in the kernal Oct 14 08:42:36 try doing an i2c transfer on an i2c bus whose pins are muxed to gpio instead of to i2c Oct 14 08:42:40 that error. Oct 14 08:50:27 i think i can catch the error in software Oct 14 08:51:38 sure, it's probably worth retrying the transfers a few times on error, if that is safe to do for what you're doing, but of course that's just an ugly workaround rather than a fix :P Oct 14 08:54:20 a missed meaurement in my case is not the end of the world Oct 14 08:54:31 but as you say, i'd rather fix the issue Oct 14 08:54:54 hanging sensors off a groove board is not always such a great idea Oct 14 08:56:19 are you using the sysfs interface for a measurement or the "proper" iio device? Oct 14 08:56:46 (i.e. python3-libiio ) Oct 14 08:59:08 ok there's no explicit EBUSY in the hp206c driver, so it must come from either the i2c layer or the iio layer Oct 14 09:00:11 wait I'm assuming you're using the hp206c kernel driver Oct 14 09:00:12 are you? Oct 14 09:00:45 if you're just doing manual i2c transfers then never mind what I just said :P Oct 14 09:07:29 zmatt, https://pastebin.com/Nm6QptNg Oct 14 09:07:44 using smbus2 Oct 14 09:10:29 why are you spawning a new thread for each measurement? Oct 14 09:11:40 for that matter, why are you opening and closing the i2c bus device for each measurement :P Oct 14 09:12:40 I'm assuming there's no concurrent access to this same i2c device by any other process? Oct 14 09:20:14 why do you think its being 'opened and closed' Oct 14 09:20:17 i';m confused. Oct 14 09:20:35 bus = smbus2.SMBus(2) that opens the bus Oct 14 09:20:54 and it'll get closed when this object gets garbage collected Oct 14 09:21:18 and you're doing this inside def measure() rather than outside it Oct 14 09:22:03 yes, i suppose that is a valid point Oct 14 09:22:33 practically i doubt it will make much difference Oct 14 09:23:02 well given that it is undefined when garbage collection happens, you may end up with a lot of open instances Oct 14 09:23:11 and I don't know what impact that may have Oct 14 09:25:03 its worth sorting though Oct 14 09:25:04 if you do choose to reopen the bus each time, use a with-block ( with smbus2.SMBus(2) as bus: ) to ensure it will always get closed Oct 14 09:25:41 ok, its bed time, and i need to go now Oct 14 09:25:48 (it ensures it will get closed at the end of the with-block, regardless of whether that block is exited normally or abnormally) Oct 14 09:26:08 es. Oct 14 09:27:11 and it seems like the only plausible source for EBUSY in the kernel is in omap_i2c_recover_bus() Oct 14 09:27:41 but it would require a bus-busy state with SCL observed low, which seems very odd Oct 14 09:36:44 Duh! - I needed to install drivers. Oct 14 09:37:09 Guest5791: oh right, windows 7 still needed those Oct 14 09:37:47 (the "driver" is actually a signed text file telling windows to use microsoft's own fucking driver for their own fucking proprietary RNDIS protocol) Oct 14 09:38:26 usb is implemented so so badly in Windows Oct 14 11:44:54 I have a BBB with Debian 9.9 2019-08-03 4GB SD IoT image. but I'm not able to configure UART Oct 14 11:45:04 how can I use the serial port ? Oct 14 11:46:23 grey99: configure the pins to uart mode, e.g. using the config-pin utility, and the you should be able to use the corresponding /dev/ttyS* device Oct 14 11:51:55 (alternatively you can configure an overlay to configure the pins instead of configuring them at runtime, whichever you prefer) Oct 14 17:25:51 er, yeah, I really want to get down to fewer images. Oct 14 17:26:11 sorry, message send got delayed. Oct 14 18:07:17 why? Oct 14 18:12:06 the latest-images page can definitely be improved though to make it easier for users to select the right image... e.g. a form (using client-side javascript) to pick the device they have, if applicable to the device select whether they want to run from SD card or flash to eMMC, select the image type (iot, lxqt, maybe console) with a short description of what each means, and then show a list of images ... Oct 14 18:12:12 ...sorted by release date (latest first) Oct 14 21:24:11 +1 ^ Oct 14 21:47:44 Does anyone know if the UIO PRU driver works with the new BeagleBone AI board? Oct 14 21:48:04 I use uio-pruss on my beagleboard-x15 Oct 14 21:48:08 (which is the same SoC) Oct 14 21:49:07 see also the README.md of my py-uio project => https://github.com/mvduin/py-uio Oct 14 21:50:54 (the BeagleBoard-X15 instructions should also apply to the BeagleBone AI) Oct 14 21:51:02 I should update the readme to reflect that Oct 14 21:51:55 Cool! I knew the BB AI didn't have the uboot_overlay_pru line in the uEnv.txt Oct 14 21:51:59 Thanks! Oct 14 21:54:17 overlays don't work yet on the beaglebone AI Oct 14 21:54:26 (afaik) Oct 14 21:54:31 oh wait, or maybe they do Oct 14 21:54:32 not sure Oct 14 21:55:10 the use of overlays is kinda limited anyway because of the pinmux headaches, but changing from remoteproc-pru to uio-pruss should be not problem Oct 14 21:56:43 you should be able to turn the dra7-uio-pruss.dtsi snippet into an overlay using my overlay-utils: https://github.com/mvduin/overlay-utils ... that would save you from having to manually transform the .dtsi to the obnoxious dts structure for an overlay Oct 14 21:56:53 (the makefile in my overlay-utils invokes a perl script to perform that transformation) Oct 14 22:36:29 doesn't look like overlays are supported yet, based on the /boot/uEnv.txt Oct 15 00:00:04 zmatt: have you tried running the x15 with ALL the PRUs spinning and cores spinning? (i.e. no sleeps) Oct 15 00:01:19 koz_: Okay. I will have some issues w/ this idea thus far. I have a computer that runs Ubuntu but the computer does not have sd card support. Oct 15 00:01:36 I need to get one of those SD Card readers. Blah. Oct 15 00:01:49 set_: I bought my laptop _specifically_ with that use case in mind. :P Oct 15 00:01:57 (she has an SD card reader/writer/slot thingo) Oct 15 00:02:10 Oh. Oct 15 00:02:19 My is an older work computer. Oct 15 00:02:32 ds2: to try to get it to heat up you mean? Oct 15 00:03:08 ds2: I haven't even tried letting both a15 cores spin, only one core. I doubt the PRUs will contribute much incomparison Oct 15 00:03:27 I have a card reader but the thing is 3.0 not 2.0. Oct 15 00:03:28 I can easily spin up the PRU cores to check though Oct 15 00:04:15 This old work computer is old, old, old. Oct 15 00:04:35 set_: Yeah, it _sounds_ pretty old. Oct 15 00:05:14 zmatt: heat or any other bad side effects Oct 15 00:05:58 zmatt: trying to decide if I should toss in an auxillery AM335x to thermally off load the AM5 :D Oct 15 00:08:22 I've spun up all four PRU cores, so far seems to have no impact on temperature whatsoever Oct 15 00:08:33 (on any of the sensors) Oct 15 00:08:45 is the PRU mux'ed to the outside world? Oct 15 00:09:12 no I'm just spinning the cores in an infinite loop (main: jmp main) Oct 15 00:10:17 so the core is clean; just remains to see how bad are the IO driver cells when toggling Oct 15 00:10:56 will obviously depend on how many IOs and how much external load Oct 15 00:11:01 and how fast they toggle Oct 15 00:14:40 no, w/o load, just talking about leakage in the driver totem pole Oct 15 00:15:17 the PRU is suppose to be able to toggle them fast but slew rate should also be a big factor Oct 15 00:15:46 https://pastebin.com/raw/VsiD182q here's the thermals I measured in case you care... 2-second measurement interval, pru cores were started a few seconds after logging started Oct 15 00:16:23 but I don't think there's any change in it other than random fluctuations Oct 15 00:16:40 what's the IVA doing? Oct 15 00:16:47 koz_: My other 'puter has the reader port but it is a Win 'puter. Oct 15 00:16:51 nothing I presume Oct 15 00:16:56 or is the PRU heating the IVA indirectly? Oct 15 00:17:27 PRU doesn't seem to be heating anything Oct 15 00:17:39 I see no changes in the IVA sensor Oct 15 00:17:56 set_: :( Oct 15 00:18:01 54.2, 58.8, 54.6, etc Oct 15 00:18:09 koz_: If you have more time, good. If not, I understand. The card reader will be here at some point. 18th. Oct 15 00:18:16 I can wait, no rush. Oct 15 00:18:20 Yea boy! Oct 15 00:18:21 Just when you can. Oct 15 00:18:24 Okay. Oct 15 00:18:32 whereas the other ones are much lower variation, i.e. the GPU Oct 15 00:18:53 Now, on to researching that github page for beagleboard.org. Oct 15 00:19:09 They have everything on it but one needs to find it first. Oct 15 00:19:18 ds2: where are you seeing 58.8? it just seems to fluctuate between 53.8 and 54.2 (and on rare occasion 54.6) Oct 15 00:19:37 my guess would be the iva sensor is physically closer to the cortex-a15 Oct 15 00:19:42 zmatt: typo - 53.8 I mean Oct 15 00:20:18 anyway, it has those values at the start and still has those values at the end, so pru had no impact on it Oct 15 00:20:38 the first reading had 0 PRU activity? Oct 15 00:20:49 yeah I started the cores after the first few readings Oct 15 00:20:52 (vs you grab this while the PRU is running) Oct 15 00:20:55 ah got it Oct 15 00:21:23 so as we already knew, the PRUs are pretty cool ;) Oct 15 00:21:43 (pun definitely intended) Oct 15 00:21:44 nifty Oct 15 00:21:55 koz_: I am going to set up the system as is... Oct 15 00:22:09 W/ how it is described first in the instruction page. Oct 15 00:22:37 Then, off to test things. They say this reader will be in on the 18th. Fri! Oct 15 00:23:02 I will have all weekend to do the bidding! Oct 15 00:24:51 koz_: Did you ever get the Adafruit_BBIO library to work on the Arch? Oct 15 00:25:04 set_: I don't think I tried. Oct 15 00:25:12 Okay. No issue. Oct 15 00:25:25 What would you use Arch on the BBB for exactly? Oct 15 00:25:34 Prying eyes would like to know...Ha. Oct 15 00:26:18 For display or just for basic computing? Oct 15 00:26:34 oh yeah, I starting making a (pure-)python gpio library that doesn't suck... I should probably try to finish it Oct 15 00:26:48 (for a lot of purposes a library is kinda overkill though) Oct 15 00:26:49 Yea boy! Oct 15 00:27:06 https://github.com/beagleboard/linux/blob/4.14/arch/arm/boot/dts/am335x-abbbi.dts is a .dts file we can use but it is not the one we will use. Oct 15 00:27:32 I need to keep searching. We can make it suit your needs but there are some more ideas that need to be completed first. Oct 15 00:30:50 https://github.com/beagleboard/linux/blob/4.14/arch/arm/boot/dts/am335x-boneblack-common.dtsi is it I think but we need to figure out how to compile it at boot time while making the image. Oct 15 00:30:51 ... Oct 15 00:31:02 Here lies the hard part for a new comer to Arch. Oct 15 00:32:08 koz_: I heard once that there is some sort of incorrect toolchain that works w/ Debian that does not work in the Arch Distro. Oct 15 00:32:10 But... Oct 15 00:32:22 Who knows? I will test it. Oct 15 00:34:20 koz_: Do you have a Cape for display? I forgot... Oct 15 00:35:44 I think these HDMI, .dtsi files are for use w/ "Display" Capes or a viewer utility. Oct 15 00:39:10 Scratch that... Oct 15 00:39:23 I keep forgetting we are just getting the HDMI on the BBB to work. Sheesh. Oct 15 00:40:30 koz_: When you start up your image w/ the overlays, is the HDMI overlay for the BBB listed in those options? Oct 15 00:40:51 koz_: tell X11 to use 16-bit color depth instead of 24-bit color depth Oct 15 00:42:08 I ask b/c...when I compile my images on my desktop env, I get an option screen w/ many available options. Oct 15 00:42:39 koz_: in the Screen section: DefaultDepth 16 Oct 15 00:43:22 koz_: that should have a decent chance of fixing your error (the "modeset(0): failed to set mode: Invalid argument") Oct 15 00:45:30 In those options, you can pick and choose what you desire. Until Fri, I am talking trash. But... Oct 15 00:46:02 If it is available, we compile it and then put it on the board for runtime/boot. Oct 15 00:46:33 koz_: for some reason X11 is too dumb to query the kernel which pixel formats are actually supported :P Oct 15 00:48:17 which for the BBB is normally RGB565 (RG16), BGR888 (BG24), and XBGR888 (XB24) Oct 15 00:51:37 the hdmi framer does support swapping the red and blue channels, so with a DT change it is possible to change that list to BGR565 (BG16), RGB888 (RG24), XRGB888 (XR24) ... but then old/dumb applications like X11 will only be able to use 24-bit depth and not 16-bit depth, and it's actually better to use 16-bit depth since only 16 data lines are connected to the HDMI framer... using 24-bit color depth ... Oct 15 00:51:43 ...will just waste memory and memory bandwidth (and misinform X11 client applications, which could otherwise compensate by e.g. dithering) Oct 15 00:52:14 when using an LCD cape instead of the HDMI framer it'll depend on how the lcd is wired up to the beaglebone Oct 15 00:54:35 (it is possible to query the list of supported pixelformats via libdrm, and X11 is already using libdrm for modesetting, so it really has no excuse for requiring manual configuration in xorg.conf for this) Oct 15 00:56:25 Hmm. That sounds reasonable and could completely put me on the shelf on this project. Oct 15 00:56:36 Still. I am going to try it out! Oct 15 00:56:52 this is configured right on debian images Oct 15 00:57:07 Right. koz_ wants to put it on Arch. Oct 15 00:57:39 He put the system on the BBB but he cannot find a way to make it work yet. Oct 15 00:57:48 w/ HDMI! Oct 15 00:57:50 Sorry. Oct 15 00:58:38 yeah, sounds like Arch Oct 15 00:58:38 https://archlinuxarm.org/platforms/armv7/ti/beaglebone-black is the link. Oct 15 00:58:48 Oh. Oct 15 00:59:06 So, you are aware of it and it may just be a simple exchange in the .dtsi file? Oct 15 00:59:21 no it's a simple change in xorg.conf, which is what I said Oct 15 00:59:25 Oh. Oct 15 00:59:29 Yikes. Oct 15 00:59:35 koz_: You say that? Oct 15 00:59:44 say = saw Oct 15 00:59:56 I'm sure he'll read scrollback when he gets back Oct 15 01:00:02 Okay. Oct 15 01:00:29 See. I figured there would be no way for it to be on his distro already since the files were not located on his BBB. Oct 15 01:01:06 ? Oct 15 01:01:11 I figured one would need to put the files on the BBB during the compilation. Oct 15 01:01:18 Or before, whatever. Oct 15 01:01:21 And then... Oct 15 01:01:23 xorg.conf normally doesn't exist, he may have to create it Oct 15 01:01:30 Oh! Oct 15 01:01:34 I don't know what you're talking about sorry Oct 15 01:01:38 No issue. Oct 15 01:02:04 @zmatt: When I cross-compile images... Oct 15 01:02:22 1. set up the booting source Oct 15 01:02:33 what do you mean by "cross-compile images" Oct 15 01:02:55 Using a desktop env. to make the image and then put it on the BBB. Oct 15 01:03:31 I thought this was the only way to put all the correct files available for the BBB. Oct 15 01:03:52 ? Oct 15 01:04:16 are you talking about rcn's image builder or.. ? also, why would you want to build an image with that instead of using a prebuilt one? Oct 15 01:04:29 also generally that doesn't involve any compilation I think Oct 15 01:04:38 Right. Okay... Oct 15 01:04:39 But... Oct 15 01:06:00 it is as easy as: apt install device-tree-compiler? Oct 15 01:06:08 ??? Oct 15 01:06:17 And then to perform the necessary functions? Oct 15 01:06:21 why are you talking about something competely different suddenly? Oct 15 01:06:34 *completely Oct 15 01:07:17 B/c.. Oct 15 01:07:29 What you are describing is not what I am talking about at all. Oct 15 01:07:58 I thought this was a way of putting files on the BBB at compilation time. Oct 15 01:08:09 what is "this" ? what are you even talking about? Oct 15 01:08:12 what "compilation time" ? Oct 15 01:08:44 you seem to be talking about some random topic but I really can't even guess what Oct 15 01:09:02 Just setting up images for the BBB w/ what is offered. That is all. Oct 15 01:09:14 ???? Oct 15 01:09:32 Heh? Oct 15 01:09:35 Yes... Oct 15 01:10:14 There is a way to get the HDMI compatible .dtsi compiled at boot w/ the image. Oct 15 01:10:20 I still have no idea what you're talking about, or what you're trying to achieve with what you're trying to say... are you asking some help with something.. or? Oct 15 01:10:33 No. No help here. Oct 15 01:10:43 I do not need help (right now). Oct 15 01:10:48 that sentence is again a word salad, but I'm assuming his .dtsi is fine... I see no reason to assume it isn't Oct 15 01:11:14 Did you see what was lacking on his board so far? Oct 15 01:11:15 my guess is that he only needs the first thing said: xorg.conf needs a DefaultDepth declaration Oct 15 01:11:23 Okay. Oct 15 01:11:30 the rest of what I said after that was just informational to explain the underlying issue Oct 15 01:11:38 If you are right, so be it. Oct 15 01:12:20 This could have been a glorious way to cross-compile w/ uboot and create a fresh image w/ hdmi for the BBB. Oct 15 01:12:23 But no! Oct 15 01:12:28 You are right, as always. Oct 15 01:12:48 it would probably be nice if this beaglebone arch image had a correct configuration to begin with, but that's not my problem :P Oct 15 01:12:49 koz_: Please try what @zmatt stated. Please. Oct 15 01:13:11 that's for whoever maintains that image Oct 15 01:13:35 @zmatt: If you are right, I will shut up but if, if, you are off base b/c of that image not having anything on it, then I can try my way. Fair? Oct 15 01:14:16 I have no idea what "your way" is, or what you're talking about in general Oct 15 01:14:22 Fine. Oct 15 01:14:40 I know what i am saying even though it may not be the "cool" way to do things. Oct 15 01:15:08 Oh well. Let us wait on koz_ to figure out the issue w/ what you said. Oct 15 01:16:25 I just checked, mainline linux seems to have a correct devicetree for the BBB as far as hdmi is concerned, so I don't think there's any problem there Oct 15 01:16:59 it's 99% sure just xorg being annoying Oct 15 01:18:09 zmatt: OK, I will try that right now. Oct 15 01:20:19 for the record, I did not look at the log. Oct 15 01:20:58 koz_: hmm, interestingly DefaultDepth is commented out in the current default xorg.conf on the BBB... https://pastebin.com/raw/vJF5GCbY Oct 15 01:21:10 this is an interesting contrast with this random other xorg.conf I found: https://github.com/RobertCNelson/tools/blob/master/ubuntu/setup-xorg.sh#L27-L46 Oct 15 01:22:03 ohh maybe it's needed for modesetting but not for fbdev Oct 15 01:22:52 zmatt: That did it. Oct 15 01:22:55 I feel like modesetting *ought* to be used, I wonder why rcn forces it to fbdev... maybe fbdev is faster than modesetting (although it really has no reason to) Oct 15 01:23:07 Thanks so much! Oct 15 01:23:14 Now at least I have a screen. Oct 15 01:23:48 koz_: it works with the modesetting driver and DefaultDepth 16 ? out of curiosity, does it also work with the fbdev driver without DefaultDepth ? Oct 15 01:24:12 <<<< shutting up Oct 15 01:24:18 I thought I was using the fbdev driver. Let me just paste you my newest log. Oct 15 01:24:37 yeah I saw stuff from both so it wasn't quite clear to me Oct 15 01:24:47 zmatt: http://ix.io/1YzO Oct 15 01:24:49 but the error it gave was from modesetting Oct 15 01:25:14 this is the old log Oct 15 01:25:35 Whoops, gotta turn off X first. Oct 15 01:25:47 and you were definitely using modesetting Oct 15 01:26:09 see around timestamp 695.831 in your old log Oct 15 01:26:40 fbdev gets unloaded, modeset is initializing Oct 15 01:27:41 Which one should I be using? Oct 15 01:27:47 I'm a bit unclear on the difference. Oct 15 01:28:11 fbdev is older and won't support xrandr nor things like double-buffering Oct 15 01:29:16 Sounds like I want modeset then? Oct 15 01:29:19 modesetting *ought* to be the right choice... but there's presumably a reason for it being forced to fbdev in this config file (which I pulled from the bone-debian-9.5-iot-armhf-2018-10-07 image) Oct 15 01:29:54 rcn-ee[m]: why does the xorg.conf select the fbdev driver instead of modesetting? Oct 15 01:33:40 OK, one second, I seem to be missing a few key things. Oct 15 01:34:50 koz_: if I had to guess, maybe fbdev turned out to perform better under some circumstances or something... though I wouldn't expect X11 to perform particularly well on the BBB either way ;P Oct 15 01:34:57 namely? Oct 15 01:35:12 zmatt: Fonts so that I can see what's actually happening in the i3 I'm spinning up. Oct 15 01:35:53 the i3 you're spinning up? Oct 15 01:36:08 I'm using startx to ... well, start X. And I'm having it launch i3. Oct 15 01:36:10 anyway, I'd suggest just using modesetting Oct 15 01:36:12 what's i3? Oct 15 01:36:19 ah, a wm Oct 15 01:36:29 https://i3wm.org/ Oct 15 01:36:38 well from here on it's just you versus Arch... nothing beaglebone specific :P Oct 15 01:36:51 Indeed. Oct 15 01:36:58 Thanks for the help! Oct 15 01:37:32 I've tried Arch briefly on my laptop a while back... my experience was that is was rare for anything to work right without manual fiddling/configuration :P Oct 15 01:38:06 zmatt: That was true a while back. Oct 15 01:38:08 though I wish debian's APT was as fast as arch's package manager (forgot the name) Oct 15 01:38:11 Not really so much now. Oct 15 01:38:14 (pacman) Oct 15 01:38:17 ah yeah Oct 15 01:40:57 I wonder if all the crap in the xorg.conf is really necessary... I feel like just Section "Screen" DefaultDepth 16 EndSection ought to be sufficient, can't it just figure the rest out by itself? Oct 15 01:44:28 Almost - you need an Identifier in there for this to fire. Oct 15 01:45:09 fair, something to match on Oct 15 01:45:49 really somebody should just dig into the modesetting driver to see it can be fixed to properly autodetect Oct 15 01:45:56 (somebody braver than me) Oct 15 01:47:23 And me. Oct 15 01:48:59 like... I'm actually reasonably comfortable digging around in the kernel drm code, but x11 is just too horrid Oct 15 01:58:09 zmatt likely true however I am uncertain how one would improve it. It's just one of those "what the heck" kind of things I guess. Oct 15 01:58:38 GenTooMan: hmm, what? Oct 15 01:59:35 I feel like that's a probably reply to something a while back, but I definitely don't remember what we last talked about :P Oct 15 01:59:44 zmatt X11's source code, it's kind of a mess Oct 15 02:01:28 ah... oh yeah I wouldn't even dare to propose somehow cleaning up x11... it should just be dumped and replaced by wayland. however someone who manages to tolerate the existing x11 codebase could definitely fix this stupid lack of color depth autodetection in the modesetting driver :P Oct 15 02:10:07 Well when one makes huge changes on something, it's going to be bad. There are reasons code is the way it is in X. Their is nothing more destructive and messy than inexperience. I can vouch for that personally :D Oct 15 02:10:57 well there's also a lot of historical baggage Oct 15 02:11:26 and come on, the xorg.conf manpage has this in it: Oct 15 02:11:30 VIDEOADAPTOR SECTION Oct 15 02:11:30 Nobody wants to say how this works. Maybe nobody knows ... Oct 15 02:12:23 :P Oct 15 02:14:44 I have looked at several X server sets the difficult issue is how to manage configuration originally it was entirely based on a fixed driver. With the PC the video hardware could change. So yes it's tricky because flexible video hardware wasn't part of the original X11 setup. Oct 15 02:16:12 sure, but the modesetting driver came after that Oct 15 02:16:59 or I mean... I'm not sure what, if anything, you're defending here Oct 15 02:17:32 I understand why x11 is the way it is... like I said, historical baggage :P Oct 15 02:31:10 I am actually defending your assertion something has to change, however I am also saying one should do so carefully with the idea of the future in mind. Oct 15 02:38:50 I am concerned people forget what X was for, a flexible system to work across numerous different systems the same way consistently. **** ENDING LOGGING AT Tue Oct 15 02:59:57 2019