date:20120728

Re: Advice on extending libv4l for media controller support

2012-07-28 Thread Hans de Goede


Hi,

On 07/26/2012 10:49 PM, Robert Abel wrote:

Hi,

Sorry to be late to the party... I wanted to follow up on this discussion, but 
forgot and haven't read anything about it since...

On 10.05.2012 17:09, Ivan T. Ivanov wrote:

On Wed, May 9, 2012 at 7:08 PM, Sergio Aguirre
sergio.a.agui...@gmail.com  mailto:sergio.a.agui...@gmail.com  wrote:

I want to create some sort of plugin with specific media
controller configurations,
to avoid userspace to worry about component names and specific
usecases (use sensor resizer, or SoC ISP resizer, etc.).

Probably following links can help you. They have been tested
with the OMAP3 ISP.

Regards,
iivanov

[1]http://www.spinics.net/lists/linux-media/msg31901.html
[2]
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/32704


I recently extended Yordan Kamenov's libv4l-mcplugin to support multiple trees 
per device with extended configurations (-stolen from- inspired by media-ctl) 
not tied to specific device nodes (but to device names instead).

I uploaded the patches here 
https://sites.google.com/site/rawbdagslair/libv4l-mcplugin.7z?attredirects=0d=1(16kB).
 Basically, I used Yordan's patches as a base and worked from there to fix up his source 
code and Makefile for cross-compiling using OpenEmbedded/Yocto.

There are a ton of minor issues with this, starting with the fact that I did 
not put proper copyright notices in any of these files. Please advise if this 
poses a problem.
Only integral frame size support and no support for native read() calls. 
There's a dummy read() function, because for some reason this is required in 
libv4l2 0.9.0-test though it's not mentioned anywhere. As the original plug-in 
by Yordan, there is currently no cleaning-up of the internal data structures.

I used this in conjunction with the Gumstix CASPA FS (MT9V032) camera using 
some of Laurent's patches and some custom patches which add ENUM_FMT support to 
the driver.

Basically, upon opening a given device, all trees are configured once to load 
the respective end-point's formats for emulation of setting and getting 
formats. Then regular format negotiation by the user application takes place.


As discussed higher up in this thread, since the initial libv4l-mcplugin was 
done for
the omap3, we've had several meetings on the topic of libv4l and 
media-controller using
devices and we came to the following conclusions:

1) The existing mediactl lib would be extended with a libmediactlvideo lib, 
which
would be able to control media-ctrl video chains, ie it can:
-give a list of possibly supported formats / sizes / framerates
-setup the chain to deliver a requested format
Since the optimal setup will be hardware specific the idea was to give this
libs per soc plugins, and a generic plugin for simple socs / as fallback.

2) A cmdline utility to set up a chain using libmediactlvideo, so that things
can be tested using raw devices, ie without libv4l2 coming into play, just
like apps like v4l2-ctl allow low level control mostly for testing purposes

3) There would then be a libv4l2 plugin much like the above linked omap3 plugin,
but then generic for any mediactl using video devices, which would use
libmediactlvideo to do the work of setting up the chain (and which will fail to
init when the to be opened device is not part of a mediactl controlled chain).

And AFAIK some work was done in this direction. Sakari? Laurent?

Eitherway it is about time someone started working on this, and I would
greatly prefer the above plan to be implemented. Once we have this in place,
then we can do a new v4l-utils release which officially supports the plugin
API (which currently only lives in master, not in any releases).

Regards,

Hans
--
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 PATCH 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com

2012-07-28 Thread Hans de Goede


Hi,

First of all many thanks for working on this! Note I've also taken
a quick look at the original patch with the actual implementation and that looks
good. I'm replying here because in my mind the API is the most interesting
thing to discuss.

Comments inline.

On 07/26/2012 06:21 PM, Konke Radlow wrote:

PATCH 1/2 was missing the public header for the rds library. I'm sorry for
that mistake:

diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
new file mode 100644
index 000..04843d3
--- /dev/null
+++ b/lib/include/libv4l2rds.h
@@ -0,0 +1,203 @@
+/*
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ * Author: Konke Radlow korad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA  02110-1335
USA
+ */
+
+#ifndef __LIBV4L2RDS
+#define __LIBV4L2RDS
+
+#include errno.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include stdbool.h
+#include unistd.h
+#include stdint.h
+#include sys/types.h
+#include sys/mman.h
+
+#include linux/videodev2.h
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+#if __GNUC__ = 4
+#define LIBV4L_PUBLIC __attribute__ ((visibility(default)))
+#else
+#define LIBV4L_PUBLIC
+#endif
+
+/* used to define the current version (version field) of the v4l2_rds struct */
+#define V4L2_RDS_VERSION (1)   
+
+/* Constants used to define the size of arrays used to store RDS information
*/
+#define MAX_ODA_CNT 18 /* there are 16 groups each with type a or b. 
Of these
+* 32 distinct groups, 18 can be used for ODA  
purposes*/
+#define MAX_AF_CNT 25  /* AF Method A allows a maximum of 25 AFs to be
defined
+* AF Method B does not impose a limit on the number of 
AFs
+* but it is not fully supported at the moment and will
+* not receive more than 25 AFs */
+
+/* Define Constants for the possible types of RDS information
+ * used to address the relevant bit in the valid_bitmask */
+#define V4L2_RDS_PI0x01/* Program Identification */
+#define V4L2_RDS_PTY   0x02/* Program Type */
+#define V4L2_RDS_TP0x04/* Traffic Program */
+#define V4L2_RDS_PS0x08/* Program Service Name */
+#define V4L2_RDS_TA0x10/* Traffic Announcement */
+#define V4L2_RDS_DI0x20/* Decoder Information */
+#define V4L2_RDS_MS0x40/* Music / Speech code */
+#define V4L2_RDS_PTYN  0x80/* Program Type Name */
+#define V4L2_RDS_RT0x100   /* Radio-Text */
+#define V4L2_RDS_TIME  0x200   /* Date and Time information */
+#define V4L2_RDS_TMC   0x400   /* TMC availability */
+#define V4L2_RDS_AF0x800   /* AF (alternative freq) available */
+#define V4L2_RDS_ECC   0x1000  /* Extended County Code */
+#define V4L2_RDS_LC0x2000  /* Language Code */
+
+/* Define Constants for the state of the RDS decoding process
+ * used to address the relevant bit in the state_bitmask */
+#define V4L2_RDS_GROUP_NEW 0x01/* New group received */
+#define V4L2_RDS_ODA   0x02/* Open Data Group announced */
+
+/* Decoder Information (DI) codes
+ * used to decode the DI information according to the RDS standard */
+#define V4L2_RDS_FLAG_STEREO   0x01
+#define V4L2_RDS_FLAG_ARTIFICIAL_HEAD  0x02
+#define V4L2_RDS_FLAG_COMPRESSED   0x04
+#define V4L2_RDS_FLAG_STATIC_PTY   0x08
+
+/* struct to encapsulate one complete RDS group */
+struct v4l2_rds_group {
+   uint16_t pi;
+   char group_version;
+   bool traffic_prog;
+   uint8_t group_id;
+   uint8_t pty;
+   uint8_t data_b_lsb;
+   uint8_t data_c_msb;
+   uint8_t data_c_lsb;
+   uint8_t data_d_msb;
+   uint8_t data_d_lsb;
+};
+
+/* struct to encapsulate some statistical information about the decoding
process */
+struct v4l2_rds_statistics {
+   uint32_t block_cnt;
+   uint32_t group_cnt;
+   uint32_t block_error_cnt;
+   uint32_t group_error_cnt;
+   uint32_t block_corrected_cnt;
+   uint32_t group_type_cnt[16];
+};
+
+/* struct to encapsulate the definition of one ODA (Open Data Application)
type */
+struct v4l2_rds_oda {
+   uint8_t group_id;
+   char group_version;
+   uint16_t

Re: [RFC PATCH 2/2] Initial version of RDS Control utility Signed-off-by: Konke Radlow krad...@cisco.com

2012-07-28 Thread Hans de Goede


Hi,

Overall this looks good, but some of the code, for example the set/get freq and
get/set tuner stuff seems to be a 1 on 1 copy of code from v4l2-ctrl, please
factor this out into a common file which can be shared between both
utilities (I think Hans V's recent work on splitting v4l2-ctl into multiple
files comes a long way towards this).

Regards,

Hans

On 07/25/2012 07:44 PM, Konke Radlow wrote:

---
  Makefile.am   |3 +-
  configure.ac  |1 +
  utils/rds-ctl/Makefile.am |5 +
  utils/rds-ctl/rds-ctl.cpp |  978 +
  4 files changed, 986 insertions(+), 1 deletion(-)
  create mode 100644 utils/rds-ctl/Makefile.am
  create mode 100644 utils/rds-ctl/rds-ctl.cpp

diff --git a/Makefile.am b/Makefile.am
index 6707f5f..47103a1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,7 +18,8 @@ SUBDIRS += \
utils/v4l2-compliance \
utils/v4l2-ctl \
utils/v4l2-dbg \
-   utils/v4l2-sysfs-path
+   utils/v4l2-sysfs-path \
+   utils/rds-ctl

  if LINUX_OS
  SUBDIRS += \
diff --git a/configure.ac b/configure.ac
index 1d7eb29..1ad99e6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,6 +28,7 @@ AC_CONFIG_FILES([Makefile
utils/v4l2-sysfs-path/Makefile
utils/xc3028-firmware/Makefile
utils/qv4l2/Makefile
+   utils/rds-ctl/Makefile

contrib/freebsd/Makefile
contrib/test/Makefile
diff --git a/utils/rds-ctl/Makefile.am b/utils/rds-ctl/Makefile.am
new file mode 100644
index 000..9a84257
--- /dev/null
+++ b/utils/rds-ctl/Makefile.am
@@ -0,0 +1,5 @@
+bin_PROGRAMS = rds-ctl
+
+rds_ctl_SOURCES = rds-ctl.cpp
+rds_ctl_LDADD = ../../lib/libv4l2/libv4l2.la ../../lib/libv4l2rds/libv4l2rds.la
+
diff --git a/utils/rds-ctl/rds-ctl.cpp b/utils/rds-ctl/rds-ctl.cpp
new file mode 100644
index 000..8ddb969
--- /dev/null
+++ b/utils/rds-ctl/rds-ctl.cpp
@@ -0,0 +1,978 @@
+/*
+ * rds-ctl.cpp is based on v4l2-ctl.cpp
+ *
+ * the following applies for all RDS related parts:
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ * Author: Konke Radlow korad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA  02110-1335  USA
+ */
+
+#include unistd.h
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include wchar.h
+#include locale.h
+#include inttypes.h
+#include getopt.h
+#include sys/types.h
+#include fcntl.h
+#include errno.h
+#include sys/ioctl.h
+#include sys/time.h
+#include dirent.h
+#include config.h
+#include signal.h
+
+#ifdef HAVE_SYS_KLOG_H
+#include sys/klog.h
+#endif
+
+#include linux/videodev2.h
+#include libv4l2.h
+#include libv4l2rds.h
+
+#include list
+#include vector
+#include map
+#include string
+#include algorithm
+
+#define ARRAY_SIZE(arr) ((int)(sizeof(arr) / sizeof((arr)[0])))
+
+typedef std::vectorstd::string dev_vec;
+typedef std::mapstd::string, std::string dev_map;
+
+/* Short option list
+
+   Please keep in alphabetical order.
+   That makes it easier to see which short options are still free.
+
+   In general the lower case is used to set something and the upper
+   case is used to retrieve a setting. */
+enum Option {
+   OptSetDevice = 'd',
+   OptGetDriverInfo = 'D',
+   OptGetFreq = 'F',
+   OptSetFreq = 'f',
+   OptHelp = 'h',
+   OptReadRds = 'R',
+   OptGetTuner = 'T',
+   OptSetTuner = 't',
+   OptUseWrapper = 'w',
+   OptAll = 128,
+   OptFreqSeek,
+   OptListDevices,
+   OptOpenFile,
+   OptPrintBlock,
+   OptSilent,
+   OptTunerIndex,
+   OptVerbose,
+   OptWaitLimit,
+   OptLast = 256
+};
+
+struct ctl_parameters {
+   bool terminate_decoding;
+   char options[OptLast];
+   char fd_name[80];
+   bool filemode_active;
+   double freq;
+   uint32_t wait_limit;
+   uint8_t tuner_index;
+   struct v4l2_hw_freq_seek freq_seek;
+};
+
+static struct ctl_parameters params;
+static int app_result;
+
+static struct option long_options[] = {
+   {all, no_argument, 0, OptAll},
+   {device, required_argument, 0, OptSetDevice},
+   {file, required_argument, 0, OptOpenFile},
+   {freq-seek, required_argument, 0, OptFreqSeek},
+   {get-freq, no_argument, 0, OptGetFreq},
+   {get-tuner, no_argument, 0, OptGetTuner},
+

[PATCH] Add support for the Terratec Cinergy T Dual PCIe IR remote

2012-07-28 Thread Djuri Baars

The following patch adds support for the infrared remote included in
the Terratec Cinergy T Dual PCIe card.

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

Signed-off-by: Djuri Baars dsba...@gmail.com

---
 drivers/media/video/cx23885/cx23885-cards.c |4 
 drivers/media/video/cx23885/cx23885-input.c |9 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/media/video/cx23885/cx23885-cards.c
b/drivers/media/video/cx23885/cx23885-cards.c
index 76b7563..0b80cf0 100644
--- a/drivers/media/video/cx23885/cx23885-cards.c
+++ b/drivers/media/video/cx23885/cx23885-cards.c
@@ -46,6 +46,7 @@ MODULE_PARM_DESC(enable_885_ir,
 Enable integrated IR controller for supported\n
 \t\tCX2388[57] boards that are wired for it:\n
 \t\t\tHVR-1250 (reported safe)\n
+\t\t\tTerraTec Cinergy T PCIe Dual (not well tested, appears 
to be safe)\n
 \t\t\tTeVii S470 (reported unsafe)\n
 \t\tThis can cause an interrupt storm with some cards.\n
 \t\tDefault: 0 [Disabled]);
@@ -1170,6 +1171,7 @@ int cx23885_ir_init(struct cx23885_dev *dev)
params.shutdown = true;
v4l2_subdev_call(dev-sd_ir, ir, tx_s_parameters, params);
break;
+   case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
case CX23885_BOARD_TEVII_S470:
if (!enable_885_ir)
break;
@@ -1210,6 +1212,7 @@ void cx23885_ir_fini(struct cx23885_dev *dev)
cx23888_ir_remove(dev);
dev-sd_ir = NULL;
break;
+   case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_HAUPPAUGE_HVR1250:
cx23885_irq_remove(dev, PCI_MSK_AV_CORE);
@@ -1253,6 +1256,7 @@ void cx23885_ir_pci_int_enable(struct cx23885_dev *dev)
if (dev-sd_ir)
cx23885_irq_add_enable(dev, PCI_MSK_IR);
break;
+   case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_HAUPPAUGE_HVR1250:
if (dev-sd_ir)
diff --git a/drivers/media/video/cx23885/cx23885-input.c
b/drivers/media/video/cx23885/cx23885-input.c
index ce765e3..bb1f7c8 100644
--- a/drivers/media/video/cx23885/cx23885-input.c
+++ b/drivers/media/video/cx23885/cx23885-input.c
@@ -85,6 +85,7 @@ void cx23885_input_rx_work_handler(struct
cx23885_dev *dev, u32 events)
case CX23885_BOARD_HAUPPAUGE_HVR1270:
case CX23885_BOARD_HAUPPAUGE_HVR1850:
case CX23885_BOARD_HAUPPAUGE_HVR1290:
+   case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_HAUPPAUGE_HVR1250:
/*
@@ -162,6 +163,7 @@ static int cx23885_input_ir_start(struct cx23885_dev *dev)
 */
params.invert_level = true;
break;
+   case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
case CX23885_BOARD_TEVII_S470:
/*
 * The IR controller on this board only returns pulse widths.
@@ -272,6 +274,13 @@ int cx23885_input_init(struct cx23885_dev *dev)
/* The grey Hauppauge RC-5 remote */
rc_map = RC_MAP_HAUPPAUGE;
break;
+   case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
+   /* Integrated CX23885 IR controller */
+   driver_type = RC_DRIVER_IR_RAW;
+   allowed_protos = RC_TYPE_NEC;
+   /* The grey Terratec remote with orange buttons */
+   rc_map = RC_MAP_NEC_TERRATEC_CINERGY_XS;
+   break;
case CX23885_BOARD_TEVII_S470:
/* Integrated CX23885 IR controller */
driver_type = RC_DRIVER_IR_RAW;
--
To unsubscribe from this list: send the line

Re: [PATCH] cx25840: Declare MODULE_FIRMWARE usage

2012-07-28 Thread Andy Walls

On Fri, 2012-07-27 at 06:06 -0600, Tim Gardner wrote:
 On 07/26/2012 03:59 PM, Andy Walls wrote:
  On Thu, 2012-07-26 at 10:44 -0600, Tim Gardner wrote:
  Cc: Mauro Carvalho Chehab mche...@infradead.org
  Cc: linux-media@vger.kernel.org
  Signed-off-by: Tim Gardner tim.gard...@canonical.com
  ---
drivers/media/video/cx25840/cx25840-firmware.c |   15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/media/video/cx25840/cx25840-firmware.c 
  b/drivers/media/video/cx25840/cx25840-firmware.c
  index 8150200..b3169f9 100644
  --- a/drivers/media/video/cx25840/cx25840-firmware.c
  +++ b/drivers/media/video/cx25840/cx25840-firmware.c
  @@ -61,6 +61,10 @@ static void end_fw_load(struct i2c_client *client)
 cx25840_write(client, 0x803, 0x03);
}
 
  +#define CX2388x_FIRMWARE v4l-cx23885-avcore-01.fw
  +#define CX231xx_FIRMWARE v4l-cx231xx-avcore-01.fw
  +#define CX25840_FIRMWARE v4l-cx25840.fw
  +
static const char *get_fw_name(struct i2c_client *client)
{
 struct cx25840_state *state = to_state(i2c_get_clientdata(client));
  @@ -68,10 +72,10 @@ static const char *get_fw_name(struct i2c_client 
  *client)
 if (firmware[0])
 return firmware;
 if (is_cx2388x(state))
  -  return v4l-cx23885-avcore-01.fw;
  +  return CX2388x_FIRMWARE;
 if (is_cx231xx(state))
  -  return v4l-cx231xx-avcore-01.fw;
  -  return v4l-cx25840.fw;
  +  return CX231xx_FIRMWARE;
  +  return CX25840_FIRMWARE;
}
 
static int check_fw_load(struct i2c_client *client, int size)
  @@ -164,3 +168,8 @@ int cx25840_loadfw(struct i2c_client *client)
 
 return check_fw_load(client, size);
}
  +
  +MODULE_FIRMWARE(CX2388x_FIRMWARE);
  +MODULE_FIRMWARE(CX231xx_FIRMWARE);
  +MODULE_FIRMWARE(CX25840_FIRMWARE);
  +
 
  How will the firmware attribute in the .module_info section be used?
 
  For any one model of TV capture device, the cx25840 only needs one of
  the above firmware files.  The others need not exist.
 
  I would not want anything in user or kernel space to refuse to load the
  module just because all 3 firmware files are not present.
 
  Regards,
  Andy
 
 
 The MODULE_FIRMWARE macro is purely informational. Declaring the 
 firmware files that the driver _might_ use helps me pare down the 
 external firmware package to just those files that I know it must have.

Would it help if the MODULE_FIRMWARE text was more descriptive, e.g.:

MODULE_FIRMWARE(CX25840_FIRMWARE  CX25840/1/2/3 chips only);
MODULE_FIRMWARE(CX231xx_FIRMWARE  CX23100/1/2 chips only);
MODULE_FIRMWARE(CX2388x_FIRMWARE  CX23885/7/8 chips only);

Similarly for ivtv:

MODULE_FIRMWARE(CX2341X_FIRM_ENC_FILENAME);
MODULE_FIRMWARE(CX2341X_FIRM_DEC_FILENAME  PVR-350 only);
MODULE_FIRMWARE(IVTV_DECODE_INIT_MPEG_FILENAME  PVR-350 only);

and cx18:

MODULE_FIRMWARE(FWFILE); /* v4l-cx23418-dig.fw */
MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
MODULE_FIRMWARE(CX18_APU_FIRMWARE);
MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE  Non-HVR-1600 cards);
MODULE_FIRMWARE(FWFILE  Yuan MPC-718 only);

or would that confuse some userspace tools?

  
 This patch will have no runtime impact.

OK.  For the original patch:

Acked-by: Andy Walls awa...@md.metrocast.net

Regards,
Andy

 Note that there are plenty of uses of the MODULE_FIRMWARE macro within 
 the kernel.
 
 rtg


--
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] ivtv: Declare MODULE_FIRMWARE usage

