<!-- 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>

   mchehab: <u>pinchartl</u>: just pulled from 4.10 on media... hopefully, it should compile again on arm64
   ***: prabhakarlad has left
   pinchartl: <u>mchehab</u>: thanks. it should work
   ***: benjiG has left
   pinchartl: <u>mchehab</u>: will you reply to "Re: &lt;Query&gt; Looking more details and reasons for using orig_add_limit." ?
   mchehab: will take a look on it...
   <br> but, basically, the first compat code merged on media came from someone that wrote the generic compat32 code
   <br> I guess that the set_fs() calls were added on that time
   pinchartl: yes the call dates from back then
   <br> it's a hack
   <br> we need to refactor ioctl handling to get rid of it
   mchehab: agreed
   ndufresne: <u>thiblahute</u>: you can't really fill-in colorspace on the OUTPUT side of a m2m here
   <br> you can for Camera capture
   <br> you can on m2m converter capture side, if the output colorspace is set
   thiblahute: <u>ndufresne</u>: I do not really get why, it has to be guessed at some point if userspace did not provide it no?
   mchehab: <u>pinchartl</u>: if the issues started with Kernel 4.9, then it is likely to be caused by VM stack changes
   thiblahute: <u>ndufresne</u>: Otherwise, what do it mean?
   ndufresne: <u>thiblahute</u>: yes, and we usually do that internally to converter, and at display
   <br> <u>thiblahute</u>: it's also the colorspace is highly overloaded, it's everything in one
   <br> How I believe it works in v4l2, for backward reason, is that the colorspace mostly define the range, and the defaults for the other 3 fields
   <br> the doc is a lot of text, and very little formula you can apply, I think this is unfortunate
   mchehab: from its original thread, on LKML, the breakage seems to happen with ARMv8.2, but it is not clear if the Kernel is 4.9+ nor if it is compiled with VMAP_STACK
   ndufresne: <u>thiblahute</u>: you'll notice that in GStreamer, we only implemented some subset of it, since it generates to many combination to be run through TRY_FMT, causing huge initialization delay for drivers like UVC
   thiblahute: <u>ndufresne</u>: Right, so basically it should not matter to let the colorspace to DEFAULT in that case and that should be figured out later in the pipeline? That should work I think
   ndufresne: yes, that's what I think
   thiblahute: <u>ndufresne</u>: Yeah noticed that, I was thinking we should cache the info so that the probing is done once for all decoders for a specific device
   ndufresne: if V4L2_TYPE_OUTPUT has colorspace default, we should keep it like this, pick the most probably converters internally, and let the display decide
   mchehab: weird... my e-mails to @vger are taking about 10 mins to popup there
   ndufresne: <u>thiblahute</u>: I believe we do that, but the cache does not persist the GstElement though
   thiblahute: <u>ndufresne</u>: Well, in that case the end result is the same if internally we guess it
   ndufresne: true
   <br> but the driver does not make up anything
   thiblahute: <u>ndufresne</u>: I think we don't , but even if we did, it should persits the GstElement
   ndufresne: userspace endup being aware that the color situation is unknown
   <br> <u>thiblahute</u>: see probed_caps ;-P
   thiblahute: <u>ndufresne</u>: Well, doesn' leak it to userspace :)
   ndufresne: but that's the wrong channel to discuss that
   <br> <u>thiblahute</u>: about GScaler, what are the colorspace param we can control ?
   <br> Is it like the old FIMC, with only 2 magical value, 1 for SD, and one for HD ?
   <br> (the Exynos 4 converter does colorspace completly wrong btw)
   -: ndufresne have to leave for a bit
   thiblahute: <u>ndufresne</u>: Right, yes, it seems to be the case.
   pinchartl: <u>mchehab</u>: that's very possible. we need to fix it in any case