Reception Troubles with Hauppauge Nova-TD Stick
Hello, I am running the Hauppauge Nova-TD Stick using the latest git drivers (I followed http://wiki.ubuntuusers.de/v4l-dvb) under Ubuntu 11.04. The stick seems to work fine, it is detected and usable by the software (w_scan, VDR, mythtv). However, the reception is very bad. Only one out of the 5 (or so) available MUXes is detected. The reception on this one mux is very bad (no stable video). Signal strength (as reported by vdr-femon) is at 40-50%, STR is less than 10%. I have tried the force_lna_activation=1 option, but that didn't make any difference. I am using the supplied antenna adapter to connect a small stick antenna. I noticed that unplugging the Antenna didn't really make the reception worse. Unplugging the adapter reduced the signal strength significantly. The stick works just fine under Windows (all MUXes are detected with good image quality). I noticed that the LED on the stick has a different color under windows (blue) than under Linux (green) - if that makes any difference. So, is there anyone that can help? Any ideas how I can get this to work? Kind Regards, Jonas -- 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: dual sveon stv22 Afatech af9015 support (kworld clone)
On 06/20/2011 11:51 AM, David wrote: Hello again: I ' m working with remote in sveon stv22: remote es a grid of buttons 4 buttons horizontally and 8 vertically That's RC_MAP_MSI_DIGIVOX_III remote. It is already used by that AF9015. You should add USB-ID mapping for that remote to auto detect. [...] If you want anything more tell my it . thanks for your time You should make patch or two and send for me in order to get changes upstream. 1. add support for your device (USB ID + name) 2. map remote to your device. regards Antti -- http://palosaari.fi/ -- 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 v8 1/2] Add driver for Aptina Micron mt9p031 sensor.
Fix BUG with output_control register and frequency calculation problems. - Output control register was being smashed, thus causing pixclk to have a high slew rate. - We cannot assume that we will always have a 20MHz input freq, so a table has been added so that the user can specify input freq and desired freq. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9p031.c | 928 + include/media/mt9p031.h | 19 + 4 files changed, 955 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 00f51dd..5f851f0 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -329,6 +329,13 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- + This is a Video4Linux2 sensor-level driver for the Aptina + (Micron) mt9p031 5 Mpixel camera. + config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index ace5d8b..912b29b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o +obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..6b25a1b --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,928 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h + +#define MT9P031_CHIP_VERSION 0x00 +#defineMT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START 0x01 +#defineMT9P031_ROW_START_MIN 1 +#defineMT9P031_ROW_START_MAX 2004 +#defineMT9P031_ROW_START_DEF 54 +#define MT9P031_COLUMN_START 0x02 +#defineMT9P031_COLUMN_START_MIN1 +#defineMT9P031_COLUMN_START_MAX2750 +#defineMT9P031_COLUMN_START_DEF16 +#define MT9P031_WINDOW_HEIGHT 0x03 +#defineMT9P031_WINDOW_HEIGHT_MIN 2 +#defineMT9P031_WINDOW_HEIGHT_MAX 2003 +#defineMT9P031_WINDOW_HEIGHT_DEF 2003 +#define MT9P031_WINDOW_WIDTH 0x04 +#defineMT9P031_WINDOW_WIDTH_MIN18 +#defineMT9P031_WINDOW_WIDTH_MAX2751 +#defineMT9P031_WINDOW_WIDTH_DEF2751 +#define MT9P031_H_BLANKING 0x05 +#defineMT9P031_H_BLANKING_VALUE0 +#define MT9P031_V_BLANKING 0x06 +#defineMT9P031_V_BLANKING_VALUE25 +#define MT9P031_OUTPUT_CONTROL 0x07 +#defineMT9P031_OUTPUT_CONTROL_CEN 2 +#defineMT9P031_OUTPUT_CONTROL_SYN 1 +#defineMT9P031_OUTPUT_CONTROL_DEF 0x1f82 +#define MT9P031_SHUTTER_WIDTH_UPPER0x08 +#define MT9P031_SHUTTER_WIDTH_LOWER0x09 +#defineMT9P031_SHUTTER_WIDTH_MIN 0x0001 +#defineMT9P031_SHUTTER_WIDTH_MAX 0x7ff +#defineMT9P031_SHUTTER_WIDTH_DEF 0x0797 +#defineMT9P031_PLL_CONTROL 0x10 +#defineMT9P031_PLL_CONTROL_PWROFF 0x0050 +#defineMT9P031_PLL_CONTROL_PWRON 0x0051 +#defineMT9P031_PLL_CONTROL_USEPLL 0x0052 +#define
[PATCH v8 2/2] Add support for mt9p031 sensor in Beagleboard XM.
Use new platform data ext_freq and target_freq.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3beagle-camera.c | 95
arch/arm/mach-omap2/board-omap3beagle.c| 50
3 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3beagle-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..05cd983 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_MACH_OMAP_2430SDP) +=
board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
+ board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
b/arch/arm/mach-omap2/board-omap3beagle-camera.c
new file mode 100644
index 000..96b4f95
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,95 @@
+#include linux/gpio.h
+#include linux/regulator/machine.h
+
+#include plat/i2c.h
+
+#include media/mt9p031.h
+#include asm/mach-types.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
+#define MT9P031_EXT_FREQ 2100
+
+static struct regulator *reg_1v8, *reg_2v8;
+
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+
+ return isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+}
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+ .ext_freq = MT9P031_EXT_FREQ,
+ .target_freq= 4800,
+ .version= MT9P031_COLOR_VERSION,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO(mt9p031, 0x48),
+ .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
+static int __init beagle_camera_init(void)
+{
+ if (!machine_is_omap3_beagle() || !cpu_is_omap3630())
+ return 0;
+
+ reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(reg_1v8))
+ pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_1v8);
+
+ reg_2v8 = regulator_get(NULL, cam_2v8);
+ if (IS_ERR(reg_2v8))
+ pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_2v8);
+
+ omap_register_i2c_bus(2, 100, NULL, 0);
+ gpio_request(MT9P031_RESET_GPIO, cam_rst);
+ gpio_direction_output(MT9P031_RESET_GPIO, 0);
+ omap3_init_camera(beagle_isp_platform_data);
+ return 0;
+}
+late_initcall(beagle_camera_init);
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..c14e9d6 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -30,6 +30,7 @@
#include linux/mtd/nand.h
#include linux/mmc/host.h
+#include linux/gpio.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
@@ -273,6 +274,44 @@ static struct regulator_consumer_supply beagle_vsim_supply
= {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct
Re: Bug: media_build always compiles with '-DDEBUG'
Hi Mauro, On Sunday 19 June 2011 13:47:16 Mauro Carvalho Chehab wrote: Em 19-06-2011 02:00, Helmut Auer escreveu: Am 18.06.2011 23:38, schrieb Oliver Endriss: On Saturday 18 June 2011 23:11:21 Helmut Auer wrote: Hi Replacing ifdef CONFIG_VIDEO_OMAP3_DEBUG by ifeq ($(CONFIG_VIDEO_OMAP3_DEBUG),y) would do the trick. I guess that would not ive the intended result. Setting CONFIG_VIDEO_OMAP3_DEBUG to yes should not lead to debug messages in all media modules, True, but it will happen only if you manually enable CONFIG_VIDEO_OMAP3_DEBUG in Kconfig. You cannot avoid this without major changes of the media_build system - imho not worth the effort. Then imho it would be better to drop the CONFIG_VIDEO_OMAP3_DEBUG variable completely, you can set CONFIG_DEBUG which would give the same results. Good catch! Yes, I agree that the better is to just drop CONFIG_VIDEO_OMAP3_DEBUG variable completely. If someone wants to build with -DDEBUG, he can just use CONFIG_DEBUG. Laurent, Any comments? CONFIG_VIDEO_OMAP3_DEBUG is used to build the OMAP3 ISP driver in debug mode, without having to compile the whole kernel with debugging enabled. I'd like to keep that feature if possible. -- 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: Bug: media_build always compiles with '-DDEBUG'
Em 20-06-2011 09:35, Laurent Pinchart escreveu: Hi Mauro, On Sunday 19 June 2011 13:47:16 Mauro Carvalho Chehab wrote: Em 19-06-2011 02:00, Helmut Auer escreveu: Am 18.06.2011 23:38, schrieb Oliver Endriss: On Saturday 18 June 2011 23:11:21 Helmut Auer wrote: Hi Replacing ifdef CONFIG_VIDEO_OMAP3_DEBUG by ifeq ($(CONFIG_VIDEO_OMAP3_DEBUG),y) would do the trick. I guess that would not ive the intended result. Setting CONFIG_VIDEO_OMAP3_DEBUG to yes should not lead to debug messages in all media modules, True, but it will happen only if you manually enable CONFIG_VIDEO_OMAP3_DEBUG in Kconfig. You cannot avoid this without major changes of the media_build system - imho not worth the effort. Then imho it would be better to drop the CONFIG_VIDEO_OMAP3_DEBUG variable completely, you can set CONFIG_DEBUG which would give the same results. Good catch! Yes, I agree that the better is to just drop CONFIG_VIDEO_OMAP3_DEBUG variable completely. If someone wants to build with -DDEBUG, he can just use CONFIG_DEBUG. Laurent, Any comments? CONFIG_VIDEO_OMAP3_DEBUG is used to build the OMAP3 ISP driver in debug mode, without having to compile the whole kernel with debugging enabled. I'd like to keep that feature if possible. If you want that, build it using media_build. I don't care of having such hacks there, but having it upstream is not the right thing to do. 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: [RFCv3 PATCH 08/18] v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain scenarios
Hi Hans, Thanks for the patch. On Tuesday 07 June 2011 17:05:13 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com It is a bit tricky to handle autogain/gain type scenerios correctly. Such controls need to be clustered and the V4L2_CTRL_FLAG_UPDATE should be set on the autofoo controls. In addition, the manual controls should be marked inactive when the automatic mode is on, and active when the manual mode is on. This also requires specialized volatile handling. The chances of drivers doing all these things correctly are pretty remote. So a new v4l2_ctrl_auto_cluster function was added that takes care of these issues. Sorry for being a killjoy, but how is this supposed to handle the auto- exposure control ? Auto-exposure can be in complete auto mode, where both exposure time and aperture are controlled automatically, in exposure- or aperture-priority mode, where only one the exposure time and aperture is controlled automatically, or in manual mode. -- 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: [beagleboard] [PATCH v8 2/2] Add support for mt9p031 sensor in Beagleboard XM.
PLEASE TAKE NOTE - THIS IS THE THIRD TIME I HAVE ASKED FOR UNSUBSCRIBE
The email address lwal...@bluechiptechnology.co.uk nneds to be deleted
urgently. This is a former employee, I have to monitor this email box and it
is full of this beagleboard messaging which is no longer relevant to this
business.;
PLEASE ACTION URGENTLY
M G Gulliford
Blue Chip Te4chnology Ltd
-Original Message-
From: Javier Martin javier.mar...@vista-silicon.com
Sent: 20/06/2011 12:21
To: linux-media@vger.kernel.org linux-media@vger.kernel.org
Cc: g.liakhovet...@gmx.de g.liakhovet...@gmx.de;
laurent.pinch...@ideasonboard.com laurent.pinch...@ideasonboard.com;
carlight...@yahoo.co.nz carlight...@yahoo.co.nz;
beaglebo...@googlegroups.com beaglebo...@googlegroups.com;
mch_...@yahoo.com.cn mch_...@yahoo.com.cn; Javier Martin
javier.mar...@vista-silicon.com
Subject: [beagleboard] [PATCH v8 2/2] Add support for mt9p031 sensor in
Beagleboard XM.
Use new platform data ext_freq and target_freq.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3beagle-camera.c | 95
arch/arm/mach-omap2/board-omap3beagle.c| 50
3 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3beagle-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..05cd983 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_MACH_OMAP_2430SDP) +=
board-2430sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
+ board-omap3beagle-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
b/arch/arm/mach-omap2/board-omap3beagle-camera.c
new file mode 100644
index 000..96b4f95
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -0,0 +1,95 @@
+#include linux/gpio.h
+#include linux/regulator/machine.h
+
+#include plat/i2c.h
+
+#include media/mt9p031.h
+#include asm/mach-types.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
+#define MT9P031_EXT_FREQ 2100
+
+static struct regulator *reg_1v8, *reg_2v8;
+
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+
+ return isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+}
+
+static int beagle_cam_reset(struct v4l2_subdev *subdev, int active)
+{
+ /* Set RESET_BAR to !active */
+ gpio_set_value(MT9P031_RESET_GPIO, !active);
+
+ return 0;
+}
+
+static struct mt9p031_platform_data beagle_mt9p031_platform_data = {
+ .set_xclk = beagle_cam_set_xclk,
+ .reset = beagle_cam_reset,
+ .ext_freq = MT9P031_EXT_FREQ,
+ .target_freq= 4800,
+ .version= MT9P031_COLOR_VERSION,
+};
+
+static struct i2c_board_info mt9p031_camera_i2c_device = {
+ I2C_BOARD_INFO(mt9p031, 0x48),
+ .platform_data = beagle_mt9p031_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info mt9p031_camera_subdevs[] = {
+ {
+ .board_info = mt9p031_camera_i2c_device,
+ .i2c_adapter_id = 2,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group beagle_camera_subdevs[] = {
+ {
+ .subdevs = mt9p031_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 1,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ { },
+};
+
+static struct isp_platform_data beagle_isp_platform_data = {
+ .subdevs = beagle_camera_subdevs,
+};
+
+static int __init beagle_camera_init(void)
+{
+ if (!machine_is_omap3_beagle() || !cpu_is_omap3630())
+ return 0;
+
+ reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(reg_1v8))
+ pr_err(%s: cannot get cam_1v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_1v8);
+
+ reg_2v8 = regulator_get(NULL, cam_2v8);
+ if (IS_ERR(reg_2v8))
+ pr_err(%s: cannot get cam_2v8 regulator\n, __func__);
+ else
+ regulator_enable(reg_2v8);
+
+ omap_register_i2c_bus(2, 100, NULL, 0);
+
Re: [RFCv3 PATCH 08/18] v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain scenarios
On Monday, June 20, 2011 15:05:47 Laurent Pinchart wrote: Hi Hans, Thanks for the patch. On Tuesday 07 June 2011 17:05:13 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com It is a bit tricky to handle autogain/gain type scenerios correctly. Such controls need to be clustered and the V4L2_CTRL_FLAG_UPDATE should be set on the autofoo controls. In addition, the manual controls should be marked inactive when the automatic mode is on, and active when the manual mode is on. This also requires specialized volatile handling. The chances of drivers doing all these things correctly are pretty remote. So a new v4l2_ctrl_auto_cluster function was added that takes care of these issues. Sorry for being a killjoy, but how is this supposed to handle the auto- exposure control ? Auto-exposure can be in complete auto mode, where both exposure time and aperture are controlled automatically, in exposure- or aperture-priority mode, where only one the exposure time and aperture is controlled automatically, or in manual mode. That you will have to implement yourself. This may need some additional support from the framework. v4l2_ctrl_auto_cluster() is meant to cater to most, but not necessarily all, use cases. This particular case clearly falls out of the scope of that function. Hmm, perhaps it should be extended with an optional callback function. That would be the most general approach. But let's deal with that when we get there. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv3 PATCH 13/18] v4l2-ctrls: add control events.
Hi Hans,
Thanks for the patch, and sorry for the late review.
On Tuesday 07 June 2011 17:05:18 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Whenever a control changes value or state an event is sent to anyone
that subscribed to it.
This functionality is useful for control panels but also for applications
that need to wait for (usually status) controls to change value.
[snip]
+static void send_event(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, u32
changes) +{
+ struct v4l2_event ev;
+ struct v4l2_ctrl_fh *pos;
+
+ if (list_empty(ctrl-fhs))
+ return;
There's one extra tab here.
+ fill_event(ev, ctrl, changes);
+
+ list_for_each_entry(pos, ctrl-fhs, node)
+ if (pos-fh != fh)
+ v4l2_event_queue_fh(pos-fh, ev);
+}
[snip]
@@ -1222,15 +1279,21 @@ EXPORT_SYMBOL(v4l2_ctrl_auto_cluster);
/* Activate/deactivate a control. */
void v4l2_ctrl_activate(struct v4l2_ctrl *ctrl, bool active)
{
+ /* invert since the actual flag is called 'inactive' */
+ bool inactive = !active;
+ bool old;
+
if (ctrl == NULL)
return;
- if (!active)
+ if (inactive)
/* set V4L2_CTRL_FLAG_INACTIVE */
- set_bit(4, ctrl-flags);
+ old = test_and_set_bit(4, ctrl-flags);
I've never been found of hardcoded constants. What about
ffs(V4L2_CTRL_FLAG_INACTIVE) - 1 instead ? gcc will optimize that to a
constant.
else
/* clear V4L2_CTRL_FLAG_INACTIVE */
- clear_bit(4, ctrl-flags);
+ old = test_and_clear_bit(4, ctrl-flags);
+ if (old != inactive)
+ send_event(NULL, ctrl, V4L2_EVENT_CTRL_CH_FLAGS);
}
EXPORT_SYMBOL(v4l2_ctrl_activate);
[snip]
@@ -182,37 +218,26 @@ void v4l2_event_queue(struct video_device *vdev,
const struct v4l2_event *ev) spin_lock_irqsave(vdev-fh_lock, flags);
list_for_each_entry(fh, vdev-fh_list, list) {
- struct v4l2_events *events = fh-events;
- struct v4l2_kevent *kev;
-
- /* Are we subscribed? */
- if (!v4l2_event_subscribed(fh, ev-type))
- continue;
-
- /* Increase event sequence number on fh. */
- events-sequence++;
-
- /* Do we have any free events? */
- if (list_empty(events-free))
- continue;
-
- /* Take one and fill it. */
- kev = list_first_entry(events-free, struct v4l2_kevent, list);
- kev-event.type = ev-type;
- kev-event.u = ev-u;
- kev-event.timestamp = timestamp;
- kev-event.sequence = events-sequence;
- list_move_tail(kev-list, events-available);
-
- events-navailable++;
-
- wake_up_all(events-wait);
+ __v4l2_event_queue_fh(fh, ev, timestamp);
}
You can remove the braces.
spin_unlock_irqrestore(vdev-fh_lock, flags);
}
EXPORT_SYMBOL_GPL(v4l2_event_queue);
--
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: Bug: media_build always compiles with '-DDEBUG'
Hi Mauro,
On Monday 20 June 2011 14:50:28 Mauro Carvalho Chehab wrote:
Em 20-06-2011 09:35, Laurent Pinchart escreveu:
On Sunday 19 June 2011 13:47:16 Mauro Carvalho Chehab wrote:
Em 19-06-2011 02:00, Helmut Auer escreveu:
Am 18.06.2011 23:38, schrieb Oliver Endriss:
On Saturday 18 June 2011 23:11:21 Helmut Auer wrote:
Hi
Replacing
ifdef CONFIG_VIDEO_OMAP3_DEBUG
by
ifeq ($(CONFIG_VIDEO_OMAP3_DEBUG),y)
would do the trick.
I guess that would not ive the intended result.
Setting CONFIG_VIDEO_OMAP3_DEBUG to yes should not lead to debug
messages in all media modules,
True, but it will happen only if you manually enable
CONFIG_VIDEO_OMAP3_DEBUG in Kconfig.
You cannot avoid this without major changes of the
media_build system - imho not worth the effort.
Then imho it would be better to drop the CONFIG_VIDEO_OMAP3_DEBUG
variable completely, you can set CONFIG_DEBUG which would give the same
results.
Good catch!
Yes, I agree that the better is to just drop CONFIG_VIDEO_OMAP3_DEBUG
variable completely. If someone wants to build with -DDEBUG, he can just
use CONFIG_DEBUG.
Laurent,
Any comments?
CONFIG_VIDEO_OMAP3_DEBUG is used to build the OMAP3 ISP driver in debug
mode, without having to compile the whole kernel with debugging enabled.
I'd like to keep that feature if possible.
If you want that, build it using media_build. I don't care of having such
hacks there, but having it upstream is not the right thing to do.
It's not a hack. Lots of drivers have debugging Kconfig options.
$ find linux-2.6 -type f -name Kconfig* -exec grep '^config.*DEBUG' {} \; | wc
243 4865826
--
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: [beagleboard] [PATCH v8 2/2] Add support for mt9p031 sensor in Beagleboard XM.
On Monday 20 June 2011 15:00:00 Mike Gulliford wrote: PLEASE TAKE NOTE - THIS IS THE THIRD TIME I HAVE ASKED FOR UNSUBSCRIBE And this is the third time you fail to read the e-mail until the end, where simple unsubscribing instructions are available. The email address lwal...@bluechiptechnology.co.uk nneds to be deleted urgently. This is a former employee, I have to monitor this email box and it is full of this beagleboard messaging which is no longer relevant to this business.; Send an e-mail from that address to beagleboard+unsubscr...@googlegroups.com PLEASE ACTION URGENTLY Shooting on mailing lists isn't considered as polite. -- 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: [RFCv1 PATCH 2/8] v4l2-ctrls/event: remove struct v4l2_ctrl_fh, instead use v4l2_subscribed_event
Hi Hans,
Thanks for the patch.
On Tuesday 14 June 2011 17:22:27 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
The v4l2_ctrl_fh struct connected v4l2_ctrl with v4l2_fh so the control
would know which filehandles subscribed to it. However, it is much easier
to use struct v4l2_subscribed_event directly for that and get rid of that
intermediate struct.
[snip]
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 042b893..eda17f8 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -38,9 +38,18 @@ struct v4l2_kevent {
};
struct v4l2_subscribed_event {
+ /* list node for the v4l2_fh-subscribed list */
struct list_headlist;
+ /* event type */
u32 type;
+ /* associated object ID (e.g. control ID) */
u32 id;
+ /* copy of v4l2_event_subscription-flags */
+ u32 flags;
+ /* filehandle that subscribed to this event */
+ struct v4l2_fh *fh;
+ /* list node that hooks into the object's event list (if there is one)
*/
+ struct list_headnode;
};
int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n);
What about using kerneldoc style and document the structure in a single
comment block right above it ? I find it easier to read.
--
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: Bug: media_build always compiles with '-DDEBUG'
Em 20-06-2011 10:38, Laurent Pinchart escreveu:
Hi Mauro,
On Monday 20 June 2011 14:50:28 Mauro Carvalho Chehab wrote:
Em 20-06-2011 09:35, Laurent Pinchart escreveu:
On Sunday 19 June 2011 13:47:16 Mauro Carvalho Chehab wrote:
Em 19-06-2011 02:00, Helmut Auer escreveu:
Am 18.06.2011 23:38, schrieb Oliver Endriss:
On Saturday 18 June 2011 23:11:21 Helmut Auer wrote:
Hi
Replacing
ifdef CONFIG_VIDEO_OMAP3_DEBUG
by
ifeq ($(CONFIG_VIDEO_OMAP3_DEBUG),y)
would do the trick.
I guess that would not ive the intended result.
Setting CONFIG_VIDEO_OMAP3_DEBUG to yes should not lead to debug
messages in all media modules,
True, but it will happen only if you manually enable
CONFIG_VIDEO_OMAP3_DEBUG in Kconfig.
You cannot avoid this without major changes of the
media_build system - imho not worth the effort.
Then imho it would be better to drop the CONFIG_VIDEO_OMAP3_DEBUG
variable completely, you can set CONFIG_DEBUG which would give the same
results.
Good catch!
Yes, I agree that the better is to just drop CONFIG_VIDEO_OMAP3_DEBUG
variable completely. If someone wants to build with -DDEBUG, he can just
use CONFIG_DEBUG.
Laurent,
Any comments?
CONFIG_VIDEO_OMAP3_DEBUG is used to build the OMAP3 ISP driver in debug
mode, without having to compile the whole kernel with debugging enabled.
I'd like to keep that feature if possible.
If you want that, build it using media_build. I don't care of having such
hacks there, but having it upstream is not the right thing to do.
It's not a hack. Lots of drivers have debugging Kconfig options.
$ find linux-2.6 -type f -name Kconfig* -exec grep '^config.*DEBUG' {} \; | wc
243 4865826
Your query is wrong. The proper query is:
$ find . -type f -name Makefile -exec grep -rH 'EXTRA_CFLAGS.*\-DDEBUG$' {} \;
./arch/x86/pci/Makefile:EXTRA_CFLAGS += -DDEBUG
./drivers/pps/generators/Makefile:EXTRA_CFLAGS += -DDEBUG
./drivers/media/video/omap3isp/Makefile:EXTRA_CFLAGS += -DDEBUG
There's nothing wrong with a debug Kconfig option
for omap3. What's wrong is:
1) It is badly implemented: it is just enabling -DDEBUG for the entire
subsystem, as the test is wrong;
2) Even if you fix, you'll be enabling debug to the entire subsystem, if you
keep adding things to EXTRA_CFLAGS.
It should be noticed that several places use a different syntax for enabling
per-driver/per-subsystem -D flag:
find . -type f -name Makefile -exec grep -rH '\-DDEBUG$' {} \;
...
./drivers/mmc/Makefile:subdir-ccflags-$(CONFIG_MMC_DEBUG) := -DDEBUG
...
./drivers/infiniband/hw/cxgb3/Makefile:ccflags-$(CONFIG_INFINIBAND_CXGB3_DEBUG)
+= -DDEBUG
I _suspect_ that using ccflags-$(foo_DEBUG) may work.
Thanks,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 4/8] v4l2-event: add optional 'merge' callback to merge two events
Hi Hans,
Thanks for the patch.
On Tuesday 14 June 2011 17:22:29 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
When the event queue for a subscribed event is full, then the oldest
event is dropped. It would be nice if the contents of that oldest
event could be merged with the next-oldest. That way no information is
lost, only intermediate steps are lost.
This patch adds an optional merge function that will be called to do
this job and implements it for the control event.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-event.c | 27 ++-
include/media/v4l2-event.h |5 +
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-event.c
b/drivers/media/video/v4l2-event.c index 9e325dd..aeec2d5 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -113,6 +113,7 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh,
const struct v4l2_event *e {
struct v4l2_subscribed_event *sev;
struct v4l2_kevent *kev;
+ bool copy_payload = true;
/* Are we subscribed? */
sev = v4l2_event_subscribed(fh, ev-type, ev-id);
@@ -130,12 +131,23 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh,
const struct v4l2_event *e sev-in_use--;
sev-first = sev_pos(sev, 1);
fh-navailable--;
+ if (sev-merge) {
+ if (sev-elems == 1) {
+ sev-merge(kev-event, ev, kev-event);
+ copy_payload = false;
+ } else {
+ struct v4l2_kevent *second_oldest =
+ sev-events + sev_pos(sev, 0);
+ sev-merge(second_oldest-event,
second_oldest-event, kev-
event);
+ }
+ }
}
/* Take one and fill it. */
kev = sev-events + sev_pos(sev, sev-in_use);
kev-event.type = ev-type;
- kev-event.u = ev-u;
+ if (copy_payload)
+ kev-event.u = ev-u;
kev-event.id = ev-id;
kev-event.timestamp = *ts;
kev-event.sequence = fh-sequence;
@@ -184,6 +196,17 @@ int v4l2_event_pending(struct v4l2_fh *fh)
}
EXPORT_SYMBOL_GPL(v4l2_event_pending);
+static void ctrls_merge(struct v4l2_event *dst,
+ const struct v4l2_event *new,
+ const struct v4l2_event *old)
+{
+ u32 changes = new-u.ctrl.changes | old-u.ctrl.changes;
+
+ if (dst == old)
+ dst-u.ctrl = new-u.ctrl;
+ dst-u.ctrl.changes = changes;
+}
+
int v4l2_event_subscribe(struct v4l2_fh *fh,
struct v4l2_event_subscription *sub, unsigned elems)
{
@@ -210,6 +233,8 @@ int v4l2_event_subscribe(struct v4l2_fh *fh,
sev-flags = sub-flags;
sev-fh = fh;
sev-elems = elems;
+ if (ctrl)
+ sev-merge = ctrls_merge;
spin_lock_irqsave(fh-vdev-fh_lock, flags);
found_ev = v4l2_event_subscribed(fh, sub-type, sub-id);
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 8d681e5..111b2bc 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -55,6 +55,11 @@ struct v4l2_subscribed_event {
struct v4l2_fh *fh;
/* list node that hooks into the object's event list (if there is one)
*/
struct list_headnode;
+ /* Optional callback that can merge two events.
+Note that 'dst' can be the same as either 'new' or 'old'. */
This can lead to various problems in drivers, if the code forgets that
changing dst will change new or old. Would it be possible to make it a two
arguments (dst, src) function ?
+ void(*merge)(struct v4l2_event *dst,
+ const struct v4l2_event *new,
+ const struct v4l2_event *old);
/* the number of elements in the events array */
unsignedelems;
/* the index of the events containing the oldest available event */
--
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: [RFCv1 PATCH 4/8] v4l2-event: add optional 'merge' callback to merge two events
On Monday, June 20, 2011 16:09:32 Laurent Pinchart wrote:
Hi Hans,
Thanks for the patch.
On Tuesday 14 June 2011 17:22:29 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
When the event queue for a subscribed event is full, then the oldest
event is dropped. It would be nice if the contents of that oldest
event could be merged with the next-oldest. That way no information is
lost, only intermediate steps are lost.
This patch adds an optional merge function that will be called to do
this job and implements it for the control event.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-event.c | 27 ++-
include/media/v4l2-event.h |5 +
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-event.c
b/drivers/media/video/v4l2-event.c index 9e325dd..aeec2d5 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -113,6 +113,7 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh,
const struct v4l2_event *e {
struct v4l2_subscribed_event *sev;
struct v4l2_kevent *kev;
+ bool copy_payload = true;
/* Are we subscribed? */
sev = v4l2_event_subscribed(fh, ev-type, ev-id);
@@ -130,12 +131,23 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh,
const struct v4l2_event *e sev-in_use--;
sev-first = sev_pos(sev, 1);
fh-navailable--;
+ if (sev-merge) {
+ if (sev-elems == 1) {
+ sev-merge(kev-event, ev, kev-event);
+ copy_payload = false;
+ } else {
+ struct v4l2_kevent *second_oldest =
+ sev-events + sev_pos(sev, 0);
+ sev-merge(second_oldest-event,
second_oldest-event, kev-
event);
+ }
+ }
}
/* Take one and fill it. */
kev = sev-events + sev_pos(sev, sev-in_use);
kev-event.type = ev-type;
- kev-event.u = ev-u;
+ if (copy_payload)
+ kev-event.u = ev-u;
kev-event.id = ev-id;
kev-event.timestamp = *ts;
kev-event.sequence = fh-sequence;
@@ -184,6 +196,17 @@ int v4l2_event_pending(struct v4l2_fh *fh)
}
EXPORT_SYMBOL_GPL(v4l2_event_pending);
+static void ctrls_merge(struct v4l2_event *dst,
+ const struct v4l2_event *new,
+ const struct v4l2_event *old)
+{
+ u32 changes = new-u.ctrl.changes | old-u.ctrl.changes;
+
+ if (dst == old)
+ dst-u.ctrl = new-u.ctrl;
+ dst-u.ctrl.changes = changes;
+}
+
int v4l2_event_subscribe(struct v4l2_fh *fh,
struct v4l2_event_subscription *sub, unsigned elems)
{
@@ -210,6 +233,8 @@ int v4l2_event_subscribe(struct v4l2_fh *fh,
sev-flags = sub-flags;
sev-fh = fh;
sev-elems = elems;
+ if (ctrl)
+ sev-merge = ctrls_merge;
spin_lock_irqsave(fh-vdev-fh_lock, flags);
found_ev = v4l2_event_subscribed(fh, sub-type, sub-id);
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 8d681e5..111b2bc 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -55,6 +55,11 @@ struct v4l2_subscribed_event {
struct v4l2_fh *fh;
/* list node that hooks into the object's event list (if there is one)
*/
struct list_headnode;
+ /* Optional callback that can merge two events.
+ Note that 'dst' can be the same as either 'new' or 'old'. */
This can lead to various problems in drivers, if the code forgets that
changing dst will change new or old. Would it be possible to make it a two
arguments (dst, src) function ?
This has been split into a replace and a merge function in the final patch in
my pull request. It's the only change I made (besides documentation) compared
to the RFCv1. This merge function was a bit too obscure and splitting it up
into two callbacks worked much better.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: media_build always compiles with '-DDEBUG'
Hi Mauro,
On Monday 20 June 2011 16:05:39 Mauro Carvalho Chehab wrote:
Em 20-06-2011 10:38, Laurent Pinchart escreveu:
On Monday 20 June 2011 14:50:28 Mauro Carvalho Chehab wrote:
Em 20-06-2011 09:35, Laurent Pinchart escreveu:
On Sunday 19 June 2011 13:47:16 Mauro Carvalho Chehab wrote:
Em 19-06-2011 02:00, Helmut Auer escreveu:
Am 18.06.2011 23:38, schrieb Oliver Endriss:
On Saturday 18 June 2011 23:11:21 Helmut Auer wrote:
Hi
Replacing
ifdef CONFIG_VIDEO_OMAP3_DEBUG
by
ifeq ($(CONFIG_VIDEO_OMAP3_DEBUG),y)
would do the trick.
I guess that would not ive the intended result.
Setting CONFIG_VIDEO_OMAP3_DEBUG to yes should not lead to debug
messages in all media modules,
True, but it will happen only if you manually enable
CONFIG_VIDEO_OMAP3_DEBUG in Kconfig.
You cannot avoid this without major changes of the
media_build system - imho not worth the effort.
Then imho it would be better to drop the CONFIG_VIDEO_OMAP3_DEBUG
variable completely, you can set CONFIG_DEBUG which would give the
same results.
Good catch!
Yes, I agree that the better is to just drop CONFIG_VIDEO_OMAP3_DEBUG
variable completely. If someone wants to build with -DDEBUG, he can
just use CONFIG_DEBUG.
Laurent,
Any comments?
CONFIG_VIDEO_OMAP3_DEBUG is used to build the OMAP3 ISP driver in debug
mode, without having to compile the whole kernel with debugging
enabled. I'd like to keep that feature if possible.
If you want that, build it using media_build. I don't care of having
such hacks there, but having it upstream is not the right thing to do.
It's not a hack. Lots of drivers have debugging Kconfig options.
$ find linux-2.6 -type f -name Kconfig* -exec grep '^config.*DEBUG' {} \;
| wc
243 4865826
Your query is wrong. The proper query is:
$ find . -type f -name Makefile -exec grep -rH 'EXTRA_CFLAGS.*\-DDEBUG$' {}
\; ./arch/x86/pci/Makefile:EXTRA_CFLAGS += -DDEBUG
./drivers/pps/generators/Makefile:EXTRA_CFLAGS += -DDEBUG
./drivers/media/video/omap3isp/Makefile:EXTRA_CFLAGS += -DDEBUG
There's nothing wrong with a debug Kconfig option
for omap3. What's wrong is:
1) It is badly implemented: it is just enabling -DDEBUG for the entire
subsystem, as the test is wrong;
I'm fine with replacing 'ifdef CONFIG_VIDEO_OMAP3_DEBUG' with 'ifeq
($(CONFIG_VIDEO_OMAP3_DEBUG),y)'.
2) Even if you fix, you'll be enabling debug to the entire subsystem, if
you keep adding things to EXTRA_CFLAGS.
That's the main issue. The Makefile has been designed for the kernel, where it
doesn't get merged in a single Makefile like media_build does. That's does a
media_build issue.
It should be noticed that several places use a different syntax for
enabling per-driver/per-subsystem -D flag:
find . -type f -name Makefile -exec grep -rH '\-DDEBUG$' {} \;
...
./drivers/mmc/Makefile:subdir-ccflags-$(CONFIG_MMC_DEBUG) := -DDEBUG
...
./drivers/infiniband/hw/cxgb3/Makefile:ccflags-$(CONFIG_INFINIBAND_CXGB3_DE
BUG) += -DDEBUG
I _suspect_ that using ccflags-$(foo_DEBUG) may work.
I've seen that, but it doubt it will work better. v4l/Makefile.media will end
up containing
ccflags-$(CONFIG_VIDEO_OMAP3_DEBUG) += -DDEBUG
which will get expanded to
ccflags-y += -DDEBUG
All media_build drivers will thus be compiled with debugging enabled.
--
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: [GIT PATCHES FOR 3.1] Improve event and control handling
Hi Mauro, I've added two small patches based on feedback from Laurent: v4l2-ctrls/v4l2-events: small coding style cleanups v4l2-event.h: add overview documentation to the header. No code change, just stylistic/documentation. Regards, Hans On Saturday, June 18, 2011 12:39:56 Hans Verkuil wrote: Hi Mauro, This pull requests sits on top of my previous pull request: http://www.mail-archive.com/linux-media@vger.kernel.org/msg32762.html This core9 branch contains the same patches as the earlier core8, so if you want you can also pull everything from the core9 branch. The patches in this pull request are almost the same as these: http://www.mail-archive.com/linux-media@vger.kernel.org/msg33054.html The two changes are the addition of documentation (both DocBook and v4l2-framework.txt) and patch 4 in the link above: instead of one single merge() callback it is now split into a replace() callback and a merge() callback. When I was documenting the original merge() callback I realized that it really had to be split into two callbacks or it would be too confusing. It's been tested extensively with ivtv and vivi. I've added support for waiting/polling on the control event to v4l2-ctl: http://git.linuxtv.org/hverkuil/v4l-utils.git?a=shortlog;h=refs/heads/core The first four and the last three patches deal with a change in the event handling, adding guarantees to the framework what should be done when the internal event queues become full and events need to be dropped. It's much more useful now. The four v4l2-ctrls patches improve the internal datastructures and reduce the time spent with a lock held. In particular it gets rid of a potential quadratic algorithm, replacing it with a linear one (and making the code shorter as well). It is the first important step towards allowing certain types of controls to be set from interrupt context. Regards, Hans The following changes since commit a07d17c00db2cff623aea8113d6cfd181baf86a1: v4l2-compat-ioctl32: add VIDIOC_DQEVENT support. (2011-06-10 10:57:27 +0200) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git core9 Hans Verkuil (11): v4l2-events/fh: merge v4l2_events into v4l2_fh v4l2-ctrls/event: remove struct v4l2_ctrl_fh, instead use v4l2_subscribed_event v4l2-event/ctrls/fh: allocate events per fh and per type instead of just per-fh v4l2-event: add optional merge and replace callbacks v4l2-ctrls: don't initially set CH_VALUE for write-only controls v4l2-ctrls: improve discovery of controls of the same cluster v4l2-ctrls: split try_or_set_ext_ctrls() v4l2-ctrls: v4l2_ctrl_handler_setup code simplification v4l2-framework.txt: updated v4l2_fh_init documentation. v4l2-framework.txt: update v4l2_event section. DocBook: update V4L Event Interface section. Documentation/DocBook/media/v4l/dev-event.xml | 30 ++- .../DocBook/media/v4l/vidioc-subscribe-event.xml | 15 +- Documentation/video4linux/v4l2-framework.txt | 59 ++- drivers/media/video/ivtv/ivtv-fileops.c| 10 +- drivers/media/video/ivtv/ivtv-ioctl.c |4 +- drivers/media/video/omap3isp/ispccdc.c |3 +- drivers/media/video/omap3isp/ispstat.c |3 +- drivers/media/video/v4l2-ctrls.c | 416 +--- drivers/media/video/v4l2-event.c | 218 -- drivers/media/video/v4l2-fh.c | 19 +- drivers/media/video/v4l2-subdev.c | 17 +- drivers/media/video/vivi.c |4 +- drivers/usb/gadget/uvc_v4l2.c | 22 +- include/media/v4l2-ctrls.h | 39 +-- include/media/v4l2-event.h | 44 ++- include/media/v4l2-fh.h| 11 +- include/media/v4l2-subdev.h|2 - 17 files changed, 417 insertions(+), 499 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 -- 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: vb2: holding buffers until after start_streaming()
On Mon, 20 Jun 2011 07:30:11 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: Because of that I decided to call start_streaming first, before the __enqueue_in_driver() to ensure the drivers will get their methods called always in the same order, whatever used does. It still seems like the wrong order to me; it means that start_streaming() can't actually start streaming. But, as has been pointed out, the driver can't count on the buffers being there in any case. This ordering does, at least, expose situations where the driver author didn't think that buffers might not have been queued yet. (BTW, lest people think I'm complaining too much, let it be said that vb2 is, indeed, a big improvement over its predecessor.) Thanks, 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 4/4] XC4000: removed card_type
On Monday 06 June 2011 22:10:22 Mauro Carvalho Chehab wrote: Please solve the firmware issue before the next merge window. I have not yet received a reply from Devin Heitmueller to my post about the changes I made to his firmware building utility, but for now here is the modified firmware file in case someone intends to test it. Analog support unfortunately cannot be tested with the PCTV 340e, but with the Leadtek cx88+xc4000 cards for which I have submitted patches about two weeks ago it can be tested. dvb-fe-xc4000-1.4.fw Description: Binary data The following XC4000 firmware file dvb-fe-xc4000-1.4.1.fw was created based on version 1.4 of xc4000_firmwares.h. Firmware provided as part of an XC4000 Linux developers kit by Brian Mathews bmath...@xceive.com to Devin Heitmueller dheitmuel...@kernellabs.org on July 1, 2009. The code was released by Xceive under the following license: // Copyright (c) 2009, Xceive Corporation i...@xceive.com // // Permission to use, copy, modify, and/or distribute this software, only // for use with Xceive ICs, for any purpose with or without fee is hereby // granted, provided that the above copyright notice and this permission // notice appear in all source code copies. // // THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES // WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF // MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR // ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES // WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN // ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF // OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Re: RTL2831U driver updates
Jan Hoogenraad wrote: Sascha: Thanks for the links Would you know how to contact poma ? I know ;) Really, the right person to contact: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/26131 http://news.gmane.org/find-root.php?message_id=%3c1291503774.1874.90.camel%40maxim%2dlaptop%3e rgds, poma -- 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] [media] af9015: setup rc keytable for LC-Power LC-USB-DVBT
On Thu, Jun 16, 2011 at 02:14:42AM +0300, Antti Palosaari wrote: Moikka Juergen, Hi! On 06/13/2011 03:38 AM, Juergen Lock wrote: af9015_rc_query: key repeated Does that help? Repeat check logick in function af9015_rc_query() is failing for some reason. You could try to look that function and checks if you wish as I cannot reproduce it. Add debug dump immediately after registers are read and look from log what happens. debug_dump(buf, 17, deb_rc); I finally got back to this (sorry it took so long :( ), added that line and this is what I got: First ir-keytable: Testing events. Please, press CTRL-C to abort. 1308574953.777114: event MSC: scancode = 1b 1308574953.777123: event key down: KEY_1 (0x0002) 1308574953.777125: event sync 1308574954.293830: event MSC: scancode = 1b 1308574954.813919: event MSC: scancode = 1b 1308574955.332231: event MSC: scancode = 1b 1308574955.848046: event MSC: scancode = 1b 1308574956.362626: event MSC: scancode = 1b 1308574956.875069: event MSC: scancode = 1b 1308574957.391143: event MSC: scancode = 1b 1308574957.908859: event MSC: scancode = 1b 1308574958.426553: event MSC: scancode = 1b 1308574958.944992: event MSC: scancode = 1b 1308574959.462682: event MSC: scancode = 1b 1308574959.981519: event MSC: scancode = 1b 1308574960.500599: event MSC: scancode = 1b 1308574961.020155: event MSC: scancode = 1b 1308574961.540230: event MSC: scancode = 1b 1308574962.057815: event MSC: scancode = 1b 1308574962.576256: event MSC: scancode = 1b 1308574963.092961: event MSC: scancode = 1b 1308574963.611549: event MSC: scancode = 1b 1308574964.130601: event MSC: scancode = 1b 1308574964.645437: event MSC: scancode = 1b 1308574965.164752: event MSC: scancode = 1b 1308574965.684325: event MSC: scancode = 1b 1308574966.202289: event MSC: scancode = 1b 1308574966.718374: event MSC: scancode = 1b 1308574967.236913: event MSC: scancode = 1b 1308574967.756988: event MSC: scancode = 1b 1308574968.276573: event MSC: scancode = 1b 1308574968.794147: event MSC: scancode = 1b 1308574969.307834: event MSC: scancode = 1b 1308574969.823410: event MSC: scancode = 1b 1308574970.342993: event MSC: scancode = 1b 1308574970.862952: event MSC: scancode = 1b 1308574971.382144: event MSC: scancode = 1b 1308574971.897716: event MSC: scancode = 1b 1308574972.412159: event MSC: scancode = 1b 1308574972.927879: event MSC: scancode = 1b 1308574973.440304: event MSC: scancode = 1b 1308574973.961383: event MSC: scancode = 1b 1308574974.479087: event MSC: scancode = 1b 1308574974.994777: event MSC: scancode = 1b 1308574976.027044: event MSC: scancode = 05 1308574976.027054: event key up: KEY_1 (0x0002) 1308574976.027056: event sync 1308574976.027060: event key down: KEY_MUTE (0x0071) 1308574976.027062: event sync 1308574976.545246: event MSC: scancode = 05 1308574977.065213: event MSC: scancode = 05 1308574977.583911: event MSC: scancode = 05 1308574978.102972: event MSC: scancode = 05 1308574978.621050: event MSC: scancode = 05 1308574979.138112: event MSC: scancode = 05 1308574979.655187: event MSC: scancode = 05 1308574980.171269: event MSC: scancode = 05 1308574980.690343: event MSC: scancode = 05 1308574981.208045: event MSC: scancode = 05 1308574981.724746: event MSC: scancode = 05 1308574982.762866: event MSC: scancode = 4d 1308574982.762874: event key up: KEY_MUTE (0x0071) 1308574982.762876: event sync 1308574982.762880: event key down: KEY_PLAYPAUSE (0x00a4) 1308574982.762882: event sync 1308574983.278592: event MSC: scancode = 4d ^C Then the debug output: [..] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. dvb-usb: pid filter enabled by module option. DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) af9013: firmware version:4.95.0.0 DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... MT2060: successfully identified (IF1 = 1220) Registered IR keymap rc-digittrade rc0: IR-receiver inside an USB DVB receiver as webcamd dvb-usb: schedule remote query interval to 500 msecs. dvb-usb: Afatech AF9015 DVB-T USB2.0 stick successfully initialized and connected. 00 00 00 00 00 00 01 00 00 00 00 00 00 ff 01 fe ff af9015_rc_query: no key press 00 00 00 00 00 00 01 00 00 00 00 00 00 ff 01 fe ff af9015_rc_query: no key press 00 00 00 00 00 00 01 00 00 00 00 00 00 ff 01 fe ff af9015_rc_query: no key press 00 00 00 00 00 00 01 00 00 00 00 00 00 ff 01 fe ff af9015_rc_query: no key press 00 00 00 00 00 00 01 00 00 00 00 00 00 ff 01 fe ff af9015_rc_query: no key press 00 00 00 00 00 00 01 00 00 00 00 00 00 ff 01 fe ff af9015_rc_query: no key press 00 00 00 00 00 00 01 00 00 00 00 00 00 ff 01 fe ff af9015_rc_query: no key press 00 00 00 00 00 00 01 00 00 00 00 00 00 ff 01 fe ff af9015_rc_query: no key press 00 00 00 00 00 00 01 00 00 00 00 00 00 ff 01 fe ff af9015_rc_query: no key press 02 00 00 00 00 00 01 00 00 00 00 00 00 ff 1b e4 00 af9015_rc_query: key
Re: vb2: holding buffers until after start_streaming()
On Monday, June 20, 2011 07:30:11 Marek Szyprowski wrote:
Hello,
On Monday, June 20, 2011 3:28 AM Pawel Osciak wrote:
On Fri, Jun 17, 2011 at 11:57, Jonathan Corbet cor...@lwn.net wrote:
Here's another videobuf2 question...I've been trying to track down some
weird behavior, the roots of which were in the fact that
start_streaming()
gets called even though no buffers have been queued. This behavior is
quite explicit in the code:
/*
* Let driver notice that streaming state has been enabled.
*/
ret = call_qop(q, start_streaming, q);
if (ret) {
dprintk(1, streamon: driver refused to start
streaming\n);
return ret;
}
q-streaming = 1;
/*
* If any buffers were queued before streamon,
* we can now pass them to driver for processing.
*/
list_for_each_entry(vb, q-queued_list, queued_entry)
__enqueue_in_driver(vb);
Pretty much every v4l2 capture application I've ever encountered passes
all
of its buffers to VIDIOC_QBUF before starting streaming for a reason - it
makes little sense to start if there's nothing to stream to. It's really
tempting to reorder that code, but... it seems you must have done things
this way for a reason. Why did you need to reorder the operations in
this
way?
I don't see a reason why these couldn't be reordered (Marek should be
able to confirm, he wrote those lines). But this wouldn't fix
everything, as the V4L2 API permits streamon without queuing any
buffers first (for capture devices). So even reordered, it's possible
for start_streaming to be called without passing any buffers to the
driver first.
The problem is the fact that you cannot guarantee the opposite order
in all cases. Even if you swap __enqueue_in_driver and
call_qop(start_streaming), user might call respective ioctl in the
opposite order and you will end with start_streaming before
__enqueue_in_driver. Calling VIDIOC_STREAMON without previous call
to VIDIOC_QBUF is legal from v4l2 api definition.
But not all drivers support this. So the api does allow for it, but I
don't believe it is mandatory (or if it is, then many, many drivers are
not compliant).
Because of that I decided to call start_streaming first, before the
__enqueue_in_driver() to ensure the drivers will get their methods
called always in the same order, whatever used does.
The problem with doing this is that in order to start streaming several
drivers need to have the queued buffers available. For example, the davinci
capture drivers (vpif_capture.c) can start the DMA if there is only one
buffer queued, but that will overwrite that buffer until another one is
queued. If it has two buffers or more, then it can start the DMA in a more
optimal fashion. (As an aside, looking at that driver I think it actually
always starts the DMA as if there is only one buffer available, thus
introducing an unnecessarily extra frame delay.)
Anyway, what I'm trying to say is that some hardware needs to have the
queued buffers in order to start DMA in the best possible way.
Start_streaming was designed to perform time consuming operations
like enabling the power, configuring the pipeline, setting up the
tuner, etc. Some of these can fail and it is really good to report
the failure asap.
Reordering doesn't affect that.
If you cannot start your hardware (the dma engine) without queued
buffers then you probably need to move dma starting routine to the
first buffer_queue call. The problem is much more complex than it
initially looks.
I don't believe that this is mandatory. And if the spec says so, then I think
that spec should be changed since it doesn't reflect reality.
Please note that in videobuf2 buffer_queue method is allowed to sleep,
unlike it was designed in old videobuf.
Hmmm, I hope the driver will remember to release and reacquire and locks
when it goes to sleep. Something to document.
Usually drivers require at least two buffers and always keep at
least one in the dma engine, which overwrites it with incoming frames
until next buffer have been queued. However there are also devices
(like camera sensors) that might be used to capture only one single
frame or a few consecutive frames (for example a series of pictures).
They need to dequeue the last buffer once it got filled with video
data, so the design with overwriting the buffer makes no sense.
Right now it is really driver dependent and no generic solution
exist.
What's wrong with keeping this driver specific?
We have been discussing it but no consensus has been made yet, so
right now I've decided to keep the current design. We probably needs
some additional flag somewhere to configure the driver either to
continuously overwrite last buffer until next one has been queued
or stop the dma engine and return the buffer
Re: [RFC] vtunerc - virtual DVB device driver
Hello, Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit : get inspired by (unfortunately close-source) solution on stb Dreambox 800 I have made my own implementation of virtual DVB device, based on the same device API. Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. In conjunction with Dreamtuner userland project [http://code.google.com/p/dreamtuner/] by Ronald Mieslinger user can create virtual DVB device on client side and connect it to the server. When connected, user is able to use any Linux DVB API compatible application on client side (like VDR, MeTV, MythTV, etc) without any need of code modification. As server can be used any Linux DVB API compatible device. IMHO, this needs a Documentation file for the userspace API (kinda like tuntap.txt). -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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] vtunerc - virtual DVB device driver
2011/6/20 Rémi Denis-Courmont r...@remlab.net: Hello, Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit : get inspired by (unfortunately close-source) solution on stb Dreambox 800 I have made my own implementation of virtual DVB device, based on the same device API. Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. Generally speaking, this is the key reason that virtual dvb drivers have been rejected in the past for upstream inclusion - it makes it easier for evil tuner manufacturers to leverage all the hard work done by the LinuxTV developers while providing a closed-source solution. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. 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: [RFC] vtunerc - virtual DVB device driver
Hi Devin. 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: 2011/6/20 Rémi Denis-Courmont r...@remlab.net: Hello, Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit : get inspired by (unfortunately close-source) solution on stb Dreambox 800 I have made my own implementation of virtual DVB device, based on the same device API. Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. Generally speaking, this is the key reason that virtual dvb drivers have been rejected in the past for upstream inclusion - it makes it Can you tell me when such disscussion was done? I did a big attempt to check if my work is not reinventing wheels, but I found only some very generic frontend template by Emard em...@softhome.net. easier for evil tuner manufacturers to leverage all the hard work done by the LinuxTV developers while providing a closed-source solution. May be I missunderstood something, but I can't see how frontend virtualization/sharing can help to leverage others work. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. I'm again not sure if you try to argument against vtunerc code or nope. Thanks /Honza -- 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] vtunerc - virtual DVB device driver
On Mon, Jun 20, 2011 at 2:17 PM, HoP jpetr...@gmail.com wrote: Can you tell me when such disscussion was done? I did a big attempt to check if my work is not reinventing wheels, but I found only some very generic frontend template by Emard em...@softhome.net. See the userspace tuner thread here for the background: http://www.linuxtv.org/pipermail/linux-dvb/2007-August/thread.html#19840 easier for evil tuner manufacturers to leverage all the hard work done by the LinuxTV developers while providing a closed-source solution. May be I missunderstood something, but I can't see how frontend virtualization/sharing can help to leverage others work. It helps in that it allows third parties to write drivers in userspace that leverage the in-kernel implementation of DVB core. It means that a product developer who didn't want to abide by the GPL could write a closed-source driver in userland which takes advantage of the thousands of lines of code that make up the DVB core. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. I'm again not sure if you try to argument against vtunerc code or nope. I am against things like this being in the upstream kernel which make it easier for third parties to leverage GPL code without making their code available under the GPL. 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
[cron job] v4l-dvb daily build: 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:Mon Jun 20 19:00:22 CEST 2011 git hash:5b5c6e080e7d3b484536fa5c96b78ff53df83e84 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: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
[PATCH] [resend] tea575x: allow multiple opens
Change locking to allow tea575x-radio device to be opened multiple times.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-06-11
15:21:50.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h 2011-06-11
14:50:55.0 +0200
@@ -49,7 +49,7 @@ struct snd_tea575x {
bool tuned; /* tuned to a station */
unsigned int val; /* hw value */
unsigned long freq; /* frequency */
- unsigned long in_use; /* set if the device is in use */
+ struct mutex mutex;
struct snd_tea575x_ops *ops;
void *private_data;
u8 card[32];
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-06-11
15:21:50.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c2011-06-11
14:57:28.0 +0200
@@ -282,26 +282,9 @@ static int vidioc_s_input(struct file *f
return 0;
}
-static int snd_tea575x_exclusive_open(struct file *file)
-{
- struct snd_tea575x *tea = video_drvdata(file);
-
- return test_and_set_bit(0, tea-in_use) ? -EBUSY : 0;
-}
-
-static int snd_tea575x_exclusive_release(struct file *file)
-{
- struct snd_tea575x *tea = video_drvdata(file);
-
- clear_bit(0, tea-in_use);
- return 0;
-}
-
static const struct v4l2_file_operations tea575x_fops = {
.owner = THIS_MODULE,
- .open = snd_tea575x_exclusive_open,
- .release= snd_tea575x_exclusive_release,
- .ioctl = video_ioctl2,
+ .unlocked_ioctl = video_ioctl2,
};
static const struct v4l2_ioctl_ops tea575x_ioctl_ops = {
@@ -340,13 +323,14 @@ int snd_tea575x_init(struct snd_tea575x
if (snd_tea575x_read(tea) != 0x55AA)
return -ENODEV;
- tea-in_use = 0;
tea-val = TEA575X_BIT_BAND_FM | TEA575X_BIT_SEARCH_10_40;
tea-freq = 90500 * 16; /* 90.5Mhz default */
snd_tea575x_set_freq(tea);
tea-vd = tea575x_radio;
video_set_drvdata(tea-vd, tea);
+ mutex_init(tea-mutex);
+ tea-vd.lock = tea-mutex;
v4l2_ctrl_handler_init(tea-ctrl_handler, 1);
tea-vd.ctrl_handler = tea-ctrl_handler;
--
Ondrej Zary
--
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] vtunerc - virtual DVB device driver
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Devin Heitmueller Sent: lundi 20 juin 2011 20:25 To: HoP Cc: Rémi Denis-Courmont; linux-media@vger.kernel.org Subject: Re: [RFC] vtunerc - virtual DVB device driver On Mon, Jun 20, 2011 at 2:17 PM, HoP jpetr...@gmail.com wrote: Can you tell me when such disscussion was done? I did a big attempt to check if my work is not reinventing wheels, but I found only some very generic frontend template by Emard em...@softhome.net. See the userspace tuner thread here for the background: http://www.linuxtv.org/pipermail/linux-dvb/2007-August/thread.html#19840 easier for evil tuner manufacturers to leverage all the hard work done by the LinuxTV developers while providing a closed-source solution. May be I missunderstood something, but I can't see how frontend virtualization/sharing can help to leverage others work. It helps in that it allows third parties to write drivers in userspace that leverage the in-kernel implementation of DVB core. It means that a product developer who didn't want to abide by the GPL could write a closed-source driver in userland which takes advantage of the thousands of lines of code that make up the DVB core. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. I'm again not sure if you try to argument against vtunerc code or nope. I am against things like this being in the upstream kernel which make it easier for third parties to leverage GPL code without making their code available under the GPL. If I may put my two cents in this discussion regarding the closed source code problem: maybe it could be great to have some closed source drivers making some DVB hardware working better or even allowing more DVB hardware working under Linux. For example, there is a good support of PCI DVB devices, but not yet so much support for PCIe DVB devices (and even less if you're searching for DVB-S2 tuner with CAM support at reasonable price). Also, most the DVB drivers code released under GPL is nearly impossible to understand as there is no documentation (because of NDA agreements with developers - as I understood) and no inline comments. So does-it make so much difference with closed source code? I really don't want to aggress anybody here, but it's really a question I have. 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 -- 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] [resend] tea575x: remove useless input ioctls
Remove empty and useless g_input and s_input ioctls.
This fixes one fail of v4l2-compliance test.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-06-11
15:29:18.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c2011-06-11
15:29:51.0 +0200
@@ -269,19 +269,6 @@ static int tea575x_s_ctrl(struct v4l2_ct
return -EINVAL;
}
-static int vidioc_g_input(struct file *filp, void *priv, unsigned int *i)
-{
- *i = 0;
- return 0;
-}
-
-static int vidioc_s_input(struct file *filp, void *priv, unsigned int i)
-{
- if (i != 0)
- return -EINVAL;
- return 0;
-}
-
static const struct v4l2_file_operations tea575x_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = video_ioctl2,
@@ -293,8 +280,6 @@ static const struct v4l2_ioctl_ops tea57
.vidioc_s_tuner = vidioc_s_tuner,
.vidioc_g_audio = vidioc_g_audio,
.vidioc_s_audio = vidioc_s_audio,
- .vidioc_g_input = vidioc_g_input,
- .vidioc_s_input = vidioc_s_input,
.vidioc_g_frequency = vidioc_g_frequency,
.vidioc_s_frequency = vidioc_s_frequency,
};
--
Ondrej Zary
--
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] Second marvell-cam patch series
OK, here's my second series of marvell-cam patches for comment; the main thing here is (finally) the addition of videobuf2 vmalloc and dma-contig support. Anybody who would just rather look at the final product can grab: git://git.lwn.net/linux-2.6.git mmp-linuxtv There is one real mystery here; ideas would be welcome. When I switch to contiguous DMA mode, mplayer gets faster as one might expect - copying all those frames in the kernel hurts. But a basic gstreamer pipeline: gst-launch v4l2src ! ffmpegcolorspace ! videoscale ! ximagesink slows down by a factor of two. Somehow the gst-launch binary finds a way to use twice as much time processing frames. Given that the difference should not really even be visible to user space, I'm at a total loss here. In this series: Jonathan Corbet (5): marvell-cam: convert to videobuf2 marvell-cam: include file cleanup marvell-cam: no need to initialize the DMA buffers marvell-cam: Don't spam the logs on frame loss marvell-cam: implement contiguous DMA operation Kconfig |4 cafe-driver.c |6 mcam-core.c | 785 +- mcam-core.h | 47 ++- mmp-driver.c |1 5 files changed, 387 insertions(+), 456 deletions(-) Todo items at this point: - Scatter/gather DMA support (probably) - Eliminate ov7670 assumptions - Userptr support (should Just Work in DMA-contiguous mode) Comments? Thanks, 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
[PATCH 5/5] marvell-cam: implement contiguous DMA operation
The core driver can now operate in either vmalloc or dma-contig modes;
obviously the latter is preferable when it is supported. Default is
currently vmalloc on all platforms; load the module with buffer_mode=1 for
contiguous DMA mode.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/Kconfig |1 +
drivers/media/video/marvell-ccic/cafe-driver.c |6 +
drivers/media/video/marvell-ccic/mcam-core.c | 230 ++--
drivers/media/video/marvell-ccic/mcam-core.h | 21 ++-
drivers/media/video/marvell-ccic/mmp-driver.c |1 +
5 files changed, 205 insertions(+), 54 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/Kconfig
b/drivers/media/video/marvell-ccic/Kconfig
index eb535b1..22314a0 100644
--- a/drivers/media/video/marvell-ccic/Kconfig
+++ b/drivers/media/video/marvell-ccic/Kconfig
@@ -14,6 +14,7 @@ config VIDEO_MMP_CAMERA
select VIDEO_OV7670
select I2C_GPIO
select VIDEOBUF2_VMALLOC
+ select VIDEOBUF2_DMA_CONTIG
---help---
This is a Video4Linux2 driver for the integrated camera
controller found on Marvell Armada 610 application
diff --git a/drivers/media/video/marvell-ccic/cafe-driver.c
b/drivers/media/video/marvell-ccic/cafe-driver.c
index 6a29cc1..d030f9b 100644
--- a/drivers/media/video/marvell-ccic/cafe-driver.c
+++ b/drivers/media/video/marvell-ccic/cafe-driver.c
@@ -482,6 +482,12 @@ static int cafe_pci_probe(struct pci_dev *pdev,
mcam-clock_speed = 45;
mcam-use_smbus = 1;
/*
+* Vmalloc mode for buffers is traditional with this driver.
+* We *might* be able to run DMA_contig, especially on a system
+* with CMA in it.
+*/
+ mcam-buffer_mode = B_vmalloc;
+ /*
* Get set up on the PCI bus.
*/
ret = pci_enable_device(pdev);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index ca3c56f..419b4e5 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -25,9 +25,16 @@
#include media/v4l2-chip-ident.h
#include media/ov7670.h
#include media/videobuf2-vmalloc.h
+#include media/videobuf2-dma-contig.h
#include mcam-core.h
+/*
+ * Basic frame stats - to be deleted shortly
+ */
+static int frames;
+static int singles;
+static int delivered;
/*
* Internal DMA buffer management. Since the controller cannot do S/G I/O,
@@ -48,7 +55,8 @@ MODULE_PARM_DESC(alloc_bufs_at_read,
Non-zero value causes DMA buffers to be allocated when the
video capture device is read, rather than at module load
time. This saves memory, but decreases the chances of
- successfully getting those buffers.);
+ successfully getting those buffers. This parameter is
+ only used in the vmalloc buffer mode);
static int n_dma_bufs = 3;
module_param(n_dma_bufs, uint, 0644);
@@ -82,6 +90,13 @@ MODULE_PARM_DESC(flip,
If set, the sensor will be instructed to flip the image
vertically.);
+static int buffer_mode = -1;
+module_param(buffer_mode, int, 0444);
+MODULE_PARM_DESC(buffer_mode,
+ Set the buffer mode to be used; default is to go with what
+ the platform driver asks for. Set to 0 for vmalloc, 1 for
+ DMA contiguous.);
+
/*
* Status flags. Always manipulated with bit operations.
*/
@@ -90,6 +105,7 @@ MODULE_PARM_DESC(flip,
#define CF_BUF2_VALID 2
#define CF_DMA_ACTIVE 3 /* A frame is incoming */
#define CF_CONFIG_NEEDED 4 /* Must configure hardware */
+#define CF_SINGLE_BUFFER 5 /* Running with a single buffer */
#define sensor_call(cam, o, f, args...) \
v4l2_subdev_call(cam-sensor, o, f, ##args)
@@ -197,10 +213,9 @@ static inline struct mcam_vb_buffer *vb_to_mvb(struct
vb2_buffer *vb)
*/
/*
- * Do everything we think we need to have the interface operating
- * according to the desired format.
+ * Set up DMA buffers when operating in vmalloc mode
*/
-static void mcam_ctlr_dma(struct mcam_camera *cam)
+static void mcam_ctlr_dma_vmalloc(struct mcam_camera *cam)
{
/*
* Store the first two Y buffers (we aren't supporting
@@ -219,6 +234,57 @@ static void mcam_ctlr_dma(struct mcam_camera *cam)
mcam_reg_write(cam, REG_UBAR, 0); /* 32 bits only */
}
+/*
+ * Set up a contiguous buffer for the given frame. Here also is where
+ * the underrun strategy is set: if there is no buffer available, reuse
+ * the buffer from the other BAR and set the CF_SINGLE_BUFFER flag to
+ * keep the interrupt handler from giving that buffer back to user
+ * space. In this way, we always have a buffer to DMA to and don't
+ * have to try to play games stopping and restarting the controller.
+ */
+static void mcam_set_contig_buffer(struct mcam_camera *cam, int frame)
+{
+
[PATCH 4/5] marvell-cam: Don't spam the logs on frame loss
The sequence numbers already give that information if user space cares; this is a frequent occurrence on slower machines, alas. Signed-off-by: Jonathan Corbet cor...@lwn.net --- drivers/media/video/marvell-ccic/mcam-core.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/marvell-ccic/mcam-core.c b/drivers/media/video/marvell-ccic/mcam-core.c index da7ec2f..ca3c56f 100644 --- a/drivers/media/video/marvell-ccic/mcam-core.c +++ b/drivers/media/video/marvell-ccic/mcam-core.c @@ -1263,8 +1263,6 @@ static void mcam_frame_complete(struct mcam_camera *cam, int frame) /* * Basic frame housekeeping. */ - if (test_bit(frame, cam-flags) printk_ratelimit()) - cam_err(cam, Frame overrun on %d, frames lost\n, frame); set_bit(frame, cam-flags); clear_bit(CF_DMA_ACTIVE, cam-flags); if (cam-next_buf 0) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] marvell-cam: no need to initialize the DMA buffers
This was an old debugging thing from years ago. It's only done at initialization time, but it's still unnecessary; take it out. Signed-off-by: Jonathan Corbet cor...@lwn.net --- drivers/media/video/marvell-ccic/mcam-core.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/marvell-ccic/mcam-core.c b/drivers/media/video/marvell-ccic/mcam-core.c index 65d9c0f..da7ec2f 100644 --- a/drivers/media/video/marvell-ccic/mcam-core.c +++ b/drivers/media/video/marvell-ccic/mcam-core.c @@ -499,8 +499,6 @@ static int mcam_alloc_dma_bufs(struct mcam_camera *cam, int loadtime) cam_warn(cam, Failed to allocate DMA buffer\n); break; } - /* For debug, remove eventually */ - memset(cam-dma_bufs[i], 0xcc, cam-dma_buf_size); (cam-nbufs)++; } -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] marvell-cam: include file cleanup
Put the includes into a slightly more readable ordering and get rid of a few unneeded ones. Signed-off-by: Jonathan Corbet cor...@lwn.net --- drivers/media/video/marvell-ccic/mcam-core.c | 14 ++ 1 files changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/media/video/marvell-ccic/mcam-core.c b/drivers/media/video/marvell-ccic/mcam-core.c index 055d843..65d9c0f 100644 --- a/drivers/media/video/marvell-ccic/mcam-core.c +++ b/drivers/media/video/marvell-ccic/mcam-core.c @@ -11,22 +11,20 @@ #include linux/i2c.h #include linux/interrupt.h #include linux/spinlock.h -#include linux/videodev2.h #include linux/slab.h -#include media/v4l2-device.h -#include media/v4l2-ioctl.h -#include media/v4l2-chip-ident.h -#include media/ov7670.h -#include media/videobuf2-vmalloc.h #include linux/device.h #include linux/wait.h #include linux/list.h #include linux/dma-mapping.h #include linux/delay.h -#include linux/jiffies.h #include linux/vmalloc.h -#include linux/uaccess.h #include linux/io.h +#include linux/videodev2.h +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/v4l2-chip-ident.h +#include media/ov7670.h +#include media/videobuf2-vmalloc.h #include mcam-core.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
2011/6/12 Antti Palosaari cr...@iki.fi: On 06/12/2011 11:23 AM, Rune Evjen wrote: I just tested a PCTV 290e device using the latest media_build drivers in MythTV as a DVB-C device, and ran into some problems. The adapter is recognized by the em28xx-dvb driver [1] and dmesg output seems to be correct [2]. I can successfully scan for channels using the scan utility in dvb-apps but when I try to scan for channels in mythtv I get the following errors logged by mythtv-setup: 2011-06-12 00:57:20.971556 PIDInfo(/dev/dvb/adapter0/ frontend1): Failed to open demux device /dev/dvb/adapter0/demux1 for filter on pid 0x0 The demux1 does not exist, I only have the following nodes under /dev/dvb/adapter0: demux0 dvr0 frontend0 frontend1 net0 When searching the linx-media I came across this thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31839.html Is there any way to circumvent with the current driver that there is no corresponding demux1 for frontend1? Or can the DVB-T/T2 part be disabled somehow so that there is only one DVB-C frontend registered which corresponds to the demux0? There is no way to say driver to create demux1 for frontend1. After all it is not 100% clear even for me if that's correct or not, but most likely it is correct as far as I understood. Thank you for your response, Antti. Your help is much appreciated. I have tested the 290e as a DVB-C adapter with some success, to use it I created a new adapter directory under /dev/dvb, and symlinked the following: ln -s /dev/dvb/adapter0/frontend1 /dev/dvb/adapter1/frontend0 ln -s /dev/dvb/adapter0/demux0 /dev/dvb/adapter1/demux0 ln -s /dev/dvb/adapter0/dvr0 /dev/dvb/adapter1/dvr0 When testing I can scan using the scan utility and mythtv, and receive QAM-64 channels. QAM-256 channels have distorted audio and video. I tried to investigate the QAM-256 problem using the debug option on cxd2820r, but when this option is enabled I get no lock using mythtv or the scan utility. This also happened intermittently without the debug option, and when I get the no lock status, the only way to solve this is to shutdown and start the computer (i.e not rebooting) to make sure the 290e gets a power cycle (and it seems that the debug option also has to be off, at least this is my experience after 3-4 power cycles with and without this option). I have attached the syslog output with failed locks [1] generated by the debug option in case this may help with the driver development. Best regards, Rune [1]: syslog output when performing a scan using the scan utility: Jun 20 21:04:21 server kernel: [ 711.180370] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:21 server kernel: [ 711.180375] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380429] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380436] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.381308] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.581398] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.581403] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.582206] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.731275] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.731281] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732101] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.732108] cxd2820r: cxd2820r_set_frontend: delsys=1 Jun 20 21:04:22 server kernel: [ 711.732112] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732118] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:22 server kernel: [ 711.732123] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792010] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792017] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.792863] cxd2820r: cxd2820r_read_status_c: lock=04 52 Jun 20 21:04:22 server kernel: [ 711.992944] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.992949] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.993769] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 712.194200] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 712.194207] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 712.195052] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:23 server kernel: [ 712.291281] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:23 server kernel: [ 712.291285] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:23 server kernel: [ 712.292073] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:23 server kernel:
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/20 Sébastien RAILLARD (COEXSI) s...@coexsi.fr: If I may put my two cents in this discussion regarding the closed source code problem: maybe it could be great to have some closed source drivers making some DVB hardware working better or even allowing more DVB hardware working under Linux. For example, there is a good support of PCI DVB devices, but not yet so much support for PCIe DVB devices (and even less if you're searching for DVB-S2 tuner with CAM support at reasonable price). Nothing prevents a third-party from writing closed source drivers. What we do *not* think is fair though is that those third parties should be able to take advantage of all the GPL code that makes up the DVB core, and the man-years spent developing that code. If somebody wants to write a closed source driver, they are welcome to (in fact, some companies actually have). But I'll be damned if they're going to reuse GPL code to accomplish it. They are welcome to reimplement the DVB core in userland if that is their goal (under whatever licensing terms suits them). Also, most the DVB drivers code released under GPL is nearly impossible to understand as there is no documentation (because of NDA agreements with developers - as I understood) and no inline comments. So does-it make so much difference with closed source code? I really don't want to aggress anybody here, but it's really a question I have. I disagree with this assertion. I have worked on *many* different drivers in the DVB subsystem, most of them without having the datasheets. While having the datasheets definitely is helpful (and can definitely speed up debugging), I would argue that they are not essential. Also, a number of the drivers are reverse engineered (no datasheets from the vendor), which is why the registers are not documented (the person writing the code didn't actually know). While there are indeed cases where an NDA specifically prohibited releasing a GPL driver that contained the register names, this tends to be more the exception rather than the rule. All the drivers I have done with vendor assistance/datasheets have allowed me to include register names in the driver. 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: [RFC] vtunerc - virtual DVB device driver
Hello again, Le lundi 20 juin 2011 20:41:44 Devin Heitmueller, vous avez écrit : Some might argue that CUSE can already do this. Then again, CUSE would not be able to reuse the kernel DVB core infrastructure: everything would need to be reinvented in userspace. Generally speaking, this is the key reason that virtual dvb drivers have been rejected in the past for upstream inclusion - it makes it easier for evil tuner manufacturers to leverage all the hard work done Err? My point is exactly the opposite: without a dedicated virtual DVB device, (open-source) developers are stuck with CUSE, which if it would work at all, would be a major waste of effort. And then, it won't work for unprivileged processes due to CUSE ioctl's restrictions. In other words, my point was technical, not political. by the LinuxTV developers while providing a closed-source solution. This does not enable much that evil closed-source device vendors couldn't already do. Virtually any Linux-DVB-capable tool will also accept MPEG-TS feed piped from standard input. Tuning would have to use a dedicated interface; that's pretty much the only inconvenience. DVB_NET can be implemented with the TUNTAP driver easily if it comes to that. And remote control can be mulated with the uinput driver all the same. There is even a mem2mem V4L2 device nowadays, is there not? And while uinput and tuntap allow proprietary userspace drivers, they come with major limitations inherent to userspace which limit their usefulness for proprietary device drivers. FWIW, virtual device driver enables (open-source) innovation. There are countless useful IP tunnels or emulators using TUN or TAP for instance. It was an explicit goal to *not* allow third parties to reuse the Linux DVB core unless they were providing in-kernel drivers which conform to the GPL. I am afraid I don't understand how is Linux-DVB different from other Linux subsystems, such as the (much larger in terms of non-driver-specific code) networking one. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On Mon, Jun 20, 2011 at 9:29 PM, Rune Evjen rune.ev...@gmail.com wrote: 2011/6/12 Antti Palosaari cr...@iki.fi: On 06/12/2011 11:23 AM, Rune Evjen wrote: I just tested a PCTV 290e device using the latest media_build drivers in MythTV as a DVB-C device, and ran into some problems. The adapter is recognized by the em28xx-dvb driver [1] and dmesg output seems to be correct [2]. I can successfully scan for channels using the scan utility in dvb-apps but when I try to scan for channels in mythtv I get the following errors logged by mythtv-setup: 2011-06-12 00:57:20.971556 PIDInfo(/dev/dvb/adapter0/ frontend1): Failed to open demux device /dev/dvb/adapter0/demux1 for filter on pid 0x0 The demux1 does not exist, I only have the following nodes under /dev/dvb/adapter0: demux0 dvr0 frontend0 frontend1 net0 When searching the linx-media I came across this thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31839.html Is there any way to circumvent with the current driver that there is no corresponding demux1 for frontend1? Or can the DVB-T/T2 part be disabled somehow so that there is only one DVB-C frontend registered which corresponds to the demux0? There is no way to say driver to create demux1 for frontend1. After all it is not 100% clear even for me if that's correct or not, but most likely it is correct as far as I understood. Thank you for your response, Antti. Your help is much appreciated. I have tested the 290e as a DVB-C adapter with some success, to use it I created a new adapter directory under /dev/dvb, and symlinked the following: ln -s /dev/dvb/adapter0/frontend1 /dev/dvb/adapter1/frontend0 ln -s /dev/dvb/adapter0/demux0 /dev/dvb/adapter1/demux0 ln -s /dev/dvb/adapter0/dvr0 /dev/dvb/adapter1/dvr0 When testing I can scan using the scan utility and mythtv, and receive QAM-64 channels. QAM-256 channels have distorted audio and video. I tried to investigate the QAM-256 problem using the debug option on cxd2820r, but when this option is enabled I get no lock using mythtv or the scan utility. This also happened intermittently without the debug option, and when I get the no lock status, the only way to solve this is to shutdown and start the computer (i.e not rebooting) to make sure the 290e gets a power cycle (and it seems that the debug option also has to be off, at least this is my experience after 3-4 power cycles with and without this option). I have attached the syslog output with failed locks [1] generated by the debug option in case this may help with the driver development. Best regards, Rune [1]: syslog output when performing a scan using the scan utility: Jun 20 21:04:21 server kernel: [ 711.180370] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:21 server kernel: [ 711.180375] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380429] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380436] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.381308] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.581398] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.581403] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.582206] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.731275] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.731281] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732101] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.732108] cxd2820r: cxd2820r_set_frontend: delsys=1 Jun 20 21:04:22 server kernel: [ 711.732112] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732118] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:22 server kernel: [ 711.732123] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792010] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792017] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.792863] cxd2820r: cxd2820r_read_status_c: lock=04 52 Jun 20 21:04:22 server kernel: [ 711.992944] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.992949] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.993769] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 712.194200] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 712.194207] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 712.195052] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:23 server kernel: [ 712.291281] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:23 server kernel: [ 712.291285]
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: 2011/6/20 Sébastien RAILLARD (COEXSI) s...@coexsi.fr: If I may put my two cents in this discussion regarding the closed source code problem: maybe it could be great to have some closed source drivers making some DVB hardware working better or even allowing more DVB hardware working under Linux. For example, there is a good support of PCI DVB devices, but not yet so much support for PCIe DVB devices (and even less if you're searching for DVB-S2 tuner with CAM support at reasonable price). Nothing prevents a third-party from writing closed source drivers. What we do *not* think is fair though is that those third parties should be able to take advantage of all the GPL code that makes up the DVB core, and the man-years spent developing that code. If somebody wants to write a closed source driver, they are welcome to (in fact, some companies actually have). But I'll be damned if they're going to reuse GPL code to accomplish it. They are welcome to reimplement the DVB core in userland if that is their goal (under whatever licensing terms suits them). Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): I have equipment, based of course on Linux and others open-source code, which is using DVB tuners sharing (the box has two DVB-S2 NIMs on inputs and ethernet on output). If I understand you well, I have to cut such box feature (which is, btw, one of very nicer usecase of such box) and stop thinking about it? Do you really think that it is a good way which should linux come? I don't like binary drivers as well. But if developers can't extend usability of linux because of worrying about blob drivers, it is not good, it is path to the hell. My 2cents. /Honza PS: I don't want to start any war, but I would like to know if it is only Devin POV or it has wider support inside linux-media hackers. Of course I will stay with my drivers outside the kernel. Ugly, I know. But I never want to enter by closed doors. Not my way. -- 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: ERRORS
Em 20-06-2011 15:44, 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:Mon Jun 20 19:00:22 CEST 2011 git hash:5b5c6e080e7d3b484536fa5c96b78ff53df83e84 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.31.12-i686: ERRORS What are the errors here? Your detailed logs show nothing. 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: [RFC] vtunerc - virtual DVB device driver
On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Every couple of years somebody implements such a driver, and they have all been rejected for upstream. I have equipment, based of course on Linux and others open-source code, which is using DVB tuners sharing (the box has two DVB-S2 NIMs on inputs and ethernet on output). If I understand you well, I have to cut such box feature (which is, btw, one of very nicer usecase of such box) and stop thinking about it? Do you really think that it is a good way which should linux come? I don't like binary drivers as well. But if developers can't extend usability of linux because of worrying about blob drivers, it is not good, it is path to the hell. The unfortunate fact is that allowing this sort of thing *does* allow for abuse of the interface, even if was not the intention of the original author of the patch/driver. In fact, I believe all the cases in the past were by people who were friendly to open source. My 2cents. /Honza PS: I don't want to start any war, but I would like to know if it is only Devin POV or it has wider support inside linux-media hackers. Of course I will stay with my drivers outside the kernel. Ugly, I know. But I never want to enter by closed doors. Not my way. To be fair, I am not the originator of this argument. If you read the history, a variety of other Linux DVB-V4L developers have shared the same view (which I adopted after hearing the arguments). 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
Updates to French scan files
In France, the DVB-T channels are currently moving (because the analog TV is being removed at the same time) The frequencies are modified region by region, with a calendar that started in late 2009, and will end on november 29th 2011 (see http://www.tousaunumerique.fr/ou-et-quand/ ) All the new channels are listed here : http://www.tousaunumerique.fr/professionnels/en-savoir-plus/documentation/categorie-doc/plans-de-frequences/ . The PDF files also lists channels that are planned to be used in the future (but are unused at the moment) Is there already a plan to update the scan files to reflect these changes? -- 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: Updates to French scan files
On 06/20/2011 11:04 PM, mossroy wrote: In France, the DVB-T channels are currently moving (because the analog TV is being removed at the same time) The frequencies are modified region by region, with a calendar that started in late 2009, and will end on november 29th 2011 (see http://www.tousaunumerique.fr/ou-et-quand/ ) All the new channels are listed here : http://www.tousaunumerique.fr/professionnels/en-savoir-plus/documentation/categorie-doc/plans-de-frequences/ . The PDF files also lists channels that are planned to be used in the future (but are unused at the moment) Is there already a plan to update the scan files to reflect these changes? Feel free to do that. regards Antti -- http://palosaari.fi/ -- 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 4/4] drm/i915: add SNB video sprite support
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52 +
drivers/gpu/drm/i915/intel_display.c | 19 +++-
drivers/gpu/drm/i915/intel_drv.h | 14 +++
drivers/gpu/drm/i915/intel_fb.c |6 +
drivers/gpu/drm/i915/intel_overlay2.c | 188 +
6 files changed, 274 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_overlay2.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0ae6a7c..6193471 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -28,6 +28,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_dvo.o \
intel_ringbuffer.o \
intel_overlay.o \
+ intel_overlay2.o \
intel_opregion.o \
dvo_ch7xxx.o \
dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2f967af..c81c4e7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2627,6 +2627,58 @@
#define _DSPBSURF 0x7119C
#define _DSPBTILEOFF 0x711A4
+/* Sprite A control */
+#define _DVSACNTR 0x72180
+#define DVS_ENABLE (131)
+#define DVS_GAMMA_ENABLE (130)
+#define DVS_PIXFORMAT_MASK (325)
+#define DVS_FORMAT_YUV422(025)
+#define DVS_FORMAT_RGBX101010(125)
+#define DVS_FORMAT_RGBX888 (225)
+#define DVS_FORMAT_RGBX161616(325)
+#define DVS_SOURCE_KEY (122)
+#define DVS_RGB_ORDER_RGBX (120)
+#define DVS_YUV_BYTE_ORDER_MASK (316)
+#define DVS_YUV_ORDER_YUYV (016)
+#define DVS_YUV_ORDER_UYVY (116)
+#define DVS_YUV_ORDER_YVYU (216)
+#define DVS_YUV_ORDER_VYUY (316)
+#define DVS_DEST_KEY (12)
+#define DVS_TRICKLE_FEED_DISABLE (114)
+#define DVS_TILED(110)
+#define _DVSASTRIDE0x72188
+#define _DVSAPOS 0x7218c
+#define _DVSASIZE 0x72190
+#define _DVSAKEYVAL0x72194
+#define _DVSAKEYMSK0x72198
+#define _DVSASURF 0x7219c
+#define _DVSAKEYMAXVAL 0x721a0
+#define _DVSATILEOFF 0x721a4
+#define _DVSASURFLIVE 0x721ac
+#define _DVSASCALE 0x72204
+#define _DVSAGAMC 0x72300
+
+#define _DVSBCNTR 0x73180
+#define _DVSBSTRIDE0x73188
+#define _DVSBPOS 0x7318c
+#define _DVSBSIZE 0x73190
+#define _DVSBKEYVAL0x73194
+#define _DVSBKEYMSK0x73198
+#define _DVSBSURF 0x7319c
+#define _DVSBKEYMAXVAL 0x731a0
+#define _DVSBTILEOFF 0x731a4
+#define _DVSBSURFLIVE 0x731ac
+#define _DVSBSCALE 0x73204
+#define _DVSBGAMC 0x73300
+
+#define DVSCNTR(pipe) _PIPE(pipe, _DVSACNTR, _DVSBCNTR)
+#define DVSSTRIDE(pipe) _PIPE(pipe, _DVSASTRIDE, _DVSBSTRIDE)
+#define DVSPOS(pipe) _PIPE(pipe, _DVSAPOS, _DVSBPOS)
+#define DVSSURF(pipe) _PIPE(pipe, _DVSASURF, _DVSBSURF)
+#define DVSSIZE(pipe) _PIPE(pipe, _DVSASIZE, _DVSBSIZE)
+#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE)
+#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF)
+
/* VBIOS regs */
#define VGACNTRL 0x71400
# define VGA_DISP_DISABLE (1 31)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7901f16..72a570a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -900,8 +900,8 @@ static void assert_panel_unlocked(struct drm_i915_private
*dev_priv,
pipe_name(pipe));
}
-static void assert_pipe(struct drm_i915_private *dev_priv,
- enum pipe pipe, bool state)
+void assert_pipe(struct drm_i915_private *dev_priv,
+enum pipe pipe, bool state)
{
int reg;
u32 val;
@@ -914,8 +914,6 @@ static void assert_pipe(struct drm_i915_private *dev_priv,
pipe %c assertion failure (expected %s, current %s)\n,
pipe_name(pipe), state_string(state), state_string(cur_state));
}
-#define assert_pipe_enabled(d, p) assert_pipe(d, p, true)
-#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
static void assert_plane_enabled(struct drm_i915_private *dev_priv,
enum plane plane)
@@ -4319,7 +4317,8 @@ static void sandybridge_update_wm(struct drm_device *dev)
sandybridge_cursor_wm_info, latency,
plane_wm, cursor_wm)) {
I915_WRITE(WM0_PIPEA_ILK,
- (plane_wm WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+ (plane_wm
[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_crtc.c| 71 -
drivers/gpu/drm/drm_crtc_helper.c |3 +-
drivers/gpu/drm/drm_drv.c |1 +
drivers/gpu/drm/i915/intel_display.c |9 ++--
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_fb.c |3 +-
drivers/gpu/drm/nouveau/nouveau_display.c |4 +-
drivers/gpu/drm/radeon/radeon_display.c |4 +-
drivers/gpu/drm/radeon/radeon_fb.c|5 +-
drivers/gpu/drm/radeon/radeon_mode.h |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |2 +-
drivers/staging/gma500/psb_fb.c |2 +-
include/drm/drm.h |1 +
include/drm/drm_crtc.h|6 ++-
include/drm/drm_crtc_helper.h |2 +-
include/drm/drm_mode.h| 14 ++
16 files changed, 112 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9be36a5..f963cf5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1909,7 +1909,76 @@ out:
int drm_mode_addfb(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
- struct drm_mode_fb_cmd *r = data;
+ struct drm_mode_fb_cmd *or = data;
+ struct drm_mode_fb_cmd2 r;
+ struct drm_mode_config *config = dev-mode_config;
+ struct drm_framebuffer *fb;
+ int ret = 0;
+
+ /* Use new struct with format internally */
+ r.fb_id = or-fb_id;
+ r.width = or-width;
+ r.height = or-height;
+ r.pitch = or-pitch;
+ r.bpp = or-bpp;
+ r.depth = or-depth;
+ r.pixel_format = 0;
+ r.handle = or-handle;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ if ((config-min_width r.width) || (r.width config-max_width)) {
+ DRM_ERROR(mode new framebuffer width not within limits\n);
+ return -EINVAL;
+ }
+ if ((config-min_height r.height) || (r.height config-max_height))
{
+ DRM_ERROR(mode new framebuffer height not within limits\n);
+ return -EINVAL;
+ }
+
+ mutex_lock(dev-mode_config.mutex);
+
+ /* TODO check buffer is sufficiently large */
+ /* TODO setup destructor callback */
+
+ fb = dev-mode_config.funcs-fb_create(dev, file_priv, r);
+ if (IS_ERR(fb)) {
+ DRM_ERROR(could not create framebuffer\n);
+ ret = PTR_ERR(fb);
+ goto out;
+ }
+
+ or-fb_id = fb-base.id;
+ list_add(fb-filp_head, file_priv-fbs);
+ DRM_DEBUG_KMS([FB:%d]\n, fb-base.id);
+
+out:
+ mutex_unlock(dev-mode_config.mutex);
+ return ret;
+}
+
+/**
+ * drm_mode_addfb2 - add an FB to the graphics configuration
+ * @inode: inode from the ioctl
+ * @filp: file * from the ioctl
+ * @cmd: cmd from ioctl
+ * @arg: arg from ioctl
+ *
+ * LOCKING:
+ * Takes mode config lock.
+ *
+ * Add a new FB to the specified CRTC, given a user request with format.
+ *
+ * Called by the user via ioctl.
+ *
+ * RETURNS:
+ * Zero on success, errno on failure.
+ */
+int drm_mode_addfb2(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_fb_cmd2 *r = data;
struct drm_mode_config *config = dev-mode_config;
struct drm_framebuffer *fb;
int ret = 0;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9236965..5adab04 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -801,13 +801,14 @@ void drm_helper_connector_dpms(struct drm_connector
*connector, int mode)
EXPORT_SYMBOL(drm_helper_connector_dpms);
int drm_helper_mode_fill_fb_struct(struct drm_framebuffer *fb,
- struct drm_mode_fb_cmd *mode_cmd)
+ struct drm_mode_fb_cmd2 *mode_cmd)
{
fb-width = mode_cmd-width;
fb-height = mode_cmd-height;
fb-pitch = mode_cmd-pitch;
fb-bits_per_pixel = mode_cmd-bpp;
fb-depth = mode_cmd-depth;
+ fb-pixel_format = mode_cmd-pixel_format;
return 0;
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 15da618..f24b9b6 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -152,6 +152,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
[PATCH 1/4] drm: add plane support
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_crtc.c | 235 +++-
drivers/gpu/drm/drm_drv.c |3 +
include/drm/drm.h |3 +
include/drm/drm_crtc.h | 73 ++-
include/drm/drm_mode.h | 35 +++
5 files changed, 346 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 872747c..9be36a5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -533,6 +533,47 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+void drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
+ unsigned long possible_crtcs,
+ const struct drm_plane_funcs *funcs,
+ uint32_t *formats, uint32_t format_count)
+{
+ mutex_lock(dev-mode_config.mutex);
+
+ plane-dev = dev;
+ drm_mode_object_get(dev, plane-base, DRM_MODE_OBJECT_PLANE);
+ plane-funcs = funcs;
+ plane-format_types = kmalloc(sizeof(uint32_t) * format_count,
+ GFP_KERNEL);
+ if (!plane-format_types) {
+ DRM_DEBUG_KMS(out of memory when allocating plane\n);
+ drm_mode_object_put(dev, plane-base);
+ return;
+ }
+
+ memcpy(plane-format_types, formats, format_count);
+ plane-format_count = format_count;
+ plane-possible_crtcs = possible_crtcs;
+
+ list_add_tail(plane-head, dev-mode_config.plane_list);
+ dev-mode_config.num_plane++;
+
+ mutex_unlock(dev-mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_init);
+
+void drm_plane_cleanup(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane-dev;
+
+ mutex_lock(dev-mode_config.mutex);
+ drm_mode_object_put(dev, plane-base);
+ list_del(plane-head);
+ dev-mode_config.num_plane--;
+ mutex_unlock(dev-mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_cleanup);
+
/**
* drm_mode_create - create a new display mode
* @dev: DRM device
@@ -864,6 +905,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(dev-mode_config.encoder_list);
INIT_LIST_HEAD(dev-mode_config.property_list);
INIT_LIST_HEAD(dev-mode_config.property_blob_list);
+ INIT_LIST_HEAD(dev-mode_config.plane_list);
idr_init(dev-mode_config.crtc_idr);
mutex_lock(dev-mode_config.mutex);
@@ -1467,6 +1509,193 @@ out:
}
/**
+ * drm_mode_getplane_res - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return an plane count and set of IDs.
+ */
+int drm_mode_getplane_res(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_plane_res *plane_resp = data;
+ struct drm_mode_config *config;
+ struct drm_plane *plane;
+ uint32_t __user *plane_ptr;
+ int copied = 0, ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ mutex_lock(dev-mode_config.mutex);
+ config = dev-mode_config;
+
+ /*
+* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it.
+*/
+ if (config-num_plane
+ (plane_resp-count_planes = config-num_plane)) {
+ plane_ptr = (uint32_t *)(unsigned long)plane_resp-plane_id_ptr;
+
+ list_for_each_entry(plane, config-plane_list, head) {
+ if (put_user(plane-base.id, plane_ptr + copied)) {
+ ret = -EFAULT;
+ goto out;
+ }
+ copied++;
+ }
+ }
+ plane_resp-count_planes = config-num_plane;
+
+out:
+ mutex_unlock(dev-mode_config.mutex);
+ return ret;
+}
+
+/**
+ * drm_mode_getplane - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return plane info, including formats supported, gamma size, any
+ * current fb, etc.
+ */
+int drm_mode_getplane(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_plane *plane_resp = data;
+ struct drm_mode_object *obj;
+ struct drm_plane *plane;
+ uint32_t __user *format_ptr;
+ int ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ mutex_lock(dev-mode_config.mutex);
+ obj = drm_mode_object_find(dev, plane_resp-plane_id,
+ DRM_MODE_OBJECT_PLANE);
+ if (!obj) {
+ ret = -EINVAL;
+ goto out;
+ }
+ plane =
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. Every couple of years somebody implements such a driver, and they have all been rejected for upstream. Why same not apply to other devices? If I would be really accurate I would vote for removing nfs, smbfs and all other network sharing filesystems. original author of the patch/driver. In fact, I believe all the cases in the past were by people who were friendly to open source. I would like to know how much such bad guys stayed with kernel development. To be fair, I am not the originator of this argument. If you read the history, a variety of other Linux DVB-V4L developers have shared the same view (which I adopted after hearing the arguments). Seems DVB hackers are very specific group. Such politic rule don't wan't to have any place in the code development. Of course, it's my personal opinion only. /Honza -- 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] vtunerc - virtual DVB device driver
Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. 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: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
2011/6/20 Markus Rechberger mrechber...@gmail.com: On Mon, Jun 20, 2011 at 9:29 PM, Rune Evjen rune.ev...@gmail.com wrote: 2011/6/12 Antti Palosaari cr...@iki.fi: On 06/12/2011 11:23 AM, Rune Evjen wrote: I just tested a PCTV 290e device using the latest media_build drivers in MythTV as a DVB-C device, and ran into some problems. The adapter is recognized by the em28xx-dvb driver [1] and dmesg output seems to be correct [2]. I can successfully scan for channels using the scan utility in dvb-apps but when I try to scan for channels in mythtv I get the following errors logged by mythtv-setup: 2011-06-12 00:57:20.971556 PIDInfo(/dev/dvb/adapter0/ frontend1): Failed to open demux device /dev/dvb/adapter0/demux1 for filter on pid 0x0 The demux1 does not exist, I only have the following nodes under /dev/dvb/adapter0: demux0 dvr0 frontend0 frontend1 net0 When searching the linx-media I came across this thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31839.html Is there any way to circumvent with the current driver that there is no corresponding demux1 for frontend1? Or can the DVB-T/T2 part be disabled somehow so that there is only one DVB-C frontend registered which corresponds to the demux0? There is no way to say driver to create demux1 for frontend1. After all it is not 100% clear even for me if that's correct or not, but most likely it is correct as far as I understood. Thank you for your response, Antti. Your help is much appreciated. I have tested the 290e as a DVB-C adapter with some success, to use it I created a new adapter directory under /dev/dvb, and symlinked the following: ln -s /dev/dvb/adapter0/frontend1 /dev/dvb/adapter1/frontend0 ln -s /dev/dvb/adapter0/demux0 /dev/dvb/adapter1/demux0 ln -s /dev/dvb/adapter0/dvr0 /dev/dvb/adapter1/dvr0 When testing I can scan using the scan utility and mythtv, and receive QAM-64 channels. QAM-256 channels have distorted audio and video. I tried to investigate the QAM-256 problem using the debug option on cxd2820r, but when this option is enabled I get no lock using mythtv or the scan utility. This also happened intermittently without the debug option, and when I get the no lock status, the only way to solve this is to shutdown and start the computer (i.e not rebooting) to make sure the 290e gets a power cycle (and it seems that the debug option also has to be off, at least this is my experience after 3-4 power cycles with and without this option). I have attached the syslog output with failed locks [1] generated by the debug option in case this may help with the driver development. Best regards, Rune [1]: syslog output when performing a scan using the scan utility: Jun 20 21:04:21 server kernel: [ 711.180370] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:21 server kernel: [ 711.180375] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380429] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380436] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.381308] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.581398] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.581403] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.582206] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.731275] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.731281] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732101] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.732108] cxd2820r: cxd2820r_set_frontend: delsys=1 Jun 20 21:04:22 server kernel: [ 711.732112] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732118] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:22 server kernel: [ 711.732123] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792010] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792017] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.792863] cxd2820r: cxd2820r_read_status_c: lock=04 52 Jun 20 21:04:22 server kernel: [ 711.992944] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.992949] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.993769] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 712.194200] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 712.194207] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 712.195052] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:23 server kernel: [ 712.291281] cxd2820r: cxd2820r_read_status: delsys=1
Re: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On 06/20/2011 11:55 PM, Rune Evjen wrote: 2011/6/20 Markus Rechbergermrechber...@gmail.com: to tell the difference the amplifier is for DVB-T2, DVB-C is disabled in windows because it's not reliable. Technically the chip supports it but the LNA decreases the quality. There are already some other PCI boards out there with that chip which do not use that LNA which should have a better performance with that Sony chip. Is it possible to work around this by disabling the lna or is the quality decreased permanently as part of the hardware design, independently of whether the lna is enabled or not ? I searched the linux-media list and it seems that an lna option was discussed as a module parameter, but modinfo for the module I use [1] (using the media_build git repository) doesn't show a lna parameter. Can the lna be disabled in another way ? LNA is controlled by demod GPIO line. I don't remember if it is on or off for DVB-C currently. Look em28xx-dvb.c file, you can disable or enable it from there (needs re-compiling driver). I also saw BER counter running some muxes during development, but I think all channels I have are still working. And I didn't even have time to optimal parameters for tuner / demod. I will try to examine those later... regards Antti -- http://palosaari.fi/ -- 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: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On Mon, Jun 20, 2011 at 10:55 PM, Rune Evjen rune.ev...@gmail.com wrote: 2011/6/20 Markus Rechberger mrechber...@gmail.com: On Mon, Jun 20, 2011 at 9:29 PM, Rune Evjen rune.ev...@gmail.com wrote: 2011/6/12 Antti Palosaari cr...@iki.fi: On 06/12/2011 11:23 AM, Rune Evjen wrote: I just tested a PCTV 290e device using the latest media_build drivers in MythTV as a DVB-C device, and ran into some problems. The adapter is recognized by the em28xx-dvb driver [1] and dmesg output seems to be correct [2]. I can successfully scan for channels using the scan utility in dvb-apps but when I try to scan for channels in mythtv I get the following errors logged by mythtv-setup: 2011-06-12 00:57:20.971556 PIDInfo(/dev/dvb/adapter0/ frontend1): Failed to open demux device /dev/dvb/adapter0/demux1 for filter on pid 0x0 The demux1 does not exist, I only have the following nodes under /dev/dvb/adapter0: demux0 dvr0 frontend0 frontend1 net0 When searching the linx-media I came across this thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31839.html Is there any way to circumvent with the current driver that there is no corresponding demux1 for frontend1? Or can the DVB-T/T2 part be disabled somehow so that there is only one DVB-C frontend registered which corresponds to the demux0? There is no way to say driver to create demux1 for frontend1. After all it is not 100% clear even for me if that's correct or not, but most likely it is correct as far as I understood. Thank you for your response, Antti. Your help is much appreciated. I have tested the 290e as a DVB-C adapter with some success, to use it I created a new adapter directory under /dev/dvb, and symlinked the following: ln -s /dev/dvb/adapter0/frontend1 /dev/dvb/adapter1/frontend0 ln -s /dev/dvb/adapter0/demux0 /dev/dvb/adapter1/demux0 ln -s /dev/dvb/adapter0/dvr0 /dev/dvb/adapter1/dvr0 When testing I can scan using the scan utility and mythtv, and receive QAM-64 channels. QAM-256 channels have distorted audio and video. I tried to investigate the QAM-256 problem using the debug option on cxd2820r, but when this option is enabled I get no lock using mythtv or the scan utility. This also happened intermittently without the debug option, and when I get the no lock status, the only way to solve this is to shutdown and start the computer (i.e not rebooting) to make sure the 290e gets a power cycle (and it seems that the debug option also has to be off, at least this is my experience after 3-4 power cycles with and without this option). I have attached the syslog output with failed locks [1] generated by the debug option in case this may help with the driver development. Best regards, Rune [1]: syslog output when performing a scan using the scan utility: Jun 20 21:04:21 server kernel: [ 711.180370] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:21 server kernel: [ 711.180375] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380429] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.380436] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.381308] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.581398] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.581403] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.582206] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.731275] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.731281] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732101] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 711.732108] cxd2820r: cxd2820r_set_frontend: delsys=1 Jun 20 21:04:22 server kernel: [ 711.732112] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.732118] cxd2820r: cxd2820r_set_frontend_c: RF=45000 SR=695 Jun 20 21:04:22 server kernel: [ 711.732123] cxd2820r: cxd2820r_gpio: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792010] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.792017] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.792863] cxd2820r: cxd2820r_read_status_c: lock=04 52 Jun 20 21:04:22 server kernel: [ 711.992944] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 711.992949] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 711.993769] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:22 server kernel: [ 712.194200] cxd2820r: cxd2820r_read_status: delsys=1 Jun 20 21:04:22 server kernel: [ 712.194207] cxd2820r: cxd2820r_lock: active_fe=1 Jun 20 21:04:22 server kernel: [ 712.195052] cxd2820r: cxd2820r_read_status_c: lock=05 52 Jun 20 21:04:23
Re: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On 06/21/2011 12:04 AM, Markus Rechberger wrote: On Mon, Jun 20, 2011 at 10:55 PM, Rune Evjenrune.ev...@gmail.com wrote: 2011/6/20 Markus Rechbergermrechber...@gmail.com: to tell the difference the amplifier is for DVB-T2, DVB-C is disabled in windows because it's not reliable. Technically the chip supports it but the LNA decreases the quality. There are already some other PCI boards out there with that chip which do not use that LNA which should have a better performance with that Sony chip. Is it possible to work around this by disabling the lna or is the quality decreased permanently as part of the hardware design, independently of whether the lna is enabled or not ? I searched the linux-media list and it seems that an lna option was discussed as a module parameter, but modinfo for the module I use [1] (using the media_build git repository) doesn't show a lna parameter. Can the lna be disabled in another way ? no, otherwise it would be sold as full hybrid device. DVB-T2 is weak that's why it was added. Failing DVB-C would increase the device return rate, that's why it is sold as DVB-T2 only. How the others have resolved that problem? Is that signal strength only issue when TDA18271 tuner is used? Antti -- http://palosaari.fi/ -- 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: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On Mon, Jun 20, 2011 at 11:02 PM, Antti Palosaari cr...@iki.fi wrote: On 06/20/2011 11:55 PM, Rune Evjen wrote: 2011/6/20 Markus Rechbergermrechber...@gmail.com: to tell the difference the amplifier is for DVB-T2, DVB-C is disabled in windows because it's not reliable. Technically the chip supports it but the LNA decreases the quality. There are already some other PCI boards out there with that chip which do not use that LNA which should have a better performance with that Sony chip. Is it possible to work around this by disabling the lna or is the quality decreased permanently as part of the hardware design, independently of whether the lna is enabled or not ? I searched the linux-media list and it seems that an lna option was discussed as a module parameter, but modinfo for the module I use [1] (using the media_build git repository) doesn't show a lna parameter. Can the lna be disabled in another way ? LNA is controlled by demod GPIO line. I don't remember if it is on or off for DVB-C currently. Look em28xx-dvb.c file, you can disable or enable it from there (needs re-compiling driver). I also saw BER counter running some muxes during development, but I think all channels I have are still working. And I didn't even have time to optimal parameters for tuner / demod. I will try to examine those later... sure things can be optimized forward and backward but unsupported features won't be better. DVB-C is disabled on purpose, the reason is not that it's not allowed in UK with some providers. In Germany some providers don't want alternative boxes either but no one can check that anyway. The LNA is for DVB-T2 not for DVB-C, PCTV sells it like that because they designed it for that purpose the rest is out of spec. Markus -- 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: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On Mon, Jun 20, 2011 at 11:10 PM, Antti Palosaari cr...@iki.fi wrote: On 06/21/2011 12:04 AM, Markus Rechberger wrote: On Mon, Jun 20, 2011 at 10:55 PM, Rune Evjenrune.ev...@gmail.com wrote: 2011/6/20 Markus Rechbergermrechber...@gmail.com: to tell the difference the amplifier is for DVB-T2, DVB-C is disabled in windows because it's not reliable. Technically the chip supports it but the LNA decreases the quality. There are already some other PCI boards out there with that chip which do not use that LNA which should have a better performance with that Sony chip. Is it possible to work around this by disabling the lna or is the quality decreased permanently as part of the hardware design, independently of whether the lna is enabled or not ? I searched the linux-media list and it seems that an lna option was discussed as a module parameter, but modinfo for the module I use [1] (using the media_build git repository) doesn't show a lna parameter. Can the lna be disabled in another way ? no, otherwise it would be sold as full hybrid device. DVB-T2 is weak that's why it was added. Failing DVB-C would increase the device return rate, that's why it is sold as DVB-T2 only. How the others have resolved that problem? Is that signal strength only issue when TDA18271 tuner is used? USB is expected to be mobile, so sensitivity is a more important issue. The T2 tuner in question is designed to be a little bit mobile (you can use it with your notebook without moving at least). If you use a PC card you can play around with the antenna and won't move it all the time. The sensitivity optimization is quite clear why it's there for T2. C is clearly not the focus of that design. We already switched away from the tda18271 for our current (and especially upcoming) designs as well. Markus -- 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: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
2011/6/20 Antti Palosaari cr...@iki.fi: On 06/20/2011 11:55 PM, Rune Evjen wrote: 2011/6/20 Markus Rechbergermrechber...@gmail.com: to tell the difference the amplifier is for DVB-T2, DVB-C is disabled in windows because it's not reliable. Technically the chip supports it but the LNA decreases the quality. There are already some other PCI boards out there with that chip which do not use that LNA which should have a better performance with that Sony chip. Is it possible to work around this by disabling the lna or is the quality decreased permanently as part of the hardware design, independently of whether the lna is enabled or not ? I searched the linux-media list and it seems that an lna option was discussed as a module parameter, but modinfo for the module I use [1] (using the media_build git repository) doesn't show a lna parameter. Can the lna be disabled in another way ? LNA is controlled by demod GPIO line. I don't remember if it is on or off for DVB-C currently. Look em28xx-dvb.c file, you can disable or enable it from there (needs re-compiling driver). I also saw BER counter running some muxes during development, but I think all channels I have are still working. And I didn't even have time to optimal parameters for tuner / demod. I will try to examine those later... Thank you Antti, I will test with lna disabled in the em28xx-dvb module In line 349 of the code, I see this: /* enable LNA for DVB-T2 and DVB-C */ .gpio_dvbt2[0] = CXD2820R_GPIO_E | CXD2820R_GPIO_O | CXD2820R_GPIO_L, .gpio_dvbc[0] = CXD2820R_GPIO_E | CXD2820R_GPIO_O | CXD2820R_GPIO_L, I suspect I should modify line 351, what should it be changed to ? Best regards, Rune -- 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: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On 06/21/2011 12:20 AM, Rune Evjen wrote: 2011/6/20 Antti Palosaaricr...@iki.fi: LNA is controlled by demod GPIO line. I don't remember if it is on or off for DVB-C currently. Look em28xx-dvb.c file, you can disable or enable it from there (needs re-compiling driver). I also saw BER counter running some muxes during development, but I think all channels I have are still working. And I didn't even have time to optimal parameters for tuner / demod. I will try to examine those later... Thank you Antti, I will test with lna disabled in the em28xx-dvb module In line 349 of the code, I see this: /* enable LNA for DVB-T2 and DVB-C */ .gpio_dvbt2[0] = CXD2820R_GPIO_E | CXD2820R_GPIO_O | CXD2820R_GPIO_L, .gpio_dvbc[0] = CXD2820R_GPIO_E | CXD2820R_GPIO_O | CXD2820R_GPIO_L, I suspect I should modify line 351, what should it be changed to ? Remove corresponding line (.gpio_dvbc[0]). regards Antti -- http://palosaari.fi/ -- 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: PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C) - DVB-C channel scan in mythtv - missing
On 06/21/2011 12:25 AM, Antti Palosaari wrote: On 06/21/2011 12:20 AM, Rune Evjen wrote: 2011/6/20 Antti Palosaaricr...@iki.fi: LNA is controlled by demod GPIO line. I don't remember if it is on or off for DVB-C currently. Look em28xx-dvb.c file, you can disable or enable it from there (needs re-compiling driver). I also saw BER counter running some muxes during development, but I think all channels I have are still working. And I didn't even have time to optimal parameters for tuner / demod. I will try to examine those later... Thank you Antti, I will test with lna disabled in the em28xx-dvb module In line 349 of the code, I see this: /* enable LNA for DVB-T2 and DVB-C */ .gpio_dvbt2[0] = CXD2820R_GPIO_E | CXD2820R_GPIO_O | CXD2820R_GPIO_L, .gpio_dvbc[0] = CXD2820R_GPIO_E | CXD2820R_GPIO_O | CXD2820R_GPIO_L, I suspect I should modify line 351, what should it be changed to ? Remove corresponding line (.gpio_dvbc[0]). Or change CXD2820R_GPIO_L = CXD2820R_GPIO_H. Have to check that too, I suspect removing it leaves it Hi-Z (which could result same). Antti -- http://palosaari.fi/ -- 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] vtunerc - virtual DVB device driver
2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. Mauro, you totally misunderstood me. If you see on my first post in that thread I was sending full GPL-ed driver to the mailinglist. I simply didn't expect that my source will be refused because of worrying about misuse it to the bad things(tm). Note again: I did it GPLed and opensourced, I never ever thought about binary blobs or some other closed stuffs! /Honza -- 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] vtunerc - virtual DVB device driver
Devin Heitmueller dheitmuel...@kernellabs.com writes: Nothing prevents a third-party from writing closed source drivers. What we do *not* think is fair though is that those third parties should be able to take advantage of all the GPL code that makes up the DVB core, and the man-years spent developing that code. You could use the same argument against adding a loadable module interface to the Linux kernel (and I'm pretty sure it was used). Thankfully, usability won back then. Or we most likely wouldn't have had a single Linux DVB driver. Or Linux at all, except as a historical footnote. Honza posted a GPL licensed driver and gave a pretty good usage scenario. Please don't reject it based on fear of abuse. If you think about it, almost any usability improvement will also make abuse easier. And if you reject all of them based on such fear, then your system will die. Thanks. Bjørn -- 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: TW68 Driver
Does it work for TW6868-based capture cards? Like one, IVCE-T608, by iEi? -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Roman Gaufman Sent: Sunday, June 19, 2011 8:07 AM To: linux-media@vger.kernel.org Subject: TW68 Driver There is a really great driver for the thousands of capture cards floating around ebay called TW68. It is available here: http://gitorious.org/tw68 I'm not a developer but I have been using it for a number of years and it's a shame it's still not included in the kernel. Is anyone interested in making this happen? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RTL2831U driver updates
It is Maxim who have been hacking with RTL2832/RTL2832U lately. But I think he have given up since no noise anymore. I have taken now it again up to my desk and have been hacking two days now. Currently I am working with RTL2830 demod driver, I started it from scratch. Take sniffs, make scripts to generate code from USB traffic, copy pasted that to driver skeleton and now I have picture. Just implement all one-by-one until ready :-) I think I will implement it as minimum possible, no any signal statistic counters - lets add those later if someone wants to do that. USB-bridge part is rather OK as I did earlier and it is working with RTL2831U and RTL2832U at least. No remote support yet. I hope someone else would make missing driver for RTL2832U demod still... Antti -- http://palosaari.fi/ -- 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] vtunerc - virtual DVB device driver
On Mon, Jun 20, 2011 at 6:11 PM, Bjørn Mork bj...@mork.no wrote: Devin Heitmueller dheitmuel...@kernellabs.com writes: Nothing prevents a third-party from writing closed source drivers. What we do *not* think is fair though is that those third parties should be able to take advantage of all the GPL code that makes up the DVB core, and the man-years spent developing that code. You could use the same argument against adding a loadable module interface to the Linux kernel (and I'm pretty sure it was used). Thankfully, usability won back then. Or we most likely wouldn't have had a single Linux DVB driver. Or Linux at all, except as a historical footnote. Honza posted a GPL licensed driver and gave a pretty good usage scenario. Please don't reject it based on fear of abuse. If you think about it, almost any usability improvement will also make abuse easier. And if you reject all of them based on such fear, then your system will die. There isn't much sense in having this discussion again (and kicking off yet another flamewar). All of your arguments have been made before (and in the case of Linux DVB, they failed). I would suggest you read the archives and see how the developers arrived at their conclusions. If you have some *new* argument to offer, then feel free. Otherwise it's just flamebait. Anyway, I've said what I have to say on this topic. Cheers, 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: [RFC] vtunerc - virtual DVB device driver
Em 20-06-2011 18:31, HoP escreveu: 2011/6/20 Mauro Carvalho Chehab mche...@redhat.com: Em 20-06-2011 17:24, HoP escreveu: 2011/6/20 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jun 20, 2011 at 3:56 PM, HoP jpetr...@gmail.com wrote: Do you think it is really serious enough reason to prevent of having such virtualization driver in the kernel? Let check my situation and tell me how I should continue (TBH, I already thought that driver can be accepted, but my dumb brain thought because of non quality code/design or so. It was really big surprise which reason was used aginst it): Yes, this is entirely a political issue and not a technical one. Political? So we can declare that politics win (again) technicians. Sad. This is not a political issue. It is a licensing issue. If you want to use someone's else code, you need to accept the licensing terms that the developers are giving you, by either paying the price for the code usage (on closed source licensing models), or by accepting the license when using an open-sourced code. Preserving the open-source eco-system is something that everyone developing open source expect: basically, you're free to do whatever you want, but if you're using a code written by an open-source developer, the expected behaviour that GPL asks (and that the developer wants, when he opted for GPL) is that you should return back to the community with any changes you did, including derivative work. This is an essential rule of working with GPL. If you're not happy with that, that's fine. You can implement another stack that is not GPL-licensed. Mauro, you totally misunderstood me. If you see on my first post in that thread I was sending full GPL-ed driver to the mailinglist. You misunderstood me. Something that exposes the kernel interface to for an userspace client driver to implement DVB is not a driver, it is a wrapper. The real driver will be in userspace, using the DVB stack, and can even be closed source. Some developers already tried to do things like that and sell the userspace code. Such code submission were nacked. There is even one case where the kernelspace code were dropped due to that (and later, replaced by an opensource driver). We don't want to go on this way again. 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
KAIOMY ISDB-T Hybrid USB Dongle Receiver
I bought a KAIOMY ISDB-T Hybrid USB Dongle Receiver to use with my Dell Inspiron 15 Laptop under Ubuntu 11.04 Linux. But I connect it in the USB port and it doesn't recognises it. The kernel version I am using is the 2.6.38-8-generic. I opened the menuconfig of the kernel and I could saw that all modules in the especific section Device Drivers -- Multimedia support -- DVB/ATSC Adapters are all set to M. I was thinking that the driver v2l already was buit in this modules. But when I connected the device in the USB port I got the following autputs to the lsusb and dmesg commands in the console: Without the device connected nogueira@nogueira-Inspiron-1545:~$ lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 005: ID 413c:8160 Dell Computer Corp. Bus 003 Device 004: ID 413c:8162 Dell Computer Corp. Bus 003 Device 003: ID 413c:8161 Dell Computer Corp. Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 04e8:1f05 Samsung Electronics Co., Ltd Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 0c45:63ee Microdia Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub nogueira@nogueira-Inspiron-1545:~$ With the device connected nogueira@nogueira-Inspiron-1545:~$ lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 005: ID 413c:8160 Dell Computer Corp. Bus 003 Device 004: ID 413c:8162 Dell Computer Corp. Bus 003 Device 003: ID 413c:8161 Dell Computer Corp. Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 014: ID 1554:5019 Prolink Microsystems Corp. Bus 002 Device 002: ID 04e8:1f05 Samsung Electronics Co., Ltd Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 0c45:63ee Microdia Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub nogueira@nogueira-Inspiron-1545:~$ I guess that the device pointed is Device 014, Prolink Microsystems Corp. Here the output of the last lines of dmesg: [21677.320057] usb0: no IPv6 routers present [24094.384020] input: Navigator 905BT Mouse as /devices/pci:00/:00:1a.0/usb3/3-1/3-1.3/3-1.3:1.0/bluetooth/hci0/hci0:12/input15 [24094.384377] generic-bluetooth 0005:0458:00A7.0005: input,hidraw1: BLUETOOTH HID v1.00 Mouse [Navigator 905BT Mouse] on 00:26:5E:E0:61:18 [24622.528358] usb 2-3: USB disconnect, address 11 [24622.528559] rndis_host 2-3:1.0: usb0: unregister 'rndis_host' usb-:00:1d.7-3, RNDIS device [24622.970104] usb 2-3: new high speed USB device using ehci_hcd and address 12 [24623.125469] scsi14 : usb-storage 2-3:1.0 [24624.121792] scsi 14:0:0:0: Direct-Access SAMSUNG GT-I5500 Card PQ: 0 ANSI: 2 [24624.123433] sd 14:0:0:0: Attached scsi generic sg4 type 0 [24624.128097] sd 14:0:0:0: [sdd] Attached SCSI removable disk [24633.138586] usb 2-3: USB disconnect, address 12 [24649.596828] wlan0: authenticate with 00:1a:3f:4b:50:8b (try 1) [24649.599160] wlan0: authenticated [24649.599226] wlan0: associate with 00:1a:3f:4b:50:8b (try 1) [24649.602074] wlan0: RX AssocResp from 00:1a:3f:4b:50:8b (capab=0x451 status=0 aid=4) [24649.602082] wlan0: associated [29210.660319] usb 2-3: new high speed USB device using ehci_hcd and address 13 I am not an expert in linux but I can't see anything that could indicate that it recognised it in dmesg. I would like if you may help me in order I could use this device in Linux (in windows 7 it is working properly...). I would like you send me the routine that I must to follow (step by step, please because I am not an expert as I already said). Hopping you help me I would like to tanks in advantage. Sincerely Antonio Carlos Ribeiro Nogueira -- 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: ERRORS
On Monday, June 20, 2011 22:02:01 Mauro Carvalho Chehab wrote: Em 20-06-2011 15:44, 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:Mon Jun 20 19:00:22 CEST 2011 git hash:5b5c6e080e7d3b484536fa5c96b78ff53df83e84 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.31.12-i686: ERRORS What are the errors here? Your detailed logs show nothing. Cheers, Mauro The full log did show the error: Mon Jun 20 19:22:59 CEST 2011 make -C /home/hans/work/build/media_build/v4l stagingconfig make[1]: Entering directory `/home/hans/work/build/media_build/v4l' Searching in /home/hans/work/build/trees/i686/linux-2.6.31.12/Makefile for kernel version. Forcing compiling to version 2.6.31.12 make[1]: Leaving directory `/home/hans/work/build/media_build/v4l' make[1]: Entering directory `/home/hans/work/build/media_build/v4l' make[2]: Entering directory `/home/hans/work/build/media_build/linux' Applying patches for kernel v2.6.31 patch -s -f -N -p1 -i ../backports/v2.6.37_dont_use_alloc_ordered_workqueue.patch patch -s -f -N -p1 -i ../backports/v2.6.36_input_getkeycode.patch patch -s -f -N -p1 -i ../backports/v2.6.36_dvb_usb_input_getkeycode.patch patch -s -f -N -p1 -i ../backports/v2.6.35_vm_prev.patch patch -s -f -N -p1 -i ../backports/v2.6.35_firedtv_handle_fcp.patch patch -s -f -N -p1 -i ../backports/v2.6.35_i2c_new_probed_device.patch patch -s -f -N -p1 -i ../backports/v2.6.35_work_handler.patch patch -s -f -N -p1 -i ../backports/v2.6.34_dvb_net.patch patch -s -f -N -p1 -i ../backports/v2.6.34_fix_define_warnings.patch patch -s -f -N -p1 -i ../backports/v2.6.33_input_handlers_are_int.patch patch -s -f -N -p1 -i ../backports/v2.6.33_pvrusb2_sysfs.patch patch -s -f -N -p1 -i ../backports/v2.6.32_kfifo.patch patch -s -f -N -p1 -i ../backports/v2.6.31_nodename.patch patch -s -f -N -p1 -i ../backports/v2.6.31_vm_ops.patch 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/cafe_ccic.c.rej make[2]: *** [apply_patches] Error 1 make[2]: Leaving directory `/home/hans/work/build/media_build/linux' make[1]: *** [stagingconfig] Error 2 make[1]: Leaving directory `/home/hans/work/build/media_build/v4l' make: *** [stagingconfig] Error 2 make -C /home/hans/work/build/media_build/v4l prepare make[1]: Entering directory `/home/hans/work/build/media_build/v4l' Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RTL2831U driver updates
Antti: You are great ! So as far as I am concerned, it would be great if one of the others could use up your work on the USB bridge, and add the IR remote interface, based on the LIRC framework. It actually should yield little code, and mainly requires a) understanding of LIRC and b) comparing code tables to that the in-kernel code tables can be re-used. Note that Zdenek Styblik seems to have received updates from Realtek THIS month http://wiki.zeratul.org/doku.php?id=linux:v4l:realtek:start He has posted a Ver 2.2.0 of the driver at: http://www.turnovfree.net/~stybla/linux/v4l-dvb/lv5tdlx/ It supports the RTL2832U and RTL2836 and way more tuners (MT2266 FC2580 TUA9001 and MXL5007T E4000 FC0012 tda18272 fc0013) However, the code is not split up. Antti Palosaari wrote: It is Maxim who have been hacking with RTL2832/RTL2832U lately. But I think he have given up since no noise anymore. I have taken now it again up to my desk and have been hacking two days now. Currently I am working with RTL2830 demod driver, I started it from scratch. Take sniffs, make scripts to generate code from USB traffic, copy pasted that to driver skeleton and now I have picture. Just implement all one-by-one until ready :-) I think I will implement it as minimum possible, no any signal statistic counters - lets add those later if someone wants to do that. USB-bridge part is rather OK as I did earlier and it is working with RTL2831U and RTL2832U at least. No remote support yet. I hope someone else would make missing driver for RTL2832U demod still... Antti -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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