2012-07-28 Thread Andy Walls

On Fri, 2012-07-27 at 09:45 -0600, Tim Gardner wrote:
 On 07/26/2012 04:21 PM, Andy Walls wrote:
  On Thu, 2012-07-26 at 12:26 -0600, Tim Gardner wrote:
  Cc: Andy Walls awa...@md.metrocast.net
  Cc: Mauro Carvalho Chehab mche...@infradead.org
  Cc: ivtv-de...@ivtvdriver.org
  Cc: linux-media@vger.kernel.org
  Signed-off-by: Tim Gardner tim.gard...@canonical.com
  ---
   drivers/media/video/ivtv/ivtv-firmware.c |4 
   1 file changed, 4 insertions(+)
 
  diff --git a/drivers/media/video/ivtv/ivtv-firmware.c 
  b/drivers/media/video/ivtv/ivtv-firmware.c
  index 02c5ade..6ec7705 100644
  --- a/drivers/media/video/ivtv/ivtv-firmware.c
  +++ b/drivers/media/video/ivtv/ivtv-firmware.c
  @@ -396,3 +396,7 @@ int ivtv_firmware_check(struct ivtv *itv, char *where)
   
 return res;
   }
  +
  +MODULE_FIRMWARE(CX2341X_FIRM_ENC_FILENAME);
  +MODULE_FIRMWARE(CX2341X_FIRM_DEC_FILENAME);
  +MODULE_FIRMWARE(IVTV_DECODE_INIT_MPEG_FILENAME);
  
  Only the PVR-350, based on the iTVC-15/CX23415 chip, needs the
  CX2341X_FIRM_DEC_FILENAME and IVTV_DECODE_INIT_MPEG_FILENAME.  (And even
  in the case of that card, not having the IVTV_DECODE_INIT_MPEG_FILENAME
  file is non-fatal.)
  
  I would not want anything in user-space or kernel space preventing the
  ivtv module from loading, if some of those files don't exist.
  
  Regards,
  Andy
  
 
 MODULE_FIRMWARE is informational only and has no runtime impact.

OK.

Acked-by: Andy Walls awa...@md.metrocast.net

Regards,
Andy

 
 rtg


--
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 v3] cx18: Declare MODULE_FIRMWARE usage

2012-07-28 Thread Andy Walls

On Fri, 2012-07-27 at 10:45 -0600, Tim Gardner wrote:
 Cc: Andy Walls awa...@md.metrocast.net

Acked-by: Andy Walls awa...@md.metrocast.net

Regards,
Andy

 Cc: Mauro Carvalho Chehab mche...@infradead.org
 Cc: ivtv-de...@ivtvdriver.org
 Cc: linux-media@vger.kernel.org
 Signed-off-by: Tim Gardner tim.gard...@canonical.com
 ---
  drivers/media/video/cx18/cx18-av-firmware.c |2 ++
  drivers/media/video/cx18/cx18-driver.c  |1 +
  drivers/media/video/cx18/cx18-dvb.c |6 +-
  drivers/media/video/cx18/cx18-firmware.c|   10 --
  4 files changed, 16 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/media/video/cx18/cx18-av-firmware.c 
 b/drivers/media/video/cx18/cx18-av-firmware.c
 index 280aa4d..a34fd08 100644
 --- a/drivers/media/video/cx18/cx18-av-firmware.c
 +++ b/drivers/media/video/cx18/cx18-av-firmware.c
 @@ -221,3 +221,5 @@ int cx18_av_loadfw(struct cx18 *cx)
   release_firmware(fw);
   return 0;
  }
 +
 +MODULE_FIRMWARE(FWFILE);
 diff --git a/drivers/media/video/cx18/cx18-driver.c 
 b/drivers/media/video/cx18/cx18-driver.c
 index 7e5ffd6..c67733d 100644
 --- a/drivers/media/video/cx18/cx18-driver.c
 +++ b/drivers/media/video/cx18/cx18-driver.c
 @@ -1357,3 +1357,4 @@ static void __exit module_cleanup(void)
  
  module_init(module_start);
  module_exit(module_cleanup);
 +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
 diff --git a/drivers/media/video/cx18/cx18-dvb.c 
 b/drivers/media/video/cx18/cx18-dvb.c
 index f41922b..3eac59c 100644
 --- a/drivers/media/video/cx18/cx18-dvb.c
 +++ b/drivers/media/video/cx18/cx18-dvb.c
 @@ -40,6 +40,8 @@
  
  DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
  
 +#define FWFILE dvb-cx18-mpc718-mt352.fw
 +
  #define CX18_REG_DMUX_NUM_PORT_0_CONTROL 0xd5a000
  #define CX18_CLOCK_ENABLE20xc71024
  #define CX18_DMUX_CLK_MASK0x0080
 @@ -135,7 +137,7 @@ static int yuan_mpc718_mt352_reqfw(struct cx18_stream 
 *stream,
  const struct firmware **fw)
  {
   struct cx18 *cx = stream-cx;
 - const char *fn = dvb-cx18-mpc718-mt352.fw;
 + const char *fn = FWFILE;
   int ret;
  
   ret = request_firmware(fw, fn, cx-pci_dev-dev);
 @@ -603,3 +605,5 @@ static int dvb_register(struct cx18_stream *stream)
  
   return ret;
  }
 +
 +MODULE_FIRMWARE(FWFILE);
 diff --git a/drivers/media/video/cx18/cx18-firmware.c 
 b/drivers/media/video/cx18/cx18-firmware.c
 index b85c292..a1c1cec 100644
 --- a/drivers/media/video/cx18/cx18-firmware.c
 +++ b/drivers/media/video/cx18/cx18-firmware.c
 @@ -376,6 +376,9 @@ void cx18_init_memory(struct cx18 *cx)
   cx18_write_reg(cx, 0x0101, CX18_WMB_CLIENT14);  /* AVO */
  }
  
 +#define CX18_CPU_FIRMWARE v4l-cx23418-cpu.fw
 +#define CX18_APU_FIRMWARE v4l-cx23418-apu.fw
 +
  int cx18_firmware_init(struct cx18 *cx)
  {
   u32 fw_entry_addr;
 @@ -400,7 +403,7 @@ int cx18_firmware_init(struct cx18 *cx)
   cx18_sw1_irq_enable(cx, IRQ_CPU_TO_EPU | IRQ_APU_TO_EPU);
   cx18_sw2_irq_enable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
  
 - sz = load_cpu_fw_direct(v4l-cx23418-cpu.fw, cx-enc_mem, cx);
 + sz = load_cpu_fw_direct(CX18_CPU_FIRMWARE, cx-enc_mem, cx);
   if (sz = 0)
   return sz;
  
 @@ -408,7 +411,7 @@ int cx18_firmware_init(struct cx18 *cx)
   cx18_init_scb(cx);
  
   fw_entry_addr = 0;
 - sz = load_apu_fw_direct(v4l-cx23418-apu.fw, cx-enc_mem, cx,
 + sz = load_apu_fw_direct(CX18_APU_FIRMWARE, cx-enc_mem, cx,
   fw_entry_addr);
   if (sz = 0)
   return sz;
 @@ -451,3 +454,6 @@ int cx18_firmware_init(struct cx18 *cx)
   cx18_write_reg_expect(cx, 0x14001400, 0xc78110, 0x1400, 0x14001400);
   return 0;
  }
 +
 +MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
 +MODULE_FIRMWARE(CX18_APU_FIRMWARE);


--
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: media_tree daily build: ERRORS

2012-07-28 Thread Hans Verkuil

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

Results of the daily build of media_tree:

date:Sat Jul 28 19:00:20 CEST 2012
git hash:931efdf58bd83af8d0578a6cc53421675daf6d41
gcc version:  i686-linux-gcc (GCC) 4.7.1
host hardware:x86_64
host os:  3.4.07-marune

linux-git-arm-eabi-davinci: ERRORS
linux-git-arm-eabi-exynos: OK
linux-git-arm-eabi-omap: 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-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-x86_64: WARNINGS
linux-3.4-x86_64: WARNINGS
linux-3.5-x86_64: ERRORS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2.1-i686: WARNINGS
linux-3.3-i686: WARNINGS
linux-3.4-i686: WARNINGS
linux-3.5-i686: ERRORS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build 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: [PATCH v2] mt9v032: Export horizontal and vertical blanking as V4L2 controls

2012-07-28 Thread Laurent Pinchart

Hi Sakari,

On Saturday 28 July 2012 00:27:23 Sakari Ailus wrote:
 On Fri, Jul 27, 2012 at 01:02:04AM +0200, Laurent Pinchart wrote:
  On Thursday 26 July 2012 23:54:01 Sakari Ailus wrote:
   On Tue, Jul 24, 2012 at 01:10:42AM +0200, Laurent Pinchart wrote:
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---

 drivers/media/video/mt9v032.c |   36  ---
 1 files changed, 33 insertions(+), 3 deletions(-)

Changes since v1:

- Make sure the total horizontal time will not go below 660 when
  setting the horizontal blanking control

- Restrict the vertical blanking value to 3000 as documented in the
  datasheet. Increasing the exposure time actually extends vertical
  blanking, as long as the user doesn't forget to turn auto-exposure
  off...
   
   Does binning either horizontally or vertically affect the blanking
   limits? If the process is analogue then the answer is typically yes.
  
  The datasheet doesn't specify whether binning and blanking can influence
  each other.
 
 Vertical binning is often analogue since digital binning would require as
 much temporary memory as the row holds pixels. This means the hardware
 already does binning before a/d conversion and there's only need to actually
 read half the number of rows, hence the effect on frame length.

That will affect the frame length, but why would it affect vertical blanking ?

   It's not directly related to this patch, but the effect of the driver
   just exposing one sub-device really shows better now. Besides lacking
   the way to specify binning as in the V4L2 subdev API (compose selection
   target), the user also can't use the crop bounds selection target to get
   the size of the pixel array.
   
   We could either accept this for the time being and fix it later on of
   fix it now.
   
   I prefer fixing it right now but admit that this patch isn't breaking
   anything, it rather is missing quite relevant functionality to control
   the sensor in a generic way.
  
  I'd rather apply this patch first, as it doesn't break anything :-) Fixing
  the problem will require discussions, and that will take time.
 
 How so? There's nothing special in this sensor as far as I can see.
 
  Binning/skipping is a pretty common feature in sensors. Exposing two sub-
  devices like the SMIA++ driver does is one way to fix the problem, but do
  we really want to do that for the vast majority of sensors ?
 
 If we want to expose the sensor's functionality using the V4L2 subdev API
 and not a sensor specific API, the answer is yes. The bottom line is that
 we have just one API to configure scaling and cropping and that API
 (selections) is the same independently of where the operation is being
 performed; whether it's the sensor or the ISP.

If we want to expose two subdevices for every sensor we will need to get both 
kernelspace (ISP drivers) and userspace ready for this. I'm not against the 
idea, but we need to plan it properly.

-- 
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: Advice on extending libv4l for media controller support

2012-07-28 Thread Laurent Pinchart

Hi Hans,

On Saturday 28 July 2012 12:46:35 Hans de Goede wrote:
 On 07/26/2012 10:49 PM, Robert Abel wrote:
  Sorry to be late to the party... I wanted to follow up on this discussion,
  but forgot and haven't read anything about it since... 
  On 10.05.2012 17:09, Ivan T. Ivanov wrote:
  On Wed, May 9, 2012 at 7:08 PM, Sergio Aguirre
  
  sergio.a.agui...@gmail.com  mailto:sergio.a.agui...@gmail.com  wrote:
  I want to create some sort of plugin with specific media
  controller configurations,
  to avoid userspace to worry about component names and specific
  usecases (use sensor resizer, or SoC ISP resizer, etc.).
  
  Probably following links can help you. They have been tested
  with the OMAP3 ISP.
  
  Regards,
  iivanov
  
  [1]http://www.spinics.net/lists/linux-media/msg31901.html
  [2]
  http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/
  32704 
  I recently extended Yordan Kamenov's libv4l-mcplugin to support multiple
  trees per device with extended configurations (-stolen from- inspired by
  media-ctl) not tied to specific device nodes (but to device names
  instead).
  
  I uploaded the patches here
  https://sites.google.com/site/rawbdagslair/libv4l-mcplugin.7z?attredirec
  ts=0d=1(16kB). Basically, I used Yordan's patches as a base and worked
  from there to fix up his source code and Makefile for cross-compiling
  using OpenEmbedded/Yocto.
  
  There are a ton of minor issues with this, starting with the fact that I
  did not put proper copyright notices in any of these files. Please advise
  if this poses a problem. Only integral frame size support and no support
  for native read() calls. There's a dummy read() function, because for
  some reason this is required in libv4l2 0.9.0-test though it's not
  mentioned anywhere. As the original plug-in by Yordan, there is currently
  no cleaning-up of the internal data structures.
  
  I used this in conjunction with the Gumstix CASPA FS (MT9V032) camera
  using some of Laurent's patches and some custom patches which add
  ENUM_FMT support to the driver.
  
  Basically, upon opening a given device, all trees are configured once to
  load the respective end-point's formats for emulation of setting and
  getting formats. Then regular format negotiation by the user application
  takes place.
 As discussed higher up in this thread, since the initial libv4l-mcplugin was
 done for the omap3, we've had several meetings on the topic of libv4l and
 media-controller using devices and we came to the following conclusions:
 
 1) The existing mediactl lib would be extended with a libmediactlvideo lib,
 which would be able to control media-ctrl video chains, ie it can:
 -give a list of possibly supported formats / sizes / framerates
 -setup the chain to deliver a requested format
 Since the optimal setup will be hardware specific the idea was to give this
 libs per soc plugins, and a generic plugin for simple socs / as fallback.
 
 2) A cmdline utility to set up a chain using libmediactlvideo, so that
 things can be tested using raw devices, ie without libv4l2 coming into
 play, just like apps like v4l2-ctl allow low level control mostly for
 testing purposes
 
 3) There would then be a libv4l2 plugin much like the above linked omap3
 plugin, but then generic for any mediactl using video devices, which would
 use libmediactlvideo to do the work of setting up the chain (and which will
 fail to init when the to be opened device is not part of a mediactl
 controlled chain).
 
 And AFAIK some work was done in this direction. Sakari? Laurent?

