Re: [PATCH v5 00/39] i.MX Media Driver

From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: mark.rutland@arm.com, andrew-ct.chen@mediatek.com,
	minghsiu.tsai@mediatek.com, sakari.ailus@linux.intel.com,
	nick@shmanahar.org, songjun.wu@microchip.com, hverkuil@xs4all.nl,
	pavel@ucw.cz, robert.jarzmik@free.fr, devel@driverdev.osuosl.org,
	markus.heiser@darmarIT.de,
	Steve Longerbeam <steve_longerbeam@mentor.com>,
	shuah@kernel.org, geert@linux-m68k.org,
	Steve Longerbeam <slongerbeam@gmail.com>,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	kernel@pengutronix.de, arnd@arndb.de, mchehab@kernel.org,
	bparrot@ti.com, robh+dt@kernel.org, horms+renesas@verge.net.au,
	tiffany.lin@mediatek.com,
	laurent.pinchart+renesas@ideasonboard.com,
	linux-arm-kernel@lists.infradead.org,
	niklas.soderlund+renesas@ragnatech.se,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	jean-christophe.trotin@st.com, p.zabel@pengutronix.de,
	fabio.estevam@nxp.com, shawnguo@kernel.org, sud
Subject: Re: [PATCH v5 00/39] i.MX Media Driver
Date: Sun, 19 Mar 2017 10:33:25 -0400	[thread overview]
Message-ID: <1489934005.3388.1.camel@ndufresne.ca> (raw)
In-Reply-To: <20170319005453.GN21222@n2100.armlinux.org.uk>

[-- Attachment #1.1: Type: text/plain, Size: 2984 bytes --]

Le dimanche 19 mars 2017 à 00:54 +0000, Russell King - ARM Linux a
écrit :
> > 
> > In practice, I have the impression there is a fair reason why
> > framerate
> > enumeration isn't implemented (considering there is only 1 valid
> > rate).
> 
> That's actually completely incorrect.
> 
> With the capture device interfacing directly with CSI, it's possible
> _today_ to select:
> 
> * the CSI sink pad's resolution
> * the CSI sink pad's resolution with the width and/or height halved
> * the CSI sink pad's frame rate
> * the CSI sink pad's frame rate divided by the frame drop factor
> 
> To put it another way, these are possible:
> 
> # v4l2-ctl -d /dev/video10 --list-formats-ext
> ioctl: VIDIOC_ENUM_FMT
>         Index       : 0
>         Type        : Video Capture
>         Pixel Format: 'RGGB'
>         Name        : 8-bit Bayer RGRG/GBGB
>                 Size: Discrete 816x616
>                         Interval: Discrete 0.040s (25.000 fps)
>                         Interval: Discrete 0.048s (20.833 fps)
>                         Interval: Discrete 0.050s (20.000 fps)
>                         Interval: Discrete 0.053s (18.750 fps)
>                         Interval: Discrete 0.060s (16.667 fps)
>                         Interval: Discrete 0.067s (15.000 fps)
>                         Interval: Discrete 0.080s (12.500 fps)
>                         Interval: Discrete 0.100s (10.000 fps)
>                         Interval: Discrete 0.120s (8.333 fps)
>                         Interval: Discrete 0.160s (6.250 fps)
>                         Interval: Discrete 0.200s (5.000 fps)
>                         Interval: Discrete 0.240s (4.167 fps)
>                 Size: Discrete 408x616
> <same intervals>
>                 Size: Discrete 816x308
> <same intervals>
>                 Size: Discrete 408x308
> <same intervals>
> 
> These don't become possible as a result of implementing the enums,
> they're all already requestable through /dev/video10.

Ok that wasn't clear. So basically video9 is a front-end to video10,
and it does not proxy the enumerations. I understand this is what you
are now fixing. And this has to be fixed, because I can image cases
where the front-end could support only a subset of the sub-dev. So
having userspace enumerate on another device (and having to find this
device by walking the tree) is unlikely to work in all scenarios.

regards,
Nicolas

p.s. This is why caps negotiation is annoyingly complex in GStreamer,
specially that there is no shortcut, you connect pads, and they figure-
out what format they will use between each other.

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel