Re: [RFC] HDMI-CEC proposal

[Hans Verkuil]

Hi Alex,

On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote:
 On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge)
 marbu...@cisco.com wrote:
  Author: Martin Bugge marbu...@cisco.com
  Date:  Tue, 1 March 2010
  ==
 
  This is a proposal for adding a Consumer Electronic Control (CEC) API to
  V4L2.
  This document describes the changes and new ioctls needed.
 
  Version 1.0 (This is first version)
 
  Background
  ==
  CEC is a protocol that provides high-level control functions between 
various
  audiovisual products.
  It is an optional supplement to the High-Definition Multimedia Interface
  Specification (HDMI).
  Physical layer is a one-wire bidirectional serial bus that uses the
  industry-standard AV.link protocol.
 
  In short: CEC uses pin 13 on the HDMI connector to transmit and receive
  small data-packets
   (maximum 16 bytes including a 1 byte header) at low data rates
  (~400 bits/s).
 
  A CEC device may have any of 15 logical addresses (0 - 14).
  (address 15 is broadcast and some addresses are reserved)
 
 
 It would be nice if this was not tied to v4l as we'll start seeing CEC
 support show in GPUs soon as well.

As mentioned in other emails it is my firm believe that mixing APIs is a bad 
idea. I've never seen that work in practice. That said, I do think that any 
userspace CEC library shouldn't be tied to V4L allowing it to be used by GPUs. 

It would also be interesting to see if i2c HDMI receiver/transmitter drivers 
can be used by both subsystems. This would make a lot of sense.

Apologies if I asked this before, but are you planning to attend the ELC in 
San Francisco? If so, then we should sit together and compare the subsystems 
and see if we can work something out.

Regards,

Hans

 
 Alex
 
 
  References
  ==
  [1] High-Definition Multimedia Interface Specification version 1.3a,
 Supplement 1 Consumer Electronic Control (CEC).
 http://www.hdmi.org/manufacturer/specification.aspx
 
  [2]
  http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
 
 
  Proposed solution
  =
 
  Two new ioctls:
 VIDIOC_CEC_CAP (read)
 VIDIOC_CEC_CMD (read/write)
 
  VIDIOC_CEC_CAP:
  ---
 
  struct vl2_cec_cap {
__u32 logicaldevices;
__u32 reserved[7];
  };
 
  The capability ioctl will return the number of logical devices/addresses
  which can be
  simultaneously supported on this HW.
 0:   This HW don't support CEC.
 1 - 14: This HW supports n logical devices simultaneously.
 
  VIDIOC_CEC_CMD:
  ---
 
  struct v4l2_cec_cmd {
 __u32 cmd;
 __u32 reserved[7];
 union {
 struct {
 __u32 index;
 __u32 enable;
 __u32 addr;
 } conf;
 struct {
 __u32 len;
 __u8  msg[16];
 __u32 status;
 } data;
 __u32 raw[8];
 };
  };
 
  Alternatively the data struct could be:
 struct {
 __u8  initiator;
 __u8  destination;
 __u8  len;
 __u8  msg[15];
 __u32 status;
 } data;
 
  Commands:
 
  #define V4L2_CEC_CMD_CONF  (1)
  #define V4L2_CEC_CMD_TX(2)
  #define V4L2_CEC_CMD_RX(3)
 
  Tx status field:
 
  #define V4L2_CEC_STAT_TX_OK(0)
  #define V4L2_CEC_STAT_TX_ARB_LOST  (1)
  #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
 
  The command ioctl is used both for configuration and to receive/transmit
  data.
 
  * The configuration command must be done for each logical device address
   which is to be enabled on this HW. Maximum number of logical devices
   is found with the capability ioctl.
 conf:
  index:  0 - number_of_logical_devices-1
  enable: true/false
  addr:   logical address
 
   By default all logical devices are disabled.
 
  * Tx/Rx command
 data:
  len:length of message (data + header)
  msg:the raw CEC message received/transmitted
  status: when the driver is in blocking mode it gives the result 
for
  transmit.
 
  Events
  --
 
  In the case of non-blocking mode the driver will issue the following 
events:
 
  V4L2_EVENT_CEC_TX
  V4L2_EVENT_CEC_RX
 
  V4L2_EVENT_CEC_TX
  -
   * transmit is complete with the following status:
  Add an additional struct to the struct v4l2_event
 
  struct v4l2_event_cec_tx {
__u32 status;
  }
 
  V4L2_EVENT_CEC_RX
  -
   * received a complete message
 
 
  Comments ?
 
Martin Bugge
 
  --
  Martin Bugge - Tandberg (now a part of Cisco)
  --
 
  --
  To unsubscribe from this list: send the line unsubscribe linux-media in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org

Re: [RFC] HDMI-CEC proposal

[Martin Bugge (marbugge)]

On 03/02/2011 12:38 AM, Daniel Glöckner wrote:

On Tue, Mar 01, 2011 at 10:59:07AM +0100, Martin Bugge (marbugge) wrote:
   

CEC is a protocol that provides high-level control functions between
various audiovisual products.
It is an optional supplement to the High-Definition Multimedia
Interface Specification (HDMI).
Physical layer is a one-wire bidirectional serial bus that uses the
industry-standard AV.link protocol.
 

Apart from CEC being twice as fast as AV.link and using 3.6V
instead of 5V, CEC does look like an extension to the frame format
defined in EN 50157-2-2 for multiple data bytes.

So, how about adding support for EN 50157-2-* messages as well?
SCART isn't dead yet.

EN 50157-2-1 is tricky in that it requires devices to override
data bits like it is done for ack bits to announce their status.
There is a single message type with 21 bits.

For EN 50157-2-2 the only change necessary would be to tell the
application that it has to use AV.link commands instead of CEC
commands. In theory one could mix AV.link and CEC on a single
wire as they can be distinguished by their start bits.

EN 50157-2-3 allows 7 vendors to register their own applications
with up to 100 data bits per message. I doubt we can support
these if they require bits on the wire to be modified.
As they still didn't make use of the reserved value to extend the
application number space beyond 7, chances are no vendor ever
applied for a number.

Just my 2 cents.

   Daniel
   


Hi Daniel and thank you.

I haven't read these standards myself but will do so as soon as I get 
hold of them.

But this sounds like a good idea since cec is based on these protocols.

I will look into it.

Regards,
Martin

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Remote controller AsusU3100Mini plus

[Michal Bojda]

Hello there,

I am trying figure how to make this remote controller working. I tried
LIRC, but on the website isnt this card in supported controllers.
After apt-getting lirc and depencies. controller isnt reacting. At
least how he should be. If I open terminal, and trying to push
buttons, my PC starts to make interesting sounds :) And after that,
even my keaboard isnt working how it is supposed to. So I dont think
this is the right way. Maybe some kind of reprogramming? Or someone
got config file for it ?

I will be glad for any help, posting image found on google. I know its
not DVB-T card I am writing, but controller looks same. Just for
imagination.

I thanks once more for any reply.

Best regards M. Bojda

http://www.waroengkom.com/product/TV%20TUNER%20MYC-U3000%20HYBRID.png

-- 
Those who watches their backs, meet death from the front.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: isp or soc-camera for image co-processors

[Sakari Ailus]

Hi Bhupesh and Laurent,

Bhupesh SHARMA wrote:
...
 Try to configure your mailer to use spaces instead of tabs, or to make
 tabs 8
 spaces wide. It should then look good. Replies will usually mess the
 diagrams
 up though.
 
 Ok, I will try it :)

Attachments are usually safe as well.

...

 Are there are reference drivers that I can use for my study?

 The OMAP3 ISP driver.
 
 Thanks, I will go through the same.

