Re: Media bus pixel code and pixel format enumeration (was: )

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Sakari,

thank you for your reply (and finding a nice subject for this)!

> On Mon, Jul 21, 2014 at 02:35:39PM +0200, Peter Meerwald wrote:
> > how can I query the supported pixel format(s) of a sensor connected via 
> > media-ctl and exposed via /dev/videoX
> > 
> > there is 
> > VIDIOC_ENUM_FMT (which fails)
> > and
> > VIDIOC_SUBDEV_ENUM_MBUS_CODE (which works, but on a subdev, not on 
> > /dev/videoX)
> > 
> > v4l2_subdev_video_ops has .enum_mbus_fmt (this is SoC camera stuff?)
> > 
> > v4l2_subdev_pad_ops has .enum_mbus_code
> > 
> > 
> > the application just sees /dev/videoX and cannot do VIDIOC_ENUM_FMT
> > what is the logic behind this?
> > shouldn't a compabatibility layer be added turning VIDIOC_ENUM_FMT into 
> > VIDIOC_SUBDEV_ENUM_MBUS_CODE?
> 
> The issue has been that enumerating should not change the state of the
> device. Within a single device node things are fine, but in this case the
> media bus pixel code at the other end of the link affects the result of the
> enumeration.

good to know this has been considered before
 
> There hasn't been really a solution for this in the past; what has been
> discussed as possible options have been (at least to my recollection) but
> none has been implemented:
> 
> 1) Use the media bux pixel code from the other end of the link. As there is
> no common file handle to share the state with, the link configuration and
> setting the media bus pixel code are necessary state changes before the
> enumeration can take place, and the two must not be changed during the it.
> This breaks the separation between configuration and enumeration. (There has
> been a patch to the omap3isp driver which essentially did this long time ago
> AFAIR.)
> 
> 2) Use a reserved field in struct v4l2_fmtdesc to tell the pixel code. This
> way enumeration can stay separate from configuration and is probably easier
> for the user space as well. I vote for this: it's clean, simple and gets the
> job done.

I not sure if I fully understand your suggestion

let's assume the following setup: 
sensor (subdev8) <-> OMAP3 CCDC (subdev2) <-> output (video2)

userspace would query VIDIOC_ENUM_FMT on video2; what is the expected 
answer? and how would it be obtained?

for me it would be good enough if first configuration via media-ctl is 
done, and ENUM_FMT video2 would just return at least one FMT that can be 
set

so configuration would be fixed, I'm not interested in all possible FMTs

regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux