**** BEGIN LOGGING AT Fri May 11 03:00:04 2018
May 11 03:06:28 <GenTooMan> python3 -m pip ?
May 11 03:07:04 <GenTooMan> ehh night sleep time
May 11 03:08:28 <set_> The stuff was already installed on my system. I found it! The prompt just did not state that it was already satisfied.
May 11 03:08:40 <set_> Oops!
May 11 04:42:14 <kremlin> good evening
May 11 07:21:47 <parduz> Hello to all. Hi zmatt.
May 11 07:23:13 <parduz> I would create a "driver" for my own cape, deriving it from the LCD4 one. What should i do?
May 11 07:23:33 <kremlin> need more information parduz
May 11 07:23:50 <parduz> If i remember well, the best way should be to create a "device overlay".... am i right?
May 11 07:25:14 <parduz> Hi kremlin. We started from a LCD4 touchscreen cape and built our own "cape", with a Atmega emulating EEPROM and managing i2c bus.
May 11 07:25:16 <kremlin> device overlays (DTBs, DTSs etc) allow the early boot code of the operating system to associate drivers with address ranges
May 11 07:25:35 <kremlin> you'd still need a driver that acknowleges the new name in DTB, and attachs to it
May 11 07:28:12 <parduz> Ok. From the "point of view" of the BBB, our cape is a LCD4 equivalent. To start, I'd want to change the association of the 5 pins the LCD4 capes uses as Keys.
May 11 07:30:26 <parduz> The idea is to get SO events from them to be handled in my GUI app.... i could associate that inputs to "unusual keys" for now, if there's not a simpe way to get user events.
May 11 07:31:12 <parduz> (as a windows programmer, i'm a bit lost in this environment)
May 11 07:34:43 <kremlin> hmm
May 11 07:35:05 <kremlin> you sent these messages at the right time if my understanding that LCD4 is related to the LCDC
May 11 07:36:38 <parduz> LCD4 is a 4.3" LCD touchscreen. Mine is from 4D.
May 11 07:36:50 <kremlin> are you using the LCDC to control it?
May 11 07:38:24 <parduz> What is the LCDC?
May 11 07:39:29 <kremlin> lcd controller
May 11 07:40:49 <kremlin> hold on
May 11 07:41:18 <parduz> ...all i know is that the related DTS file is BB-VIEW-LCD4-01-00A0.dts
May 11 07:41:25 <kremlin> oh wait. you are probbly going to be using the touchscreen controller
May 11 07:41:37 <kremlin> you said you are looking to write a whole driver from scratch, right?
May 11 07:41:47 <kremlin> or is this just a "hook the cape up with linux" thing
May 11 07:42:18 <parduz> sorry for havent been clear....
May 11 07:42:28 <kremlin> it's fine
May 11 07:42:40 <kremlin> there was supposed to be a question mark at the end of my last msg
May 11 07:43:00 <parduz> let say i want to have my own DTS file
May 11 07:43:05 <kremlin> if you are writing your own driver, and it involves the LCD controller, i could probably lend a hand. i wrote that same driver for openbsd
May 11 07:43:13 <kremlin> ok
May 11 07:48:58 <kremlin> ...yeah?
May 11 07:49:03 <kremlin> what do you want to have the DTS do
May 11 07:49:13 <kremlin> & what operating system are you going to be running
May 11 07:49:16 <kremlin> @ parduz
May 11 07:50:02 <parduz> I'm running debian stretch with lxqt
May 11 07:50:19 <kremlin> ok, so debian already has the display driver
May 11 07:50:26 <kremlin> what are you trying to do with the dts?
May 11 07:50:33 <kremlin> configure the cape properly?
May 11 07:51:06 <parduz> the cape is like a LCD4
May 11 07:51:18 <parduz> what i need is a different input assignement
May 11 07:51:43 <parduz> as i don't want the LCD4 defined keys
May 11 07:51:54 <fred__tv> I'm interested too as  need to chenge resolution on my LCD7 clone
May 11 07:51:59 <kremlin> oh, yeah
May 11 07:52:04 <kremlin> im starting to get it
May 11 07:52:09 <kremlin> yes, modifying the DTS is the way to go
May 11 07:52:14 <kremlin> wait, wait
May 11 07:52:51 <fred__tv> no more overlays the old way, now uboot is used , how to do to modify dts and commit ??
May 11 07:53:13 <kremlin> i'm not sure exactly if you can do that through the DTS. i suspect you can. but on bsd, we use the control module described in section 9 of the TRM
May 11 07:53:16 <kremlin> BUT
May 11 07:53:32 <kremlin> i suspect that if you modify the phandle values, you can get it to do all of this through firmware
May 11 07:55:10 <parduz> About me, what i'd theoretically need is to get two events from the OS to be handled in my wxWidgets app. I don't know it is possible, so i'd be fine to still use two keydown events, using very uncommon keys.
May 11 07:56:03 <kremlin> how do you mean events
May 11 07:56:05 <kremlin> interupts?
May 11 07:57:16 <parduz> i'm a high level programmer.... events like "key down", "key up", "mouse move" "left mouse click", "paint".....
May 11 07:57:37 <parduz> i don't know how they're "made".
May 11 07:58:16 <parduz> the DTS assign inputs to keys, and as a result in my app i see keystrokesù
May 11 08:01:24 <parduz> i just wonder if there's a way to not use keystrokes (which on a desktop app are a bit triky to catch when focus switches around the various windows controls) and have other kind of events.... in windows you can generate  "user events" to be sent in a app queue and handle them as normal SO events....
May 11 08:02:01 <parduz> I hope what i says means something :)
May 11 08:18:52 <kremlin> 1 sec, work got busy
May 11 08:21:39 <parduz> no prl
May 11 08:34:29 <tbr>  parduz: did you ask on stackoverflow about this?
May 11 08:35:43 * tbr has dejavu: https://stackoverflow.com/questions/50227215/no-dispaly-on-bbb-running-with-android-marshmallow/50255418#50255418
May 11 08:36:55 <parduz> no, I tend to come here before going there
May 11 08:38:39 <parduz> but i have no problem with the display.
May 11 08:41:02 <tbr> :)
May 11 10:05:30 <zmatt> fred__tv: it's still exactly the same as before, the only thing that has changed is that u-boot loads the overlay
May 11 10:06:19 <zmatt> kremlin: you're not being helpful :P
May 11 10:06:45 <kremlin> something bad happened at work and im swamped
May 11 10:12:01 <parduz> hi zmatt
May 11 10:47:20 <tverrbjelke> hei zmatt, I owuld like to thank you again for your helping hand yesterday. This morning my both kids were so amazed by this 3 bbb I have here. (One newer from work and two anchient one I own myself). So I let them flash the 3rd one "themselves" (I wrote some doc-text from our session yesterday).
May 11 10:49:34 <fhassis> Hi! I'm trying to debug a simple hello world in Beagleboard-x15 using CCSv8 and a XDS560v2 emulator, but I'm struggling with loading the image in the target.
May 11 10:50:01 <fhassis> Is there some .ccxml and .cmd for beagleboard-x15 to use as an example?
May 11 10:50:55 <fhassis> I've been looking everywhere and tried several links with AM572x GP EVM without success.
May 11 10:52:38 <tverrbjelke> Now I am going to install "znc" irc bouncer server on one BBB ... if I would use an sd-card as "harddrive for user-data" - any tips how to format and mount inside debian 9 to maimize livetime? I have a nice 32GB UHS-I here, and I could live with 2-8GB real space for a very long time. Is there a way to maximize lifetime? Like only create a 4-8GB partition and ignore the remaining GB? Does that have
May 11 10:53:19 <tverrbjelke> experience with filesystems? ext4 OK?
May 11 11:48:26 <vishal1502> Hi There!
May 11 11:52:32 <fred__tv> Hi, anyway, I have to modify dts and create a new dtb  isn't it ?
May 11 11:57:34 <fred__tv> I'm screwed up.....
May 11 11:58:53 <fred__tv> uEnv.txt says :
May 11 11:58:55 <fred__tv> enable_uboot_overlays=1
May 11 11:59:23 <fred__tv> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
May 11 11:59:35 <fred__tv> enable_uboot_cape_universal=1
May 11 12:01:14 <fred__tv> so?  should I modify required dts to compile a new AM335X-PRU-UIO-00A0.dtbo ?
May 11 12:01:33 <fred__tv> what about cape_universal ?
May 11 12:27:12 <zmatt> what?
May 11 12:27:19 <zmatt> none of those have anything to do with LCD
May 11 12:28:50 <zmatt> unless you're overriding something, which it sounds like you're not, it's still going to be loading the same overlay as it used to.. you've already mentioned its name earlier
May 11 12:30:15 <zmatt> fhassis: you're trying to do baremetal development on an x15 ? that sounds... adventurous
May 11 12:31:42 <zmatt> fhassis: the GP EVM and the x15 are the same board, the EVM just has an lcd board attached to it
May 11 12:32:20 <zmatt> fhassis: my recommendation would be you ask on TI's E2E forum
May 11 12:33:16 <fhassis> yes, I'm doing baremetal development. I thought these two boards were the same, but for some reason it is not working.
May 11 12:33:41 <zmatt> they are the same
May 11 12:33:54 <fhassis> I'll post the problems on TI forum. Thanks for this clarification!
May 11 12:38:29 <zmatt> fhassis: I think the board would require quite some amount of initialization to be properly working though... wouldn't it make more sense to have your program loaded by u-boot so it can at least take care of basic initialization?
May 11 12:39:21 <fred__tv> zmatt: this is to modify LCD7 cape to fit my resolution, I'm wrong with something ??
May 11 12:40:05 <zmatt> fred__tv: well you were talking about very different overlays than the LCD one
May 11 12:40:35 <zmatt> also, something that's not entirely clear to me: do I understand correctly that this cape *claims* to be LCD7, but isn't, and in fact doesn't even have the same resolution?
May 11 12:53:51 <fred__tv> reset.... this cape claims to be an LCD7 but it has a 640x480 resolution. To fix this, I have modified BB-BONE-LCD7-01-00A3.dts with  hactive = <640>;  instead of 800,
May 11 12:54:34 <zmatt> okay, so essentially the cape has bogus eeprom content... great :P   but yeah, that same solution still applies
May 11 12:54:36 <fred__tv> hencompiled to obtain a .dtb loaded automatically at boot
May 11 12:54:51 <zmatt> yep, still works the same
May 11 12:54:58 <fred__tv> now, should I do the same ??
May 11 12:56:58 <fred__tv> If I remember, I used to do   dtc -O dtb -o myfile.dtb -b 0 -@ myfile.dts
May 11 12:56:58 <fred__tv>           still valid ?
May 11 12:57:35 <zmatt> if you clone the bb.org-overlays repository and edit the dts file in there, you can just do 'make src/arm/BB-BONE-LCD7-01-00A3.dtbo'
May 11 12:57:53 <zmatt> no need to remember the precise invocation of dtc
May 11 12:59:14 <fred__tv> git clone https://github.com/beagleboard/bb.org-overlays ?
May 11 12:59:21 <zmatt> yes
May 11 13:00:25 <fred__tv> trying .....
May 11 13:04:01 <fred__tv> another issue with gstreamer/kmssink red and blue colours are swapped , I've read it has to do with 16bit vs 24bit, any idea ??
May 11 13:04:39 <zmatt> that's also a problem in the DT
May 11 13:06:10 <fred__tv> but if I start desktop environment i.e. lxde all colours are fine....
May 11 13:06:36 <fred__tv> it's just when using gstreamer
May 11 13:06:37 <zmatt> yes
May 11 13:07:03 <zmatt> in the absence of a correct DT declaration, either 16-bit color or 24-bit color will look correctly but the other one won't
May 11 13:07:45 <zmatt> x11 has been configured to use 16-bit color, while as I observed earlier kmssink doesn't support 16-bit color at all (this is something you should probably report as a bug, as it will negatively impact performance)
May 11 13:08:14 <zmatt> with the right declaration in DT, both 16-bit and 24-bit color will look correct (or neither will if you use the wrong declaration :P )
May 11 13:09:28 <zmatt> inside the overlay fragment for &lcdc, put this: blue-and-red-wiring = "straight";
May 11 13:09:53 <fred__tv> to be fixed into LCD7 dts too ?
May 11 13:09:56 <zmatt> yes
May 11 13:10:05 <fred__tv> well
May 11 13:10:38 <zmatt> right after line 133 in the current version of the overlay
May 11 13:11:28 <zmatt> https://pastebin.com/qiBJS7Sc
May 11 13:12:40 <zmatt> I'm pretty sure "straight" is the correct one to use, but if it causes blue and red colors to be swapped everywhere (in both X11 and gstreamer) then use "crossed" instead of "straight"
May 11 13:13:02 <fred__tv> not sure if 00A2 or 00A3 was used, how to check ?
May 11 13:13:45 <zmatt> are you booting from eMMC ?
May 11 13:14:34 <fred__tv> no , old beagle white
May 11 13:14:39 <zmatt> oh
May 11 13:14:43 <zmatt> ehm
May 11 13:17:01 <zmatt> get my show-pins utility: https://github.com/mvduin/bbb-pin-utils/#show-pins
May 11 13:18:42 <zmatt> A2 uses P8.20 and P9.27
May 11 13:18:50 <zmatt> A3 uses P9.21 and P9.22
May 11 13:19:33 <zmatt> in the output of show-pins you can check which of those pins are being used by the lcd cape
May 11 13:20:12 <zmatt> crap, I really need to go
May 11 13:21:18 <fred__tv> Thank you !
May 11 13:21:25 <fred__tv> very much !
May 11 16:38:48 <tverrbjelke_> ping
May 11 17:34:13 <zmatt> ping timeout?
May 11 20:06:53 <fred__tv> HI, LCD7: after editing of dts file and make src/arm/BB-BONE-LCD7-01-00A2.dtbo, to apply changes what I have to do ?
May 11 20:07:11 <fred__tv> just copy new dtbo into /lib/firmware and reboot ?
May 11 20:07:14 <zmatt> yep
May 11 20:07:53 <fred__tv> so no need for ./install and reboot (like I have done....)
May 11 20:08:32 <zmatt> ./install builds the dtbos and copies them to /lib/firmware/
May 11 20:09:00 <zmatt> doing that for all dtbos is a bit excessive when you only need to replace one
May 11 20:09:31 <fred__tv> sure....  anyway RGB and resolution fixed
May 11 20:10:16 <fred__tv> now I'm stuck on streaming into kmssink not working.....
May 11 20:10:27 <fred__tv> but this is another topic...
May 11 20:11:38 <fred__tv> (after some hours with gstreamer channel guys)
May 11 20:18:41 <zmatt> streaming into kmssink doesn't work? even though kmssink in general does? that sounds oddly specific
May 11 20:19:14 <zmatt> are you getting any drm-related errors, or is it really just gstreamer being annoying?
May 11 20:22:52 <fred__tv> yes still DRM, I don't know how much you knos gstreamer anyway we thought this was the final command:
May 11 20:23:14 <fred__tv> gst-launch-1.0 rtspsrc location=rtsp://user:pass@ipaddress/Streaming/Channels/2 ! rtph264depay ! decodebin ! videoconvert ! videoscale ! video/x-raw,width=640,height=480 ! kmssink
May 11 20:24:09 <fred__tv> (as I need to play network camera stream into beagle's display)
May 11 20:24:35 <fred__tv> stream is played for 1 second then stops with error :
May 11 20:25:06 <fred__tv> https://pastebin.com/qeS9daCY
May 11 20:26:52 <fred__tv> testing mode: gst-launch-1.0 -v videotestsrc ! video/x-raw,width=800,height=480 ! kmssink   works like a charm
May 11 20:27:21 <fred__tv> sorry width=640,height=480
May 11 20:31:50 <zmatt> it plays for one second but then stops? that sounds really odd
May 11 20:32:45 <zmatt> I have trouble imagining how it could end up playing for a while and then suddenly get an error from drmModeSetPlane
May 11 20:36:01 <zmatt> you could try enabling debug messages from the kernel driver
May 11 20:37:14 <zmatt> looks like a few can be enabled via dyndbg:  echo 'file drivers/gpu/drm/tilcdc/* +p' >/sys/kernel/debug/dynamic_debug/control
May 11 20:37:43 <zmatt> most debug messages however use drm's debug infra... I forgot how that works
May 11 20:39:48 <zmatt> just to be sure, you weren't seeing any messages in kernel log?
May 11 20:40:48 <zmatt> it seems most reasons for getting EINVAL should actually log an error in the kernel log
May 11 20:46:31 <fred__tv> just set GST_DEBUG=4 , it gives me 269k of output....
May 11 20:46:37 <zmatt> lol
May 11 20:46:48 <zmatt> I saw you can also enable debugging more selective
May 11 20:46:49 <zmatt> ly
May 11 20:47:32 <fred__tv> not sure if further EINVAL errors....
May 11 20:48:16 <zmatt> do check the kernel log (using dmesg or journalctl -k) for errors/warning if you haven't already
May 11 20:48:32 <zmatt> and use the command I gave above to enable a few more messages from the driver
May 11 20:49:38 <fred__tv> how it works ? what should I expect ?
May 11 20:50:45 <zmatt> it just enables a few more messages to the kernel log
May 11 20:52:12 <zmatt> including two that accompany an EINVAL
May 11 20:55:06 <fred__tv> from dmesg:
May 11 20:55:25 <fred__tv> [ 5669.842573] tilcdc 4830e000.lcdc: tilcdc_plane_atomic_check: crtc position must be zero.
May 11 20:57:32 <zmatt> it's trying to display a frame that's smaller than the display
May 11 20:59:09 <zmatt> or more specifically, it's trying to display a frame that doesn't begin in the topleft corner of the screen
May 11 20:59:29 <zmatt> but I think it mainly does that if the frame doesn't quite fit the screen (so it ends up cropped/centered)
May 11 21:01:01 <zmatt> this error occurs if result.x or result.y are nonzero here: https://github.com/GStreamer/gst-plugins-bad/blob/master/sys/kms/gstkmssink.c#L1482-L1487
May 11 21:02:25 <fred__tv> so if frame doesn't fit exactly the display, it returns an error...
May 11 21:02:36 <fred__tv> dmesg:
May 11 21:02:41 <fred__tv> [ 5879.459705] tilcdc 4830e000.lcdc: tilcdc_plane_atomic_check: crtc position must be zero.
May 11 21:02:41 <fred__tv> [ 5879.468462] tilcdc 4830e000.lcdc: tilcdc_plane_atomic_check(): pixel format change requires mode_change
May 11 21:02:41 <fred__tv> [ 5881.931501] tilcdc 4830e000.lcdc: tilcdc_plane_atomic_check: crtc position must be zero.
May 11 21:03:00 <fred__tv>  this every time I launch command
May 11 21:03:04 <zmatt> what the fuck is gstreamer doing
May 11 21:03:21 <zmatt> oh I guess the pixel format thing isn't an error
May 11 21:03:33 <zmatt> it's probably because it's switching from 16-bit color to 24-bit color
May 11 21:05:47 <fred__tv> and strace sill gives
May 11 21:05:48 <fred__tv> [ 5669.842573] tilcdc 4830e000.lcdc: tilcdc_plane_atomic_check: crtc position must be zero.
May 11 21:05:52 <fred__tv> soory
May 11 21:06:08 <fred__tv> 1899  ioctl(7, DRM_IOCTL_MODE_SETPLANE, 0xb1eebc94) = -1 EINVAL (Invalid argument)
May 11 21:06:08 <fred__tv> 1899  ioctl(7, DRM_IOCTL_MODE_SETPLANE, 0xb1eebe54) = -1 EINVAL (Invalid argument)
May 11 21:06:13 <zmatt> yes you're getting EINVAL, we already know that
May 11 21:06:17 <zmatt> and I've already told you the reason]
May 11 21:06:36 <zmatt> or rather, the kernel has told you the reason
May 11 21:07:49 <zmatt> tilcdc requires the destination rectangle of drmModeSetPlane() to exactly cover the display, i.e. it must be { 0, 0, 640, 480 } in your case
May 11 21:10:00 <fred__tv> I don't understand why it works for a second then stops...
May 11 21:10:32 <zmatt> neither do I, you'd have to ask the gstreamer people why it would suddenly try to use a different destination rectangle
May 11 21:17:15 <fred__tv> gst-launch-1.0 -v videotestsrc ! video/x-raw,width=640,height=480 ! kmssink  : the video test pattern is piped into raw mode 640x480 and all is ok , something different happens when all those piping sequence evolves...
May 11 21:19:14 <fred__tv> however, [ 5879.468462] tilcdc 4830e000.lcdc: tilcdc_plane_atomic_check(): pixel format change requires mode_change   happens also with correct test pattern
May 11 21:20:31 <zmatt> I already said that's just because of switching from 16-bit color (which is normally used) to 24/32-bit color (which kmssink forces, annoyingly)
May 11 21:20:36 <zmatt> it's not an error
May 11 21:21:04 <zmatt> it's just a debug message
May 11 21:25:10 <fred__tv> just for information, if as rstp source I give an internet rtsp url , it works ok :
May 11 21:25:27 <fred__tv> gst-launch-1.0 rtspsrc location=rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov ! rtph264depay ! decodebin ! videoconvert ! videoscale ! video/x-raw,width=640,height=480 ! kmssink
May 11 21:28:40 <fred__tv> wait !  it works if I change the network camera stream url:
May 11 21:29:40 <fred__tv> rtsp://user:password@ipaddress/Streaming/Channels/2 to
May 11 21:29:43 <fred__tv> rtsp://user:password@ipaddress/Streaming/Channels/1
May 11 21:30:09 <fred__tv> 2 is low res. 1 is high res.
May 11 21:31:50 <zmatt> I hope you're not expecting feedback from me, since I don't know anything about gstreamer or its quirks
May 11 21:33:01 <fred__tv> 1 is 1280x960 , 2 is 352x288
May 11 21:34:04 <fred__tv> probably when connected , camera gives hi-res for 1 second then switch to lo-res causing the issue....
May 11 21:34:23 <zmatt> 352x288 isn't 4:3 ratio
May 11 21:36:06 <zmatt> scaling that up while preserving its weirdass 11:9 aspect ratio results in a size of 587x480 pixels
May 11 21:36:57 <fred__tv> aha !
May 11 21:37:31 <fred__tv> trying to force lo-res stream to 640x480....
May 11 21:41:45 <zmatt> it would have been nice if gstreamer actually treated that "width=640,height=480" spec in your pipeline as a constraint and not merely as a suggestion
May 11 21:41:49 <fred__tv> that works !
May 11 21:42:20 <zmatt> but feeding the correct size is probably a good idea anyway, it avoids the need for scaling
May 11 21:43:07 <fred__tv> I guess scaling involves more cpu load..
May 11 21:43:15 <zmatt> indeed
May 11 21:44:30 <fred__tv> anyway , even streaming the lo-res cpu load is almost 100% .....poor beagle....
May 11 21:44:54 <fred__tv> in fact:
May 11 21:45:03 <zmatt> I'm not hugely surprised
May 11 21:45:14 <fred__tv> WARNING: from element /GstPipeline:pipeline0/GstKMSSink:kmssink0: A lot of buffers are being dropped.
May 11 21:45:14 <fred__tv> Additional debug info:
May 11 21:45:14 <fred__tv> gstbasesink.c(2902): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstKMSSink:kmssink0:
May 11 21:45:14 <fred__tv> There may be a timestamping problem, or this computer is too slow.
May 11 21:45:59 <zmatt> are you using h264 ? since that's pretty cpu-intensive
May 11 21:46:19 <fred__tv> yes
May 11 21:47:05 <zmatt> perhaps something like mpeg2 might work better
May 11 21:47:37 <zmatt> I also wonder how well optimized gstreamer's implementations of these codecs are for the cortex-a8 + neon
May 11 21:47:55 <TonyTheLion> I'm trying to get my gpio pin registered as a gpio-key, but its not showing up in /dev/input/
May 11 21:48:09 <TonyTheLion> is there any other place I could look for it in the filesystem
May 11 21:48:15 <TonyTheLion> to see if its correctly configured
May 11 21:48:25 <zmatt> if it's not showing up in /dev/input it's evidently not configured correctly
May 11 21:48:33 <TonyTheLion> hmmm
May 11 21:48:38 <TonyTheLion> I can link the config here
May 11 21:48:48 <TonyTheLion> if someone cares to see if they can see what I'm not seeing
May 11 21:49:50 <zmatt> that sounds like a plausible strategy.  at least your chances of getting useful feedback will be a lot better if you do share that link than if you don't ;)
May 11 21:52:19 <TonyTheLion> https://www.paste.org/93213
May 11 21:52:40 <TonyTheLion> argh
May 11 21:52:42 <TonyTheLion> copied it wrong
May 11 21:54:26 <zmatt> ?
May 11 21:55:00 <fred__tv> I have to stay on h264 because is needed by proprietary camera visualization software
May 11 21:55:10 <zmatt> fred__tv: ok
May 11 21:55:20 <TonyTheLion> zmatt: https://pastebin.com/mu6ZziWw
May 11 21:55:42 <TonyTheLion> this is more correct, it had removed the pin number for whatever reason... and the comment
May 11 21:56:04 <zmatt> I was about to comment on that yes :P
May 11 21:56:37 <zmatt> lines 37-38 should be removed, it is inappropriate to override such properties on the &ocp node, even if you're overriding them with the value they already had
May 11 21:57:18 <TonyTheLion> I'm compiling it as so: `dtc -O dtb -o GPIO-Interrupt-00A0.dtbo -b 0 -@ GPIO-Interrupt.dts`
May 11 21:57:24 <TonyTheLion> zmatt: ah ok
May 11 21:57:27 <zmatt> there's no need to give your node a global label ("test_helper:") if you're not going to refer to it anyway
May 11 21:57:57 <fred__tv> hmmmm   switching from rtsp://user:password@ipaddress/Streaming/Channels/1 to rtsp://user:password@ipaddress/Streaming/Channels/2 have no changes (while those url played with vlc shows the different resolution)....
May 11 21:58:03 <fred__tv> hmmmm   switching from rtsp://user:password@ipaddress/Streaming/Channels/1 to rtsp://user:password@ipaddress/Streaming/Channels/2 have no changes (while those url played with vlc shows the different resolution)....
May 11 21:58:11 <TonyTheLion> so you're talking about lines with `#address-cells` and `size-cells`?
May 11 21:58:33 <zmatt> and the status = "okay"; is also unnecessary, its presence is only needed to override an earlier status = "disabled";  but that doesn't apply here
May 11 21:58:36 <zmatt> yes
May 11 21:58:37 <fred__tv> hmmmm   switching from rtsp://user:password@ipaddress/Streaming/Channels/1 to rtsp://user:password@ipaddress/Streaming/Channels/2 gives no changes (while those url played with vlc shows the different resolution)....
May 11 21:58:45 <TonyTheLion> ok
May 11 21:58:48 <zmatt> fred__tv: ...
May 11 21:58:59 <fred__tv> oops...
May 11 21:59:17 <zmatt> TonyTheLion: I'm not immediately seeing a problem, but I'm not hugely familiar with the dt binding for gpio-keys... lemme look that up
May 11 21:59:33 <TonyTheLion> hmmm
May 11 21:59:36 <TonyTheLion> it used to work
May 11 21:59:38 <fred__tv> gstreamer shows always hi-res (so huge cpu load) i'll investigate
May 11 21:59:46 <TonyTheLion> I merely tried to add a pin, and then it stopped working
May 11 22:00:18 <zmatt> TonyTheLion: what do you mean?
May 11 22:00:25 <zmatt> there's only one pin here
May 11 22:00:45 <TonyTheLion> I originally had one pin
May 11 22:00:55 <zmatt> and this still has only one pin
May 11 22:01:08 <zmatt> actually, no, it has zero pins
May 11 22:01:16 <TonyTheLion> yesterday I added a line under that pin for pin 0x28, it didn't work, so I removed it again
May 11 22:01:22 <TonyTheLion> thinking that was the problem
May 11 22:01:29 <TonyTheLion> but it obviously isn't the problem
May 11 22:01:37 <zmatt> there are no actual keys being declares inside your gpio-keys device
May 11 22:01:55 <TonyTheLion> hmmm
May 11 22:01:58 <zmatt> *declared
May 11 22:02:03 <TonyTheLion> how did this ever work?!
May 11 22:02:07 <TonyTheLion> lolol
May 11 22:02:33 <zmatt> you must somehow have managed to delete a whole bunch of lines
May 11 22:03:08 <zmatt> look at this for example: https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD7-01-00A3.dts#L200-L247
May 11 22:03:09 <TonyTheLion> I would say no, but it seems I somehow must have
May 11 22:04:12 <zmatt> although that looks bogus too
May 11 22:04:31 <TonyTheLion> what is this language actually called?
May 11 22:04:31 <zmatt> it makes no sense to have #address-cells in gpio-keys
May 11 22:04:35 <zmatt> device tree source
May 11 22:04:38 <TonyTheLion> ah
May 11 22:05:00 <zmatt> hmm, do I have a gpio-keys example in my overlay-utils? lemme check
May 11 22:05:33 <zmatt> I do!  https://github.com/mvduin/overlay-utils/blob/master/gpio-wakeup-key.dtsi
May 11 22:05:54 <zmatt> (my overlay utils lets you write overlays in a bit more readable way.  use the makefile in that project to build the dtbo)
May 11 22:06:05 <TonyTheLion> yesss thank you
May 11 22:06:12 <TonyTheLion> and I just realized I have your repo on my device
May 11 22:06:17 <zmatt> lol
May 11 22:06:21 <TonyTheLion> I was looking in the wrong repo
May 11 22:06:28 <TonyTheLion> omg, I'm a bit of a ditz
May 11 22:06:41 <TonyTheLion> can I just add another pin to that list?
May 11 22:06:47 <TonyTheLion> or do I need to create  new file?
May 11 22:08:08 <zmatt> to add another pin, you'd add another child node to the gpio-keys node (similar to wakeup { ... }; ) and a corresponding pinmux line to the &gpio_keys_pins node
May 11 22:09:21 <zmatt> you'll want to give each key a suitable key code of course, see linux/input-event-codes.h for the full list
May 11 22:10:34 <TonyTheLion> I want it to be wakeup as the first one
May 11 22:12:07 <zmatt> uhh, why have two different keys then in the first place?  you could just have tied both buttons to one gpio
May 11 22:13:43 <TonyTheLion> cause I'm testing two different interrupts
May 11 22:13:53 <zmatt> ?
May 11 22:14:13 <zmatt> anyway, you can use the same keycode of course
May 11 22:14:18 <TonyTheLion> cool
May 11 22:14:20 <TonyTheLion> :)
May 11 22:14:38 <zmatt> just not the same node name, but you can name the other one wakeup2 { ... };  or whatever
May 11 22:15:13 <TonyTheLion> right
May 11 22:15:19 <fred__tv> zmatt: a curiousity, what does "perl -pi -e 's/radeon/tilcdc/gaa' /usr/lib/arm-linux-gnueabihf/gstreamer-1.0/libgstkms.so" do
May 11 22:15:27 <fred__tv> ?
May 11 22:15:57 <zmatt> fred__tv: replace every occurrence of 'radeon' by 'tilcdc' in that shared library, which is probably only the one occurrence in the list of drivers it is searching for
May 11 22:16:18 <zmatt> (radeon was the first entry in that list that had the same length as 'tilcdc' hence could be replaced hassle-free)
May 11 22:16:38 <TonyTheLion> does that `&gpio0` stay the same or have to be different?
May 11 22:17:05 <zmatt> TonyTheLion: depends on what gpio bank the pin is located
May 11 22:17:49 <zmatt> <&gpio0 26> means gpio 0.26
May 11 22:27:13 <TonyTheLion> zmatt: works now, thanks :) :)
May 11 22:48:14 <zmatt> yay :D
May 11 23:02:01 <fred__tv> bedtime, thanks a lot !
May 11 23:26:32 <GenTooMan> zmatt: do you sleep?
May 11 23:26:49 <zmatt> it happens sometimes
May 11 23:27:12 <zmatt> I'm not proud of it
May 11 23:45:23 <GenTooMan> Well then you would not be proud of me, if I don't get sleep I become completely incoherent as opposed to somewhat incoherent.
May 11 23:53:57 <zmatt> hehe
**** ENDING LOGGING AT Sat May 12 03:00:03 2018