Re: RFCl libv4l2 plugin API
Hi Sakari, On 10/28/2010 08:30 AM, Hans de Goede wrote: Hans de Goede wrote: Hi All, Hi Hans, Thanks for the RFC! I'd have a few comments and questions. The coding style for libv4l hasn't been defined as far as I understand. Should kernel coding style be assumed, or something else? v4l-utils uses kernel coding style. RFC: a plugin API for libv4l2 = During the Plumbers conference in 2009 various parties expresse interest in adding a plugin API to libv4l2. Some hardware can do some processing steps in hardware, but this needs to be setup from userspace and sometimes still need some regulation from userspace as streaming happens, hardware specific libv4l2 plugins could be a solution here. During the v4l summit in Helsinki this was discussed further and a simple and very generic plugin API was pitched. This is a first draft specification for this API. Basic libv4l2 principles The basic unit libv4l2's API deals with is a /dev/video node represented by a fd. A libv4l2 plugin will sit in between libv4l2 itself and the actual /dev/video device node a fd refers to. It will be called each time libv4l2 wants to do an operation (read/write/ioctl/mmap/munmap) on the actual /dev/video node in question. When called the plugin can then choose to do one of the following: 1. Pass the call unmodified to the fd, and return the return value unmodifed (iow do nothing) 2. Modify some arguments in the call and pass it through 3. Modify the return(ed) value(s) of a passed through call 4. Not do any operation on the fd at all but instead completely fake it (which opens the possibility for fake v4l devices) Note that: 1. A plugin may decide between 1. - 4. on a per call basis depending on the operations arguments and / or state. This esp. is important with the ioctl operation where a plugin may want to intercept some ioctls but not all 2. If a plugin always wants to pass all calls through for a certain operation, it is allowed to simply not define a callback function for that operation 3. As libv4l2 does some faking itself esp. when it comes to format conversion a single libv4l2 call may result in multiple calls to the plugin, or to none at all. So to summarize the above: Anything goes :) Plugin internal data bound to file descriptors make probably sense for webcams, but we can have more complex setups than that. For example the OMAP 3 ISP driver. Several video nodes may be used to capture video, and there are dependencies between the nodes. Essentially this kind of plugin can handle one media device at a time, not a V4L2 device. For webcams etc. this would still be the same since libv4l isn't aware of media devices. However, the application is a V4L2 application which works on V4L2 devices and may well be unaware of the media device. I don't think this is _necessarily_ a problem since the plugin can do whatever it sees fit for user's request; it could even open another video node. Yes this is the whole idea, the app uses just one video node, like with any regular v4l device, and then the plugin can open video nodes for sub-devices to hook up all the plumbing to get a pipeline which does what the app wants. For example, there is likely one device node a general purpose application is interested in in the OMAP 3 ISP driver. Right. Obviously, there can be only one of this kind of media device control plugins at a time. Other plugins should have their say before that, so that the device appears a regular V4L2 device for those plugins as well. The current design (the RFC) assumes only one plugin per /dev/video# device, so no stacking of plugins on the same fd. It is possible to have multiple plugins, but only one will get attached to a certain fd. The idea here is that plugins are meant for doing certain hardware specific stuff. And different /dev/video# nodes could relate to completely different hardware, so we do need multiple plugins to support this. But as the purpose of the plugins is to deal with certain hardware specific things, having one plugin per type of hardware seems enough. The order in which the plugins are executed matters also if they do image processing. The result may well be different. As said, there can only be one plugin per fd. Perhaps it'd be good to experiment with one plugin per device first? :-) Right, well one plugin per fd, as libv4l does everything at the fd level. Note that currently besides this RFC the plugin support is completely vaporware but it should be quite easy to implement the RFC, patches welcome :) 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
[RFCv2/PATCH 2/5] vpif: Consolidate formats from capture and display
From: Mats Randgaard mats.randga...@tandberg.com
- The ch_params tables in vpif_capture.c and vpif_display.c are moved to a
common
table in vpif.c. Then it is easier to maintain the table.
- The field fps is removed from the struct vpif_channel_config_params because
it
is not used.
Signed-off-by: Mats Randgaard mats.randga...@tandberg.com
Signed-off-by: Hans Verkuil hans.verk...@tandberg.com
Acked-by : Murali Karicheri mkarich...@gmail.com
---
drivers/media/video/davinci/vpif.c | 50
drivers/media/video/davinci/vpif.h |4 ++-
drivers/media/video/davinci/vpif_capture.c | 18 +-
drivers/media/video/davinci/vpif_display.c | 17 ++
4 files changed, 58 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
index 1f532e3..54cc0da 100644
--- a/drivers/media/video/davinci/vpif.c
+++ b/drivers/media/video/davinci/vpif.c
@@ -41,6 +41,56 @@ spinlock_t vpif_lock;
void __iomem *vpif_base;
+/**
+ * ch_params: video standard configuration parameters for vpif
+ * The table must include all presets from supported subdevices.
+ */
+const struct vpif_channel_config_params ch_params[] = {
+ /* SDTV formats */
+ {
+ .name = NTSC_M,
+ .width = 720,
+ .height = 480,
+ .frm_fmt = 0,
+ .ycmux_mode = 1,
+ .eav2sav = 268,
+ .sav2eav = 1440,
+ .l1 = 1,
+ .l3 = 23,
+ .l5 = 263,
+ .l7 = 266,
+ .l9 = 286,
+ .l11 = 525,
+ .vsize = 525,
+ .capture_format = 0,
+ .vbi_supported = 1,
+ .hd_sd = 0,
+ .stdid = V4L2_STD_525_60,
+ },
+ {
+ .name = PAL_BDGHIK,
+ .width = 720,
+ .height = 576,
+ .frm_fmt = 0,
+ .ycmux_mode = 1,
+ .eav2sav = 280,
+ .sav2eav = 1440,
+ .l1 = 1,
+ .l3 = 23,
+ .l5 = 311,
+ .l7 = 313,
+ .l9 = 336,
+ .l11 = 624,
+ .vsize = 625,
+ .capture_format = 0,
+ .vbi_supported = 1,
+ .hd_sd = 0,
+ .stdid = V4L2_STD_625_50,
+ },
+};
+
+const unsigned int vpif_ch_params_count = ARRAY_SIZE(ch_params);
+
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
if (val)
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index 188841b..940c30f 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -577,7 +577,6 @@ struct vpif_channel_config_params {
char name[VPIF_MAX_NAME]; /* Name of the mode */
u16 width; /* Indicates width of the image */
u16 height; /* Indicates height of the image */
- u8 fps;
u8 frm_fmt; /* Indicates whether this is interlaced
* or progressive format */
u8 ycmux_mode; /* Indicates whether this mode requires
@@ -594,6 +593,9 @@ struct vpif_channel_config_params {
v4l2_std_id stdid;
};
+extern const unsigned int vpif_ch_params_count;
+extern const struct vpif_channel_config_params ch_params[];
+
struct vpif_video_params;
struct vpif_params;
struct vpif_vbi_params;
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index 3b5c98b..4768f79 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -82,20 +82,6 @@ static struct vpif_device vpif_obj = { {NULL} };
static struct device *vpif_dev;
/**
- * ch_params: video standard configuration parameters for vpif
- */
-static const struct vpif_channel_config_params ch_params[] = {
- {
- NTSC_M, 720, 480, 30, 0, 1, 268, 1440, 1, 23, 263, 266,
- 286, 525, 525, 0, 1, 0, V4L2_STD_525_60,
- },
- {
- PAL_BDGHIK, 720, 576, 25, 0, 1, 280, 1440, 1, 23, 311, 313,
- 336, 624, 625, 0, 1, 0, V4L2_STD_625_50,
- },
-};
-
-/**
* vpif_uservirt_to_phys : translate user/virtual address to phy address
* @virtp: user/virtual address
*
@@ -444,7 +430,7 @@ static int vpif_update_std_info(struct channel_obj *ch)
std_info = vpifparams-std_info;
- for (index = 0; index ARRAY_SIZE(ch_params); index++) {
+ for (index = 0; index vpif_ch_params_count; index++) {
config = ch_params[index];
if (config-stdid vid_ch-stdid) {
memcpy(std_info, config, sizeof(*config));
@@ -453,7 +439,7 @@ static int vpif_update_std_info(struct channel_obj *ch)
}
/* standard not found */
- if (index
[RFCv2/PATCH 3/5] vpif_cap/disp: Add support for DV presets
From: Mats Randgaard mats.randga...@tandberg.com
- Added functions to set/get/query/enum DV presets for vpif_caputre and
vpif_display.
- The format specification table is extended with all the DV formats supportet
by TVP7002.
support DV formats.
Signed-off-by: Mats Randgaard mats.randga...@tandberg.com
Signed-off-by: Hans Verkuil hans.verk...@tandberg.com
---
drivers/media/video/davinci/vpif.c | 127
drivers/media/video/davinci/vpif.h |1 +
drivers/media/video/davinci/vpif_capture.c | 124 ++-
drivers/media/video/davinci/vpif_capture.h |1 +
drivers/media/video/davinci/vpif_display.c | 105 ++--
drivers/media/video/davinci/vpif_display.h |1 +
6 files changed, 350 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
index 54cc0da..9f3bfc1 100644
--- a/drivers/media/video/davinci/vpif.c
+++ b/drivers/media/video/davinci/vpif.c
@@ -46,6 +46,133 @@ void __iomem *vpif_base;
* The table must include all presets from supported subdevices.
*/
const struct vpif_channel_config_params ch_params[] = {
+ /* HDTV formats */
+ {
+ .name = 480p59_94,
+ .width = 720,
+ .height = 480,
+ .frm_fmt = 1,
+ .ycmux_mode = 0,
+ .eav2sav = 138-8,
+ .sav2eav = 720,
+ .l1 = 1,
+ .l3 = 43,
+ .l5 = 523,
+ .vsize = 525,
+ .capture_format = 0,
+ .vbi_supported = 0,
+ .hd_sd = 1,
+ .dv_preset = V4L2_DV_480P59_94,
+ },
+ {
+ .name = 576p50,
+ .width = 720,
+ .height = 576,
+ .frm_fmt = 1,
+ .ycmux_mode = 0,
+ .eav2sav = 144-8,
+ .sav2eav = 720,
+ .l1 = 1,
+ .l3 = 45,
+ .l5 = 621,
+ .vsize = 625,
+ .capture_format = 0,
+ .vbi_supported = 0,
+ .hd_sd = 1,
+ .dv_preset = V4L2_DV_576P50,
+ },
+ {
+ .name = 720p50,
+ .width = 1280,
+ .height = 720,
+ .frm_fmt = 1,
+ .ycmux_mode = 0,
+ .eav2sav = 700-8,
+ .sav2eav = 1280,
+ .l1 = 1,
+ .l3 = 26,
+ .l5 = 746,
+ .vsize = 750,
+ .capture_format = 0,
+ .vbi_supported = 0,
+ .hd_sd = 1,
+ .dv_preset = V4L2_DV_720P50,
+ },
+ {
+ .name = 720p60,
+ .width = 1280,
+ .height = 720,
+ .frm_fmt = 1,
+ .ycmux_mode = 0,
+ .eav2sav = 370 - 8,
+ .sav2eav = 1280,
+ .l1 = 1,
+ .l3 = 26,
+ .l5 = 746,
+ .vsize = 750,
+ .capture_format = 0,
+ .vbi_supported = 0,
+ .hd_sd = 1,
+ .dv_preset = V4L2_DV_720P60,
+ },
+ {
+ .name = 1080I50,
+ .width = 1920,
+ .height = 1080,
+ .frm_fmt = 0,
+ .ycmux_mode = 0,
+ .eav2sav = 720 - 8,
+ .sav2eav = 1920,
+ .l1 = 1,
+ .l3 = 21,
+ .l5 = 561,
+ .l7 = 563,
+ .l9 = 584,
+ .l11 = 1124,
+ .vsize = 1125,
+ .capture_format = 0,
+ .vbi_supported = 0,
+ .hd_sd = 1,
+ .dv_preset = V4L2_DV_1080I50,
+ },
+ {
+ .name = 1080I60,
+ .width = 1920,
+ .height = 1080,
+ .frm_fmt = 0,
+ .ycmux_mode = 0,
+ .eav2sav = 280 - 8,
+ .sav2eav = 1920,
+ .l1 = 1,
+ .l3 = 21,
+ .l5 = 561,
+ .l7 = 563,
+ .l9 = 584,
+ .l11 = 1124,
+ .vsize = 1125,
+ .capture_format = 0,
+ .vbi_supported = 0,
+ .hd_sd = 1,
+ .dv_preset = V4L2_DV_1080I60,
+ },
+ {
+ .name = 1080p60,
+ .width = 1920,
+ .height = 1080,
+ .frm_fmt = 1,
+ .ycmux_mode = 0,
+ .eav2sav = 280 - 8,
+ .sav2eav = 1920,
+ .l1 = 1,
+ .l3 = 42,
+ .l5 = 1122,
+ .vsize = 1125,
+ .capture_format = 0,
+ .vbi_supported = 0,
+ .hd_sd = 1,
+ .dv_preset = V4L2_DV_1080P60,
+ },
+
/* SDTV formats */
{
.name = NTSC_M,
diff --git
[RFCv2/PATCH 5/5] vpif_cap/disp: Cleanup, improved comments
From: Mats Randgaard mats.randga...@tandberg.com
Signed-off-by: Mats Randgaard mats.randga...@tandberg.com
Signed-off-by: Hans Verkuil hans.verk...@tandberg.com
Acked-by: Murali Karicheri mkarich...@gmail.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/davinci/vpif.h | 13 ++---
drivers/media/video/davinci/vpif_capture.c | 13 ++---
drivers/media/video/davinci/vpif_display.c | 23 ---
3 files changed, 32 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index b121683..aea7487 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -577,11 +577,10 @@ struct vpif_channel_config_params {
char name[VPIF_MAX_NAME]; /* Name of the mode */
u16 width; /* Indicates width of the image */
u16 height; /* Indicates height of the image */
- u8 frm_fmt; /* Indicates whether this is interlaced
-* or progressive format */
- u8 ycmux_mode; /* Indicates whether this mode requires
-* single or two channels */
- u16 eav2sav;/* length of sav 2 eav */
+ u8 frm_fmt; /* Interlaced (0) or progressive (1) */
+ u8 ycmux_mode; /* This mode requires one (0) or two (1)
+ channels */
+ u16 eav2sav;/* length of eav 2 sav */
u16 sav2eav;/* length of sav 2 eav */
u16 l1, l3, l5, l7, l9, l11;/* Other parameter configurations */
u16 vsize; /* Vertical size of the image */
@@ -589,8 +588,8 @@ struct vpif_channel_config_params {
* is in BT or in CCD/CMOS */
u8 vbi_supported; /* Indicates whether this mode
* supports capturing vbi or not */
- u8 hd_sd;
- v4l2_std_id stdid;
+ u8 hd_sd; /* HDTV (1) or SDTV (0) format */
+ v4l2_std_id stdid; /* SDTV format */
u32 dv_preset; /* HDTV format */
};
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index 0635b10..c8c574f 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -329,7 +329,7 @@ static void vpif_schedule_next_buffer(struct common_obj
*common)
* @dev_id: dev_id ptr
*
* It changes status of the captured buffer, takes next buffer from the queue
- * and sets its address in VPIF registers
+ * and sets its address in VPIF registers
*/
static irqreturn_t vpif_channel_isr(int irq, void *dev_id)
{
@@ -422,14 +422,12 @@ static int vpif_update_std_info(struct channel_obj *ch)
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
struct vpif_params *vpifparams = ch-vpifparams;
const struct vpif_channel_config_params *config;
- struct vpif_channel_config_params *std_info;
+ struct vpif_channel_config_params *std_info = vpifparams-std_info;
struct video_obj *vid_ch = ch-video;
int index;
vpif_dbg(2, debug, vpif_update_std_info\n);
- std_info = vpifparams-std_info;
-
for (index = 0; index vpif_ch_params_count; index++) {
config = ch_params[index];
if (config-hd_sd == 0) {
@@ -458,6 +456,7 @@ static int vpif_update_std_info(struct channel_obj *ch)
common-fmt.fmt.pix.bytesperline = std_info-width;
vpifparams-video_params.hpitch = std_info-width;
vpifparams-video_params.storage_mode = std_info-frm_fmt;
+
return 0;
}
@@ -1691,7 +1690,7 @@ static int vpif_s_fmt_vid_cap(struct file *file, void
*priv,
struct v4l2_pix_format *pixfmt;
int ret = 0;
- vpif_dbg(2, debug, VIDIOC_S_FMT\n);
+ vpif_dbg(2, debug, %s\n, __func__);
/* If streaming is started, return error */
if (common-started) {
@@ -2333,9 +2332,9 @@ static __init int vpif_probe(struct platform_device *pdev)
if (vpif_obj.sd[i])
vpif_obj.sd[i]-grp_id = 1 i;
}
- v4l2_info(vpif_obj.v4l2_dev, DM646x VPIF Capture driver
- initialized\n);
+ v4l2_info(vpif_obj.v4l2_dev,
+ DM646x VPIF capture driver initialized\n);
return 0;
probe_subdev_out:
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index 12bfcb9..bb7583d 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -363,6 +363,13 @@ static irqreturn_t vpif_channel_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
[RFCv2/PATCH 4/5] vpif_cap/disp: Added support for DV timings
From: Mats Randgaard mats.randga...@tandberg.com
Added functions to set and get custom DV timings.
Signed-off-by: Mats Randgaard mats.randga...@tandberg.com
Signed-off-by: Hans Verkuil hans.verk...@tandberg.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/davinci/vpif_capture.c | 119 +++
drivers/media/video/davinci/vpif_capture.h |1 +
drivers/media/video/davinci/vpif_display.c | 120
drivers/media/video/davinci/vpif_display.h |1 +
4 files changed, 241 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index f713d08..0635b10 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -1908,6 +1908,123 @@ static int vpif_g_dv_preset(struct file *file, void
*priv,
return 0;
}
+/**
+ * vpif_s_dv_timings() - S_DV_TIMINGS handler
+ * @file: file ptr
+ * @priv: file handle
+ * @timings: digital video timings
+ */
+static int vpif_s_dv_timings(struct file *file, void *priv,
+ struct v4l2_dv_timings *timings)
+{
+ struct vpif_fh *fh = priv;
+ struct channel_obj *ch = fh-channel;
+ struct vpif_params *vpifparams = ch-vpifparams;
+ struct vpif_channel_config_params *std_info = vpifparams-std_info;
+ struct video_obj *vid_obj = ch-video;
+ struct v4l2_bt_timings *bt = vid_obj-bt_timings;
+ int ret;
+
+ if (timings-type != V4L2_DV_BT_656_1120) {
+ vpif_dbg(2, debug, Timing type not defined\n);
+ return -EINVAL;
+ }
+
+ /* Configure subdevice timings, if any */
+ ret = v4l2_subdev_call(vpif_obj.sd[ch-curr_sd_index],
+ video, s_dv_timings, timings);
+ if (ret == -ENOIOCTLCMD) {
+ vpif_dbg(2, debug, Custom DV timings not supported by
+ subdevice\n);
+ return -EINVAL;
+ }
+ if (ret 0) {
+ vpif_dbg(2, debug, Error setting custom DV timings\n);
+ return ret;
+ }
+
+ if (!(timings-bt.width timings-bt.height
+ (timings-bt.hbackporch ||
+timings-bt.hfrontporch ||
+timings-bt.hsync)
+ timings-bt.vfrontporch
+ (timings-bt.vbackporch ||
+timings-bt.vsync))) {
+ vpif_dbg(2, debug, Timings for width, height,
+ horizontal back porch, horizontal sync,
+ horizontal front porch, vertical back porch,
+ vertical sync and vertical back porch
+ must be defined\n);
+ return -EINVAL;
+ }
+
+ *bt = timings-bt;
+
+ /* Configure video port timings */
+
+ std_info-eav2sav = bt-hbackporch + bt-hfrontporch +
+ bt-hsync - 8;
+ std_info-sav2eav = bt-width;
+
+ std_info-l1 = 1;
+ std_info-l3 = bt-vsync + bt-vbackporch + 1;
+
+ if (bt-interlaced) {
+ if (bt-il_vbackporch || bt-il_vfrontporch || bt-il_vsync) {
+ std_info-vsize = bt-height * 2 +
+ bt-vfrontporch + bt-vsync + bt-vbackporch +
+ bt-il_vfrontporch + bt-il_vsync +
+ bt-il_vbackporch;
+ std_info-l5 = std_info-vsize/2 -
+ (bt-vfrontporch - 1);
+ std_info-l7 = std_info-vsize/2 + 1;
+ std_info-l9 = std_info-l7 + bt-il_vsync +
+ bt-il_vbackporch + 1;
+ std_info-l11 = std_info-vsize -
+ (bt-il_vfrontporch - 1);
+ } else {
+ vpif_dbg(2, debug, Required timing values for
+ interlaced BT format missing\n);
+ return -EINVAL;
+ }
+ } else {
+ std_info-vsize = bt-height + bt-vfrontporch +
+ bt-vsync + bt-vbackporch;
+ std_info-l5 = std_info-vsize - (bt-vfrontporch - 1);
+ }
+ strncpy(std_info-name, Custom timings BT656/1120, VPIF_MAX_NAME);
+ std_info-width = bt-width;
+ std_info-height = bt-height;
+ std_info-frm_fmt = bt-interlaced ? 0 : 1;
+ std_info-ycmux_mode = 0;
+ std_info-capture_format = 0;
+ std_info-vbi_supported = 0;
+ std_info-hd_sd = 1;
+ std_info-stdid = 0;
+ std_info-dv_preset = V4L2_DV_INVALID;
+
+ return 0;
+}
+
+/**
+ * vpif_g_dv_timings() - G_DV_TIMINGS handler
+ * @file: file ptr
+ * @priv: file handle
+ * @timings: digital video timings
+ */
+static int vpif_g_dv_timings(struct
[RFCv2/PATCH 1/5] vpif_cap/disp: Add debug functionality
From: Mats Randgaard mats.randga...@tandberg.com
The following functions are added to the drivers:
- vpif_g_chip_ident
- vpif_dbg_g_register
- vpif_dbg_s_register
- vpif_log_status
Signed-off-by: Mats Randgaard mats.randga...@tandberg.com
Signed-off-by: Hans Verkuil hans.verk...@tandberg.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/davinci/vpif_capture.c | 83 +++
drivers/media/video/davinci/vpif_display.c | 86
2 files changed, 169 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index 6ac6acd..3b5c98b 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -37,6 +37,7 @@
#include linux/slab.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-chip-ident.h
#include vpif_capture.h
#include vpif.h
@@ -1807,6 +1808,82 @@ static int vpif_cropcap(struct file *file, void *priv,
return 0;
}
+/*
+ * vpif_g_chip_ident() - Identify the chip
+ * @file: file ptr
+ * @priv: file handle
+ * @chip: chip identity
+ *
+ * Returns zero or -EINVAL if read operations fails.
+ */
+static int vpif_g_chip_ident(struct file *file, void *priv,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ chip-ident = V4L2_IDENT_NONE;
+ chip-revision = 0;
+ if (chip-match.type != V4L2_CHIP_MATCH_I2C_DRIVER
+ chip-match.type != V4L2_CHIP_MATCH_I2C_ADDR) {
+ vpif_dbg(2, debug, match_type is invalid.\n);
+ return -EINVAL;
+ }
+
+ return v4l2_device_call_until_err(vpif_obj.v4l2_dev, 0, core,
+ g_chip_ident, chip);
+}
+
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+/*
+ * vpif_dbg_g_register() - Read register
+ * @file: file ptr
+ * @priv: file handle
+ * @reg: register to be read
+ *
+ * Debugging only
+ * Returns zero or -EINVAL if read operations fails.
+ */
+static int vpif_dbg_g_register(struct file *file, void *priv,
+ struct v4l2_dbg_register *reg){
+ struct vpif_fh *fh = priv;
+ struct channel_obj *ch = fh-channel;
+
+ return v4l2_subdev_call(vpif_obj.sd[ch-curr_sd_index], core,
+ g_register, reg);
+}
+
+/*
+ * vpif_dbg_s_register() - Write to register
+ * @file: file ptr
+ * @priv: file handle
+ * @reg: register to be modified
+ *
+ * Debugging only
+ * Returns zero or -EINVAL if write operations fails.
+ */
+static int vpif_dbg_s_register(struct file *file, void *priv,
+ struct v4l2_dbg_register *reg){
+ struct vpif_fh *fh = priv;
+ struct channel_obj *ch = fh-channel;
+
+ return v4l2_subdev_call(vpif_obj.sd[ch-curr_sd_index], core,
+ s_register, reg);
+}
+#endif
+
+/*
+ * vpif_log_status() - Status information
+ * @file: file ptr
+ * @priv: file handle
+ *
+ * Returns zero.
+ */
+static int vpif_log_status(struct file *filep, void *priv)
+{
+ /* status for sub devices */
+ v4l2_device_call_all(vpif_obj.v4l2_dev, 0, core, log_status);
+
+ return 0;
+}
+
/* vpif capture ioctl operations */
static const struct v4l2_ioctl_ops vpif_ioctl_ops = {
.vidioc_querycap= vpif_querycap,
@@ -1829,6 +1906,12 @@ static const struct v4l2_ioctl_ops vpif_ioctl_ops = {
.vidioc_streamon= vpif_streamon,
.vidioc_streamoff = vpif_streamoff,
.vidioc_cropcap = vpif_cropcap,
+ .vidioc_g_chip_ident= vpif_g_chip_ident,
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+ .vidioc_g_register = vpif_dbg_g_register,
+ .vidioc_s_register = vpif_dbg_s_register,
+#endif
+ .vidioc_log_status = vpif_log_status,
};
/* vpif file operations */
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index 685f6a6..57b206c 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -38,6 +38,7 @@
#include media/adv7343.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-chip-ident.h
#include mach/dm646x.h
@@ -1315,6 +1316,85 @@ static int vpif_s_priority(struct file *file, void
*priv, enum v4l2_priority p)
return v4l2_prio_change(ch-prio, fh-prio, p);
}
+
+/*
+ * vpif_g_chip_ident() - Identify the chip
+ * @file: file ptr
+ * @priv: file handle
+ * @chip: chip identity
+ *
+ * Returns zero or -EINVAL if read operations fails.
+ */
+static int vpif_g_chip_ident(struct file *file, void *priv,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ chip-ident = V4L2_IDENT_NONE;
+ chip-revision = 0;
+ if (chip-match.type != V4L2_CHIP_MATCH_I2C_DRIVER
+ chip-match.type != V4L2_CHIP_MATCH_I2C_ADDR) {
+ vpif_dbg(2, debug, match_type is invalid.\n);
[RFCv2/PATCH 0/5] DaVinci VPIF: Support for DV preset and DV timings.
From: Mats Randgaard mats.randga...@tandberg.com Support for DV preset and timings added to vpif_capture and vpif_display drivers. Functions for debugging are added and the code is improved as well. Mats Randgaard (5): vpif_cap/disp: Add debug functionality vpif: Consolidate formats from capture and display vpif_cap/disp: Add support for DV presets vpif_cap/disp: Added support for DV timings vpif_cap/disp: Cleanup, improved comments drivers/media/video/davinci/vpif.c | 177 ++ drivers/media/video/davinci/vpif.h | 18 +- drivers/media/video/davinci/vpif_capture.c | 357 ++-- drivers/media/video/davinci/vpif_capture.h |2 + drivers/media/video/davinci/vpif_display.c | 351 +-- drivers/media/video/davinci/vpif_display.h |2 + 6 files changed, 850 insertions(+), 57 deletions(-) -- 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: [cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
Hi Hans, Provided that we're without a maintainer for Mercurial tree, I doubt that anyone would fix the problems there. So, I think you should disable the mercurial build reports, while we don't have any backport tree maintainer. Cheers, Mauro Em 27-10-2010 17:05, Hans Verkuil escreveu: 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 Oct 27 19:00:19 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15167:abd3aac6644e git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: a348e9110ddb5d494e060d989b35dd1f35359d58 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.32.6-armv5: WARNINGS linux-2.6.33-armv5: WARNINGS linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-armv5-davinci: ERRORS linux-2.6.35.3-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-armv5-ixp: ERRORS linux-2.6.35.3-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-armv5-omap2: ERRORS linux-2.6.35.3-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS 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.32.6-m32r: WARNINGS linux-2.6.33-m32r: WARNINGS linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-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 spec-git: OK 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 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 -- 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
Changing frame size on the fly in SOC module
Hi, Sometime ago I developed an SOC based camera driver for my platform (ov7675 on iMX25), for the most part it seems to be working well however at the time I couldn't manage to change the frame size on the fly (without closing / re-opening the device). The current problem I have is that my application needs to display a 320x240 preview image on screen, but to capture a static image at 640x480. I can do this as long as I close the device in between, unfortunately for power consumption reasons the camera device is put into a low power state whenever the device is released. This means that the image capture takes approx 1.5s (the requirement I have to meet is 1s). Now I could cheat and simply subsample (in software) the 640x480 image, but that puts additional burden on an already overworked MCU. Having been through the soc_camera and videobuf code and as far as I can tell this inability to change the frame size without closing the camera device appears to be a design decision. What I'm really after is confirmation one way of the other. If it's not, what is the correct process to achieve the frame change without closing the device. And if it is, does anybody have any suggestions of possible workarounds? Thanks Adam Plextek Limited Registered Address: London Road, Great Chesterford, Essex, CB10 1NY, UK Company Registration No. 2305889 VAT Registration No. GB 918 4425 15 Tel: +44 1799 533 200. Fax: +44 1799 533 201 Web:http://www.plextek.com Electronics Design and Consultancy -- 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
Fwd: Re: [PATCH] DiSEqC bug fixed for stv0288 based interfaces
Hi Mauro
can you try to insert it in your GIT please?
Fixed problem with DiSEqC communication. The message was wrongly
modulated,
so the DiSEqC switch was not work.
This patch fixes DiSEqC messages, simple tone burst and tone on/off.
I verified it with osciloscope against the DiSEqC documentation.
Interface: PCI DVB-S TV tuner TeVii S420
Kernel: 2.6.32-24-generic (UBUNTU 10.4)
Signed-off-by: Josef Pavlik jo...@pavlik.it
-- Forwarded Message --
Subject: Re: [PATCH] DiSEqC bug fixed for stv0288 based interfaces
Date: Sunday 26 September 2010
From: tvbox tvbox...@gmail.com
To: jo...@pavlik.it
Hi Josef
This patch does work and has been tested in my driver.
However, your patch was still corrupt, here is a cleaned up version.
I have had to shorten some quotes in some lines to within 80 characters
Tested-by: Malcolm Priestley tvbox...@gmail.com
It is also in my own hg tree at
http://mercurial.intuxication.org/hg/tvboxspy/rev/666fe763c5f6
diff --git a/drivers/media/dvb/frontends/stv0288.c
b/drivers/media/dvb/frontends/stv0288.c
index 2930a5d..6cd442e 100644
--- a/drivers/media/dvb/frontends/stv0288.c
+++ b/drivers/media/dvb/frontends/stv0288.c
@@ -6,6 +6,8 @@
Copyright (C) 2008 Igor M. Liplianin liplia...@me.by
Removed stb6000 specific tuner code and revised some
procedures.
+ 2010-09-01 Josef Pavlik jo...@pavlik.it
+ Fixed diseqc_msg, diseqc_burst and set_tone problems
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -156,14 +158,13 @@ static int stv0288_send_diseqc_msg(struct dvb_frontend
*fe,
stv0288_writeregI(state, 0x09, 0);
msleep(30);
- stv0288_writeregI(state, 0x05, 0x16);
+ stv0288_writeregI(state, 0x05, 0x12);/* modulated mode, single shot */
for (i = 0; i m-msg_len; i++) {
if (stv0288_writeregI(state, 0x06, m-msg[i]))
return -EREMOTEIO;
- msleep(12);
}
-
+ msleep(m-msg_len*12);
return 0;
}
@@ -174,13 +175,14 @@ static int stv0288_send_diseqc_burst(struct dvb_frontend
*fe,
dprintk(%s\n, __func__);
- if (stv0288_writeregI(state, 0x05, 0x16))/* burst mode */
- return -EREMOTEIO;
-
- if (stv0288_writeregI(state, 0x06, burst == SEC_MINI_A ? 0x00 : 0xff))
+ if (stv0288_writeregI(state, 0x05, 0x03))/* burst mode, single shot */
+ return -EREMOTEIO;
+
+ if (stv0288_writeregI(state, 0x06, burst == SEC_MINI_A ? 0x00 : 0xff))
return -EREMOTEIO;
- if (stv0288_writeregI(state, 0x06, 0x12))
+ msleep(15);
+ if (stv0288_writeregI(state, 0x05, 0x12))
return -EREMOTEIO;
return 0;
@@ -192,18 +194,19 @@ static int stv0288_set_tone(struct dvb_frontend *fe,
fe_sec_tone_mode_t tone)
switch (tone) {
case SEC_TONE_ON:
- if (stv0288_writeregI(state, 0x05, 0x10))/* burst mode */
+ if (stv0288_writeregI(state, 0x05, 0x10))/* cont carrier */
return -EREMOTEIO;
- return stv0288_writeregI(state, 0x06, 0xff);
+ break;
case SEC_TONE_OFF:
- if (stv0288_writeregI(state, 0x05, 0x13))/* burst mode */
+ if (stv0288_writeregI(state, 0x05, 0x12))/* burst mode off*/
return -EREMOTEIO;
- return stv0288_writeregI(state, 0x06, 0x00);
+ break;
default:
return -EINVAL;
}
+ return 0;
}
static u8 stv0288_inittab[] = {
sorry, but something eats the leading spaces (but no the tabs) in the inlined
patch making it unusable, so please use the attached one.
-
on Sep 12, 2010, at 13:30, I wrote:
seems that the patch was corrupted by the kmail used for the post (missing
space before the last close bracket resulting corrupted patch)
the corrected patch follows (and I'm sending it with another mail program)
Signed-off-by: Josef Pavlik jo...@pavlik.it
-
diff --git a/drivers/media/dvb/frontends/stv0288.c
b/drivers/media/dvb/frontends/stv0288.c
index 2930a5d..6cd442e 100644
--- a/drivers/media/dvb/frontends/stv0288.c
+++ b/drivers/media/dvb/frontends/stv0288.c
@@ -6,6 +6,8 @@
Copyright (C) 2008 Igor M. Liplianin liplia...@me.by
Removed stb6000 specific tuner code and revised some
procedures.
+2010-09-01 Josef Pavlik jo...@pavlik.it
+Fixed diseqc_msg, diseqc_burst and set_tone problems
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -156,14 +158,13 @@ static int stv0288_send_diseqc_msg(struct dvb_frontend
*fe,
Re: OMAP 3530 camera ISP forks and new media framework
Hi Laurent, Laurent Pinchart wrote: First of all, you need to get the latest OMAP3 ISP driver sources. The most recent OMAP3 ISP driver for the N900 can be found in the omap3isp- rx51 git tree on gitorious.org (devel branch from http://meego.gitorious.org/maemo-multimedia/omap3isp-rx51). This is the tree used by MeeGo for the OMAP3 ISP camera driver. The driver has been ported to the media controller framework, but the latest changes to the framework are not present in that tree as they break the driver ABI and API. This should be fixed in the future, but I can't give you any time estimate at the moment. The most recent OMAP3 ISP driver and media controller framework can be found in the pinchartl/media git tree on linuxtv.org (media-0004-omap3isp branch from http://git.linuxtv.org/pinchartl/media.git). This is the tree used for upstream submission of the media controller and OMAP3 ISP driver. The OMAP3 ISP driver implements the latest media controller API, but the tree doesn't contain RX51 camera support. You say the most recent OMAP3 ISP driver for the N900 is on gitorious but the most recent OMAP3 ISP driver and media controller framework is your branch. I'm confused about where I find the most recent OMAP3 ISP driver. To take a concrete example, in media-0004-omap3isp, media_device_register() WARNs if mdev doesn't have a model name (I get the warning). On the Meego branch, it WARNs only if it's missing both a model name and a parent dev pointer. If I understood you correctly above, media-0004-omap3isp has the newer framework, so the newer framework requires a model name? I don't need RX51 camera support, but I would like to have a reasonably up-to-date OMAP3 ISP driver. Laurent said before that media-0004-omap3isp will be updated regularly. Do these updates come from a cherry-pick of the gitorious branch? I anticipate sending a patch based on media-0004-omap3isp someday (like one addressing my WARN_ON issue) and getting as a reply, yeah, we already did that on meego.gitorious.org. I appreciate your help so far. -- Michael Jones MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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: OMAP 3530 camera ISP forks and new media framework
Hi Michael, On Thursday 28 October 2010 12:28:46 Michael Jones wrote: Laurent Pinchart wrote: First of all, you need to get the latest OMAP3 ISP driver sources. The most recent OMAP3 ISP driver for the N900 can be found in the omap3isp- rx51 git tree on gitorious.org (devel branch from http://meego.gitorious.org/maemo-multimedia/omap3isp-rx51). This is the tree used by MeeGo for the OMAP3 ISP camera driver. The driver has been ported to the media controller framework, but the latest changes to the framework are not present in that tree as they break the driver ABI and API. This should be fixed in the future, but I can't give you any time estimate at the moment. The most recent OMAP3 ISP driver and media controller framework can be found in the pinchartl/media git tree on linuxtv.org (media-0004-omap3isp branch from http://git.linuxtv.org/pinchartl/media.git). This is the tree used for upstream submission of the media controller and OMAP3 ISP driver. The OMAP3 ISP driver implements the latest media controller API, but the tree doesn't contain RX51 camera support. You say the most recent OMAP3 ISP driver for the N900 is on gitorious but the most recent OMAP3 ISP driver and media controller framework is your branch. I'm confused about where I find the most recent OMAP3 ISP driver. The OMAP3 ISP driver on linuxtv is the most recent one, but doesn't support the N900 as it lacks sensor drivers and board code. The gitorious tree has full N900 camera support but is based on 2.6.35 and on an older media controller API. To take a concrete example, in media-0004-omap3isp, media_device_register() WARNs if mdev doesn't have a model name (I get the warning). On the Meego branch, it WARNs only if it's missing both a model name and a parent dev pointer. If I understood you correctly above, media-0004-omap3isp has the newer framework, so the newer framework requires a model name? That's correct. I don't need RX51 camera support, but I would like to have a reasonably up-to-date OMAP3 ISP driver. Then go for the linuxtv tree. Laurent said before that media-0004-omap3isp will be updated regularly. Do these updates come from a cherry-pick of the gitorious branch? Both the gitorious and the linuxtv tree are updated from an internal development tree. I anticipate sending a patch based on media-0004-omap3isp someday (like one addressing my WARN_ON issue) and getting as a reply, yeah, we already did that on meego.gitorious.org. It would be the other way around, patches against the gitorious tree could fix problems already fixed on linuxtv. I appreciate your help so far. You're welcome. -- 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
Kworld usb 2800D audio
Hi, I'm able to capture video just fine with my Kworld usb 2800D usb device and the recent (I've installed the April v4l-dvb em28xx driver), but I can't get any audio. I tried modprobe em28xx-alsa, and the module loads, but alsa can't find any sound cards. Do I need the snd-usb-audio driver? the usb device is based on the em2860 chip. Any help would be greatly appreciated, thanks. -Tim -- 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: Kworld usb 2800D audio
On Thu, Oct 28, 2010 at 10:18 AM, Tim Stowell stowe...@gmail.com wrote: Hi, I'm able to capture video just fine with my Kworld usb 2800D usb device and the recent (I've installed the April v4l-dvb em28xx driver), but I can't get any audio. I tried modprobe em28xx-alsa, and the module loads, but alsa can't find any sound cards. Do I need the snd-usb-audio driver? the usb device is based on the em2860 chip. Any help would be greatly appreciated, thanks. Hello Tim, If I recall, the KWorld 2800D doesn't actually capture audio directly via the USB. The device has a 2.5mm cable that you are required to connect to our sound card's line-in. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: Kworld usb 2800D audio
Thanks for the response! That makes sense about the 2.5 mm cable. Not to be obstinate or anything but I found this link http://video4linux-list.1448896.n2.nabble.com/SUCCESS-KWorld-VS-USB2800D-recognized-as-PointNix-Intra-Oral-Camera-No-Composite-Input-td3069455.html where the users claims they were able to get a new capture device that didn't require using the 2.5mm cable, although I'm not sure how they did it. I guess I'm hoping to not have to buy a sound card for capture if at all possible as I'm using an embedded pc that doesn't have any sound cards, thanks -Tim On Thu, Oct 28, 2010 at 8:27 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Thu, Oct 28, 2010 at 10:18 AM, Tim Stowell stowe...@gmail.com wrote: Hi, I'm able to capture video just fine with my Kworld usb 2800D usb device and the recent (I've installed the April v4l-dvb em28xx driver), but I can't get any audio. I tried modprobe em28xx-alsa, and the module loads, but alsa can't find any sound cards. Do I need the snd-usb-audio driver? the usb device is based on the em2860 chip. Any help would be greatly appreciated, thanks. Hello Tim, If I recall, the KWorld 2800D doesn't actually capture audio directly via the USB. The device has a 2.5mm cable that you are required to connect to our sound card's line-in. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
New media framework user space usage
Hello Laurent,
my mt9p031 camera project for the omap3530 isp has come to the point
where the ISP registered video[0-6], media0 and v4l-subdev[0-7].
As far as I can see from the names...
cat /sys/class/video4linux/video*/names
OMAP3 ISP CCP2 input
OMAP3 ISP CSI2a output
OMAP3 ISP CCDC output
OMAP3 ISP preview input
OMAP3 ISP preview output
OMAP3 ISP resizer input
OMAP3 ISP resizer output
cat /sys/class/video4linux/v4l-subdev*/names
OMAP3 ISP CCP2
OMAP3 ISP CSI2a
OMAP3 ISP CCDC
OMAP3 ISP preview
OMAP3 ISP resizer
OMAP3 ISP AEWB
OMAP3 ISP AF
OMAP3 ISP histogram
... I want to read /dev/video2 (CCDC).
When I try out a little test program from the V4L2 doc, this line fails:
ioctl (fd, VIDIOC_G_STD, std_id)
So far I adopted your mt9t001 driver, merged it with Guennadis
mt9p031. It contains lot of stubs that I want to fill out when I
succeed to make them called inside the kernel.
I looked at your presentation for the media controller and wonder if I
have to set up a pipeline by myself before I can read /dev/video2
(http://linuxtv.org/downloads/presentations/summit_jun_2010/20100614-v4l2_summit-media.pdf).
I failed at the point where I wanted to try out the little snippet on
page 17 as I don't have definitions of the MEDIA_IOC_ENUM_ENTITIES.
Are there somewhere userspace headers available?
int fd;
fd = open(“/dev/media0”, O_RDWR);
while (1) {
struct media_user_entity entity;
struct media_user_links links;
ret = ioctl(fd, MEDIA_IOC_ENUM_ENTITIES, entity);
if (ret 0)
break;
while (1) {
ret = ioctl(fd, MEDIA_IOC_ENUM_LINKS, links);
if (ret 0)
break;
}
Thanks for help,
Bastian
APPENDIX A: dmesg
[ 103.356018] Linux media interface: v0.10
[ 103.356048] device class 'media': registering
[ 103.442230] Linux video capture interface: v2.00
[ 103.442260] device class 'video4linux': registering
[ 103.814239] bus: 'i2c': add driver mt9p031
[ 103.894622] bus: 'platform': add driver omap3isp
[ 103.933959] address of isp_platform_data in boardconfig: bf065074
[ 103.940155] Registering platform device 'omap3isp'. Parent at platform
[ 103.940185] device: 'omap3isp': device_add
[ 103.940246] bus: 'platform': add device omap3isp
[ 103.940490] bus: 'platform': driver_probe_device: matched device
omap3isp with driver omap3isp
[ 103.940490] bus: 'platform': really_probe: probing driver omap3isp
with device omap3isp
[ 103.940551] address of isp_platform_data bf065074
[ 103.954467] omap3isp omap3isp: Revision 2.0 found
[ 103.962738] omap-iommu omap-iommu.0: isp: version 1.1
[ 103.969879] omap3isp omap3isp: hist: DMA channel = 0
[ 103.970001] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 576 Hz
[ 103.972229] omap3isp omap3isp: -ISP Register dump--
[ 103.972259] omap3isp omap3isp: ###ISP SYSCONFIG=0x0001
[ 103.972259] omap3isp omap3isp: ###ISP SYSSTATUS=0x0001
[ 103.972290] omap3isp omap3isp: ###ISP IRQ0ENABLE=0x
[ 103.972290] omap3isp omap3isp: ###ISP IRQ0STATUS=0x
[ 103.972320] omap3isp omap3isp: ###ISP TCTRL_GRESET_LENGTH=0x
[ 103.972320] omap3isp omap3isp: ###ISP TCTRL_PSTRB_REPLAY=0x
[ 103.972351] omap3isp omap3isp: ###ISP CTRL=0x00200200
[ 103.972351] omap3isp omap3isp: ###ISP TCTRL_CTRL=0x001e
[ 103.972381] omap3isp omap3isp: ###ISP TCTRL_FRAME=0x
[ 103.972381] omap3isp omap3isp: ###ISP TCTRL_PSTRB_DELAY=0x
[ 103.972412] omap3isp omap3isp: ###ISP TCTRL_STRB_DELAY=0x
[ 103.972442] omap3isp omap3isp: ###ISP TCTRL_SHUT_DELAY=0x
[ 103.972442] omap3isp omap3isp: ###ISP TCTRL_PSTRB_LENGTH=0x
[ 103.972473] omap3isp omap3isp: ###ISP TCTRL_STRB_LENGTH=0x
[ 103.972473] omap3isp omap3isp: ###ISP TCTRL_SHUT_LENGTH=0x
[ 103.972503] omap3isp omap3isp: ###SBL PCR=0x
[ 103.972503] omap3isp omap3isp: ###SBL SDR_REQ_EXP=0x
[ 103.972534] omap3isp omap3isp:
[ 103.974700] device: 'media0': device_add
[ 103.975128] device: 'v4l-subdev0': device_add
[ 103.975524] device: 'video0': device_add
[ 103.975799] device: 'v4l-subdev1': device_add
[ 103.976104] device: 'video1': device_add
[ 103.976409] device: 'v4l-subdev2': device_add
[ 103.976684] device: 'video2': device_add
[ 103.976959] device: 'v4l-subdev3': device_add
[ 103.977294] device: 'video3': device_add
[ 103.977600] device: 'video4': device_add
[ 103.977905] device: 'v4l-subdev4': device_add
[ 103.978210] device: 'video5': device_add
[ 103.978485] device: 'video6': device_add
[ 103.978759] device: 'v4l-subdev5': device_add
[ 103.979156] device: 'v4l-subdev6': device_add
[ 103.979461] device: 'v4l-subdev7': device_add
[ 104.752685] device: '2-005d': device_add
[ 104.752777] bus: 'i2c': add device 2-005d
[ 104.753051] bus: 'i2c': driver_probe_device: matched device 2-005d
with driver mt9p031
[ 104.753082] bus: 'i2c': really_probe: probing driver mt9p031 with
device 2-005d
[ 104.769897] mt9p031 2-005d: Detected a MT9P031
Re: Kworld usb 2800D audio
On Thu, Oct 28, 2010 at 10:36 AM, Tim Stowell stowe...@gmail.com wrote: Thanks for the response! That makes sense about the 2.5 mm cable. Not to be obstinate or anything but I found this link http://video4linux-list.1448896.n2.nabble.com/SUCCESS-KWorld-VS-USB2800D-recognized-as-PointNix-Intra-Oral-Camera-No-Composite-Input-td3069455.html where the users claims they were able to get a new capture device that didn't require using the 2.5mm cable, although I'm not sure how they did it. I guess I'm hoping to not have to buy a sound card for capture if at all possible as I'm using an embedded pc that doesn't have any sound cards, thanks Read my response in the second message in that thread you provided a link for. :-) The fact that the ALSA device was being created was actually a bug in the em28xx driver. The hardware does not support capture over the USB. There are other devices which do support audio over the USB - the limitation is specific to this particular product. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: Kworld usb 2800D audio
On Thu, Oct 28, 2010 at 10:48 AM, Tim Stowell stowe...@gmail.com wrote: Ah my bad, I need to read a little deeper it seems :) Thanks for the info, now I'll stop pulling my hair out trying to get non-existent audio. If it's any consolation, I had to rip one of the units apart and break out a scope to come to that conclusion. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: New media framework user space usage
Hi,
after reading the topic controls, subdevs, and media framework
(http://www.spinics.net/lists/linux-media/msg24474.html) I guess I
double-posted something here :S
But what I still don't understand is, how configuring the camera
works. You say that the subdevs (my camera sensor) are configured
directly. 2 things make me wonder. How gets the ISP informed about the
change and why don't I see my camera in the subdevs name list I
posted. All subdevs are from the ISP.
My camera already receives a clock, the i2c connection works and my
oscilloscope shows that the sensor is throwing out data on the
parallel bus pins. But unfortunately I am a completely v4l2 newbie. I
read through the v4l2-docs now but the first example already didn't
work because of the new framework. Can you point me to a way to read
/dev/video2?
Thank you very much,
Bastian
2010/10/28 Bastian Hecht hec...@googlemail.com:
Hello Laurent,
my mt9p031 camera project for the omap3530 isp has come to the point
where the ISP registered video[0-6], media0 and v4l-subdev[0-7].
As far as I can see from the names...
cat /sys/class/video4linux/video*/names
OMAP3 ISP CCP2 input
OMAP3 ISP CSI2a output
OMAP3 ISP CCDC output
OMAP3 ISP preview input
OMAP3 ISP preview output
OMAP3 ISP resizer input
OMAP3 ISP resizer output
cat /sys/class/video4linux/v4l-subdev*/names
OMAP3 ISP CCP2
OMAP3 ISP CSI2a
OMAP3 ISP CCDC
OMAP3 ISP preview
OMAP3 ISP resizer
OMAP3 ISP AEWB
OMAP3 ISP AF
OMAP3 ISP histogram
... I want to read /dev/video2 (CCDC).
When I try out a little test program from the V4L2 doc, this line fails:
ioctl (fd, VIDIOC_G_STD, std_id)
So far I adopted your mt9t001 driver, merged it with Guennadis
mt9p031. It contains lot of stubs that I want to fill out when I
succeed to make them called inside the kernel.
I looked at your presentation for the media controller and wonder if I
have to set up a pipeline by myself before I can read /dev/video2
(http://linuxtv.org/downloads/presentations/summit_jun_2010/20100614-v4l2_summit-media.pdf).
I failed at the point where I wanted to try out the little snippet on
page 17 as I don't have definitions of the MEDIA_IOC_ENUM_ENTITIES.
Are there somewhere userspace headers available?
int fd;
fd = open(“/dev/media0”, O_RDWR);
while (1) {
struct media_user_entity entity;
struct media_user_links links;
ret = ioctl(fd, MEDIA_IOC_ENUM_ENTITIES, entity);
if (ret 0)
break;
while (1) {
ret = ioctl(fd, MEDIA_IOC_ENUM_LINKS, links);
if (ret 0)
break;
}
Thanks for help,
Bastian
APPENDIX A: dmesg
[ 103.356018] Linux media interface: v0.10
[ 103.356048] device class 'media': registering
[ 103.442230] Linux video capture interface: v2.00
[ 103.442260] device class 'video4linux': registering
[ 103.814239] bus: 'i2c': add driver mt9p031
[ 103.894622] bus: 'platform': add driver omap3isp
[ 103.933959] address of isp_platform_data in boardconfig: bf065074
[ 103.940155] Registering platform device 'omap3isp'. Parent at platform
[ 103.940185] device: 'omap3isp': device_add
[ 103.940246] bus: 'platform': add device omap3isp
[ 103.940490] bus: 'platform': driver_probe_device: matched device
omap3isp with driver omap3isp
[ 103.940490] bus: 'platform': really_probe: probing driver omap3isp
with device omap3isp
[ 103.940551] address of isp_platform_data bf065074
[ 103.954467] omap3isp omap3isp: Revision 2.0 found
[ 103.962738] omap-iommu omap-iommu.0: isp: version 1.1
[ 103.969879] omap3isp omap3isp: hist: DMA channel = 0
[ 103.970001] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 576 Hz
[ 103.972229] omap3isp omap3isp: -ISP Register dump--
[ 103.972259] omap3isp omap3isp: ###ISP SYSCONFIG=0x0001
[ 103.972259] omap3isp omap3isp: ###ISP SYSSTATUS=0x0001
[ 103.972290] omap3isp omap3isp: ###ISP IRQ0ENABLE=0x
[ 103.972290] omap3isp omap3isp: ###ISP IRQ0STATUS=0x
[ 103.972320] omap3isp omap3isp: ###ISP TCTRL_GRESET_LENGTH=0x
[ 103.972320] omap3isp omap3isp: ###ISP TCTRL_PSTRB_REPLAY=0x
[ 103.972351] omap3isp omap3isp: ###ISP CTRL=0x00200200
[ 103.972351] omap3isp omap3isp: ###ISP TCTRL_CTRL=0x001e
[ 103.972381] omap3isp omap3isp: ###ISP TCTRL_FRAME=0x
[ 103.972381] omap3isp omap3isp: ###ISP TCTRL_PSTRB_DELAY=0x
[ 103.972412] omap3isp omap3isp: ###ISP TCTRL_STRB_DELAY=0x
[ 103.972442] omap3isp omap3isp: ###ISP TCTRL_SHUT_DELAY=0x
[ 103.972442] omap3isp omap3isp: ###ISP TCTRL_PSTRB_LENGTH=0x
[ 103.972473] omap3isp omap3isp: ###ISP TCTRL_STRB_LENGTH=0x
[ 103.972473] omap3isp omap3isp: ###ISP TCTRL_SHUT_LENGTH=0x
[ 103.972503] omap3isp omap3isp: ###SBL PCR=0x
[ 103.972503] omap3isp omap3isp: ###SBL SDR_REQ_EXP=0x
[ 103.972534] omap3isp omap3isp:
[ 103.974700] device: 'media0': device_add
[ 103.975128]
Re: no DVB-T with AVerMedia M115S
if this is the wrong list for requesting support for a device, please let me know. thank you daniel Am 19.10.2010 21:28, schrieb Daniel: is there any additional information i could give to help supporting this card? thanks, daniel Am 15.10.2010 16:00, schrieb Daniel: Hi, i own a mini-PCI card builtin in a Sony Vaio VGN-AR71ZU Notebook. After searching the web it looks like this is a AVerMedia M115S (maybe the S stands for Sony?), which is somehow different to an ordinary M115. Is there any chance to get DVB-T working with this card? It seems, that the tuner is the problem, but i don't know how to find out the type of the tuner. lspci -vvvnn gives this: 08:04.0 Multimedia controller [0480]: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1) Subsystem: Avermedia Technologies Inc Device [1461:e836] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 Interrupt: pin A routed to IRQ 22 Region 0: Memory at fc006800 (32-bit, non-prefetchable) [size=2K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: saa7134 Kernel modules: saa7134 and dmesg with the actual checkout of v4l gives this: saa7130/34: v4l2 driver version 0.2.16 loaded saa7133[0]: found at :08:04.0, rev: 209, irq: 22, latency: 64, mmio: 0xfc006800 saa7133[0]: subsystem: 1461:e836, board: UNKNOWN/GENERIC [card=0,autodetected] saa7133[0]: board init: gpio is eff saa7133[0]/core: hwinit1 saa7133[0]: i2c xfer: a0 00 saa7133[0]: i2c xfer: a1 =61 =14 =36 =e8 =00 =00 =00 =00 =00 =00 =00 =00 =00 =00 =00 =00 =ff =ff =ff =ff =ff =20 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =01 =40 =01 =02 =02 =01 =01 =03 =08 =ff =00 =00 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =65 =00 =ff =c2 =00 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =0d =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff saa7133[0]: i2c eeprom 00: 61 14 36 e8 00 00 00 00 00 00 00 00 00 00 00 00 saa7133[0]: i2c eeprom 10: ff ff ff ff ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 01 03 08 ff 00 00 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 65 00 ff c2 00 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: 0d ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c xfer: 01 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 03 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 05 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 07 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 09 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 0b ERROR: NO_DEVICE saa7133[0]: i2c xfer: 0d ERROR: NO_DEVICE saa7133[0]: i2c xfer: 0f ERROR: NO_DEVICE saa7133[0]: i2c xfer: 11 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 13 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 15 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 17 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 19 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 1b ERROR: NO_DEVICE saa7133[0]: i2c xfer: 1d ERROR: NO_DEVICE saa7133[0]: i2c xfer: 1f ERROR: NO_DEVICE saa7133[0]: i2c xfer: 21 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 23 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 25 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 27
Re: Non-fluent V4L Playback with BTTV-card
Am Donnerstag 14 Oktober 2010, um 17:18:30 schrieb Lukas Ruetz: Hello everyone, I have a Haupauge Impact capture card (bt878) and the problem that the playback of the captured PAL-video (no audio) isn't fluent. The video jumps every few seconds as if there were frames dropped. It occures (or is only then visible) if there is bigger movement in the video. This behaviour is nearly the same with mplayer, gstreamer and vlc depending on the output type. [snip] Now I've tried this capture card with a different PC and look, the problem is gone. Don't know where's the incompatibility with this HP z400 Quad-Core ... -- 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] cafe_ccic: fix colorspace corruption on resume
On Wed, 27 Oct 2010 14:55:00 +0100 (BST) Daniel Drake d...@laptop.org wrote: Only power down during resume if the camera is not in use, and correctly reconfigure the sensor during resume. Makes sense to me. Acked-by: Jonathan Corbet cor...@lwn.net jon -- 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: [cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
Hi Jan, Em 28-10-2010 16:01, Jan Hoogenraad escreveu: Douglas: First of all thank you for the support you have done so far. Hans: Is it possible to build the tar from http://git.linuxtv.org/mchehab/new_build.git automatically each night, just like the way the hg archive was built ? I don't have sufficient processing power to run that. Mauro: I'm willing to give the mercurial conversion a shot. I do not know a lot about v4l, but tend to be able to resolve this kind of release-type issues. The way it seems to me is that first new_build.git should compile for all releases that the hg archive supported. We still lack a maintainer for the new_build ;) I think we need to have someone with time looking on it, before flooding the ML's with breakage reports. I did the initial work: the tree is compiling, and I did a basic test with a few drivers on v2.6.32, but, unfortunately, I won't have time to maintain it. So, someone needs to head it. A few already talked to me about maintaining it it in priv, but didn't manifest yet publicly, because they're still analysing it. Also, so far, I received only one patch not made by me. Currently, the new_build tree covers kernel versions from .32 to .36, but, if nobody handles it, the backport patches will break with the time. Probably, some API will change on .37, requiring a new backport patch. In the meantime, someone may change one of the backported lines, breaking those patches. The good news is that there are just a few backport patches to maintain: 8 patches were enough for 2.6.32 (plus the v4l/compat.h logic). It is up to the one that takes the maintainership to decide what will be the minimum supported version. IMHO, 2.6.32 is a good choice, as it has a long-maintained stable version and almost all major distros are using it as basis for their newest version (and anyone 'crazy' enough to use an experimental, pre -rc version, is likely using a brand new distribution ;) ). Then I'd like some support from you as to transfer all current HG branches to the git line. In principle, that should be fixed by the maintainers. If the new_build.git complies well, that should be relatively straightforward. For me, it would be great if Mauro could transfer these branches automatically at that time to git. I can't do it, due to several reasons: 1) it would be a huge manual effort; 2) Trees will require up-port to the latest git version; 3) some trees are there mostly due to historic reasons; 4) developers need to rebase their drivers to the latest git, and test on their hardware if the up-port didn't break anything; 5) developers should be ok on migrating to git; I sent already a procedure for everybody with an account at linuxtv explaining how to create a git tree there. If they have any doubts, it is just a matter of pinging me, in priv. Cheers, 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: Changing frame size on the fly in SOC module
Hi Adam On Thu, 28 Oct 2010, Adam Sutton wrote: Hi, Sometime ago I developed an SOC based camera driver for my platform (ov7675 on iMX25), for the most part it seems to be working well however at the time I couldn't manage to change the frame size on the fly (without closing / re-opening the device). The current problem I have is that my application needs to display a 320x240 preview image on screen, but to capture a static image at 640x480. I can do this as long as I close the device in between, unfortunately for power consumption reasons the camera device is put into a low power state whenever the device is released. This means that the image capture takes approx 1.5s (the requirement I have to meet is 1s). Now I could cheat and simply subsample (in software) the 640x480 image, but that puts additional burden on an already overworked MCU. Having been through the soc_camera and videobuf code and as far as I can tell this inability to change the frame size without closing the camera device appears to be a design decision. Yes, it is. What I'm really after is confirmation one way of the other. If it's not, what is the correct process to achieve the frame change without closing the device. And if it is, does anybody have any suggestions of possible workarounds? It has been decided that way, because we didn't have a good use-case for changing the frame format on-the-fly to develop for and to test with. You seem to have one now, so, go ahead;) There are a couple of issues to address though - videobuffer configuration is one of them, host reconfiguration is the other one, possible multiple simultaneous users is the third one (ok, only one of them will be actually streaming). This use case - different size preview and single shot capture has come up a couple of times before, but noone has brought it to a proper mainstream solution. One thing you'd still want to do, I think, is to stop streaming before reconfiguring, and restart it afterwards. So, maybe a viable solution would be: in soc_camera_s_fmt_vid_cap() check not just for icf-vb_vidq.bufs[0] != NULL, but rather for if streaming is not running, and then someone will certainly have to check for large enough buffers. So, you'd have to request max size buffers from the beginning even for preview. 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
[cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
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:Thu Oct 28 19:00:17 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15167:abd3aac6644e git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: a348e9110ddb5d494e060d989b35dd1f35359d58 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.32.6-armv5: WARNINGS linux-2.6.33-armv5: WARNINGS linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-armv5-davinci: ERRORS linux-2.6.35.3-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-armv5-ixp: ERRORS linux-2.6.35.3-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-armv5-omap2: ERRORS linux-2.6.35.3-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS 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.32.6-m32r: WARNINGS linux-2.6.33-m32r: WARNINGS linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-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 spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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] via-camera: fix OLPC serial port check
On Wed, 27 Oct 2010 20:02:28 +0100 (BST) Daniel Drake d...@laptop.org wrote: CONFIG_OLPC_XO_1_5 does not exist in mainline, and it's not certain that we'll find a reason to add it later. We should also be detecting this at runtime, and if we do it at probe time we can be sure not to mess around with the PCI config space on XO-1. This makes every user carry a bit of OLPC-specific code. But there are no non-OLPC users currently, the code is small, and we get rid of some #ifdefs, which is always a good thing. Seems good to me. Acked-by: Jonathan Corbet cor...@lwn.net jon -- 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] via-camera: fix OLPC serial port check
On 28 October 2010 20:08, Jonathan Corbet cor...@lwn.net wrote: This makes every user carry a bit of OLPC-specific code. But there are no non-OLPC users currently, the code is small, and we get rid of some #ifdefs, which is always a good thing. Seems good to me. I think the compiler might be smart enough to optimize it out. When CONFIG_OLPC=n, machine_is_olpc() compiles down to a simple no. Hopefully that then makes all of that code candidate for dead code elimination by the compiler. Daniel -- 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] via-camera: fix OLPC serial port check
On Thu, 28 Oct 2010 20:14:35 +0100 Daniel Drake d...@laptop.org wrote: I think the compiler might be smart enough to optimize it out. When CONFIG_OLPC=n, machine_is_olpc() compiles down to a simple no. Hopefully that then makes all of that code candidate for dead code elimination by the compiler. Ah, yes, good point. It certainly *should* work that way, anyway... jon -- 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
Firmware for Telgent 2300 V4L/DVB driver
Hi David, Huang sent me a firmware file for Telgent 2300 some time ago, with the proper redistribution rights from the manufacturer. Not sure why, but it seems that I forgot to add on my linux-next tree and to ask you to pull from it. So, please pull it from my tree: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git master Thanks, Mauro --- The following changes since commit e9f9e3a9b7d780e93ae869c1b8502c843bfd93a4: wimax: update WiMAX firmwares for 2.6.35 (2010-09-29 12:02:34 +0900) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git master Mauro Carvalho Chehab (1): Add firmware for Telgent 2300 V4L/DVB driver WHENCE | 16 tlg2300_firmware.bin | Bin 0 - 51972 bytes 2 files changed, 16 insertions(+), 0 deletions(-) create mode 100644 tlg2300_firmware.bin -- 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] Too slow libv4l MJPEG decoding with HD cameras
Hi! On Wed, Oct 27, 2010 at 7:43 PM, Hans de Goede hdego...@redhat.com wrote: Are you sure you cannot make some time for this? Sorry, probably not. At least not in the near future. Mitar -- 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] Patch for cx18 module with added support of GoTView PCI DVD3 Hybrid tuner
Hello,
I've got code which adds support of GoTView PCI DVD3 Hybrid tuner in cx18
module and Andy Walls in ivtv mailing-list gave me some advice on making a
patch and sending it here. So here's the patch against staging/2.6.37-rc1
branch (the tutorial recommends to include it as plain text but if it's
the case I can surely send as an attachment):
diff -uprB v4l-dvb.orig/drivers/media/video/cx18/cx18-cards.c
v4l-dvb/drivers/media/video/cx18/cx18-cards.c
--- v4l-dvb.orig/drivers/media/video/cx18/cx18-cards.c 2010-10-28
22:04:11.0 +0400
+++ v4l-dvb/drivers/media/video/cx18/cx18-cards.c 2010-10-29
00:31:53.0 +0400
@@ -251,6 +251,66 @@ static const struct cx18_card cx18_card_
/* - */
+/* GoTView PCI */
+
+static const struct cx18_card_pci_info cx18_pci_gotview_dvd3[] = {
+ { PCI_DEVICE_ID_CX23418, CX18_PCI_ID_GOTVIEW, 0x3343 },
+ { 0, 0, 0 }
+};
+
+static const struct cx18_card cx18_card_gotview_dvd3 = {
+ .type = CX18_CARD_GOTVIEW_PCI_DVD3,
+ .name = GoTView PCI DVD3 Hybrid,
+ .comment = Experimenters needed for device to work well.\n
+ \tTo help, mail the ivtv-devel list (www.ivtvdriver.org).\n,
+ .v4l2_capabilities = CX18_CAP_ENCODER,
+ .hw_audio_ctrl = CX18_HW_418_AV,
+ .hw_muxer = CX18_HW_GPIO_MUX,
+ .hw_all = CX18_HW_TVEEPROM | CX18_HW_418_AV | CX18_HW_TUNER |
+ CX18_HW_GPIO_MUX | CX18_HW_DVB | CX18_HW_GPIO_RESET_CTRL,
+ .video_inputs = {
+ { CX18_CARD_INPUT_VID_TUNER, 0, CX18_AV_COMPOSITE2 },
+ { CX18_CARD_INPUT_SVIDEO1,1,
+ CX18_AV_SVIDEO_LUMA3 | CX18_AV_SVIDEO_CHROMA4 },
+ { CX18_CARD_INPUT_COMPOSITE1, 1, CX18_AV_COMPOSITE1 },
+ { CX18_CARD_INPUT_SVIDEO2,2,
+ CX18_AV_SVIDEO_LUMA7 | CX18_AV_SVIDEO_CHROMA8 },
+ { CX18_CARD_INPUT_COMPOSITE2, 2, CX18_AV_COMPOSITE6 },
+ },
+ .audio_inputs = {
+ { CX18_CARD_INPUT_AUD_TUNER, CX18_AV_AUDIO5,0 },
+ { CX18_CARD_INPUT_LINE_IN1, CX18_AV_AUDIO_SERIAL1, 1 },
+ { CX18_CARD_INPUT_LINE_IN2, CX18_AV_AUDIO_SERIAL2, 1 },
+ },
+ .tuners = {
+ /* XC3028 tuner */
+ { .std = V4L2_STD_ALL, .tuner = TUNER_XC2028 },
+ },
+ /* FIXME - the FM radio is just a guess and driver doesn't use SIF */
+ .radio_input = { CX18_CARD_INPUT_AUD_TUNER, CX18_AV_AUDIO5, 2 },
+ .ddr = {
+ /* Hynix HY5DU283222B DDR RAM */
+ .chip_config = 0x303,
+ .refresh = 0x3bd,
+ .timing1 = 0x36320966,
+ .timing2 = 0x1f,
+ .tune_lane = 0,
+ .initial_emrs = 2,
+ },
+ .gpio_init.initial_value = 0x1,
+ .gpio_init.direction = 0x3,
+
+ .gpio_audio_input = { .mask = 0x3,
+ .tuner = 0x1,
+ .linein = 0x2,
+ .radio = 0x1 },
+ .xceive_pin = 0,
+ .pci_list = cx18_pci_gotview_dvd3,
+ .i2c = cx18_i2c_std,
+};
+
+/* - */
+
/* Conexant Raptor PAL/SECAM: note that this card is analog only! */
static const struct cx18_card_pci_info cx18_pci_cnxt_raptor_pal[] = {
@@ -463,6 +523,7 @@ static const struct cx18_card *cx18_card
cx18_card_toshiba_qosmio_dvbt,
cx18_card_leadtek_pvr2100,
cx18_card_leadtek_dvr3100h,
+ cx18_card_gotview_dvd3
};
const struct cx18_card *cx18_get_card(u16 index)
diff -uprB v4l-dvb.orig/drivers/media/video/cx18/cx18-driver.c
v4l-dvb/drivers/media/video/cx18/cx18-driver.c
--- v4l-dvb.orig/drivers/media/video/cx18/cx18-driver.c 2010-10-28
22:04:11.0 +0400
+++ v4l-dvb/drivers/media/video/cx18/cx18-driver.c 2010-10-28
22:19:09.0 +0400
@@ -156,6 +156,7 @@ MODULE_PARM_DESC(cardtype,
\t\t\t 6 = Toshiba Qosmio DVB-T/Analog\n
\t\t\t 7 = Leadtek WinFast PVR2100\n
\t\t\t 8 = Leadtek WinFast DVR3100 H\n
+\t\t\t 9 = GoTView PCI DVD3 Hybrid\n
\t\t\t 0 = Autodetect (default)\n
\t\t\t-1 = Ignore this card\n\t\t);
MODULE_PARM_DESC(pal, Set PAL standard: B, G, H, D, K, I, M, N, Nc, 60);
@@ -333,6 +334,7 @@ void cx18_read_eeprom(struct cx18 *cx, s
tveeprom_hauppauge_analog(c, tv, eedata);
break;
case CX18_CARD_YUAN_MPC718:
+ case CX18_CARD_GOTVIEW_PCI_DVD3:
tv-model = 0x718;
cx18_eeprom_dump(cx, eedata, sizeof(eedata));
CX18_INFO(eeprom PCI ID: %02x%02x:%02x%02x\n,
diff -uprB v4l-dvb.orig/drivers/media/video/cx18/cx18-driver.h
v4l-dvb/drivers/media/video/cx18/cx18-driver.h
---
Re: New media framework user space usage
Hi Bastian,
On Thursday 28 October 2010 16:38:01 Bastian Hecht wrote:
Hello Laurent,
my mt9p031 camera project for the omap3530 isp has come to the point
where the ISP registered video[0-6], media0 and v4l-subdev[0-7].
As far as I can see from the names...
cat /sys/class/video4linux/video*/names
OMAP3 ISP CCP2 input
OMAP3 ISP CSI2a output
OMAP3 ISP CCDC output
OMAP3 ISP preview input
OMAP3 ISP preview output
OMAP3 ISP resizer input
OMAP3 ISP resizer output
cat /sys/class/video4linux/v4l-subdev*/names
OMAP3 ISP CCP2
OMAP3 ISP CSI2a
OMAP3 ISP CCDC
OMAP3 ISP preview
OMAP3 ISP resizer
OMAP3 ISP AEWB
OMAP3 ISP AF
OMAP3 ISP histogram
That's nice, but you seem to be missing a sensor sub-device. See below.
... I want to read /dev/video2 (CCDC).
When I try out a little test program from the V4L2 doc, this line fails:
ioctl (fd, VIDIOC_G_STD, std_id)
The VIDIOC_G_STD ioctl isn't implemented. Just skip that.
So far I adopted your mt9t001 driver, merged it with Guennadis mt9p031. It
contains lot of stubs that I want to fill out when I succeed to make them
called inside the kernel.
I looked at your presentation for the media controller and wonder if I have
to set up a pipeline by myself before I can read /dev/video2
(http://linuxtv.org/downloads/presentations/summit_jun_2010/20100614-
v4l2_summit-media.pdf).
I failed at the point where I wanted to try out the little snippet on page
17 as I don't have definitions of the MEDIA_IOC_ENUM_ENTITIES. Are there
somewhere userspace headers available?
Yes, in include/linux/media.h.
int fd;
fd = open(“/dev/media0”, O_RDWR);
while (1) {
struct media_user_entity entity;
struct media_user_links links;
ret = ioctl(fd, MEDIA_IOC_ENUM_ENTITIES, entity);
if (ret 0)
break;
while (1) {
ret = ioctl(fd, MEDIA_IOC_ENUM_LINKS, links);
if (ret 0)
break;
}
The structure names have changed, you should now use media_entity and
media_links instead of media_user_entity and media_user_links.
You can have a look at http://git.ideasonboard.org/?p=media-ctl.git;a=summary
(new-api branch) to see how links are configured.
[snip]
static int mt9p031_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
struct mt9p031 *mt9p031;
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
int ret;
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) {
dev_warn(adapter-dev,
I2C-Adapter doesn't support I2C_FUNC_SMBUS_WORD\n);
return -EIO;
}
mt9p031 = kzalloc(sizeof(struct mt9p031), GFP_KERNEL);
if (!mt9p031)
return -ENOMEM;
v4l2_i2c_subdev_init(mt9p031-subdev, client, mt9p031_subdev_ops);
Add
mt9p031-subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
here to create a subdev node for the sensor.
[snip]
--
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: New media framework user space usage
Hi Bastian, On Thursday 28 October 2010 17:16:10 Bastian Hecht wrote: after reading the topic controls, subdevs, and media framework (http://www.spinics.net/lists/linux-media/msg24474.html) I guess I double-posted something here :S But what I still don't understand is, how configuring the camera works. You say that the subdevs (my camera sensor) are configured directly. 2 things make me wonder. How gets the ISP informed about the change The ISP doesn't need to know about sensor parameters except for image formats. Formats need to be set on both ends of every link, so the ISP will get informed when you will setup the sensor - CCDC link. and why don't I see my camera in the subdevs name list I posted. All subdevs are from the ISP. See my answer to your previous e-mail for that. My camera already receives a clock, the i2c connection works and my oscilloscope shows that the sensor is throwing out data on the parallel bus pins. But unfortunately I am a completely v4l2 newbie. I read through the v4l2-docs now but the first example already didn't work because of the new framework. Can you point me to a way to read /dev/video2? With the media-ctl and yavta test applications, just run ./media-ctl -r -l 'mt9t001 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9t001 3-005d:0[SGRBG10 1024x768], OMAP3 ISP CCDC:1[SGRBG10 1024x768]' ./yavta -f SGRBG10 -s 1024x768 -n 4 --capture=4 --skip 3 -F $(./media-ctl -e OMAP3 ISP CCDC output) Replace all occurences of 1024x768 by your sensor native resolution, and mt9t001 3-005d by the sensur subdev name. -- 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 0/3] mceusb cleanups and new device support
Another round of mceusb patches... Jarod Wilson (3): mceusb: add support for Conexant Hybrid TV RDU253S mceusb: fix up reporting of trailing space mceusb: buffer parsing fixups for 1st-gen device drivers/media/IR/mceusb.c | 82 +-- 1 files changed, 55 insertions(+), 27 deletions(-) -- Jarod Wilson ja...@redhat.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
[PATCH 1/3] mceusb: add support for Conexant Hybrid TV RDU253S
Another multi-function Conexant device. Interface 0 is IR, though on
this model, TX isn't wired up at all, so I've mixed in support for
models without TX (and verified that lircd says TX isn't supported when
trying to send w/this device).
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/mceusb.c | 37 +++--
1 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 9dce684..e453c6b 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -146,6 +146,7 @@ enum mceusb_model_type {
MCE_GEN3,
MCE_GEN2_TX_INV,
POLARIS_EVK,
+ CX_HYBRID_TV,
};
struct mceusb_model {
@@ -154,6 +155,7 @@ struct mceusb_model {
u32 mce_gen3:1;
u32 tx_mask_inverted:1;
u32 is_polaris:1;
+ u32 no_tx:1;
const char *rc_map; /* Allow specify a per-board map */
const char *name; /* per-board name */
@@ -183,7 +185,12 @@ static const struct mceusb_model mceusb_model[] = {
* to allow testing it
*/
.rc_map = RC_MAP_RC5_HAUPPAUGE_NEW,
- .name = cx231xx MCE IR,
+ .name = Conexant Hybrid TV (cx231xx) MCE IR,
+ },
+ [CX_HYBRID_TV] = {
+ .is_polaris = 1,
+ .no_tx = 1, /* tx isn't wired up at all */
+ .name = Conexant Hybrid TV (cx231xx) MCE IR,
},
};
@@ -292,9 +299,12 @@ static struct usb_device_id mceusb_dev_table[] = {
{ USB_DEVICE(VENDOR_NORTHSTAR, 0xe004) },
/* TiVo PC IR Receiver */
{ USB_DEVICE(VENDOR_TIVO, 0x2000) },
- /* Conexant SDK */
+ /* Conexant Hybrid TV Shelby Polaris SDK */
{ USB_DEVICE(VENDOR_CONEXANT, 0x58a1),
.driver_info = POLARIS_EVK },
+ /* Conexant Hybrid TV RDU253S Polaris */
+ { USB_DEVICE(VENDOR_CONEXANT, 0x58a5),
+ .driver_info = CX_HYBRID_TV },
/* Terminating entry */
{ }
};
@@ -334,6 +344,7 @@ struct mceusb_dev {
u32 connected:1;
u32 tx_mask_inverted:1;
u32 microsoft_gen1:1;
+ u32 no_tx:1;
} flags;
/* transmit support */
@@ -724,7 +735,7 @@ out:
return ret ? ret : n;
}
-/* Sets active IR outputs -- mce devices typically (all?) have two */
+/* Sets active IR outputs -- mce devices typically have two */
static int mceusb_set_tx_mask(void *priv, u32 mask)
{
struct mceusb_dev *ir = priv;
@@ -984,9 +995,11 @@ static void mceusb_get_parameters(struct mceusb_dev *ir)
mce_async_out(ir, GET_CARRIER_FREQ, sizeof(GET_CARRIER_FREQ));
mce_sync_in(ir, NULL, maxp);
- /* get the transmitter bitmask */
- mce_async_out(ir, GET_TX_BITMASK, sizeof(GET_TX_BITMASK));
- mce_sync_in(ir, NULL, maxp);
+ if (!ir-flags.no_tx) {
+ /* get the transmitter bitmask */
+ mce_async_out(ir, GET_TX_BITMASK, sizeof(GET_TX_BITMASK));
+ mce_sync_in(ir, NULL, maxp);
+ }
/* get receiver timeout value */
mce_async_out(ir, GET_RX_TIMEOUT, sizeof(GET_RX_TIMEOUT));
@@ -1035,9 +1048,11 @@ static struct input_dev *mceusb_init_input_dev(struct
mceusb_dev *ir)
props-priv = ir;
props-driver_type = RC_DRIVER_IR_RAW;
props-allowed_protos = IR_TYPE_ALL;
- props-s_tx_mask = mceusb_set_tx_mask;
- props-s_tx_carrier = mceusb_set_tx_carrier;
- props-tx_ir = mceusb_tx_ir;
+ if (!ir-flags.no_tx) {
+ props-s_tx_mask = mceusb_set_tx_mask;
+ props-s_tx_carrier = mceusb_set_tx_carrier;
+ props-tx_ir = mceusb_tx_ir;
+ }
ir-props = props;
@@ -1151,6 +1166,7 @@ static int __devinit mceusb_dev_probe(struct
usb_interface *intf,
ir-len_in = maxp;
ir-flags.microsoft_gen1 = is_microsoft_gen1;
ir-flags.tx_mask_inverted = tx_mask_inverted;
+ ir-flags.no_tx = mceusb_model[model].no_tx;
ir-model = model;
init_ir_raw_event(ir-rawir);
@@ -1191,7 +1207,8 @@ static int __devinit mceusb_dev_probe(struct
usb_interface *intf,
mceusb_get_parameters(ir);
- mceusb_set_tx_mask(ir, MCE_DEFAULT_TX_MASK);
+ if (!ir-flags.no_tx)
+ mceusb_set_tx_mask(ir, MCE_DEFAULT_TX_MASK);
usb_set_intfdata(intf, ir);
--
1.7.1
--
Jarod Wilson
ja...@redhat.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
[PATCH 2/3] mceusb: fix up reporting of trailing space
We were storing a bunch of spaces at the end of each signal, rather than
a single long space. The in-kernel decoders were actually okay with
this, but lirc isn't. Both are happy again with this change, which
starts accumulating data upon seeing an 0x7f space, and then stores it
when we see the next non-space, non-0x7f space, or an 0x80 end of signal
command. To get to that final 0x80 properly, we also need to support
proper parsing of 0x9f 0x01 commands, support for which is also added.
Also remove an obsolete include, some stray colon-space pairs from
prior to conversion to dev_foo printk macros and a magic number.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/mceusb.c | 39 +++
1 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index e453c6b..a05dec7 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -38,7 +38,6 @@
#include linux/usb.h
#include linux/input.h
#include media/ir-core.h
-#include media/ir-common.h
#define DRIVER_VERSION 1.91
#define DRIVER_AUTHOR Jarod Wilson ja...@wilsonet.com
@@ -74,6 +73,7 @@
#define MCE_PACKET_LENGTH_MASK 0x1f /* Packet length mask */
/* Sub-commands, which follow MCE_COMMAND_HEADER or MCE_HW_CMD_HEADER */
+#define MCE_CMD_SIG_END0x01/* End of signal */
#define MCE_CMD_PING 0x03/* Ping device */
#define MCE_CMD_UNKNOWN0x04/* Unknown */
#define MCE_CMD_UNKNOWN2 0x05/* Unknown */
@@ -422,6 +422,7 @@ static int mceusb_cmdsize(u8 cmd, u8 subcmd)
case MCE_CMD_G_RXSENSOR:
datasize = 2;
break;
+ case MCE_CMD_SIG_END:
case MCE_CMD_S_TXMASK:
case MCE_CMD_S_RXSENSOR:
datasize = 1;
@@ -502,6 +503,9 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir,
char *buf,
break;
case MCE_COMMAND_HEADER:
switch (subcmd) {
+ case MCE_CMD_SIG_END:
+ dev_info(dev, End of signal\n);
+ break;
case MCE_CMD_PING:
dev_info(dev, Ping\n);
break;
@@ -539,7 +543,7 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir,
char *buf,
if (len == 2)
dev_info(dev, Get receive sensor\n);
else
- dev_info(dev, Received pulse count is %d\n,
+ dev_info(dev, Remaining pulse count is %d\n,
((data1 8) | data2));
break;
case MCE_RSP_CMD_INVALID:
@@ -763,7 +767,7 @@ static int mceusb_set_tx_carrier(void *priv, u32 carrier)
if (carrier == 0) {
ir-carrier = carrier;
- cmdbuf[2] = 0x01;
+ cmdbuf[2] = MCE_CMD_SIG_END;
cmdbuf[3] = MCE_IRDATA_TRAILER;
dev_dbg(ir-dev, %s: disabling carrier
modulation\n, __func__);
@@ -823,8 +827,11 @@ static void mceusb_process_ir_data(struct mceusb_dev *ir,
int buf_len)
ir-rawir.duration = rawir.duration;
ir-rawir.pulse = rawir.pulse;
}
- if (ir-rem)
- break;
+ if (!ir-rem)
+ ir-parser_state = CMD_HEADER;
+ dev_dbg(ir-dev, Accumulating %d worth of
+ space\n, rawir.duration);
+ break;
}
rawir.duration += ir-rawir.duration;
ir-rawir.duration = 0;
@@ -853,14 +860,14 @@ static void mceusb_process_ir_data(struct mceusb_dev *ir,
int buf_len)
mceusb_dev_printdata(ir, ir-buf_in, i, ir-rem + 1,
false);
if (ir-rem) {
ir-parser_state = PARSE_IRDATA;
- break;
+ } else if (ir-rawir.duration) {
+ /* this means we've encounter an 0x80 pkt,
+* which means end of signal */
+ dev_dbg(ir-dev, Storing final space with
+ duration %d\n, ir-rawir.duration);
+ ir_raw_event_store(ir-idev, ir-rawir);
+ ir-rawir.duration = 0;
}
- /*
-* a package with len=0 (e. g. 0x80) means end of
-*
[PATCH 3/3] mceusb: buffer parsing fixups for 1st-gen device
If we pass in an offset, we shouldn't skip 2 bytes. And the first-gen
hardware generates a constant stream of interrupts, always with two
header bytes, and if there's been no IR, with nothing else. Bail from
ir processing without calling ir_handle_raw_event when we get such a
buffer delivered to us.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/mceusb.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index a05dec7..09a62f1 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -445,7 +445,7 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir,
char *buf,
return;
/* skip meaningless 0xb1 0x60 header bytes on orig receiver */
- if (ir-flags.microsoft_gen1 !out)
+ if (ir-flags.microsoft_gen1 !out !offset)
skip = 2;
if (len = skip)
@@ -806,6 +806,10 @@ static void mceusb_process_ir_data(struct mceusb_dev *ir,
int buf_len)
if (ir-flags.microsoft_gen1)
i = 2;
+ /* if there's no data, just return now */
+ if (buf_len = i)
+ return;
+
for (; i buf_len; i++) {
switch (ir-parser_state) {
case SUBCMD:
--
1.7.1
--
Jarod Wilson
ja...@redhat.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
[RFC PATCH 0/2] Apple remote support
I've got one of those tiny little 6-button Apple remotes here, now it can be decoded in-kernel (tested w/an mceusb transceiver). Jarod Wilson (2): ir-nec-decoder: decode Apple's NEC remote variant IR: add Apple remote keymap drivers/media/IR/ir-nec-decoder.c | 10 +- drivers/media/IR/keymaps/Makefile |1 + drivers/media/IR/keymaps/rc-nec-apple.c | 51 +++ include/media/rc-map.h |1 + 4 files changed, 62 insertions(+), 1 deletions(-) create mode 100644 drivers/media/IR/keymaps/rc-nec-apple.c -- Jarod Wilson ja...@redhat.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
[RFC PATCH 1/2] ir-nec-decoder: decode Apple's NEC remote variant
Apple's remotes use an NEC-like protocol, but without checksumming. See
http://en.wikipedia.org/wiki/Apple_Remote for details. Since they always
send a specific vendor code, check for that, and bypass the checksum
check.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/ir-nec-decoder.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/media/IR/ir-nec-decoder.c
b/drivers/media/IR/ir-nec-decoder.c
index 70993f7..6dcddd2 100644
--- a/drivers/media/IR/ir-nec-decoder.c
+++ b/drivers/media/IR/ir-nec-decoder.c
@@ -50,6 +50,7 @@ static int ir_nec_decode(struct input_dev *input_dev, struct
ir_raw_event ev)
struct nec_dec *data = ir_dev-raw-nec;
u32 scancode;
u8 address, not_address, command, not_command;
+ bool apple = false;
if (!(ir_dev-raw-enabled_protocols IR_TYPE_NEC))
return 0;
@@ -158,7 +159,14 @@ static int ir_nec_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
command = bitrev8((data-bits 8) 0xff);
not_command = bitrev8((data-bits 0) 0xff);
- if ((command ^ not_command) != 0xff) {
+ /* Apple remotes use an NEC-like proto, but w/o a checksum */
+ if ((address == 0xee) (not_address == 0x87)) {
+ apple = true;
+ IR_dprintk(1, Apple remote, ID byte 0x%02x\n,
+ not_command);
+ }
+
+ if (((command ^ not_command) != 0xff) !apple) {
IR_dprintk(1, NEC checksum error: received 0x%08x\n,
data-bits);
break;
--
1.7.1
--
Jarod Wilson
ja...@redhat.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
[RFC PATCH 2/2] IR: add Apple remote keymap
There are at least two variants, and probably more, of the Apple
remotes. http://en.wikipedia.org/wiki/Apple_Remote contains one set of
codes, while the Apple remote I have in my possession sends a slightly
different set of codes. Just add both to the table. Probably needs
extending for the latest Apple remote, but I don't have one of those.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/keymaps/Makefile |1 +
drivers/media/IR/keymaps/rc-nec-apple.c | 51 +++
include/media/rc-map.h |1 +
3 files changed, 53 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/IR/keymaps/rc-nec-apple.c
diff --git a/drivers/media/IR/keymaps/Makefile
b/drivers/media/IR/keymaps/Makefile
index 3194d39..8fa0e53 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-msi-tvanywhere.o \
rc-msi-tvanywhere-plus.o \
rc-nebula.o \
+ rc-nec-apple.o \
rc-nec-terratec-cinergy-xs.o \
rc-norwood.o \
rc-npgtech.o \
diff --git a/drivers/media/IR/keymaps/rc-nec-apple.c
b/drivers/media/IR/keymaps/rc-nec-apple.c
new file mode 100644
index 000..9f6189c
--- /dev/null
+++ b/drivers/media/IR/keymaps/rc-nec-apple.c
@@ -0,0 +1,51 @@
+/* rc-nec-apple.c - Keytable for Apple Remote Controls
+ *
+ * Copyright (c) 2010 by Jarod Wilson ja...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+
+static struct ir_scancode nec_apple[] = {
+ { 0xee8702, KEY_MENU},
+ { 0xee8703, KEY_MENU},
+ { 0xee8704, KEY_PLAYPAUSE},
+ { 0xee8705, KEY_PLAYPAUSE},
+ { 0xee8706, KEY_FORWARD},
+ { 0xee8707, KEY_FORWARD},
+ { 0xee8708, KEY_BACK},
+ { 0xee8709, KEY_BACK},
+ { 0xee870a, KEY_VOLUMEUP},
+ { 0xee870b, KEY_VOLUMEUP},
+ { 0xee870c, KEY_VOLUMEDOWN},
+ { 0xee870d, KEY_VOLUMEDOWN},
+};
+
+static struct rc_keymap nec_apple_map = {
+ .map = {
+ .scan= nec_apple,
+ .size= ARRAY_SIZE(nec_apple),
+ .ir_type = IR_TYPE_NEC,
+ .name= RC_MAP_NEC_APPLE,
+ }
+};
+
+static int __init init_rc_map_nec_apple(void)
+{
+ return ir_register_map(nec_apple_map);
+}
+
+static void __exit exit_rc_map_nec_apple(void)
+{
+ ir_unregister_map(nec_apple_map);
+}
+
+module_init(init_rc_map_nec_apple)
+module_exit(exit_rc_map_nec_apple)
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Jarod Wilson ja...@redhat.com);
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 25883cf..868f0c3 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -110,6 +110,7 @@ void rc_map_init(void);
#define RC_MAP_MSI_TVANYWHERE_PLUS rc-msi-tvanywhere-plus
#define RC_MAP_MSI_TVANYWHERErc-msi-tvanywhere
#define RC_MAP_NEBULArc-nebula
+#define RC_MAP_NEC_APPLE rc-nec-apple
#define RC_MAP_NEC_TERRATEC_CINERGY_XS rc-nec-terratec-cinergy-xs
#define RC_MAP_NORWOOD rc-norwood
#define RC_MAP_NPGTECH rc-npgtech
--
1.7.1
--
Jarod Wilson
ja...@redhat.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 PATCH 0/2] Apple remote support
On Thu, Oct 28, 2010 at 11:11:31PM -0400, Jarod Wilson wrote: I've got one of those tiny little 6-button Apple remotes here, now it can be decoded in-kernel (tested w/an mceusb transceiver). Oh yeah, RFC, because I'm not sure if we should have a more generic skip the checksum check support -- I seem to recall discussion about it in the not so recent past. And a decoder hack for one specific remote is just kinda ugly... -- Jarod Wilson ja...@redhat.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
