daniels has quit [Read error: Connection reset by peer]
daniels has joined #linux-exynos
ansiwon has quit [Quit: leaving]
ansiwon has joined #linux-exynos
amitk has joined #linux-exynos
wwilly has joined #linux-exynos
masta has quit [Ping timeout: 258 seconds]
masta has joined #linux-exynos
LiquidAcid has joined #linux-exynos
masta has quit [Ping timeout: 260 seconds]
masta has joined #linux-exynos
<ndufresne>
LiquidAcid: I've been looking into how the Renesas R-CAR works with blocks like g2d, gscaler, etc. I notice that instead of forking the drivers, they have a single media-node driver, and using the media controller you can assign it in userspace to be used with the DRM driver or through memory interface using V4L2 nodes
<ndufresne>
Is there any plane to follow this path ?
<LiquidAcid>
not that i know of
<ndufresne>
(a single driver per block of course)
<Wizzup>
LiquidAcid: no, I have not been able to try it yet, I've been working on compiling firefox and debug the grsec issue
<Wizzup>
when that is done I'm going to try your change
<LiquidAcid>
ndufresne, i think the plan from samsung side is to move away from v4l2
<ndufresne>
which is kind of lame, as drm will probably never be a good streaming interface
<sjoerd`>
javier__: ^ :p
<ndufresne>
all the DRM bits are custom API
<ndufresne>
that's also a problem
<LiquidAcid>
ndufresne, i'm probably not the right one to ask though, maybe drop krzh a line when he's online
<ndufresne>
nod, I'm expressing a personal opinion here btw, anyone free to say otherwise
<LiquidAcid>
<ndufresne> which is kind of lame, as drm will probably never be a good streaming interface <- i think there were plans to join forces with another driver there
<ndufresne>
we could probably start using videobuf2 framework, this queue and allocation framework is now v4l2 free
<LiquidAcid>
ndufresne, no, i mean some interface on the drm side
<ndufresne>
the thing I notice, is that with the drm stuff, you can't use the IP blocks outside of the compositor, because of the DRM master thingy
<ndufresne>
That prevents implement application side composition (like video mixing)
<ndufresne>
at least this is the choice you need to make with Exynos at the moment (I don't know if there is a larger view on the future plan)
<LiquidAcid>
i think you don't need to be master to do this, the ioctls should have the render node flag set
<ndufresne>
ok
<ndufresne>
is Sylwester involved (the guy who wrote the v4l2 ipp stuff)
<LiquidAcid>
wasn't ipp just on the drm side?
<ndufresne>
no, it all started on v4l2 side
<ndufresne>
the drm side is partial copy paste, there is actually more feature implemented on v4l2 side (not saying they all work)
<ndufresne>
The thing is that those blocks are very close to the camera sensor, same type of signal
<LiquidAcid>
hmm, i'm not finding any reference to IPP on the v4l2 side, but just to quote marek:
<ndufresne>
so when moving the colorspace bits (let's say g2d in drm make quite some sense, hence using csp as an example), you endup with the sensor driver being nearly unusable
<LiquidAcid>
"Existing code for Exynos DRM IPP is terribly broken. There are several design
<LiquidAcid>
flaws as well as simple bugs in existing drivers. Also the error checking
<LiquidAcid>
is missing in many places, so it is quite easy to crash the kernel if
<LiquidAcid>
userspace provides incorrect data or does invalid operations. Better don't
<LiquidAcid>
use IPP feature yet."
<ndufresne>
LiquidAcid: it's capps exynos4-fimc I believe
<ndufresne>
base on the name of the set of IP Blocks, they are all FIMC something ...
<LiquidAcid>
ndufresne, but ipp/drm is a layer above fimc
<ndufresne>
there is scaler, colorspace, two type of rotator, deinterlacer, face/smile recognition, I think that's about it
<ndufresne>
LiquidAcid: yes, whcih prevents using the FIMCs in front of the camera sensors
<LiquidAcid>
why is that?
<ndufresne>
unless you wamt to capture using drm driver, but the media APIs are well designed for that
<ndufresne>
LiquidAcid: the FIMC are both m2m and IP to IP (signal) type of IPs
<ndufresne>
the sensor don't have a memory interface
<LiquidAcid>
ah, so you want IP to IP here
<ndufresne>
so whenever you want to capture, you need to connect one of the FIMC instance to the sensor
<LiquidAcid>
i see, well i guess there is some interop api between drm and v4l2 missing
<ndufresne>
that's would have been a better idea then forking the driver tbh
<LiquidAcid>
i'm mainly interested in the blocks because of CSC from YUV to RGB
<ndufresne>
those forks existed for a long time (like before 2011)
<LiquidAcid>
yeah, but there is nothing in userspace using ipp/drm
<ndufresne>
LiquidAcid: sure, as I said, I think the Renesas team nailed the right design, they can use any IPP from both v4l2 and drm
<LiquidAcid>
except for some testing code tizen's libdrm (iirc)
<ndufresne>
LiquidAcid: GStreamer is using the v4l2 side, which you can't expose if you build the DRM sid
<LiquidAcid>
but who's using gstreamer? :D
<ndufresne>
I understand this is all very experimental then
<ndufresne>
LiquidAcid: a lot of people ;-P
<ndufresne>
you'd be surprised
<LiquidAcid>
well, certainly not me though
<ndufresne>
any particular reason ? ;-P
<ndufresne>
or just that you don't have to deal with video capture, encoding, decoding and streaming ?
<LiquidAcid>
if i would install it here, i probably pull in lots of gnome dependencies, so eventually meant installing systemd
<LiquidAcid>
no, actually i don't use my arm board for anything video related -- i have vaapi working fine on my laptop, which is pretty much enough for me
<LiquidAcid>
i don't encode video, i don't stream, i don't do any video conferencing stuff, etc.
<ndufresne>
that's probably true on debian, but no, you don't need systemd, and all the deps are optional, except of course glib (which rely on ffi and libc)
<ndufresne>
Make sense then
<ndufresne>
I'd love to say vaapi is finally stable in GStreamer, but not yet, it's not longer a third party component, that is going to help, but it's under development still
Vasco_O is now known as Vasco
<LiquidAcid>
any watching blurays on an arm board is pretty much impossible anyway
<LiquidAcid>
just checked, if i enable the gstreamer useflag i get like 40 new packages, and 8 rebuilds or so, one being libreoffice.... so nope! :D
<Wizzup>
using gentoo?
<LiquidAcid>
yes
<Wizzup>
:)
<LiquidAcid>
i know, i could use the bin pkg
<Wizzup>
Is there one for arm?
<Wizzup>
I doubt it
<Wizzup>
I build it on my arm build server (if6410 with swap)
<LiquidAcid>
no, but this is on my laptop anyway
<LiquidAcid>
i don't have libreoffice installed on the odroid
<Wizzup>
:)
<LiquidAcid>
actually i have almost none gui stuff installed there, just bare xfce and fluxbox to test the ddx
<ndufresne>
LiquidAcid: I think most hard medium are dead by now ;-P
<LiquidAcid>
ndufresne, you might find this funny, but i don't buy digital stuff at all, be it games, music, film, etc.
<ndufresne>
LiquidAcid: hmm, you probably have weird use flags ;-P (was it name like this?)
<ndufresne>
me neither
<ndufresne>
very rarely at least
<ndufresne>
oh, I pay for netflix, I guess that counts
<LiquidAcid>
no netflix, no steam here
<LiquidAcid>
i have around 700 cds though, not including other optical media
<ndufresne>
on another subject, I just realised that the difference in the dmabuf import path is that when I use generated image, I use a single allocation, while the dmabuf from the decoder have two allocation
* ndufresne
need to check that attentively
<LiquidAcid>
ndufresne, you mean because of the l/r mfc split?
<ndufresne>
using an offset in the luma pointer, rather then using the chroma pointer would explain the page fault
<ndufresne>
(just guessing)
<ndufresne>
at the same time, the v4l2 side should protect against that, making the map() fail
<LiquidAcid>
you mean the pagefault that happens when you import on the drm side?
<ndufresne>
yes
<ndufresne>
the dmabuf is cma backed, so I don't see any otherway to get a page fault then reading passed the segment
<LiquidAcid>
but don't you have to import luma and chroma separately anyway?
<ndufresne>
there is two DMABuf fd, yet, but it could be ignore, the DMABuf on many many drivers only work with 1 FD per plane
<ndufresne>
sorry, per image
<ndufresne>
(an image have two planes)
<LiquidAcid>
i mean on the drm side, if you addfb2 nv12 then you need to set two planes, right?
<ndufresne>
yes, what I'm saying is that there could be a subtile bug in there, which works if you have that same FD twice