On Tuesday 01 September 2009 11:56:19 ext Laurent Pinchart wrote:
> On Monday 31 August 2009 13:58:54 Tuukka.O Toivonen wrote:
> > When user space queues a buffer using VIDIOC_QBUF, the kernel
> > should set flags in struct v4l2_buffer as specified in the V4L2
> > documenta
When user space queues a buffer using VIDIOC_QBUF, the kernel
should set flags in struct v4l2_buffer as specified in the V4L2
documentation.
---
drivers/media/video/videobuf-core.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b
Hi, quoting V4L2 spec:
http://v4l2spec.bytesex.org/spec/r13317.htm
"__s32 step
[...]
Generally drivers should not scale hardware control values. It may be
necessary for example when the name or id imply a particular unit and the
hardware actually accepts only multiples of said unit. If so, driv
When user space queues a buffer using VIDIOC_QBUF, the kernel
should set flags to V4L2_BUF_FLAG_QUEUED in struct v4l2_buffer.
videobuf_qbuf() was missing a call to videobuf_status() which does
that. This patch adds the proper function call.
Signed-off-by: Tuukka Toivonen
---
drivers/media/video/
On Monday 22 June 2009 17:00:53 ext Dongsoo Kim wrote:
> OK, what I'm afraid is that even though the device could be opened and
> recognized as a v4l2 device but has no capability should be weird.
> Actually I'm not sure about this case is spec-in or not.
> In my opinion it should be better whe
On Saturday 20 June 2009 12:05:13 ext Dongsoo, Nathaniel Kim wrote:
> Following patch.
> http://www.gitorious.org/omap3camera/mainline/commit/d92c96406296310a977b00f45b209523929b15b5
> What happens to the capability when the int device is dummy? (does it
> mean that there is no int device?)
Yes, w
On Wednesday 18 March 2009 18:17:56 ext Suresh Rao wrote:
> I am working with MT9V023 RAW sensor. The data format from the sensor is
>
> B G B G B G B G ...
> G R G R G R G R ...
> B G B G B G B G ...
> G R G R G R G R [ Format 1]
[...]
> I want to use the ISP on the OMAP for doing
On Monday 09 March 2009 23:29:27 ext Menon, Nishanth wrote:
> Further, we have multiple sensors following CCI[1] - why not have a driver
> for the same, it will simplify the entire process - ov3640, mt9p012 both
> follow the spec at least.. dependency would be sensor -> cci dev->i2c
> framework.
On Wednesday 04 March 2009 16:52:20 ext Hans Verkuil wrote:
> > Alternatively, VIDIOC_QUERYCAP could be used to identify the sensor.
> > Would it make more sense if it would return something like
> > capability.card: `omap3/smia-sensor-12-1234-5678//'
> > where 12 would be manufacturer_id, 1234
Hi,
I am writing a generic driver for SMIA-compatible sensors.
SMIA-sensors have registers containing:
u16 model_id
u16 revision_number
u8 manufacturer_id
which could be used to detect the sensor.
However, since the driver is generic, it is not interested
of these values.
Nevertheless, in s
On Wednesday 04 March 2009 09:39:48 ext Hans Verkuil wrote:
> BTW, do I understand correctly that e.g. lens drivers also get their
> own /dev/videoX node? Please tell me I'm mistaken! Since that would be so
> very wrong.
You're mistaken :)
With the v4l2-int-interface/omap34xxcam camera driver o
11 matches
Mail list logo
