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: 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?
<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]