I'm currently in a plane to Finland to work on this with Sakari next week. You 
should hopefully hear from us soon :-)

 Eitherway it is about time someone started working on this, and I would
 greatly prefer the above plan to be implemented. Once we have this in place,
 then we can do a new v4l-utils release which officially supports the plugin
 API (which currently only lives in master, not in any releases).

-- 
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

[PATCH 1/1] [media] uvcvideo: Add 10,12bit and alternate 8bit greyscale

2012-07-28 Thread Stefan Muenzel

Some cameras support 10bit and 12bit greyscale, or use the alternate Y8
 FOURCC for 8bit greyscale. Add support for these.

Tested on a 12bit camera.

Signed-off-by: Stefan Muenzel stefanmuen...@googlemail.com
---
 drivers/media/video/uvc/uvc_driver.c |   19 +--
 drivers/media/video/uvc/uvcvideo.h   |9 +
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/uvc/uvc_driver.c 
b/drivers/media/video/uvc/uvc_driver.c
index 1d13172..11db262 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -95,12 +95,27 @@ static struct uvc_format_desc uvc_fmts[] = {
.fcc= V4L2_PIX_FMT_UYVY,
},
{
-   .name   = Greyscale (8-bit),
+   .name   = Greyscale 8-bit (Y800),
.guid   = UVC_GUID_FORMAT_Y800,
.fcc= V4L2_PIX_FMT_GREY,
},
{
-   .name   = Greyscale (16-bit),
+   .name   = Greyscale 8-bit (Y8  ),
+   .guid   = UVC_GUID_FORMAT_Y8,
+   .fcc= V4L2_PIX_FMT_GREY,
+   },
+   {
+   .name   = Greyscale 10-bit (Y10 ),
+   .guid   = UVC_GUID_FORMAT_Y10,
+   .fcc= V4L2_PIX_FMT_Y10,
+   },
+   {
+   .name   = Greyscale 12-bit (Y12 ),
+   .guid   = UVC_GUID_FORMAT_Y12,
+   .fcc= V4L2_PIX_FMT_Y12,
+   },
+   {
+   .name   = Greyscale 16-bit (Y16 ),
.guid   = UVC_GUID_FORMAT_Y16,
.fcc= V4L2_PIX_FMT_Y16,
},
diff --git a/drivers/media/video/uvc/uvcvideo.h 
b/drivers/media/video/uvc/uvcvideo.h
index 7c3d082..3764040 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -79,6 +79,15 @@
 #define UVC_GUID_FORMAT_Y800 \
{ 'Y',  '8',  '0',  '0', 0x00, 0x00, 0x10, 0x00, \
 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_Y8 \
+   { 'Y',  '8',  ' ',  ' ', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_Y10 \
+   { 'Y',  '1',  '0',  ' ', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_Y12 \
+   { 'Y',  '1',  '2',  ' ', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
 #define UVC_GUID_FORMAT_Y16 \
{ 'Y',  '1',  '6',  ' ', 0x00, 0x00, 0x10, 0x00, \
 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
-- 
1.7.10.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

[PATCH RFC] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats

2012-07-28 Thread Ilyes Gouta

Define the two new V4L2_PIX_FMT_NV16M (4:2:2 two-buffers) and 
V4L2_PIX_FMT_NV24M (4:4:4 two-buffers)
pixel formats, the non-contiguous variants of the existing V4L2_PIX_FMT_NV16 
and V4L2_PIX_FMT_NV24 formats.

Existing h/w IPs, such as decoders, operate on such separate luma and chroma 
buffers.

Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 166 +
 Documentation/DocBook/media/v4l/pixfmt-nv24m.xml | 182 +++
 Documentation/DocBook/media/v4l/pixfmt.xml   |   2 +
 include/linux/videodev2.h|   2 +
 4 files changed, 352 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24m.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml 
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..76e48bf
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,166 @@
+refentry id=V4L2-PIX-FMT-NV16M
+  refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16')/refentrytitle
+   manvol;
+  /refmeta
+  refnamediv
+ refname constantV4L2_PIX_FMT_NV16M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV16/constant with 
planes
+ non contiguous in memory. /refpurpose
+  /refnamediv
+  refsect1
+   titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:2 format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs from 
constantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the 
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per 
pixel.
+In the second plane there is a chrominance data with alternating chroma 
samples.
+The CbCr plane has the same width and height, in bytes, as the Y plane (and of 
the image).
+Each CbCr pair belongs to two pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Ysubscript00/subscript, Y'subscript01/subscript. /para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+   paraIf the Y plane has pad bytes after each row, then the
+CbCr plane has as many pad bytes after its rows./para
+
+   example
+   titleconstantV4L2_PIX_FMT_NV16M/constant 4 times; 4 pixel 
image/title
+
+ formalpara
+   titleByte Order./title
+   paraEach cell is one byte.
+   informaltable frame=none
+   tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+   row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+   /row
+   row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+   /row
+   row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+   /row
+   row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+   /row
+   row
+ entry/entry
+   /row
+   row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+   /row
+   row
+ entrystart1nbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+   /row
+

Re: [PATCH 1/1] [media] uvcvideo: Add 10,12bit and alternate 8bit greyscale

2012-07-28 Thread Laurent Pinchart

Hi Stefan,

Thanks for the patch.

On Saturday 28 July 2012 18:49:14 Stefan Muenzel wrote:
 Some cameras support 10bit and 12bit greyscale, or use the alternate Y8
  FOURCC for 8bit greyscale. Add support for these.

Could you please tell me which camera(s) use those formats ?

 Tested on a 12bit camera.
 
 Signed-off-by: Stefan Muenzel stefanmuen...@googlemail.com
 ---
  drivers/media/video/uvc/uvc_driver.c |   19 +--
  drivers/media/video/uvc/uvcvideo.h   |9 +
  2 files changed, 26 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/video/uvc/uvc_driver.c
 b/drivers/media/video/uvc/uvc_driver.c index 1d13172..11db262 100644
 --- a/drivers/media/video/uvc/uvc_driver.c
 +++ b/drivers/media/video/uvc/uvc_driver.c
 @@ -95,12 +95,27 @@ static struct uvc_format_desc uvc_fmts[] = {
   .fcc= V4L2_PIX_FMT_UYVY,
   },
   {
 - .name   = Greyscale (8-bit),
 + .name   = Greyscale 8-bit (Y800),
   .guid   = UVC_GUID_FORMAT_Y800,
   .fcc= V4L2_PIX_FMT_GREY,
   },
   {
 - .name   = Greyscale (16-bit),
 + .name   = Greyscale 8-bit (Y8  ),
 + .guid   = UVC_GUID_FORMAT_Y8,
 + .fcc= V4L2_PIX_FMT_GREY,
 + },
 + {
 + .name   = Greyscale 10-bit (Y10 ),
 + .guid   = UVC_GUID_FORMAT_Y10,
 + .fcc= V4L2_PIX_FMT_Y10,
 + },
 + {
 + .name   = Greyscale 12-bit (Y12 ),
 + .guid   = UVC_GUID_FORMAT_Y12,
 + .fcc= V4L2_PIX_FMT_Y12,
 + },
 + {
 + .name   = Greyscale 16-bit (Y16 ),
   .guid   = UVC_GUID_FORMAT_Y16,
   .fcc= V4L2_PIX_FMT_Y16,
   },
 diff --git a/drivers/media/video/uvc/uvcvideo.h
 b/drivers/media/video/uvc/uvcvideo.h index 7c3d082..3764040 100644
 --- a/drivers/media/video/uvc/uvcvideo.h
 +++ b/drivers/media/video/uvc/uvcvideo.h
 @@ -79,6 +79,15 @@
  #define UVC_GUID_FORMAT_Y800 \
   { 'Y',  '8',  '0',  '0', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
 +#define UVC_GUID_FORMAT_Y8 \
 + { 'Y',  '8',  ' ',  ' ', 0x00, 0x00, 0x10, 0x00, \
 +  0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
 +#define UVC_GUID_FORMAT_Y10 \
 + { 'Y',  '1',  '0',  ' ', 0x00, 0x00, 0x10, 0x00, \
 +  0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
 +#define UVC_GUID_FORMAT_Y12 \
 + { 'Y',  '1',  '2',  ' ', 0x00, 0x00, 0x10, 0x00, \
 +  0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
  #define UVC_GUID_FORMAT_Y16 \
   { 'Y',  '1',  '6',  ' ', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}

-- 
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: Advice on extending libv4l for media controller support

Re: [RFC PATCH 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com

Re: [RFC PATCH 2/2] Initial version of RDS Control utility Signed-off-by: Konke Radlow krad...@cisco.com

[PATCH] Add support for the Terratec Cinergy T Dual PCIe IR remote

Re: [PATCH] cx25840: Declare MODULE_FIRMWARE usage

Re: [PATCH] ivtv: Declare MODULE_FIRMWARE usage

Re: [PATCH v3] cx18: Declare MODULE_FIRMWARE usage

cron job: media_tree daily build: ERRORS

Re: [PATCH v2] mt9v032: Export horizontal and vertical blanking as V4L2 controls

Re: Advice on extending libv4l for media controller support

[PATCH 1/1] [media] uvcvideo: Add 10,12bit and alternate 8bit greyscale

[PATCH RFC] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats

Re: [PATCH 1/1] [media] uvcvideo: Add 10,12bit and alternate 8bit greyscale

13 matches

Site Navigation

Mail list logo

Footer information