[7] has quit [Disconnected by services]
TheSeven has joined #linux-exynos
LiquidAcid has quit [Quit: Leaving]
_whitelogger has joined #linux-exynos
zenmetsu has quit [Ping timeout: 250 seconds]
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
<ndufresne> we'll see when I get to look at this
<LiquidAcid> i had always wondered where that single-plane nv12 format really came from
<ndufresne> actually, the VP supports 6 formats
<ndufresne> as it support both single allocation and bi-allocation NV12/NV21
<ndufresne> for the HW it's only 4 formats
<ndufresne> (for gst too)
<LiquidAcid> but there's not uni-planar nv12 on the drm side, that was the point back then
<ndufresne> 1 allocation or two should not make much difference
<ndufresne> it's just a memory address ;-P
<LiquidAcid> yes, but iirc there is a seperate format on the v4l2 for that
<LiquidAcid> *v4l2 side
<ndufresne> I don't agree with the v4l2 folk on forking the formats base on the number of allocation, but they had API backward compatibility issue
<ndufresne> I think I'd look into where the plane->dma_addr[] is poplulated
<LiquidAcid> ndufresne, iirc it was in the plane code
<LiquidAcid> oh well, it wasn't :D
<ndufresne> in any case, it's userspace that should provide/pass the offset to second plane
<ndufresne> ok, so there should be two seperate gem here, that's created through PRIME right ?
<ndufresne> LiquidAcid: looking that that code, it seems to indicate that maybe the userspace provided offset is broken
<ndufresne> I wonder what code is missing to validate that
<LiquidAcid> ndufresne, i would expect validation for that to be done in drm code
<LiquidAcid> core i mean
<ndufresne> LiquidAcid: do gem have a size specified somewhere ?, we could add a check that plane_size + offsets <= gem_size ?
<ndufresne> nod
<ndufresne> it's likely that the core does not know how to calulate plane size for NV12 tiled though
<LiquidAcid> ndufresne, the size is in struct exynos_drm_gem
<ndufresne> it's not trivial
<LiquidAcid> ndufresne, but i would really suspect that drm core already checks that
<ndufresne> I didn't find it anywhere
<ndufresne> they usuall do stride * height
<ndufresne> which is incorrect for tiles
<LiquidAcid> ndufresne, have you asked on #dri-devel?
<ndufresne> you need to round up the height to 64, and roundup to 2 the number of row on the second plane
<ndufresne> not yet
<ndufresne> it's first time I forsee a userspace bug, that in fact didn't get blocked by drm checks
cosm has joined #linux-exynos
wwilly has quit [Quit: Leaving]
amitk has quit [Quit: leaving]
wwilly has joined #linux-exynos
afaerber has quit [Quit: Ex-Chat]
cosm has quit [Ping timeout: 240 seconds]
Vasco is now known as Vasco_O
LiquidAcid has quit [Quit: Leaving]
Ultrasauce has quit [Read error: Connection reset by peer]
wwilly has quit [Quit: Leaving]
Ultrasauce has joined #linux-exynos