The major difference in this to OMAP 3 is that the OMAP 3 does have
access to host side memory but the co-processor doesn't --- as it's a
CSI-2 link.

Additional CSI-2 receiver (and a driver for it) is required on the host
side. This receiver likely is not dependent on the co-processor so the
driver shouldn't be either.

For example, using this co-processor should well be possible with the
OMAP 3 ISP, in theory at least. What would be needed in this case is...
support for multiple complex Media device drivers under a single Media
device --- both drivers would be accessible through the same media device.

The co-processor would mostly look like a sensor for the OMAP 3 ISP
driver. Its internal topology would be more complex, though.

Just a few ideas; what do you think of this? :-)

 Unfortunately the data-sheet of the co-processor cannot be made
 public
 as of yet.

 Can you publish a block diagram of the co-processor internals ?
 
 I will check internally to see if I can send a block-diagram
 of the co-processor internals to you. The internals seem similar to 

I'd be very interested in this as well, thank you.

 OMAP ISP (which I can see from the public TRM). However, our
 co-processor doesn't have the circular buffer and MMU that ISP seem to
 have (and some other features).
 
 In the meantime I copy the features of the co-processor here for your review:
 
 Input / Output interfaces of co-processor:
 ==
 - Sensor interfaces: 2 x MIPI CSI-2 receivers (1 x dual-lane up to 1.6 Gbit/s
  and 1 x single lane up to 800 Mbit/s)
 - Host interface: MIPI CSI-2 dual lane transmitter (up to 1.6 Gbit/s) or ITU
  (8-bit CCIR interface, up to 100 MHz) - all with independent variable
  transmitter clock (PLL)
 - Control interface: CCI (up to 400 kHz) or SPI
 
 Sensor support:
 ===
 - Supports two MIPI compliant sensors of up to 8 Megapixel resolution
  (one sensor streaming at a time)
 - Support for auto-focus (AF), extended depth of field (EDOF) and wide dynamic
  range (WDR)sensors 
 
 Internal Features:
 ==
 - Versatile clock manager and internal buffer to accommodate a wide range of 
 data rates
   between sensors and the coprocessor and between the coprocessor and the 
 host.
 - Synchronized flash gun control with red-eye reduction (pre-flash and 
 main-flash strobes) for
   high-power LED or Xenon strobe light

Does the co-processor have internal memory or can external memory be
attached to it for buffer storage?

Regards,

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: isp or soc-camera for image co-processors

[Laurent Pinchart]

Hi Sakari,

On Wednesday 02 March 2011 11:55:47 Sakari Ailus wrote:
 Bhupesh SHARMA wrote:

[snip]

  Are there are reference drivers that I can use for my study?
  
  The OMAP3 ISP driver.
  
  Thanks, I will go through the same.
 
 The major difference in this to OMAP 3 is that the OMAP 3 does have
 access to host side memory but the co-processor doesn't --- as it's a
 CSI-2 link.
 
 Additional CSI-2 receiver (and a driver for it) is required on the host
 side. This receiver likely is not dependent on the co-processor so the
 driver shouldn't be either.
 
 For example, using this co-processor should well be possible with the
 OMAP 3 ISP, in theory at least. What would be needed in this case is...
 support for multiple complex Media device drivers under a single Media
 device --- both drivers would be accessible through the same media device.
 
 The co-processor would mostly look like a sensor for the OMAP 3 ISP
 driver. Its internal topology would be more complex, though.
 
 Just a few ideas; what do you think of this? :-)

Hierachical subdevs is something that will be discussed during the next V4L2 
brainstorming meeting. We will need hierachical entities support in the Media 
Controller as well. This should help in this case, the co-processor entity 
will be made of several sub-entities.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] HDMI-CEC proposal

[Alex Deucher]

On Wed, Mar 2, 2011 at 4:13 AM, Hans Verkuil hansv...@cisco.com wrote:
 Hi Alex,

 On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote:
 On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge)
 marbu...@cisco.com wrote:
  Author: Martin Bugge marbu...@cisco.com
  Date:  Tue, 1 March 2010
  ==
 
  This is a proposal for adding a Consumer Electronic Control (CEC) API to
  V4L2.
  This document describes the changes and new ioctls needed.
 
  Version 1.0 (This is first version)
 
  Background
  ==
  CEC is a protocol that provides high-level control functions between
 various
  audiovisual products.
  It is an optional supplement to the High-Definition Multimedia Interface
  Specification (HDMI).
  Physical layer is a one-wire bidirectional serial bus that uses the
  industry-standard AV.link protocol.
 
  In short: CEC uses pin 13 on the HDMI connector to transmit and receive
  small data-packets
           (maximum 16 bytes including a 1 byte header) at low data rates
  (~400 bits/s).
 
  A CEC device may have any of 15 logical addresses (0 - 14).
  (address 15 is broadcast and some addresses are reserved)
 

 It would be nice if this was not tied to v4l as we'll start seeing CEC
 support show in GPUs soon as well.

 As mentioned in other emails it is my firm believe that mixing APIs is a bad
 idea. I've never seen that work in practice. That said, I do think that any
 userspace CEC library shouldn't be tied to V4L allowing it to be used by GPUs.


Right.  That was my concern.  You are probably more of an expert on
CEC so I'll leave the API to you, but as it's going to show up in
GPUs, I'd rather not re-invent the wheel to support it on the GPU side
in some incompatible manner if it can be avoided.

 It would also be interesting to see if i2c HDMI receiver/transmitter drivers
 can be used by both subsystems. This would make a lot of sense.

There are already several i2c tmds drivers in the drm tree:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/i2c;h=9eb6dad3ffa6cac6dfc07afb0b8526049416398b;hb=HEAD
And a few in the intel kms driver that could be broken out as
independent drivers.  See the dvo_*.c files in:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/i915;h=19e4b8fe8f5413f0c5d5059d8b2561eafab9e5dd;hb=HEAD
Still they are tied to the drm as they are used as kms encoders.



 Apologies if I asked this before, but are you planning to attend the ELC in
 San Francisco? If so, then we should sit together and compare the subsystems
 and see if we can work something out.

Probably not, but I'll know more soon.

Alex


 Regards,

        Hans


 Alex

 
  References
  ==
  [1] High-Definition Multimedia Interface Specification version 1.3a,
     Supplement 1 Consumer Electronic Control (CEC).
     http://www.hdmi.org/manufacturer/specification.aspx
 
  [2]
  http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
 
 
  Proposed solution
  =
 
  Two new ioctls:
     VIDIOC_CEC_CAP (read)
     VIDIOC_CEC_CMD (read/write)
 
  VIDIOC_CEC_CAP:
  ---
 
  struct vl2_cec_cap {
        __u32 logicaldevices;
        __u32 reserved[7];
  };
 
  The capability ioctl will return the number of logical devices/addresses
  which can be
  simultaneously supported on this HW.
     0:       This HW don't support CEC.
     1 - 14: This HW supports n logical devices simultaneously.
 
  VIDIOC_CEC_CMD:
  ---
 
  struct v4l2_cec_cmd {
     __u32 cmd;
     __u32 reserved[7];
     union {
         struct {
             __u32 index;
             __u32 enable;
             __u32 addr;
         } conf;
         struct {
             __u32 len;
             __u8  msg[16];
             __u32 status;
         } data;
         __u32 raw[8];
     };
  };
 
  Alternatively the data struct could be:
         struct {
             __u8  initiator;
             __u8  destination;
             __u8  len;
             __u8  msg[15];
             __u32 status;
         } data;
 
  Commands:
 
  #define V4L2_CEC_CMD_CONF  (1)
  #define V4L2_CEC_CMD_TX    (2)
  #define V4L2_CEC_CMD_RX    (3)
 
  Tx status field:
 
  #define V4L2_CEC_STAT_TX_OK            (0)
  #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
  #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
 
  The command ioctl is used both for configuration and to receive/transmit
  data.
 
  * The configuration command must be done for each logical device address
   which is to be enabled on this HW. Maximum number of logical devices
   is found with the capability ioctl.
     conf:
          index:  0 - number_of_logical_devices-1
          enable: true/false
          addr:   logical address
 
   By default all logical devices are disabled.
 
  * Tx/Rx command
     data:
          len:    length of message (data + header)
          msg:    the raw CEC message received/transmitted
          status: when the driver is in blocking 

Big ptoblem with small webcam

[W.P.]

Hi there,
I just got an Creative VGA (640x480) USB Live Webcam, VF0520.

lsusb (partial):

Bus 003 Device 007: ID 041e:406c Creative Technology, Ltd
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x041e Creative Technology, Ltd
  idProduct  0x406c
  bcdDevice   10.19
  iManufacturer   1 Creative Labs
  iProduct3 VF0520 Live! Cam Sync
  iSerial 0
  bNumConfigurations  1

lsmod | grep vid:
uvcvideo   50184  0
compat_ioctl32  5120  1 uvcvideo
videodev   32000  1 uvcvideo
v4l1_compat15876  2 uvcvideo,videodev

uname -a (kernel from Fedora 10):
[root@laurent-home ~]# uname -a
Linux laurent-home 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST
2008 i686 athlon i386 GNU/Linux

Problem: device nodes are created, but NO video in gmplayer, tvtime
complains: can't open /dev/video0.

Only trace in syslog is:

Mar  2 16:26:56 laurent-home kernel: uvcvideo: Failed to submit URB 0 (-28).

Webcam is connected to VIA USB 2.0 controller through a USB 2.0 hub.

What is strange, two days ago I tried apparently the same (model VF)
with SUCCESS.
Device seems working in Windoze (Ekiga).

What should I check/ do?

W.P.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Missing /dev/video[N] devices...?

[Nick Pelling]

Hi everyone,

I'm trying to bring up the 2.6.37 kernel from scratch on a new 
Samsung S5PC100-based board, but have hit a media problem. Though my 
various v4l2 devices are all registering OK during the boot process 
and end up visible in /sys/class/video4linux , they never manage to 
become visible in /dev , i.e.


# ls /dev/video*
ls: /dev/video*: No such file or directory

# ls /sys/class/video4linux/
video0   video1   video14  video2   video21  video22

# ls /sys/class/video4linux/video0/
devindex  name   subsystem  uevent

# cat /sys/class/video4linux/video0/name
s5p-fimc.0:m2m

# cat /sys/class/video4linux/video0/uevent
MAJOR=81
MINOR=0
DEVNAME=video0

I've tried enabling everything that seems relevant in the kernel's 
menuconfig options, but it seems as though I've omitted some crucial 
piece of the v4l2 infrastructure. Any suggestions for what's missing?


Thanks!, Nick Pelling

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Missing /dev/video[N] devices...?

[Nick Pelling]

Hi everyone,

Problem solved - the boot sequence didn't have a makedev, so the 
/dev/video[N] nodes weren't getting automatically created. A few 
mknod c X  Y commands later, all the /dev/video[N] items are in place. :-)


Cheers, Nick Pelling

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Big ptoblem with small webcam

[W.P.]

Użytkownik W.P. napisał:
 Hi there,
 I just got an Creative VGA (640x480) USB Live Webcam, VF0520.

 lsusb (partial):

 Bus 003 Device 007: ID 041e:406c Creative Technology, Ltd
 Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass  239 Miscellaneous Device
   bDeviceSubClass 2 ?
   bDeviceProtocol 1 Interface Association
   bMaxPacketSize064
   idVendor   0x041e Creative Technology, Ltd
   idProduct  0x406c
   bcdDevice   10.19
   iManufacturer   1 Creative Labs
   iProduct3 VF0520 Live! Cam Sync
   iSerial 0
   bNumConfigurations  1

 lsmod | grep vid:
 uvcvideo   50184  0
 compat_ioctl32  5120  1 uvcvideo
 videodev   32000  1 uvcvideo
 v4l1_compat15876  2 uvcvideo,videodev

 uname -a (kernel from Fedora 10):
 [root@laurent-home ~]# uname -a
 Linux laurent-home 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST
 2008 i686 athlon i386 GNU/Linux

 Problem: device nodes are created, but NO video in gmplayer, tvtime
 complains: can't open /dev/video0.

 Only trace in syslog is:

 Mar  2 16:26:56 laurent-home kernel: uvcvideo: Failed to submit URB 0 (-28).

 Webcam is connected to VIA USB 2.0 controller through a USB 2.0 hub.

 What is strange, two days ago I tried apparently the same (model VF)
 with SUCCESS.
 Device seems working in Windoze (Ekiga).

 What should I check/ do?
   

[added]
syslog with modprobe trace=65535:

Mar  2 18:24:00 laurent-home kernel: uvcvideo: Found UVC 1.00 device
VF0520 Liv
e! Cam Sync (041e:406c)
Mar  2 18:24:00 laurent-home kernel: uvcvideo: Found a valid video chain
(1 -
2).
Mar  2 18:24:00 laurent-home kernel: usbcore: registered new interface
driver u
vcvideo
Mar  2 18:24:23 laurent-home kernel: VIDIOC_QUERYCAP7uvcvideo:
uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_STD7uvcvideo:
Unsupported ioctl
 0x80085617
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_PARM7uvcvideo:
uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_ENUMSTD7uvcvideo:
Unsupported ioc
tl 0xc0405619
Mar  2 18:24:23 laurent-home kernel: VIDIOC_ENUMINPUT7uvcvideo:
uvc_v4l2_ioct
l
Mar  2 18:24:23 laurent-home kernel: VIDIOC_ENUMINPUT7uvcvideo:
uvc_v4l2_ioct
l
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_INPUT7uvcvideo:
uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_ENUM_FMT7uvcvideo:
uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_ENUM_FMT7uvcvideo:
uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_S_FMT7uvcvideo: Trying
format 0x4
7504a4d (MJPG): 640x480.
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_S_FMT7uvcvideo: Trying
format 0x3
2315659 (YV12): 640x480.
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_S_FMT7uvcvideo: Trying
format 0x3
2315559 (YU12): 640x480.
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_S_FMT7uvcvideo: Trying
format 0x5
9565955 (UYVY): 640x480.
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_S_FMT7uvcvideo: Trying
format 0x5
6595559 (YUYV): 640x480.
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_S_FMT7uvcvideo: Trying
format 0x3
4424752 (RGB4): 640x480.
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_S_FMT7uvcvideo: Trying
format 0x3
3424752 (RGB3): 640x480.
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_S_FMT7uvcvideo: Trying
format 0x5
2474210 (BGR): 640x480.
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_S_FMT7uvcvideo: Trying
format 0x5
247420f (BGR): 640x480.
Mar  2 18:24:23 laurent-home kernel: VIDIOC_ENUMINPUT7uvcvideo:
uvc_v4l2_ioct
l
Mar  2 18:24:23 laurent-home kernel: VIDIOC_S_INPUT7uvcvideo:
uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_ENUMSTD7uvcvideo:
Unsupported ioc
tl 0xc0405619
Mar  2 18:24:23 laurent-home kernel: VIDIOC_ENUMSTD7uvcvideo:
Unsupported ioc
tl 0xc0405619
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_G_FMT7uvcvideo: uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_REQBUFS7uvcvideo:
uvc_v4l2_ioctl
Mar  2 18:24:23 laurent-home kernel: VIDIOC_QUERYBUF7uvcvideo:
uvc_v4l2_mmap
Mar  2 18:24:23 laurent-home kernel: 

RE: Sony CXD2099AR support

[COEXSI]

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Ralph Metzler
 Sent: mardi 1 mars 2011 14:03
 To: Issa Gorissen
 Cc: linux-media@vger.kernel.org
 Subject: Sony CXD2099AR support
 
 Issa Gorissen writes:
   I have read that this CI chip driver is in staging because some
 questions on   how to handle it are still not answered.
  
   I volunteer to handle this one. I'm a regular java developer, but I'm
 willing   to put effort in learning linux drivers writing.
  
   So Ralph, can you give me some pointers on where the discussion
 should resume   ?
  
 
 AFAIR, the only problem was that the old sec-Device name was abused. I
 do not see a problem in just adding a cam or whatever device in dvb-
 core and use that.
 Or just rename sec since it is no longer used.
 
 Regarding the interface I think it should just remain being like a pipe.
 Using the dvr and demux devices for this just adds overhead.
 

Dear all,

I'm looking for a while the work done on the nGene driver and especially the
CI driver.
For sure, this new kind of card add a lot of flexibility as the CI is
completely independent.

I wondering if a parameter can be added to the driver in order to make the
card working like a classic one:

- Having the tuner#1 working with the CAM the classic way:

  * Keep the frontend0 device as it is for controlling the tuning parameters

  * Create the ca0 and sec0 devices attached to the CI like it is done now

  * Send the full TS stream from the demodulator unfiltered to the CI
interface (CAM usually need full TS stream for working correctly - The Multi
Transponder Decrypt advertised has a risky future with all the new
protections planed for smartcard and CAM). Is this can be done directly in
the APB7202 chip or all data has first to be retrieved by the kernel before
being send back to the CI trough sec0?

  * Create the dvr0 and demux0 devices for the sec0 output

- Having the tuner#2 working without the CAM, with its demux1, dvr1,
frontend1 devices

It may help to keep compatibility with existent DVB applications.
What do you think?

Best regards,
Sebastien.

 
 -Ralph
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-media
 in the body of a message to majord...@vger.kernel.org More majordomo
 info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v21 1/3] MFD: WL1273 FM Radio: MFD driver for the FM radio.

[Mauro Carvalho Chehab]

Em 01-03-2011 08:43, Samuel Ortiz escreveu:
 Hi Matti,
 
 On Tue, Mar 01, 2011 at 10:00:48AM +0200, Matti J. Aaltonen wrote:
 This is the core of the WL1273 FM radio driver, it connects
 the two child modules. The two child drivers are
 drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c.

 The radio-wl1273 driver implements the V4L2 interface and communicates
 with the device. The ALSA codec offers digital audio, without it only
 analog audio is available.
 
 Acked-by: Samuel Ortiz sa...@linux.intel.com
 
 Mauro, I suppose you're taking this one ?

Yes, I'm taking this patch series. As patch 1/3 didn't seem to change
between v21 and v22, I'm adding your acked-by to the v22 1/3 and committing
it on my tree.

Thanks!
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] snapshot mode, flash capabilities and control

[Guennadi Liakhovetski]

...Just occurred to me:

On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote:

 On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote:
 
  On Mon, 28 Feb 2011, Hans Verkuil wrote:
  
   Does anyone know which drivers stop capture if there are no buffers 
   available? 
   I'm not aware of any.
  
  Many soc-camera hosts do that.
  
   I think this is certainly a good initial approach.
   
   Can someone make a list of things needed for flash/snapshot? So don't 
   look yet 
   at the implementation, but just start a list of functionalities that we 
   need 
   to support. I don't think I have seen that yet.
  
  These are not the features, that we _have_ to implement, these are just 
  the ones, that are related to the snapshot mode:
  
  * flash strobe (provided, we do not want to control its timing from 
  generic controls, and leave that to reasonable defaults or to 
  private controls)

Wouldn't it be a good idea to also export an LED (drivers/leds/) API from 
our flash implementation? At least for applications like torch. Downside: 
the LED API itself is not advanced enough for all our uses, and exporting 
two interfaces to the same device is usually a bad idea. Still, 
conceptually it seems to be a good fit.

Thanks
Guennadi

  * trigger pin / command
  * external exposure
  * exposure mode (ERS, GRR,...)
  * use trigger or shutter for readout
  * number of frames to capture
 
 Add
 
 * multiple videobuffer queues
 
 to the list

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] snapshot mode, flash capabilities and control

[Hans Verkuil]

On Wednesday, March 02, 2011 18:51:43 Guennadi Liakhovetski wrote:
 ...Just occurred to me:
 
 On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote:
 
  On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote:
  
   On Mon, 28 Feb 2011, Hans Verkuil wrote:
   
Does anyone know which drivers stop capture if there are no buffers 
available? 
I'm not aware of any.
   
   Many soc-camera hosts do that.
   
I think this is certainly a good initial approach.

Can someone make a list of things needed for flash/snapshot? So don't 
look yet 
at the implementation, but just start a list of functionalities that we 
need 
to support. I don't think I have seen that yet.
   
   These are not the features, that we _have_ to implement, these are just 
   the ones, that are related to the snapshot mode:
   
   * flash strobe (provided, we do not want to control its timing from 
 generic controls, and leave that to reasonable defaults or to 
 private controls)
 
 Wouldn't it be a good idea to also export an LED (drivers/leds/) API from 
 our flash implementation? At least for applications like torch. Downside: 
 the LED API itself is not advanced enough for all our uses, and exporting 
 two interfaces to the same device is usually a bad idea. Still, 
 conceptually it seems to be a good fit.

I believe we discussed LEDs before (during a discussion about adding illuminator
controls). I think the preference was to export LEDs as V4L controls.

In general I am no fan of exporting multiple interfaces. It only leads to double
maintenance and I see no noticable advantage to userspace, only confusion.

Just my 2 cents.

Regards,

Hans

 
 Thanks
 Guennadi
 
   * trigger pin / command
   * external exposure
   * exposure mode (ERS, GRR,...)
   * use trigger or shutter for readout
   * number of frames to capture
  
  Add
  
  * multiple videobuffer queues
  
  to the list
 
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hauppauge grey remote not working in recent kernels

[Tony Houghton]

