pinchartl: just pulled from 4.10 on media... hopefully, it should compile again on arm64
mchehab: thanks. it should work
mchehab: will you reply to "Re: <Query> Looking more details and reasons for using orig_add_limit." ?
will take a look on it...
but, basically, the first compat code merged on media came from someone that wrote the generic compat32 code
I guess that the set_fs() calls were added on that time
yes the call dates from back then
it's a hack
we need to refactor ioctl handling to get rid of it
agreed
thiblahute: you can't really fill-in colorspace on the OUTPUT side of a m2m here
you can for Camera capture
you can on m2m converter capture side, if the output colorspace is set
ndufresne: I do not really get why, it has to be guessed at some point if userspace did not provide it no?
pinchartl: if the issues started with Kernel 4.9, then it is likely to be caused by VM stack changes
ndufresne: Otherwise, what do it mean?
thiblahute: yes, and we usually do that internally to converter, and at display
thiblahute: it's also the colorspace is highly overloaded, it's everything in one
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
the doc is a lot of text, and very little formula you can apply, I think this is unfortunate
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
thiblahute: 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
ndufresne: 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
yes, that's what I think
ndufresne: 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
if V4L2_TYPE_OUTPUT has colorspace default, we should keep it like this, pick the most probably converters internally, and let the display decide
weird... my e-mails to @vger are taking about 10 mins to popup there
thiblahute: I believe we do that, but the cache does not persist the GstElement though
ndufresne: Well, in that case the end result is the same if internally we guess it
true
but the driver does not make up anything
ndufresne: I think we don't , but even if we did, it should persits the GstElement
userspace endup being aware that the color situation is unknown
thiblahute: see probed_caps ;-P
ndufresne: Well, doesn' leak it to userspace :)
but that's the wrong channel to discuss that
thiblahute: about GScaler, what are the colorspace param we can control ?
Is it like the old FIMC, with only 2 magical value, 1 for SD, and one for HD ?
(the Exynos 4 converter does colorspace completly wrong btw)
ndufresne: Right, yes, it seems to be the case.
mchehab: that's very possible. we need to fix it in any case