isaque has quit [Quit: isaque]
ansiwon has quit [Ping timeout: 240 seconds]
isaque has joined #linux-exynos
isaque has quit [Quit: isaque]
prahal_ has joined #linux-exynos
[7] has quit [Disconnected by services]
TheSeven has joined #linux-exynos
_whitelogger has joined #linux-exynos
amitk has joined #linux-exynos
ansiwon has joined #linux-exynos
indy has quit [Ping timeout: 276 seconds]
ansiwon has quit [Ping timeout: 240 seconds]
indy has joined #linux-exynos
paulk-collins has joined #linux-exynos
ansiwon has joined #linux-exynos
Gottox has quit [Ping timeout: 272 seconds]
ansiwon has quit [Ping timeout: 265 seconds]
prahal has joined #linux-exynos
prahal_ has quit [Ping timeout: 265 seconds]
paulk-collins has quit [Quit: Leaving]
ansiwon has joined #linux-exynos
Gottox has joined #linux-exynos
RzR has quit [Changing host]
RzR has joined #linux-exynos
dlezcano has joined #linux-exynos
dlan has quit [Ping timeout: 250 seconds]
dlan has joined #linux-exynos
isaque has joined #linux-exynos
Vasco_O is now known as Vasco
<ndufresne> javier__: malidiction goes on me, the other day I could not get logs, not I've hit some build system bug where the zImage is never rebuilt from the new kernel
<javier__> ndufresne: really? what was the build system bug?
<ndufresne> that I don't know, I'm cleaning and rebuilding now
<javier__> sigh
<ndufresne> hmm, still there, I'm update my branch to 4.8-rc8, but the zImage have stirng 4.8.0-rc6
<ndufresne> it picks old files from somewhere, but can't figure-out, and make clean is not getting rid of it ...
<ndufresne> I've lost so much time with that
<javier__> that's really strange
<ndufresne> ok, this time if I have an old version, I'm clueless, I've clean the git repo "git clean -xdff"
<ndufresne> arg, wtf, got ccache on this system ...
<javier__> I see, I haven't had any issues with ccache though
<ndufresne> it's first time, I didn't know it was doign anything with links
<ndufresne> I'm rebuilding without now
<javier__> cool
amitk has quit [Ping timeout: 240 seconds]
dlezcano has quit [Ping timeout: 265 seconds]
<ndufresne> success
afaerber has quit [Quit: Ex-Chat]
dlezcano has joined #linux-exynos
paulk-collins has joined #linux-exynos
dlezcano has quit [Ping timeout: 260 seconds]
dlezcano has joined #linux-exynos
afaerber has joined #linux-exynos
afaerber has quit [Ping timeout: 255 seconds]
afaerber has joined #linux-exynos
dlezcano has quit [Ping timeout: 244 seconds]
dlezcano has joined #linux-exynos
libv_ has joined #linux-exynos
dlezcano has quit [Ping timeout: 260 seconds]
indy has quit [Ping timeout: 260 seconds]
leming has quit [Ping timeout: 260 seconds]
afaerber has quit [Ping timeout: 255 seconds]
TheSeven has quit [Ping timeout: 255 seconds]
ansiwon has quit [Ping timeout: 265 seconds]
prahal_ has joined #linux-exynos
prahal has quit [Ping timeout: 264 seconds]
RzR has quit [Ping timeout: 265 seconds]
afaerber has joined #linux-exynos
TheSeven has joined #linux-exynos
libv has quit [Ping timeout: 244 seconds]
paulk-collins has quit [Ping timeout: 265 seconds]
isaque has quit [Ping timeout: 265 seconds]
ansiwon has joined #linux-exynos
steev_ has quit [Ping timeout: 255 seconds]
_whitelogger has quit [Ping timeout: 272 seconds]
TheSeven has quit [Ping timeout: 255 seconds]
_whitelogger_ has joined #linux-exynos
prahal__ has joined #linux-exynos
prahal_ has quit [Read error: Connection reset by peer]
_whitelogger has quit [Ping timeout: 272 seconds]
[7] has joined #linux-exynos
dlan has quit [Ping timeout: 252 seconds]
libv has joined #linux-exynos
leming has joined #linux-exynos
paulk-collins has joined #linux-exynos
prahal__ has quit [Ping timeout: 252 seconds]
prahal__ has joined #linux-exynos
masta has quit [Ping timeout: 244 seconds]
indy has joined #linux-exynos
masta has joined #linux-exynos
dlan has joined #linux-exynos
RzR has joined #linux-exynos
libv has quit [Ping timeout: 244 seconds]
_whitelogger_ has quit [Read error: Connection reset by peer]
_whitelogger has joined #linux-exynos
theblazehen has quit [Read error: Connection reset by peer]
libv has joined #linux-exynos
_whitelogger has quit [Excess Flood]
_whitelogger has joined #linux-exynos
dlezcano has joined #linux-exynos
Tox is now known as Gottox
theblazehen__ has quit [Remote host closed the connection]
ansiwon_ has joined #linux-exynos
indy has quit [Ping timeout: 272 seconds]
paulk-collins has quit [Ping timeout: 272 seconds]
_whitelogger has joined #linux-exynos
TheSeven has joined #linux-exynos
indy has joined #linux-exynos
<javier__> although the exynos-gsc driver sets sizeimage to bytesperline * height so it seems to be doing the right thing
<ndufresne> javier__: size image will be different formula depending on the plane
<ndufresne> e.g. NV12, the UV plane is have the height (same stride)
<ndufresne> thinking of it, for XRGB shall be correct
<ndufresne> hmm -> plane_fmt=[{sizeimage=0,
<javier__> ndufresne: but YV12 is also single planar
<ndufresne> YV12 is also called I420, it's multi planar (3 planes)
<ndufresne> maybe you mean YUY2 (also called YUYV), which is planar
<ndufresne> s/planar/single plane
<ndufresne> javier__: your notes at the end are not correct, size image shall be at least 1280*240=307200
<ndufresne> javier__: did you check what returns EINVAL ?
<javier__> ndufresne: you mean for the "gst_video_frame_map_id: failed to map video frame plane 1" ? I don't see an ioctl before that error
<ndufresne> ah, it fails on that, thought it refused to queue or dequeue, sorry
<javier__> the -EINVAL I used to have on STREAMON is due the format being reset on REQBUFS(0) as mentioned but I've a local fix for that
<ndufresne> javier__: can you break in that function
<javier__> ndufresne: I'm facing this gdb/glibc bug on my armhf Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1196181 :(
<ndufresne> weird, I'm also running fedora here ... maybe it's big.little specific ?
<javier__> ndufresne: dunno, what version? I'm running Fedora 22 here (so pretty old)
<javier__> ndufresne: but AFAICT the function that returns an error is https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst-libs/gst/video/video-frame.c#n103
<ndufresne> ah, I'm running 24 here
<javier__> yeah, I should update to a newer Fedora. Anyways, do you have any idea of what the error could be?
<ndufresne> bad offset, or bad size
<javier__> ndufresne: yeah, but do you think is really a gst issue or more the driver not setting the correct values on {S,G}_FMT ?
<ndufresne> javier__: can you give me the exact error, with GST_DEBUG=2
<ndufresne> wait, thos eare in GST_DEBUG leve
<ndufresne> javier__: trace with GST_DEBUG=videometa:7
<javier__> ndufresne: Ok, one sec
<javier__> ndufresne: weird, I don't get any aditional debug log when using videometa:7, I also tried *videometa*:7, *gstvideometa*:7, etc
<ndufresne> weird, I usually step debug this in general
<javier__> this is with GST_DEBUG=*:7 shows me lines with videometa though
<ndufresne> javier__: so the driver reports 268800 for a 320x240 YV12 ?
daniels has joined #linux-exynos
<ndufresne> I'm confused since there is also a trace saying 115200, which is clearly too small, the extrapolated offset for plane 2 is 144
<ndufresne> 14400
<ndufresne> arg, 1 more 0
<ndufresne> javier__: where is this stride 480 from ?
<ndufresne> I'm in serious doubt this is correct
paulk-collins has joined #linux-exynos
<ndufresne> javier__: I think planar formats are broken in that driver
<javier__> ndufresne: http://hastebin.com/lajowosudi.tex is GST_DEBUG=*:7 and I did a grep -i videometa
_whitelogger has quit [Ping timeout: 272 seconds]
_whitelogger has joined #linux-exynos
<ndufresne> we need to figure-out
<javier__> ndufresne: I'm also confused why it gets 480 stride instead of 320
<ndufresne> somehow, something does not agree
<javier__> ndufresne: also, why gst says "Desired format is 320x240, format YV12, nb planes 1" ?
<javier__> if the format is multi planar (3 planes) as you said
<ndufresne> javier__: because it received a single allocation, it's confusing, but in nb_planes in term of v4l2 planes
indy has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-exynos
paulk-collins has quit [Excess Flood]
paulk-collins has joined #linux-exynos
<ndufresne> javier__: see map for V4L2_PIX_FMT_YUV420, num_planes = 1, num_comp = 3
<javier__> ndufresne: ah, that's why it talks about offsets later then?
<ndufresne> javier__: yes, we need to guess the offset in this mode
<ndufresne> cause it's missing in the v4l2 API
<ndufresne> and get solve with V4L2_PIX_FMT_YUV420M
<ndufresne> I'm surprise gst does not favour V4L2_PIX_FMT_YUV420M over the other, or maybe this is in the stuff I merged for 1.10 ...
<ndufresne> javier__: int bpl = (pix_mp->width * fmt->depth[i]) >> 3;
<ndufresne> this is wrong for YUY420
indy has joined #linux-exynos
<ndufresne> well, I mean, this can be wrong
<ndufresne> I don't see any code that set the width as being half the Y plane width
<javier__> ndufresne: just to see IIUC something, both V4L2_PIX_FMT_YUV420 and V4L2_PIX_FMT_YUV420M could be used when setting a format=YV12 cap?
<ndufresne> javier__: ah, no, it's just wrong, since it does not keep a per plane width/height, with is different
<ndufresne> javier__: yes, in git master, we try the YUY420M first, and fallback to the otherone
<ndufresne> ah, maybe that line is right, so confusing, cause num_plane is 1, so it only computes the Y plane stride
<ndufresne> javier__: ok, that line, bpl = 320 * 12 / 8 = 480
<ndufresne> but the stride is 320
<javier__> ndufresne: Ok, now we know where the 480 came from
<ndufresne> javier__: so no, this magic forumula does not work, I remember the fimc was trying to do something with magic formula too
<ndufresne> and it didn't work
<javier__> ndufresne: btw, are you talking about commit ab075b2013b7 ("v4l2provider: Fix device type detection") ?
<javier__> instead of trying to be clever and compute?
<javier__> ndufresne: so we should set the stride for each format in struct gsc_fmt ?
<ndufresne> javier__: possibly, I absolutly don't rememeber
<ndufresne> javier__: maybe we could hack around with a stride depth, and size depth ?
<ndufresne> remains that there is also bunch of rounding rules that you need to obay
<ndufresne> I'm still surprise that there is no generic function to get that in videobuf2
* javier__ still didn't get how everything things have to be rounded
<ndufresne> javier__: just copy the code from fimc
<javier__> I remember you mentioned that s5p-mfc is also broken w.r.t rounding rules
<javier__> ndufresne: Ok, I'll take a look to the fimc code
<ndufresne> javier__: dues to sub-sampling, you must roundup 2 the width/height iirc
<javier__> ndufresne: Ok, I'll first look at this wrong stride calculation
<javier__> thanks a lot for your help!
<ndufresne> javier__: quite ugly, but see fimc_adjust_mplane_format()
<ndufresne> and there is still bugs int hat function, I have a patch I should send
<javier__> ndufresne: Ok, thanks for the pointer
Vasco has quit [Ping timeout: 276 seconds]
LiquidAcid has joined #linux-exynos
<LiquidAcid> ndufresne, hey, about that 0x40 offset -- i think it only applies when both top and bottom fields are used
<ndufresne> possible
<ndufresne> LiquidAcid: doc does say say much here, "If TILE mode is enable, VP_BOT_Y_PTR = VP_TOP_Y_PTR + 0x40", so I can imagine that same rules apply, if you don't have interlaced content, it can stay 0
<ndufresne> the drm driver does not support interlacing anyway I beleive
<ndufresne> (saw that 0x40 first in s5p-tv)
<LiquidAcid> yes, but there it's always applied, so not only if interlacing is on
<LiquidAcid> anyway, i find it suspicious that the page fault address changes when you enable debugging
isaque has joined #linux-exynos
<ndufresne> that's why I suspect a use after free
<LiquidAcid> can you try to printk() the dma addr when the buffer gets exported from v4l2?
<ndufresne> yes, but that will have to wait till tomorrow I'm sorry
<ndufresne> So you'd like to compare the dma adresses in both drivers ?
<LiquidAcid> why use after free? shouldn't it then fail at the old dma addr?
<LiquidAcid> like i said in the mail, grasping at straws :D
<ndufresne> there is no single physical address here
<ndufresne> (or unmap being called to soon, e.g. page table being cleared)
indy has quit [Ping timeout: 264 seconds]
indy_ has joined #linux-exynos
_whitelogger has joined #linux-exynos
paulk-collins_ has joined #linux-exynos
paulk-collins has quit [Ping timeout: 264 seconds]
afaerber has joined #linux-exynos
TheSeven has quit [Ping timeout: 272 seconds]
_whitelogger has quit [Ping timeout: 272 seconds]
ssvb has quit [Ping timeout: 272 seconds]
Wizzup has quit [Ping timeout: 250 seconds]
_whitelogger_ has joined #linux-exynos
leming has quit [Ping timeout: 264 seconds]
zombah_ has joined #linux-exynos
bzyx has joined #linux-exynos
TheSeven has joined #linux-exynos
ssvb has joined #linux-exynos
_whitelogger_ has quit [Excess Flood]
_whitelogger has joined #linux-exynos
TheSeven has quit [Ping timeout: 272 seconds]
zombah_ has quit [Ping timeout: 264 seconds]
ssvb has quit [Ping timeout: 264 seconds]
[7] has joined #linux-exynos
indy has joined #linux-exynos
Wizzup has joined #linux-exynos
leming has joined #linux-exynos
<javier__> ndufresne: calculating the bytesperline and sizeimage like in fimc_adjust_mplane_format() fixes the issue
<ndufresne> yeah !
<javier__> ndufresne: I removed the user-space provided stride part since as you said, there isn't validation anyways (just that is not 0)
<javier__> and I also need to add generic logic to calculate the bytesperline for multi-planar formats, since IIUC fimc_adjust_mplane_format() just hardcodes for V4L2_PIX_FMT_YUV420M a bytesperline /= 2 for the planes > 0
dlezcano has quit [Ping timeout: 276 seconds]
<javier__> ndufresne: do you know if is correct for a driver to override the stride if provided by user-space or should honor it?
<javier__> ndufresne: and last question, you said to test all the formats combinations but some formats can't be tested since videotestsrc doesn't support it AFAICT (i.e: NM12)
<ndufresne> it really depends, if you are doing USRPTR or DMABuf importation, you should try and honor, cause otherwise import will fail
_whitelogger has joined #linux-exynos
TheSeven has joined #linux-exynos
_whitelogger has quit [Excess Flood]
pekka20 has quit [Ping timeout: 276 seconds]
leming has quit [Ping timeout: 264 seconds]
_whitelogger has joined #linux-exynos
leming has joined #linux-exynos
krzk has joined #linux-exynos
leming has quit [Ping timeout: 264 seconds]
_whitelogger has joined #linux-exynos
afaerber has joined #linux-exynos
zombah has joined #linux-exynos
Vasco has joined #linux-exynos
decay has joined #linux-exynos
leming has joined #linux-exynos
Vasco is now known as Vasco_O
paulk-collins_ has quit [Quit: Leaving]
prahal__ has quit [Ping timeout: 276 seconds]
dlezcano has joined #linux-exynos
dlezcano has quit [Remote host closed the connection]
dlezcano has joined #linux-exynos
alexst has joined #linux-exynos
indy has quit [Ping timeout: 244 seconds]
indy has joined #linux-exynos
isaque has joined #linux-exynos