Since upgrading my kernel from 2.6.32 to 2.6.37 in Debian my DVB remote
control no longer works. The card is a Hauppauge Nova-T PCI with the
grey remote. It uses the saa7146, tda1004x, budget_ci and budget_core
modules (but it doesn't actually have a CI).

There used to be a patch for the budget_ci driver to support this model
of remote because the driver's key mappings were incorrect, but that
patch was no longer necessary from about Linux 2.6.20 onwards. Has there
been a regression or is there a new problem?

FWIW I have two cards which used the saa7146, but the other one is DVB-S
and doesn't have a remote. The one with the remote is adapter1 and the
one without is adapter0. Could that have anything to do with the
problem?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[cron job] v4l-dvb daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Wed Mar  2 19:00:28 CET 2011
git master:   1b59be2a6cdcb5a12e18d8315c07c94a624de48f
git media-master: gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: ERRORS
linux-2.6.35.3-i686: ERRORS
linux-2.6.36-i686: ERRORS
linux-2.6.37-i686: ERRORS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: ERRORS
linux-2.6.35.3-x86_64: ERRORS
linux-2.6.36-x86_64: ERRORS
linux-2.6.37-x86_64: ERRORS
spec-git: ERRORS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The V4L-DVB specification failed to build, but the last compiled spec is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge grey remote not working in recent kernels

[Jarod Wilson]

On Mar 2, 2011, at 1:14 PM, Tony Houghton wrote:

 Since upgrading my kernel from 2.6.32 to 2.6.37 in Debian my DVB remote
 control no longer works. The card is a Hauppauge Nova-T PCI with the
 grey remote. It uses the saa7146, tda1004x, budget_ci and budget_core
 modules (but it doesn't actually have a CI).
 
 There used to be a patch for the budget_ci driver to support this model
 of remote because the driver's key mappings were incorrect, but that
 patch was no longer necessary from about Linux 2.6.20 onwards. Has there
 been a regression or is there a new problem?
 
 FWIW I have two cards which used the saa7146, but the other one is DVB-S
 and doesn't have a remote. The one with the remote is adapter1 and the
 one without is adapter0. Could that have anything to do with the
 problem?

There's a pending patchset for ir-kbd-i2c and the hauppauge key tables
that should get you back in working order.


-- 
Jarod Wilson
ja...@wilsonet.com



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Missing /dev/video[N] devices...?

[Andy Walls]

Nick Pelling nickpell...@nanodome.com wrote:

Hi everyone,

I'm trying to bring up the 2.6.37 kernel from scratch on a new 
Samsung S5PC100-based board, but have hit a media problem. Though my 
various v4l2 devices are all registering OK during the boot process 
and end up visible in /sys/class/video4linux , they never manage to 
become visible in /dev , i.e.

   # ls /dev/video*
   ls: /dev/video*: No such file or directory

   # ls /sys/class/video4linux/
   video0   video1   video14  video2   video21  video22

   # ls /sys/class/video4linux/video0/
   devindex  name   subsystem  uevent

   # cat /sys/class/video4linux/video0/name
   s5p-fimc.0:m2m

   # cat /sys/class/video4linux/video0/uevent
   MAJOR=81
   MINOR=0
   DEVNAME=video0

I've tried enabling everything that seems relevant in the kernel's 
menuconfig options, but it seems as though I've omitted some crucial 
piece of the v4l2 infrastructure. Any suggestions for what's missing?

Thanks!, Nick Pelling

--
To unsubscribe from this list: send the line unsubscribe linux-media
in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I thought udev normally makes those nodes.

On embedded systems there is a different, smaller user space app responding to 
hotplug events including firmware load requests.

-Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3isp cache error when unloading

[Laurent Pinchart]

Hi Michael,

On Tuesday 01 March 2011 17:41:01 Michael Jones wrote:
 Hi all,
 
 I get a warning about a cache error with the following steps:
 
 0. load omap3-isp
 1. set up media broken media pipeline. (e.g. set different formats on
 opposite ends of a link, as will be the case for using the lane shifter)
 2. try to capture images.  isp_video_streamon() returns -EPIPE from the
 failed isp_video_validate_pipeline() call.
 3. unload omap3-isp module
 
 then I get the following from kmem_cache_destroy():
 
 slab error in kmem_cache_destroy(): cache `iovm_area_cache': Can't free all
 objects [c0040318] (unwind_backtrace+0x0/0xec) from [c00bfe14]
 (kmem_cache_destroy+0x88/0xf4) [c00bfe14] (kmem_cache_destroy+0x88/0xf4)
 from [c00861f8] (sys_delete_module+0x1c4/0x230) [c00861f8]
 (sys_delete_module+0x1c4/0x230) from [c003b680]
 (ret_fast_syscall+0x0/0x30)
 
 Then, when reloading the module:
 SLAB: cache with size 32 has lost its name
 
 Can somebody else confirm that they also observe this behavior?

I can't reproduce that (tried both 2.6.32 and 2.6.37). Could you give me some 
more details about your exact test procedure (such as how you configure the 
pipeline) ?

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3-isp: can't register subdev for new sensor driver mt9t001

[Bastian Hecht]

Hi Loic,

in my last post, make sure you return a v4l2_mbus_framefmt structure
that contain yuv 720x480. Else the framework thinks your driver cannot
supply this format. I do not know the exact enums myself, try to grep
it in the linux kernel includes.
In my test driver I added a printk(KERN_ALERT blabla); to all subdev
calls to see when the framework calls which functions.

good luck,

Bastian



2011/3/2 Loïc Akue akue.l...@gmail.com:
 Hi Bastien,

 Me again =)
 Thank you for your previous reply. I added some code, so my saa7113 drivers
 could be compatible with the new media framework.
 But I still can get some video data, from my sub-device. I saw in a mailing
 list that you had a similar issue, could you please help me on this?

 root@cm-t35:~# ./media-ctl -r -l 'saa7115 3-0024:0-OMAP3 ISP CCDC:0[1],
 OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'

 Resetting all links to inactive
 Setting up link 16:0 - 5:0 [1]
 Setting up link 5:1 - 6:0 [1]

 My first problem appears when I try to configure my pads before trying to
 capture

 
 root@cm-t35:~# ./media-ctl -f 'saa7115 3-0024:0[UYVY 720x480], OMAP3 ISP
 CCDC:2[UYVY 720x480]'

 Setting up format UYVY 720x480 on pad saa7115 3-0024/0
 Format set: UYVY 720x480
 Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/0
 Format set: SGRBG10 720x480
 Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/2
 Format set: SGRBG10 720x479

 Setting up format SGRBG10 720x479 on pad OMAP3 ISP AEWB/0
 Unable to set format: Invalid argument (-22)
 Setting up format SGRBG10 720x479 on pad OMAP3 ISP AF/0
 Unable to set format: Invalid argument (-22)
 Setting up format SGRBG10 720x479 on pad OMAP3 ISP histogram/0
 Unable to set format: Invalid argument (-22)
 
 Then, when I run this yavta command :
 
 root@cm-t35:~# ./yavta -f UYVY -s 720x480 -n 4 --capture=4 --skip 3 -F
 $(./media
 -ctl -e OMAP3 ISP CCDC output)

 Device /dev/video2 opened: OMAP3 ISP CCDC output (media).
 Video format set: width: 720 height: 480 buffer size: 691200
 Video format: UYVY (59565955) 720x480
 4 buffers requested.
 length: 691200 offset: 0
 Buffer 0 mapped at address 0x40306000.
 length: 691200 offset: 692224
 Buffer 1 mapped at address 0x40417000.
 length: 691200 offset: 1384448
 Buffer 2 mapped at address 0x404d1000.
 length: 691200 offset: 2076672
 Buffer 3 mapped at address 0x405ed000.
 Unable to start streaming: 22.
 
 And the system hangs.
 Do you have any idea where to look?

 Regards

 Loïc

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge grey remote not working in recent kernels

[Jarod Wilson]

On Mar 2, 2011, at 3:46 PM, Tony Houghton wrote:

 On Wed, 2 Mar 2011 13:39:32 -0500
 Jarod Wilson ja...@wilsonet.com wrote:
 
 On Mar 2, 2011, at 1:14 PM, Tony Houghton wrote:
 
 Since upgrading my kernel from 2.6.32 to 2.6.37 in Debian my DVB
 remote control no longer works. The card is a Hauppauge Nova-T PCI
 with the grey remote. It uses the saa7146, tda1004x, budget_ci
 and budget_core modules (but it doesn't actually have a CI).
 
 There's a pending patchset for ir-kbd-i2c and the hauppauge key tables
 that should get you back in working order.
 
 OK, thanks. Is it possible to download the patch(es) and apply it to a
 current kernel or is that a bit complicated?

Not sure how doable it is, don't recall if they're dependent on other
changes going into 2.6.38 or not. The patches are still in the
linux-media patchwork db (I'm actually merging and testing them in my
own tree tonight or tomorrow).

https://patchwork.kernel.org/project/linux-media/list/

-- 
Jarod Wilson
ja...@wilsonet.com



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] snapshot mode, flash capabilities and control

[Andy Walls]

On Wed, 2011-03-02 at 19:19 +0100, Hans Verkuil wrote:
 On Wednesday, March 02, 2011 18:51:43 Guennadi Liakhovetski wrote:
  ...Just occurred to me:
  
  On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote:
  
   On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote:
   
On Mon, 28 Feb 2011, Hans Verkuil wrote:

These are not the features, that we _have_ to implement, these are just 
the ones, that are related to the snapshot mode:

* flash strobe (provided, we do not want to control its timing from 
generic controls, and leave that to reasonable defaults or to 
private controls)

I consider a flash strobe to be an illuminator.  I modifies the subject
matter to be captured in the image.

 
  Wouldn't it be a good idea to also export an LED (drivers/leds/) API from 
  our flash implementation? At least for applications like torch. Downside: 
  the LED API itself is not advanced enough for all our uses, and exporting 
  two interfaces to the same device is usually a bad idea. Still, 
  conceptually it seems to be a good fit.
 
 I believe we discussed LEDs before (during a discussion about adding 
 illuminator
 controls). I think the preference was to export LEDs as V4L controls.

That is certainly my preference, especially for LED's integrated into
what the end user considers a discrete, consumer electronics device:
e.g. a USB connected webcam or microscope.

I cannot imagine a real use-case repurposing the flash strobe of a
camera purposes other than subject matter illumination.  (Inducing
seizures?  An intrusion detection systems alarm that doesn't use the
camera to which the flash is connected?)

For laptop frame integrated webcam LEDs, I can understand the desire to
perhaps co-opt the LED for some other indicator purpose.  A WLAN NIC
traffic indicator was suggested previously.

Does anyone know of any example where it could possibly make sense to
repurpose the LED of a discrete external camera or capture device for
some indication other than the camera/capture function?  (I consider
both extisngishing the LED for lighting purposes, and manipulating the
LED for the purpose of deception of the actual state of the
camera/capture function, still related to the camera function.)



 In general I am no fan of exporting multiple interfaces. It only leads to 
 double
 maintenance and I see no noticable advantage to userspace, only confusion.

I agree.

Regards,
Andy


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO

[Kim, HeungJun]

As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
this uvc is modified the usage of V4L2_CID_FOCUS_AUTO, maintaining v4l2 menu
index.

Signed-off-by: Heungjun Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/uvc/uvc_ctrl.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_ctrl.c 
b/drivers/media/video/uvc/uvc_ctrl.c
index 59f8a9a..064827f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] = {
{ 8, Aperture Priority Mode },
 };
 
+static struct uvc_menu_info focus_auto_controls[] = {
+   { 0, Manual Mode },
+   { 1, Auto Mode },
+};
+
 static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
__u8 query, const __u8 *data)
 {
@@ -560,8 +565,10 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.selector   = UVC_CT_FOCUS_AUTO_CONTROL,
.size   = 1,
.offset = 0,
-   .v4l2_type  = V4L2_CTRL_TYPE_BOOLEAN,
+   .v4l2_type  = V4L2_CTRL_TYPE_MENU,
.data_type  = UVC_CTRL_DATA_TYPE_BOOLEAN,
+   .menu_info  = focus_auto_controls,
+   .menu_count = ARRAY_SIZE(focus_auto_controls),
},
{
.id = V4L2_CID_IRIS_ABSOLUTE,
-- 
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH RESEND v2 3/3] v4l2-ctrls: document the changes about auto focus mode

[Kim, HeungJun]

Document about the type changes and the enumeration of the auto focus control.

Signed-off-by: Heungjun Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 Documentation/DocBook/v4l/controls.xml|   31 +---
 Documentation/DocBook/v4l/videodev2.h.xml |6 +
 2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/Documentation/DocBook/v4l/controls.xml 
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..889fa84 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1801,12 +1801,35 @@ negative values towards infinity. This is a write-only 
control./entry
  /row
  rowentry/entry/row
 
- row
+ row id=v4l2-focus-auto-type
entry 
spanname=idconstantV4L2_CID_FOCUS_AUTO/constantnbsp;/entry
-   entryboolean/entry
+   entryenumnbsp;v4l2_focus_auto_type/entry
  /rowrowentry spanname=descrEnables automatic focus
-adjustments. The effect of manual focus adjustments while this feature
-is enabled is undefined, drivers should ignore such requests./entry
+adjustments of the normal or macro or continuous(CAF) mode. The effect of
+manual focus adjustments while this feature is enabled is undefined,
+drivers should ignore such requests. Possible values are:/entry
+ /row
+ row
+   entrytbl spanname=descr cols=2
+ tbody valign=top
+   row
+ entryconstantV4L2_FOCUS_MANUAL/constantnbsp;/entry
+ entryManual focus mode./entry
+   /row
+   row
+ entryconstantV4L2_FOCUS_AUTO/constantnbsp;/entry
+ entryAuto focus mode with normal operation./entry
+   /row
+   row
+ entryconstantV4L2_FOCUS_MACRO/constantnbsp;/entry
+ entryAuto focus mode with macro operation./entry
+   /row
+   row
+ 
entryconstantV4L2_FOCUS_CONTINUOUS/constantnbsp;/entry
+ entryAuto focus mode with continuous(CAF) operation./entry
+   /row
+ /tbody
+   /entrytbl
  /row
  rowentry/entry/row
 
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml 
b/Documentation/DocBook/v4l/videodev2.h.xml
index 325b23b..ccf6c2b 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1291,6 +1291,12 @@ enum  link 
linkend=v4l2-exposure-auto-typev4l2_exposure_auto_type/link {
 #define V4L2_CID_FOCUS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+10)
 #define V4L2_CID_FOCUS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+11)
 #define V4L2_CID_FOCUS_AUTO (V4L2_CID_CAMERA_CLASS_BASE+12)
+enum  link linkend=v4l2-focus-auto-typev4l2_exposure_auto_type/link {
+   V4L2_FOCUS_MANUAL = 0,
+   V4L2_FOCUS_AUTO = 1,
+   V4L2_FOCUS_MACRO = 2,
+   V4L2_FOCUS_CONTINUOUS = 3
+};
 
 #define V4L2_CID_ZOOM_ABSOLUTE  (V4L2_CID_CAMERA_CLASS_BASE+13)
 #define V4L2_CID_ZOOM_RELATIVE  (V4L2_CID_CAMERA_CLASS_BASE+14)
-- 
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH RESEND v2 0/3] v4l2-ctrls: add new focus mode

[Kim, HeungJun]

Hello,

Agenda
==
I faced to the absence of the mode of v4l2 focus for a couple of years.
While dealing with some few mobile camera sensors, the focus modes
are needed more than the current v4l2 focus mode, e.g. a Macro 
Continuous mode. The M-5MOLS camera sensor I dealt with, also support
these 2 modes. So, I'm going to suggest supports of more detailed
v4l2 focus mode.

Version
==
This is second version patch about auto focus mode.
The second version changes are below:
1. switch enumeration value between V4L2_FOCUS_AUTO and V4L2_FOCUS_MACRO,
   for maintaing previous auto focus mode value.
2. add documentations about the changes of auto focus mode.
3. There are a little of changes since the second version submission,
   but it's not big changes as considering the patch version is up.
   So, this patch keep the previous version 2.

This RFC series of patch adds new auto focus modes, and documents it.

The first patch the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
and insert menus 4 enumerations: 

V4L2_FOCUS_MANUAL,
V4L2_FOCUS_AUTO, 
V4L2_FOCUS_MACRO,
V4L2_FOCUS_CONTINUOUS

The recent mobile camera sensors with ISP supports Macro  Continuous Auto
Focus aka CAF mode, of course normal AUTO mode, even Continuous mode.
Changing the type of V4L2_CID_FOCUS_MODE, is able to define more exact
focusing mode of camera sensor.

The second patch let the uvc driver using V4L2_CID_FOCUS_AUTO by
boolean type, be able to use the type of menu.

The third patch documentation about changes of the auto focus mode.

Thanks for reading this, and I hope any ideas and any comments.

Regards,
Heungjun Kim
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH RESEND v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type

[Kim, HeungJun]

Support more modes of autofocus, it changes the type of V4L2_CID_FOCUS_AUTO
from boolean to menu. And it includes 4 kinds of enumeration types:

V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS

Signed-off-by: Heungjun Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/v4l2-ctrls.c |   11 ++-
 include/linux/videodev2.h|6 ++
 2 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..da4aa7a 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Aperture Priority Mode,
NULL
};
+   static const char * const camera_focus_auto[] = {
+   Manual Focus,
+   Normal Auto Focus,
+   Macro Auto Focus,
+   Continuous Auto Focus,
+   NULL
+   };
static const char * const colorfx[] = {
None,
Black  White,
@@ -252,6 +259,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+   case V4L2_CID_FOCUS_AUTO:
+   return camera_focus_auto;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -416,7 +425,6 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_GOP_CLOSURE:
case V4L2_CID_MPEG_VIDEO_PULLDOWN:
case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
-   case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_PRIVACY:
case V4L2_CID_AUDIO_LIMITER_ENABLED:
case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
@@ -450,6 +458,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+   case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a94c4d5..959d59e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1374,6 +1374,12 @@ enum  v4l2_exposure_auto_type {
 #define V4L2_CID_FOCUS_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+10)
 #define V4L2_CID_FOCUS_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+11)
 #define V4L2_CID_FOCUS_AUTO(V4L2_CID_CAMERA_CLASS_BASE+12)
+enum  v4l2_focus_auto_type {
+   V4L2_FOCUS_MANUAL = 0,
+   V4L2_FOCUS_AUTO = 1,
+   V4L2_FOCUS_MACRO = 2,
+   V4L2_FOCUS_CONTINUOUS = 3
+};
 
 #define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
 #define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
-- 
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: isp or soc-camera for image co-processors

[Bhupesh SHARMA]

Hi Sakari, Laurent and Guennadi,

 -Original Message-
 From: Sakari Ailus [mailto:sakari.ai...@maxwell.research.nokia.com]
 Sent: Wednesday, March 02, 2011 4:26 PM
 To: Bhupesh SHARMA
 Cc: Laurent Pinchart; Guennadi Liakhovetski; linux-
 me...@vger.kernel.org
 Subject: Re: isp or soc-camera for image co-processors
 
 Hi Bhupesh and Laurent,
 
 Bhupesh SHARMA wrote:
 ...
  Try to configure your mailer to use spaces instead of tabs, or to
 make
  tabs 8
  spaces wide. It should then look good. Replies will usually mess the
  diagrams
  up though.
 
  Ok, I will try it :)
 
 Attachments are usually safe as well.

Please find attached a top level diagram of the system.
One thing to note here is that the soc itself has a camera
interface IP that supports ITU interface. As the co-processor
supports both ITU and CSI-2 interface, it should not be a problem
to connect the two via ITU interface.

 ...
 
  Are there are reference drivers that I can use for my study?
 
  The OMAP3 ISP driver.
 
  Thanks, I will go through the same.
 
 The major difference in this to OMAP 3 is that the OMAP 3 does have
 access to host side memory but the co-processor doesn't --- as it's a
 CSI-2 link.
 
 Additional CSI-2 receiver (and a driver for it) is required on the host
 side. This receiver likely is not dependent on the co-processor so the
 driver shouldn't be either.
 
 For example, using this co-processor should well be possible with the
 OMAP 3 ISP, in theory at least. What would be needed in this case is...
 support for multiple complex Media device drivers under a single Media
 device --- both drivers would be accessible through the same media
 device.
 
 The co-processor would mostly look like a sensor for the OMAP 3 ISP
 driver. Its internal topology would be more complex, though.
 
 Just a few ideas; what do you think of this? :-)

Yes, but I think I need to explain the system design better :
One, there is an camera interface IP within the SOC as well which 
has an internal buffer to store a line of image data and dma capabilities
to send this data to system ddr.

So, co-processor has no access to system MMU or buffers inside the main SoC,
but it has internal buffer to store data. It is connected via either a ITU or
CSI-2 interface to the SoC. This is the primary and major difference between our
architecture and OMAP 3 ISP.

As I read more the OMAP 3 TRM, I wonder whether SoC framework fits better
in our case, as we have three separate entities to consider here:
- Camera Host inside the SoC
- Camera Co-processor connected with host via CSI-2/ITU (data interface)
  and I2C/CCI (control interface)
- Camera sensor connected to the co-processor via CSI-2 (data interface)
  and I2C/CCI (control interface)
What are your views?
Guennadi can you also pitch in with your thoughts..

I fear that neither soc-camera  nor media framework have support
for 3 entities listed above, as of now.

  Unfortunately the data-sheet of the co-processor cannot be made
  public
  as of yet.
 
  Can you publish a block diagram of the co-processor internals ?
 
  I will check internally to see if I can send a block-diagram
  of the co-processor internals to you. The internals seem similar to
 
 I'd be very interested in this as well, thank you.

I have raised a request internally to enquire about the same :)

  OMAP ISP (which I can see from the public TRM). However, our
  co-processor doesn't have the circular buffer and MMU that ISP seem
 to
  have (and some other features).
 
  In the meantime I copy the features of the co-processor here for your
 review:
 
  Input / Output interfaces of co-processor:
  ==
  - Sensor interfaces: 2 x MIPI CSI-2 receivers (1 x dual-lane up to
 1.6 Gbit/s
   and 1 x single lane up to 800 Mbit/s)
  - Host interface: MIPI CSI-2 dual lane transmitter (up to 1.6 Gbit/s)
 or ITU
   (8-bit CCIR interface, up to 100 MHz) - all with independent
 variable
   transmitter clock (PLL)
  - Control interface: CCI (up to 400 kHz) or SPI
 
  Sensor support:
  ===
  - Supports two MIPI compliant sensors of up to 8 Megapixel resolution
   (one sensor streaming at a time)
  - Support for auto-focus (AF), extended depth of field (EDOF) and
 wide dynamic
   range (WDR)sensors
 
  Internal Features:
  ==
  - Versatile clock manager and internal buffer to accommodate a wide
 range of data rates
between sensors and the coprocessor and between the coprocessor and
 the host.
  - Synchronized flash gun control with red-eye reduction (pre-flash
 and main-flash strobes) for
high-power LED or Xenon strobe light
 
 Does the co-processor have internal memory or can external memory be
 attached to it for buffer storage?
 

The co-processor has no access to system MMU or buffers inside the main SoC,
but it has internal buffer to store data.

Regards,
Bhupesh
attachment: connection_diagram.JPG

Re: [RFC] snapshot mode, flash capabilities and control

[Kim, HeungJun]

Hi Guennadi,

I have another question about capture, not related with exact this topic.

Dose the sensor which you use make EXIF information in itself while capturing??

If it is right, how to deliver EXIF information from v4l2(subdev or media 
driver)
to userapplication?

Regards,
Heungjun Kim



2011-02-24 오후 9:18, Guennadi Liakhovetski 쓴 글:
 Agenda.
 ===
 
 In a recent RFC [1] I proposed V4L2 API extensions to support fast switching
 between multiple capture modes or data formats. However, this is not 
 sufficient
 to efficiently leverage snapshot capabilities of existing hardware - sensors 
 and
 SoCs, and to satisfy user-space needs, a few more functions have to be
 implemented.
 
 Snapshot and strobe / flash capabilities vary significantly between sensors.
 Some of them only capture a single image upon trigger activation, some can
 capture several images, readout and exposure capabilities vary too. Not all
 sensors support a strobe signal, and those, that support it, also offer very
 different options to select strobe beginning and duration. This proposal is
 trying to select a minimum API, that can be reasonably supported by many
 systems and provide a reasonable functionality set to the user.
 
 Proposed implementation.
 
 
 1. Switch the interface into the snapshot mode. This is required in addition 
 to
 simply configuring the interface with a different format to activate hardware-
 specific support for triggered single image capture. It is proposed to use the
 VIDIOC_S_PARM ioctl() with a new V4L2_MODE_SNAPSHOT value for the
 struct v4l2_captureparm::capturemode and ::capability fields. Further
 hardware-specific details can be passed in ::extendedmode, ::readbuffers can 
 be
 used to specify the exact number of frames to be captured. Similarly,
 VIDIOC_G_PARM shall return supported and current capture modes.
 
 Many sensors provide the ability to trigger snapshot capture either from an
 external source or from a control register. Usually, however, there is no
 possibility to select the trigger source, either of them can be used at any
 time.
 
 2. Specify a flash mode. Define new capture capabilities to be used with
 struct v4l2_captureparm::capturemode:
 
 V4L2_MODE_FLASH_SYNC  /* synchronise flash with image capture */
 V4L2_MODE_FLASH_ON/* turn on - torch-mode */
 V4L2_MODE_FLASH_OFF   /* turn off */
 
 Obviously, the above synchronous operation does not exactly define beginning 
 and
 duration of the strobe signal. It is proposed to leave the specific flash 
 timing
 configuration to the driver itself and, possibly, to driver-specific extended
 mode flags.
 
 3. Add a sensor-subdev operation
 
   int (*snapshot_trigger)(struct v4l2_subdev *sd)
 
 to start capturing the next frame in the snapshot mode.
 
 References.
 ===
 
 [1] 
 http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/29357
 
 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: isp or soc-camera for image co-processors

[Guennadi Liakhovetski]

Hi Bhupesh

On Thu, 3 Mar 2011, Bhupesh SHARMA wrote:

 Hi Sakari, Laurent and Guennadi,
 
  -Original Message-
  From: Sakari Ailus [mailto:sakari.ai...@maxwell.research.nokia.com]
  Sent: Wednesday, March 02, 2011 4:26 PM
  To: Bhupesh SHARMA
  Cc: Laurent Pinchart; Guennadi Liakhovetski; linux-
  me...@vger.kernel.org
  Subject: Re: isp or soc-camera for image co-processors
  
  Hi Bhupesh and Laurent,
  
  Bhupesh SHARMA wrote:
  ...
   Try to configure your mailer to use spaces instead of tabs, or to
  make
   tabs 8
   spaces wide. It should then look good. Replies will usually mess the
   diagrams
   up though.
  
   Ok, I will try it :)
  
  Attachments are usually safe as well.
 
 Please find attached a top level diagram of the system.
 One thing to note here is that the soc itself has a camera
 interface IP that supports ITU interface. As the co-processor
 supports both ITU and CSI-2 interface, it should not be a problem
 to connect the two via ITU interface.
 
  ...
  
   Are there are reference drivers that I can use for my study?
  
   The OMAP3 ISP driver.
  
   Thanks, I will go through the same.
  
  The major difference in this to OMAP 3 is that the OMAP 3 does have
  access to host side memory but the co-processor doesn't --- as it's a
  CSI-2 link.
  
  Additional CSI-2 receiver (and a driver for it) is required on the host
  side. This receiver likely is not dependent on the co-processor so the
  driver shouldn't be either.
  
  For example, using this co-processor should well be possible with the
  OMAP 3 ISP, in theory at least. What would be needed in this case is...
  support for multiple complex Media device drivers under a single Media
  device --- both drivers would be accessible through the same media
  device.
  
  The co-processor would mostly look like a sensor for the OMAP 3 ISP
  driver. Its internal topology would be more complex, though.
  
  Just a few ideas; what do you think of this? :-)
 
 Yes, but I think I need to explain the system design better :
 One, there is an camera interface IP within the SOC as well which 
 has an internal buffer to store a line of image data and dma capabilities
 to send this data to system ddr.
 
 So, co-processor has no access to system MMU or buffers inside the main SoC,
 but it has internal buffer to store data. It is connected via either a ITU or
 CSI-2 interface to the SoC. This is the primary and major difference between 
 our
 architecture and OMAP 3 ISP.
 
 As I read more the OMAP 3 TRM, I wonder whether SoC framework fits better
 in our case, as we have three separate entities to consider here:
   - Camera Host inside the SoC
   - Camera Co-processor connected with host via CSI-2/ITU (data interface)
 and I2C/CCI (control interface)
   - Camera sensor connected to the co-processor via CSI-2 (data interface)
 and I2C/CCI (control interface)
 What are your views?
 Guennadi can you also pitch in with your thoughts..

The soc-camera interface used to provide two things: (1) a standard API 
between camera hosts (video interfaces on SoCs) amd camera clients 
(camera sensors, TV decoders,...), and (2) a number of helper functions to 
handle format enumeration, simplify control handling (this is being 
replaced by a more generic API), and provide a bus-configuration 
framework. It also takes over file operations and a couple other common 
functions. Currently, given the v4l2-subdev API, the new control framework 
and the approaching Media Controller API there is not much left, that the 
soc-camera framework is still _adding_ to the standard v4l2 functionality, 
maybe just format enumeration and bus-parameter negotiation.

Further, soc-camera is not very well suited for multi-component designs 
with more than 2 components. It is possible, like I've done with the CSI2 
interface on sh-mobile, but you inherit the limitation of the current v4l2 
API: all these components are controlled over just one device node in the 
user-space, so, it becomes difficult to let the user configure conponents 
separately. This problem is eliminated by the Media Controller API, which 
gives you access to each subdevice separately from the user-space.

At some point in the future soc-camera will also be converted to the MC 
API, but until that's done, using it for complex designs like yours will 
remain difficult, at least because you'll only get one device node for 
your user-space applications. I think, the MC API provides more important 
advantages to your situation, than the soc-camera framework. Of course, if 
you want to use any of its functionality, feel free to become creative and 
combine the two or even do the soc-camera to MC porting yourself;)

Thanks
Guennadi

 
 I fear that neither soc-camera  nor media framework have support
 for 3 entities listed above, as of now.
 
   Unfortunately the data-sheet of the co-processor cannot be made
   public
   as of yet.
  
   Can you publish a block diagram of the 

Re: [RFC] snapshot mode, flash capabilities and control

[Guennadi Liakhovetski]

Hi

On Thu, 3 Mar 2011, Kim, HeungJun wrote:

 Hi Guennadi,
 
 I have another question about capture, not related with exact this topic.
 
 Dose the sensor which you use make EXIF information in itself while 
 capturing??

So far we have no sensors, about which we know, that they're delivering 
any metainformation with frames. There are a couple of sensors, about 
which we suspect, that a part of the image data might be some metadata, 
but we don't know for sure.

 If it is right, how to deliver EXIF information from v4l2(subdev or media 
 driver)
 to userapplication?

I don't think this is currently possible and it is among the topics to be 
discussed at the coming v4l2-summit.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html