Re: [PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
On Wed, 15 Apr 2009 18:20:46 +0200 Erik Andrén erik.and...@gmail.com wrote: Please pull http://linuxtv.org/hg/~eandren/v4l-dvb/ for updates to be added to the next major kernel release. Hi Erik, I found 88 changesets and some of them were already applied. I do not know from were to start. May you: - either tell me which updates should be added - or synchronize your repository with one of mines (v4l-dvb or gspca)? BTW, you should directly ask to Mauro to do the pulls... Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: libv4l release: 0.5.97: the whitebalance release!
On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. 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: [PATCH v2 1/4] ARM: DaVinci: DM646x Video: Platform and board specific setup
Hi Chaithrika,
My apologies for the delay, but here are (finally!) my review comments:
On Wednesday 08 April 2009 13:18:27 Chaithrika U S wrote:
Platform specific display device setup for DM646x EVM
Add platform device and resource structures. Also define a platform specific
clock setup function that can be accessed by the driver to configure the clock
and CPLD.
This patch is dependent on a patch submitted earlier, that patch adds
Pin Mux and clock definitions for Video on DM646x.
Signed-off-by: Manjunath Hadli m...@ti.com
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Chaithrika U S chaithr...@ti.com
---
Applies to DaVinci GIT tree
arch/arm/mach-davinci/board-dm646x-evm.c| 138
+++
arch/arm/mach-davinci/dm646x.c | 63
arch/arm/mach-davinci/include/mach/dm646x.h | 25 +
3 files changed, 226 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index bcf11d5..9071a39 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -39,6 +39,7 @@
#include mach/serial.h
#include mach/i2c.h
#include mach/mmc.h
+#include mach/mux.h
#include linux/platform_device.h
#include linux/i2c.h
@@ -49,6 +50,19 @@
#define DM646X_EVM_PHY_MASK (0x2)
#define DM646X_EVM_MDIO_FREQUENCY(220) /* PHY bus frequency */
+#define VIDCLKCTL_OFFSET (0x38)
+#define VSCLKDIS_OFFSET (0x6c)
+
+#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
+#define VCH2CLK_SYSCLK8 (BIT(9))
+#define VCH2CLK_AUXCLK (BIT(9) | BIT(8))
+#define VCH3CLK_MASK (BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
+#define VCH3CLK_SYSCLK8 (BIT(13))
+#define VCH3CLK_AUXCLK (BIT(14) | BIT(13))
+
+#define VIDCH2CLK(BIT(10))
+#define VIDCH3CLK(BIT(11))
+
static struct emac_platform_data dm646x_evm_emac_pdata = {
.phy_mask = DM646X_EVM_PHY_MASK,
.mdio_max_freq = DM646X_EVM_MDIO_FREQUENCY,
@@ -103,11 +117,54 @@ int dm646xevm_eeprom_write(void *buf, off_t off, size_t
count)
}
EXPORT_SYMBOL(dm646xevm_eeprom_write);
+static struct i2c_client *cpld_client;
+
+static int cpld_video_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ cpld_client = client;
+ return 0;
+}
+
+static int __devexit cpld_video_remove(struct i2c_client *client)
+{
+ cpld_client = NULL;
+ return 0;
+}
+
+static const struct i2c_device_id cpld_video_id[] = {
+ { cpld_video, 0 },
+ { }
+};
+
+static struct i2c_driver cpld_video_driver = {
+ .driver = {
+ .name = cpld_video,
+ },
+ .probe = cpld_video_probe,
+ .remove = cpld_video_remove,
+ .id_table = cpld_video_id,
+};
+
+static void evm_init_cpld(void)
+{
+ i2c_add_driver(cpld_video_driver);
+}
+
static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO(24c256, 0x50),
.platform_data = eeprom_info,
},
+ {
+ I2C_BOARD_INFO(adv7343, 0x2A),
+ },
+ {
+ I2C_BOARD_INFO(ths7303, 0x2C),
+ },
Is it necessary to add the v4l2 subdevs here? I think it is better to use
dm646x_vpif_subdev instead and rely on v4l2_i2c_new_subdev to initialize
the subdev. I strongly recommend using the v4l2_i2c_new* functions since
these are guaranteed to load and lock modules correctly.
+ {
+ I2C_BOARD_INFO(cpld_video, 0x3B),
+ },
};
static struct davinci_i2c_platform_data i2c_pdata = {
@@ -115,10 +172,90 @@ static struct davinci_i2c_platform_data i2c_pdata = {
.bus_delay = 0 /* usec */,
};
+static int set_vpif_clock(int mux_mode, int hd)
+{
+ int val = 0;
+ int err = 0;
+ unsigned int value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ /* disable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value |= (VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val 0)
+ return val;
+
+ if (mux_mode == 1)
+ val = ~0x40;
+ else
+ val |= 0x40;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
+
+ value = __raw_readl(base + VIDCLKCTL_OFFSET);
+ value = ~(VCH2CLK_MASK);
+ value = ~(VCH3CLK_MASK);
+
+ if (hd = 1)
+ value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
+ else
+ value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
+
+ __raw_writel(value, base + VIDCLKCTL_OFFSET);
+
+ /* enable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+
Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA)
Thomas Nicolai wrote: I have tried a few different settings, and tired updating the drivers with HG pull, but I just can't get it to work. Glad to hear I am not the only one having problems with this. If you get anywhere let me know what you did, I will try to do likewise. Tom Date: Fri, 17 Apr 2009 04:07:30 -0500 Subject: Hauppauge HVR-1500 (aka HP RM436AA#ABA) From: zenith1...@gmail.com To: linux-media@vger.kernel.org The code compiles. Okay, great. Can anyone actually use this thing in Linux? I can't on my 1-year-old HP dv-6629. Thank you. Or, you could both discuss your issues openly on the list and perhaps someone may have an idea as to why your having specific issues. - Steve -- 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 2/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi again Mike, On Sat, 18 Apr 2009 11:25:19 +0200, Jean Delvare wrote: On Fri, 17 Apr 2009 18:35:55 -0500 (CDT), Mike Isely wrote: I thought we were going to leave the pvrusb2 driver out of this since I've already got a change ready that also includes additional logic to take into account the properties of the hardware device (i.e. only activate ir-kbd-i2c when we know it has a chance of working). Hmm, I thought that our latest discussions had (at least partly) obsoleted your patches. Remember that we want to always instantiate ir_video I2C devices even when ir-kbd-i2c can't driver them, otherwise lirc won't be able to bind to the devices in question as soon as the legacy binding model is gone. So the conditionals in your second patch (which is all that makes it differ from mine) are no longer desirable. I'll work on lirc patches today or tomorrow, so that lirc doesn't break when my patches hit mainline. Speaking of this: do you know all the I2C addresses that can host IR devices on pvrusb2 cards? I understand that the only address supported by ir-kbd-i2c is 0x18, but I also need to know the addresses supported by lirc_i2c and possibly lirc_zilog, if you happen to know this. Thanks, -- Jean Delvare -- 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: libv4l release: 0.5.97: the whitebalance release!
Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Best regards, Erik 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: [PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
Jean-Francois Moine wrote: On Wed, 15 Apr 2009 18:20:46 +0200 Erik Andrén erik.and...@gmail.com wrote: Please pull http://linuxtv.org/hg/~eandren/v4l-dvb/ for updates to be added to the next major kernel release. Hi Erik, I found 88 changesets and some of them were already applied. I do not know from were to start. May you: - either tell me which updates should be added - or synchronize your repository with one of mines (v4l-dvb or gspca)? BTW, you should directly ask to Mauro to do the pulls... Cheers. Ok, I've created a new repository, cloned from your gspca tree with the changes I want you to pull. The address for the new repository is: http://linuxtv.org/hg/~eandren/gspca/ Sorry for the mess. Best regards, Erik -- 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] Stand-alone Resizer/Previewer Driver support under V4L2 framework
On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question is how many of these capabilities are 'generic' and how many are very much hardware specific. I am leaning towards using the extended control API for this. It's a bit awkward to implement in drivers at the moment, but that should improve in the future when a lot of the control handling code will move into the new core framework. I really need to know more about the sort of features that omap/davinci offer (and preferably also for similar devices by other manufacturers). Hans, Have you get a chance to look at Video-Buf layer issues I mentioned in original draft? I've asked Magnus Damm to take a look at this. I know he did some work in this area and he may have fixed some of these issues already. Very useful, that Embedded Linux conference... Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ for: changeset: 11517:bd3148610922 gspca - m5602-po1030: Remove redundant init sequences changeset: 11518:6da2047440f0 gspca - m5602-ov9650: Add auto exposure ctrl changeset: 11519:11e175efd506 gspca - m5602-po1030: Add auto exposure control changeset: 11520:c19cc928da00 gspca - m5602-po1030: Add private green balance control changeset: 11521:1c0f5f4d4108 gspca - m5602-mt9m111: Add green balance ctrl changeset: 11522:2f3f8425c065 gspca - m5602-mt9m111: Add blue balance ctrl changeset: 11523:1cdcb295fca5 gspca - m5602-mt9m111: Add red balance ctrl changeset: 11524:7ff93cf873c0 gspca - m5602-s5k4aa: Try to use proper read-modify-write of the vflip/hflip changeset: 11525:7230e56ef771 gspca - m5602-s5k4aa: Consolidate the gain settings, adjust row start changeset: 11526:b1ddd4d37a07 gspca - m5602-s5k4aa: Add noise suppression ctrl changeset: 11527:882707571f8b gspca - m5602-s5k4aa: Add brightness v4l2 ctrl changeset: 11528:3643a5689b94 gspca - m5602-po1030: Clean up some comments changeset: 11529:a8f671ebba31 gspca - m5602-po1030: Move some code from the start vector to the init vector changeset: 11530:4b88c7a40989 gspca - m5602-po1030: Setup window per resolution changeset: 11531:ca057bd9495f gspca - m5602-po1030: Synthesize the hsync/vsync setup changeset: 11532:77d7a7dc3be2 gspca - m5602-po1030: Add experimental QVGA support changeset: 11533:1b2da6ca6a18 gspca - m5602-po1030: Impove the bridge vsync/hsync configuration changeset: 11534:47952d365ff6 gspca - m5602-po1030: Clear subsampling flag when setting VGA mode changeset: 11535:416e8f56ca59 gscpa - m5602-ov9650: Add defines for some magic constants changeset: 11536:b539022b8e4b gspca - m5602-ov9650: Be more strict during the hsync/vsync synthesis changeset: 11537:838481c4968c gspca - m5602-mt9m111: Replace magic constants with defines changeset: 11538:7ddb52c21f00 gspca - m5602-mt9m111: Add a start function changeset: 11539:b5a4ce975018 gspca - m5602-mt9m111: Synthesize the hsync/vsync setup changeset: 11540:7f0e97fed800 gspca - m5602-mt9m111: Setup VGA resolution changeset: 11541:a10fed9aa479 gspca - m5602-mt9m111: Add experimental QVGA support changeset: 11542:9c88b25eb73a gspca - m5602-mt9m111: Activate vflip/hflip by default changeset: 11543:a10797581025 gspca - m5602-mt9m111: Endianness fixes. changeset: 11544:70683ced4534 gspca - m5602-s5k83a: Align the v4l2 ctrl definitions changeset: 11545:bd885510ad3d gspca - m5602-s5k83a: No need to initialize some registers in init changeset: 11546:b82839b37df1 gspca - m5602-s5k83a: Remove lots of useless init Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Sat Apr 18 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11517:cda79523a93c gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc1-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-rc1-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-rc1-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc1-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29.1-mips: OK linux-2.6.30-rc1-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: OK linux-2.6.30-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-rc1-x86_64: WARNINGS fw/apps: OK sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: libv4l release: 0.5.97: the whitebalance release!
On Saturday 18 Apr 2009, Hans de Goede wrote: Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. I tried v4l2ucp first (I rebuilt the Debian package of 1.3 for Ubuntu) and only switched to v4l2-ctl when I wanted something command line oriented to debug with. Not sure when I'd get time to look at V4L2_CTRL_FLAG_NEXT_CTRL support either but if I find time before you post an update then I think I know how to fix it. Adam -- 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][libv4l] Support V4L2_CTRL_FLAG_NEXT_CTRL for fake controls
The fake controls added by libv4l to provide whitebalance on some cameras do
not respect the V4L2_CTRL_FLAG_NEXT_CTRL and hence don't appear on control
programs that try to use that flag if there are any driver controls that do
support the flag. Add support for V4L2_CTRL_FLAG_NEXT_CTRL
Signed-off-by: Adam Baker li...@baker-net.org.uk
---
This isn't extensively tested but v4l2ucp (and my version does use the flag) now
lists both fake and original control for a camera with both and adds the fake
controls
for a camera with none.
---
--- libv4l-0.5.97/libv4lconvert/control/libv4lcontrol.c 2009-04-14
09:17:02.0 +0100
+++ new/libv4lconvert/control/libv4lcontrol.c 2009-04-18 23:36:28.0
+0100
@@ -280,7 +280,10 @@
{
int i;
struct v4l2_queryctrl *ctrl = arg;
+ int retval;
+ __u32 orig_id=ctrl-id;
+ /* if we have an exact match return it */
for (i = 0; i V4LCONTROL_COUNT; i++)
if ((data-controls (1 i))
ctrl-id == fake_controls[i].id) {
@@ -288,7 +291,21 @@
return 0;
}
- return syscall(SYS_ioctl, data-fd, VIDIOC_QUERYCTRL, arg);
+ /* find out what the kernel driver would respond. */
+ retval = syscall(SYS_ioctl, data-fd, VIDIOC_QUERYCTRL, arg);
+
+ /* if any of our controls have an id orig_id but less than
+ ctrl-id then return that control instead. */
+ if (orig_id V4L2_CTRL_FLAG_NEXT_CTRL)
+for (i = 0; i V4LCONTROL_COUNT; i++)
+ if ((data-controls (1 i))
+ (fake_controls[i].id (orig_id ~V4L2_CTRL_FLAG_NEXT_CTRL))
+ (fake_controls[i].id = ctrl-id)) {
+memcpy(ctrl, fake_controls[i], sizeof(struct v4l2_queryctrl));
+retval = 0;
+ }
+
+ return retval;
}
int v4lcontrol_vidioc_g_ctrl(struct v4lcontrol_data *data, void *arg)
--
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
dvbd
Hi I've taken some interest in a small piece of software called dvbd. http://dvbd.sourceforge.net/ I really like the concept of this software, because it could be used for sharing one DVB card among several different applications. BUT the software have not been developed since 2004. Is this because it is not so smart anyway, or are there some better programs out there? -- Med Liberalistiske Hilsner -- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Forssavej 49, 7600 Struer, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk -- 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
