bobbytables has quit [Quit: leaving]
dlezcano has quit [Ping timeout: 252 seconds]
TheSeven has quit [Ping timeout: 255 seconds]
[7] has joined #linux-exynos
dlezcano has joined #linux-exynos
mturquette_ has joined #linux-exynos
steev__ has joined #linux-exynos
rZZZr has joined #linux-exynos
steev_ has quit [*.net *.split]
mturquette has quit [*.net *.split]
RzR has quit [*.net *.split]
indy has quit [*.net *.split]
nashpa has quit [*.net *.split]
leming has quit [*.net *.split]
leming has joined #linux-exynos
nashpa has joined #linux-exynos
mturquette_ is now known as mturquette
indy_ has joined #linux-exynos
ayaka has quit [Ping timeout: 252 seconds]
steev__ is now known as steev_
indy_ has quit [Ping timeout: 255 seconds]
ansiwon has quit [Quit: Lost terminal]
ansiwon has joined #linux-exynos
paulk-veyron-min has joined #linux-exynos
indy has joined #linux-exynos
paulk-veyron-min has quit [Read error: Connection reset by peer]
paulk-veyron-min has joined #linux-exynos
paulk-veyron-min has quit [Ping timeout: 264 seconds]
paulk-veyron-min has joined #linux-exynos
libv_ has joined #linux-exynos
libv has quit [Ping timeout: 240 seconds]
paulk-veyron-min has quit [Read error: Connection reset by peer]
nashpa has quit [Ping timeout: 260 seconds]
nashpa has joined #linux-exynos
rZZZr is now known as RzR
Ultrasauce_ has quit [Remote host closed the connection]
Ultrasauce has joined #linux-exynos
Ultrasauce has quit [Read error: Connection reset by peer]
isaque has joined #linux-exynos
Ultrasauce has joined #linux-exynos
paulk-collins has joined #linux-exynos
masta has joined #linux-exynos
libv_ is now known as libv
prahal has joined #linux-exynos
_whitelogger has joined #linux-exynos
dlezcano has quit [Ping timeout: 276 seconds]
<javier__> ndufresne: ping
<ndufresne> pong
<javier__> ndufresne: I don't know if you notice the question I asked on friday about the pixel format you are using to do zero-copy between the fimc and exynos-drm
<javier__> ndufresne: I tried to do the same with the exynos5 gsc using this pipeline: $ gst-launch-1.0 videotestsrc ! v4l2video1convert capture-io-mode=dmabuf-import ! kmssink
<javier__> but gst isn't able to negotiate the caps because the exynos-gsc output format is xRGB but kmssink says that it only supports RGBx
<ndufresne> javier__: it's most likely a coding limitation, the gsc according to the spec supports both
<ndufresne> I'm surprise that both aren't supported on the kms/drm side too
indy has quit [Ping timeout: 260 seconds]
<javier__> ndufresne: that's what I thought but I don't know which component is missing the support
_whitelogger_ has joined #linux-exynos
_whitelogger has quit [Remote host closed the connection]
<javier__> ndufresne: gst-validate-1.0 says this http://hastebin.com/dinaluwuku.pas
<ndufresne> javier__: no idea what happens, but you could share a trace, GST_DEBUG="v4l2*:7" ... 2> gst.log, we could see better
<ndufresne> clearly upstream does not believe that BGRx is supported
<ndufresne> javier__: and there is no BGRx support in gsc-core.c
indy has joined #linux-exynos
<ndufresne> javier__: so just map the missing format, and it should work ;-P
<javier__> ndufresne: I see, so is just a missing format then?
<javier__> ndufresne: I was wondering why it reported the BE format http://hastebin.com/cumevovapu.pas
<javier__> ndufresne: thanks a lot for your help, I'll add the BGRx to gst-core then
<ndufresne> javier__: I got a hard time witht he spec of that HW (it's not very good), but I believe you have too play with IN_RB_SWAP
<ndufresne> otherwise it's IN_YCBCR422_1P_ORDER that accidently change the RGB component order (that would be weird)
<javier__> ndufresne: Ok, what's the v4l2 pixel format for RGBx btw? V4L2_PIX_FMT_RGB565?
<ndufresne> this driver uses the legacy, V4L2_PIX_FMT_RGB32
<ndufresne> which is an ambiguity bettween ARGB and xRGB
<ndufresne> should be ported to V4L2_PIX_FMT_XRGB32
<javier__> ndufresne: I can't find that format in https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html
<javier__> ndufresne: is due that ambiguity that gst reports V4L2_PIX_FMT_RGB32 as just RGB16 and not RGBx ?
<javier__> Ok, I see V4L2_PIX_FMT_XRGB32 in the code even if I didn't find in the v4l2 doc. I'll test with that
<javier__> nvm, is in the doc as well
<javier__> I got confused between V4L2_PIX_FMT_RGB565 and V4L2_PIX_FMT_RGB32 in our conversation
<javier__> -ETOOMANYFORMATS
<ndufresne> yeah, I notice, RGB565 is 16bit format ;-P
<ndufresne> javier__: it'S listed here btw, https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html
<javier__> ndufresne: yeah, sorry I got confused and looked for V4L2_PIX_FMT_XRGB565
<ndufresne> javier__: to add to the confusion, we got ABGR, that is in fact BGRA (the alpha comes last)
<javier__> ndufresne: anyway, thanks for the explanation that's a missing format in exynos-gsc, I'll take a look to it
* ndufresne didn't know that gsc API was such a mess though, my apology for you having to hack with that
<ndufresne> by API I mean hw interface
<javier__> yeah, let's see how it goes. My hope is that the needed change could be minimal :)
<ndufresne> I do have the impression that it's just a matter of dding the format, and triggering the SWAP registry there
<ndufresne> javier__: it's likely in the end all the colors will be messed up, I notice that Samsung isn't concistent with their representation, sometime they use register order, and other time they use byte array order
<javier__> ndufresne: I see, thanks for the hint
<ndufresne> javier__: an example, gstreamer is byte array order, and drm is register order, that why you got this endianness ifdef
<javier__> I see
<ndufresne> in little endiant, BGRX on Gst side, matches XRGB on DRM side (can't be more fun)
<javier__> Ok, but then how do you make gst know about that match?
<javier__> if these are different formats
<javier__> ndufresne: ah, scratch that. I just read that you wrote BGR and RGB and not RGB and RGB
* javier__ needs more coffee to notice the diff between all the formats names :P
<ndufresne> javier__: if you add a new format to the driver format array, gstreamer will notice ;-P
<javier__> ndufresne: yes I know, I meant if two different formats matches but then I read you wrote different formats and not only different endianess
<ndufresne> heh
<ndufresne> javier__: note that for the ambiguity I mention, RGB32 is assumed xRGB32 by default, unless there is an ALPHA CID on the node
<ndufresne> if there is an ALPHA CID, we set if to 0xff and propose both formats
<javier__> ndufresne: I see
<ndufresne> one can obviously override the alpha using extra-controls property
<ndufresne> we never expect the input alpha to be kept though
<javier__> ndufresne: Ok, I think I have all the info I needed now. I'll let you know how it goes
<javier__> thanks a lot!
<ndufresne> I think so !
<ndufresne> javier__: question for myself, gsc in v4l2 and gsc in drm-exynos conflicts for now right ? (they have not been consolidated)
<javier__> ndufresne: yes, they conflict for now. I posted a patch a long time ago to prevent enabling DRM_EXYNOS_GSC if VIDEO_SAMSUNG_EXYNOS_GSC is already enabled
<javier__> but that wasn't picked... I'll ping Inki again
<ndufresne> long term plan should be to create an API style driver, and make both drm and v4l2 cooperate
<ndufresne> it's needed if you want to expose everything from this IP
<ndufresne> the gsc is can connect directly to a camera interface for input, and directly to the display controller for scannout, or do memory to display, camera to memory and finally memory to memory
<javier__> ndufresne: yes, since that's the case for others IP too (i.e: G2D)
* ndufresne though g2d was only m2m
<javier__> ndufresne: no, I wrote that as an answer to your previous comment about having an API style driver and make both drm and v4l2 drivers cooperate
<ndufresne> but I believe someone's working on an DRM interface for G2D like HW, cause using V4L2 in compositors seems like a pain, and you don't want to have to prime the GBM and stuff all the time
<ndufresne> nod
dlezcano has joined #linux-exynos
<javier__> ndufresne: about the gsc having two instances and the drm and v4l2 drivers being used at the same time, that's something that's supported in the tizen tree but not yet in mainline
<ndufresne> good to know, thanks
* javier__ => lunch, bbl
dlezcano has quit [Ping timeout: 240 seconds]
dlezcano has joined #linux-exynos
LiquidAcid has joined #linux-exynos
<LiquidAcid> ndufresne, hey there, i just looked through the log
<LiquidAcid> but there is still no addfb2 call to be found
<ndufresne> yeah, it's stupid, I'm missing half a second there
<ndufresne> need to get rid of systemd ...
dlezcano has quit [Ping timeout: 265 seconds]
* ndufresne lack some knowledge how to get the full dmesg to console
<LiquidAcid> ndufresne, how do you get the log?
<LiquidAcid> it should be continuously printed to the uart
<ndufresne> it's not because system take control over that to create a shell
<ndufresne> * systemds
<ndufresne> markin non-error logs
<LiquidAcid> ndufresne, you should change this then, otherwise it's not possible to get anything meaningful out of it
<ndufresne> sure, I'd love to, just need someone to help me figure-out how, you know, I didn't write systemd-journald and don't usually have to deal with this
<LiquidAcid> i guess systemd changes the console log level, or disables it completly -- so you should just switch it on again
<LiquidAcid> have you looked into the dmesg manpage?
<LiquidAcid> dmesg --console-level <- this e.g.
<ndufresne> ah, finally, dmesg -E && dmesg -l debug
<ndufresne> sound rather trivial, but when you are not looking at the right place it's frustrating
<ndufresne> lunch time, I'll be back to generate a proper log later
<LiquidAcid> bon appetit
Vasco_O is now known as Vasco
mixfix55 has quit [Ping timeout: 276 seconds]
isaque has quit [Quit: isaque]
isaque has joined #linux-exynos
<ndufresne> LiquidAcid: I've sent you a (I hope) proper trace this time, there is a "random" crash trace, as it just crash in the case it used to work
<ndufresne> probably that traces changes the timeing
<ndufresne> that's interesting "[ 136.011318] [drm:drm_fb_get_bpp_depth] unsupported pixel format NV12 little-endian (0x3231564e)"
<ndufresne> it's at least suspicious
<LiquidAcid> ndufresne, yes, i think i see the problem
<ndufresne> \o/
<LiquidAcid> nv12mt is bi-planar, isn't it?
<ndufresne> yes
<ndufresne> while NV12 is biplanaer with a single allocation
<LiquidAcid> oh wait
<ndufresne> here I notice we always pass N FDs for NV12, so we pass twice the same FD in the single allocation case
<ndufresne> I need to check what happens exactly is my case
<ndufresne> LiquidAcid: this case is a dmabuf with 2 planes and 2 memories
<ndufresne> fd 28 and 30, that get primed as 32
<LiquidAcid> sry, i had a brain-fart
dlezcano has joined #linux-exynos
<LiquidAcid> anyway, what's with FB:37?
<ndufresne> that's from the random crash log
<ndufresne> The suspicious trace is caused by call to drm_helper_mode_fill_fb_struct
<LiquidAcid> yes, but it's harmless
<LiquidAcid> depth and bpp is not used anywhere
<ndufresne> which copies pitches/offset and modifiers array, but also sets bits_per_pixel
<LiquidAcid> anyone, that other log is nicer 'PAGE FAULT occurred at 0x0'
<ndufresne> which seems to be used in drivers/gpu/drm/exynos/exynos_mixer.c
<LiquidAcid> ndufresne, where is bpp/depth used?
<ndufresne> LiquidAcid: I'm looking it up, got this lilst to check, https://paste.fedoraproject.org/436127/74914849/
<ndufresne> exynos_mixer.c is the component in used, since this is using the video interface on the display
<LiquidAcid> ndufresne, that's not the VP path
<LiquidAcid> ndufresne, you have to look at vp_video_buffer()
<ndufresne> what do you mean ?
<LiquidAcid> bpp and depth isn't used in vp_video_buffer()
<ndufresne> mixer_graph_buffer(), so the use of bits_per_pixel there is correct
<LiquidAcid> mixer_graph_buffer() is irrelevant here
<ndufresne> I know, that's what I'm saying
<LiquidAcid> :)
<ndufresne> other wrong use of bpp would lead to div by zero on cpu, I'm more confident this trace is harmless
<LiquidAcid> ndufresne, you could try putting a mdelay() after vp_regs_dump(ctx)
<LiquidAcid> so that register dumping can finish before the pagefault happens
<ndufresne> how long do we need ... ?
<LiquidAcid> mdelay(10) maybe?
<ndufresne> let's try
<LiquidAcid> currently not even mixer_regs_dump() finishes
<ndufresne> LiquidAcid: with the mdelay, https://paste.fedoraproject.org/436133/49157771/
<ndufresne> it's stops in the middle of another dump it seems
<LiquidAcid> he, that shows even less than before
<ndufresne> true, no wp_regs
<LiquidAcid> can you increase it to 100?
<LiquidAcid> it's interesting though that the pagefault happens at 0x0
<ndufresne> it wasn't the case before I turned on the traces
<ndufresne> is the location of the delay right ?
<ndufresne> cause vp_regs_dump() is called after mixer_regs_dumps() which is patrially traced before crash
<LiquidAcid> yes, that should work
<LiquidAcid> just an idea, maybe also comment out mixer_regs_dump() from vp_video_buffer(), i mean it's dumped by the update of win:0 anyway
<ndufresne> increasing didn't help, I'm comming it out now
<LiquidAcid> hmm, strange that it doesn't change anything
<ndufresne> well, it's not reached
<LiquidAcid> you sure?
<ndufresne> according to the trace
<ndufresne> could it crash as soon (or close by) "spin_unlock_irqrestore(&res->reg_slock, flags);"
<LiquidAcid> i think this is deceiving
<LiquidAcid> when the pagefault happens, vp_video_buffer() is already left
<LiquidAcid> if we were still in the function, the registers are not updated
<LiquidAcid> (happens only on vblank)
<javier__> ndufresne: at the end, the patch was pretty trivial, just a missing format as you said http://hastebin.com/osafecirey.diff
<ndufresne> LiquidAcid: ah, I think vp_video_buffer() fot inlined
<ndufresne> javier__: it's slightly suspicious that you didn't had to flip R and B, I'm gussing XRGB is broken ;-P
<ndufresne> javier__: a better guess is that you should remove XRGB as it's not supported by the HW (at least it was the case on FIMC)
<javier__> ndufresne: could be, since I got the colors correctly :)
<ndufresne> it's the same definition, so one of the two must not work ;-P
<javier__> ndufresne: indeed, but I don't feel confortable removing the other entry without testing that is actually broken
<ndufresne> javier__: it's easy, run v4l2videoNconvert ! video/x-raw,format=XRGB ! videoconvert ! kmssink
<ndufresne> you can run over all format with a simple C script
<ndufresne> I debugged fimc this way
<javier__> ndufresne: interesting, thanks for the hint
<ndufresne> for FIMC I tested every possible combinations
<ndufresne> (the original author should have done that tbf)
<ndufresne> create to list of formats, and two loops, and keep using SW convert for the final display (videotestsrc to produce the input stream
<javier__> ndufresne: Ok, gst-validate-1.0 videotestsrc ! v4l2video3convert ! video/x-raw,format=xRGB ! videoconvert ! kmssink displays correctly
<ndufresne> javier__: you got fooled ;-P
<ndufresne> the converter will be passthrough here
<ndufresne> try:
<ndufresne> gst-validate-1.0 videotestsrc ! video/x-raw,format=NV12 ! v4l2video3convert ! video/x-raw,format=xRGB ! videoconvert ! kmssink
<javier__> ndufresne: I see, videotestsrc was generating xRGB already
<ndufresne> this way you force a convertion in HW
<javier__> nod
<ndufresne> a proper test would iterate on all input/output formtas supported
<ndufresne> oh, and add a num-buffers=N so the test can stop
LiquidAcid has quit [Quit: Leaving]
<javier__> ndufresne: hmm, I wonder if it worked for me then just because the converter is passthrough when the v4l2 driver reports XBGR
<ndufresne> what's the test results now ?
<ndufresne> what was your original test ?
<ndufresne> which reminds me, we should close the FD in passthrough ...
<javier__> ndufresne: my original test was $ gst-validate-1.0 videotestsrc ! v4l2video3convert ! kmssink
<ndufresne> (if it's not already the case)
<javier__> but gst-validate-1.0 videotestsrc ! video/x-raw,format=NM12 ! v4l2video3convert ! kmssink fails
<ndufresne> javier__: ah, right, it's a no-op
<ndufresne> javier__: change NM12 into NV12
<ndufresne> NM12 is a V4L2 invention, it's not really a format
<javier__> ndufresne: when changing to NV12, STREAMON fails with -EINVAL
<javier__> ndufresne: anyway, I'll look at that. Thanks for pointing out that's a no-op when the src and sink pads use the same format
<ndufresne> ok, we need to dig why we get this einval
<ndufresne> it's not happy of some argument from gst
<javier__> ndufresne: yes, I'll dig on that
<ndufresne> javier__: btw, what kernel are you using ? I still got an XU3 here that I could bootstrap
<javier__> ndufresne: v4.8-rc8 now
<ndufresne> do you have an important patchset on top ?
<javier__> ndufresne: nothing, it should work with mainline
<ndufresne> arg, can't get a decent trace, it crash when dumping the mixer_regs ...
amitk has joined #linux-exynos
dlezcano has quit [Ping timeout: 264 seconds]
amitk has quit [Ping timeout: 260 seconds]
<javier__> ndufresne: the problem is that the format previously set is cleared on REQBUFS(0) so STREAMON fails because no format was set
<javier__> but gst first calls S_FMT and then attempts to test the I/O method by calling REQBUFS. I remember we had the same issue with other driver (s5p-mfc)
<javier__> if the fmt is not cleared, playback starts but I get errors when attempting to map video planes. I'll look at that tomorrow
<ndufresne> hmm, why would one touch the configure format because we free the buffers
<ndufresne> what a non-sense
<ndufresne> javier__: ok, great, there is probably some size not set properly in the structure
<javier__> ndufresne: yes, it's non-sense indeed. I don't know why the drivers did that
prahal_ has joined #linux-exynos
prahal has quit [Ping timeout: 265 seconds]
prahal_ has quit [Ping timeout: 265 seconds]
Vasco is now known as Vasco_O
dlezcano has joined #linux-exynos
dlezcano has quit [Ping timeout: 244 seconds]
paulk-collins has quit [Quit: Leaving]
dlezcano has joined #linux-exynos
dlezcano has quit [Remote host closed the connection]
theblazehen has joined #linux-exynos
amitk has joined #linux-exynos
amitk has quit [Ping timeout: 244 seconds]