<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   paulk-leonov: ezequielg, you mean, keep the buffers queued until they are no longer used as reference?
   ezequielg: yes.
   <br> or instead mark them, so when they are dequeued they don't get unmapped.
   <br> i mean anything that avoids the driver from doing work, if it's possible for the core for cleanly doing this.
   paulk-leonov: ezequielg, the issue is that there is no way to predict that a frame will be later used as reference
   ezequielg: right.
   <br> so you say it's only the driver who knows.
   <br> and this affects only dma-buf?
   paulk-leonov: ezequielg, right, only buffers imported with dma-buf need special map/unmap calls before access
   ezequielg: i guess the helpers can be cleaned-up, introducing map/unmap helpers that can be reused in the core.
   <br> but aside from that, the approach seems reasonable.
   <br> tfiga might have some input
   paulk-leonov: right
   <br> I was very uncertain about how it should affect the core and went for making it up to the driver
   <br> for the most part
   ***: benjiG has left
   ndufresne: pH5, ping, I've updated by test board IMX.6 Sabrelite to 5.0-rc2, that's how I could report that the m2m converter issue I reported is fixed, though I found out that capturing from mipi ov5460 is now broken, I get an -110 error, some timeout
   <br> are you already aware of this ? my media controller configuration script, https://paste.fedoraproject.org/paste/vQef5Yufasp4AOC4S61cxg, and the command to reproduce, v4l2-ctl  -d /dev/video4  --stream-mmap  --stream-count=3
   <br> these are regression in the sense that same script worked on 4.17 and 4.18 kernels
   pH5: <u>ndufresne</u>: appreciated, unfortunately I don't have ov5640. there have been quite some changes to that driver between v4.18 and v5.0-rc
   ndufresne: yes, and quite some regressions apparently ;-P
   <br> maybe I should drop an email to Steve then ?
   <br> pH5, about the m2m scaler, are you planning on enabling more RGB formats ? I notice that we only support of subset of what the HW can do (comparing against vendor one)
   <br> I wonder if it's possible to set the x value in xRGB to 0xff and enable ARGB output ...
   <br> but output I mean on capture queue
   <br> that could be handy for me to avoid a GPU render pass in gst ...
   pH5: <u>ndufresne</u>: I don't think this is possible, at least not when we have to use the CSC matrix for colorspace conversion...
   <br> <u>ndufresne</u>: What formats are you missing? I'm happy to add missing formats if there is a use case.
   <br> <u>Re</u>: ov5640, yes, probably Steve knows more about that.
   ndufresne: pH5, before 5.0, converting to xRGB was producing BGRx, so clearly there is a way to flip the comp order
   <br> most HW have seen have that, I must admit I never looked into that driver yet
   <br> the Exynos ones, FIMC and GScaler have a global alpha setting
   pH5: you mean BGRx in memory order, so V4L2_PIX_FMT_XBGR32 (fourcc 'XR24')?
   ndufresne: pH5, v4l2 fourcc for rgb, even the new one are a mess, I would need to look at the doc to confirm ;-P
   <br> I can extract later the list form the vendor side
   <br> that would get us an idea, generally this isn't hard, if you find the right registers
   <br> do we have spec for this one ? or is it reversed ?
   pH5: https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-packed-rgb.html
   ndufresne: so yes, it was producing V4L2 XBGR (which is packed BGRx)
   <br> thing is that xBGR in that order, is something that exist
   <br> pH5, oh wait, I'm rereading myself, it's producing RGBx in that order
   <br> that one is not defined in v4l2
   <br> but basically I was thinking if it can produce weirdness like this, it propably can do everything the display HW can handle
   <br> (nothing urgent, just asking what's the plan)
   pH5: I feel dirty even speculating, but we could potentially create RGBA from RGBx by telling the hardware that the R component is alpha and then using the CSC matrix to set the third component to 0xff. Though this useless if the source is YUV.
   <br> It it is useful, I see no reason not to introduce V4L2 pixel formats for RGBx/RGBA. Once those formats exist, it will be trivial to support them in the IPU driver.
   ndufresne: ok
   <br> right now for my case, ARGB would be useful