**** BEGIN LOGGING AT Sun Mar 26 03:00:04 2017
Mar 26 03:11:27 <pweh> PUSSY
Mar 26 03:11:50 <pweh> ha
Mar 26 05:58:15 <luneff> zmatt, cat fb0/virtual_size -> 1360,768. cat fb0/modes -> U:1360x768p-0. while weston tries to do mode 1360x768@60.4, preferred, current. I can't see dramatic difference
Mar 26 06:58:45 <zmatt> the error is very specifically about pitch vs width
Mar 26 07:00:28 <zmatt> I'd guess it is probably padding the line length to 1364 pixels or something like that
Mar 26 07:06:12 <luneff> zmatt, 1360 / 8 = 170.0. I thought about that. Actually, what I also see is 'alloc_contig_range: [9d300, 9d504) PFNs busy' right before invalid pitch message. Maybe, the memory is not allocated properly, it is zero and thus a pitch width error like 1360 != 0
Mar 26 07:06:29 <zmatt> PFNs busy is an unrelated warning
Mar 26 07:07:13 <zmatt> like I said, strace
Mar 26 07:10:06 <luneff> guys from #dri-devel taught me do enable drm module debugging to get any info beside failing ioctl that can be seen with strace. I get something like this: http://pastebin.com/gTWw6WFm
Mar 26 07:10:50 <zmatt> oh, strace doesn't have a decoder for the offending ioctl?  that's annoying
Mar 26 07:12:37 <luneff> I had only address in my log. decoder would definetely help, yes :-) DRM logs fails around line 747
Mar 26 07:13:43 <zmatt> all this log and still we don't know the size of the framebuffer
Mar 26 07:14:32 <zmatt> the one being made on line 721
Mar 26 07:15:33 <zmatt> run in gdb, set a breakpoint on drmModeAddFB2
Mar 26 07:15:34 <luneff> after everything it reverts to Processing mode 1360x768@60 with pixel clock 86000 and the picture is on with linux console
Mar 26 07:17:39 <zmatt> the kernel does that
Mar 26 07:21:52 <luneff> I guess I can make a weston with some debug output instead. plain old printfs
Mar 26 07:22:07 <zmatt> or, what I just said
Mar 26 07:22:10 <zmatt> 09:15 < zmatt> run in gdb, set a breakpoint on drmModeAddFB2
Mar 26 07:29:53 <zmatt> if you're on that breakpoint, you can show the width/height with   p { $r1, $r2 }
Mar 26 07:30:24 <zmatt> hmm, or just install debug symbols I guess, hehe
Mar 26 07:32:07 <zmatt> p *(unsigned*)$r5   is the pitch if I'm not mistaken
Mar 26 07:32:27 <zmatt> which should be 2 * width exactly
Mar 26 07:35:53 <zmatt> anyway, afk
Mar 26 07:39:22 <luneff> thanks, I'll try gdb
Mar 26 07:42:46 <luneff> drmModeAddFB2 (fd=11, width=width@entry=1360, height=height@entry=768,  pixel_format=pixel_format@entry=909199186, bo_handles=0xbefff3d0, bo_handles@entry=0xbefff3c8,  pitches=0xbefff3e0, pitches@entry=0xbefff3d8, offsets=0xbefff3f0, offsets@entry=0xbefff3e8, buf_id=0xa0a10,   flags=0)
Mar 26 07:44:23 <luneff> pixel_format looks suspiciously
Mar 26 08:08:58 <luneff> That's what I've gathered for drmModeAddFB2 calls. This is 'f' right before ioctl call http://pastebin.com/etYEzty4 . I can clearly see difference in pitches array yet it's still rocket science :-(
Mar 26 08:09:31 <luneff> http://pastebin.com/etYEzty4
Mar 26 10:01:42 <luneff> the first 'pitches' / 2 = 1376 that is not quite like 1360 that it should be. perhaps, I got 16 excessive pixels somehow
Mar 26 10:51:25 <thinkfat> zmatt: I think I should take a look at the CTI integration test registers too.
Mar 26 12:18:34 <thinkfat> zmatt: https://e2e.ti.com/support/arm/sitara_arm/f/791/t/584059
Mar 26 15:20:22 <Valduare> morning all
Mar 26 16:48:58 <luneff> hm. when it worked, I had mode 1024x768@60.0 as current and then --current-mode worked properly
Mar 26 17:08:19 <luneff> zmatt, I'm sorry for my dumbness, but how do I set 1024x768@60 as current mode before weston start? should I compile some version of drm modeset? I don't feel like passing kernel parameters at the moment :-( fbset doesn't set the mode properly
Mar 26 17:19:47 <beagle>  _                      _       | |                    | |      | |__   ___  __ _  __ _| | ___  | '_ \ / _ \/ _` |/ _` | |/ _ \ | |_) |  __/ (_| | (_| | |  __/ |_.__/ \___|\__,_|\__, |_|\___|                    __/ |                          |___/
Mar 26 17:20:06 <Valduare> so bbb has two micro controllers onboard?
Mar 26 17:28:04 <jtrip> Valduare, yeah there are 2 "PRUs" builting to the bbb chip.
Mar 26 17:28:25 <jtrip> bbb.io/pru
Mar 26 17:29:32 <Valduare> i came here after seeing replicape
Mar 26 17:29:34 <Valduare> for 3d printing
Mar 26 17:29:45 <Valduare> bbb and replicape seem like a real nice setup
Mar 26 17:43:26 <luneff> oh yes, optargs='video=HDMI-A-1:1024x768@60' in boot partition uEnv.txt helped with my weston startup. OK!
Mar 26 21:22:39 <Vinnie_VdB> Hi all.
Mar 26 21:23:33 <Vinnie_VdB> Is  Beagle Board suitable for making a controller working with digital and analog I/O's
Mar 26 21:23:45 <Vinnie_VdB> and control temperature and such?
**** ENDING LOGGING AT Mon Mar 27 03:00:02 2017