Re: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo
On Monday 19 January 2009, Mauro Carvalho Chehab wrote:
On Sun, 18 Jan 2009 21:49:13 +0100
Laurent Pinchart laurent.pinch...@skynet.be wrote:
Mauro,
Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/
for the following 3 changesets:
uvcvideo: replace strn{cpy,cat} with strl{cpy,cat}.
Hmm... instead of this:
+ phys = kasprintf(GFP_KERNEL, usb-%s-%s, udev-bus-bus_name,
+udev-devpath);
You should use, instead:
usb_make_path(udev, phys, sizeof(phys));
This is easier to read and it should become a standard to fill bus_name on
usb drivers, since it produces a canonical name.
input-name isn't a fixed-size buffer but a dynamically allocated one, so I
can't use usb_make_path as-is. Reading the code, the phys buffer is currently
leaked, so I'll have to fix it anyway.
Switching to a fixed-size buffer is possible and 64 bytes seems to be a
sensible value. Most USB input devices seem to set phys to usb_make_path()
+ /input0. Is there an authoritative source of information regarding how
the phys field should be formatted ?
Cheers,
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: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2
Aguirre Rodriguez, Sergio Alberto wrote: Hi, I'm sending the following patchset for review to the relevant lists (linux-omap, v4l, linux-media). Includes: - Omap3 camera core + ISP drivers. - MT9P012 sensor driver (adapted to 3430SDP) - DW9710 lens driver (adapted to work with MT9P012 for SDP) - Necessary v4l2-int-device changes to make above drivers work - Redefine OMAP3 ISP platform device. - Review comments fixed from: (Thanks a lot for their time and help) - Hans Verkuil - Tony Lindgreen - Felipe Balbi - Vaibhav Hiremath - David Brownell Hi Sergio, We should try to figure out how we could synchronise our version of the ISP and camera ASAP before making any more changes... I wouldn't want to start posting a competing version. ;-) -- Sakari Ailus sakari.ai...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld ATSC 115 all static
On Sun, 18 Jan 2009 18:36:35 -0500
CityK ci...@rogers.com wrote:
Hans Verkuil wrote:
On Sunday 18 January 2009 22:20:30 CityK wrote:
The output of dmesg is interesting (two times tuner simple initiating):
Shouldn't there be a tda9887 as well? It's what the card config says, but
I'm not sure whether that is correct.
Would you like to see the results of after enabling 12c_scan to see what
is going on, or is this the behaviour you expected?
It seems to be OK, although I find it a bit peculiar that the tuner type
is set twice. Or does that have to do with it being a hybrid tuner, perhaps?
The Philips TUV1236D NIM does indeed use a tda9887 (I know, because I
was the one who discovered this some four years ago (pats self on
head)). But the module is not loading. I can make it load, just as
Hermann demonstrated to Mike in one of the recent messages for this thread.
From what I got from the sources, nxt200x has an i2c gate. For accessing the
tuner, the gate needs to be opened. Maybe we need to close the gate in order to
access tda9887.
Unfortunately, I don't have nxt200x datasheet. Things would be clearer with the
docs.
Some Other Miscellanea:
1) Before this gets merged, can I ask you to also make one small change
to tuner-simple; specifically, swap the contents of lines 301 and 304.
This will change the driver's default behaviour in regards to the
selection of which RF input to use for digital cable and digital
over-the-air. Currently, the driver is set to use digital OTA on the
top RF input and digital cable on the lower RF input spigot. However,
IMO, a more logical/convenient configuration is to have the digital
cable input be handled by the top RF input spigot, as this is the same
one that the analog cable is also drawn from by default. Mike had made
this change, on my request, previously, but it appears that it got
reverted after the tuner re-factoring.
Could you provide a patch against the current tree?
Note: users have reported different default configurations in the past
(e.g. http://www.mythtv.org/wiki/Kworld_ATSC_110), but I actually doubt
that there has been any manufacturing difference with the TUV1236D.
Rather, I suspect that the user experiences being reported are just
reflecting a combination of the different states of how our driver
behaved in the past and differences in driver version that they may have
been using (i.e. that version provided by/within their distro or by our
Hg). After all, this configuration setting has gone from being handled
by saa7134-dvb.c to dvb-pll.c to tuner-simple.c, with changes in the
behaviour implemented along the way.
The issue doesn't seem to be related to TUV1236D, but, instead with nxt200x.
The i2c command to enable the tuner is sent to nxt200x. If there are any
ATSC110 variant with a different demod (maybe a different version of nxt200x?),
then the users may experience different behaviors.
I'm not going to merge this, it's just a quick hack for this card. This
is something for Mike or Hermann to fix.
Fair enough
Please test the enclosed patch. It adds a proper gate_ctrl callback at saa7134
core, and initializes it for ATSC110.
The gate_ctrl is close to what we currently have on cx88 driver, however with a
simpler implementation. We'll likely need to improve it, moving the i2c gate
control into nxt200x, adding the i2c close commands, and putting the gate_ctrl
initialization into saa7134-dvb.
You should notice that we don't know how to close the gate. So, the code is
still a workaroud.. However, to properly implement it, we need the help
of someone with the datasheets.
Someone with a better knowledge
of this driver and these tuners should review the saa7134_board_init2()
function and move the opening of tuner gate/muxes to a separate function.
This should be needed to do per board. The issue here is that we need to know
the i2c open and close cmds.
Cheers,
Mauro
---
saa7134: Fix tuner access on Kworld ATSC110
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff -r 0622096401ec linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Jan 18 23:20:02
2009 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Mon Jan 19 08:43:36
2009 -0200
@@ -5994,6 +5994,32 @@
}
/* --- */
+
+static void nxt200x_gate_ctrl(struct saa7134_dev *dev, int open)
+{
+ /* enable tuner */
+ int i;
+ static const u8 buffer [][2] = {
+ { 0x10, 0x12 },
+ { 0x13, 0x04 },
+ { 0x16, 0x00 },
+ { 0x14, 0x04 },
+ { 0x17, 0x00 },
+ };
+
+ dev-i2c_client.addr = 0x0a;
+
+ /* FIXME: don't know how to close the i2c gate on NXT200x */
+ if (!open)
+ return;
+
+ for (i = 0; i ARRAY_SIZE(buffer); i++)
+
kernel 2.6.28 oops with saa7124
HI I have compro videomate t750f and modprobe saa7134 creates this kernel oops on 2.6.28 On 2.6.26.8 it didn't crash but it didn't want to tune TV nor radio either I have PAL and probabley this xc3028 works only for australia? Best regards, Davor Jan 18 23:17:48 emard kernel: saa7130/34: v4l2 driver version 0.2.14 loaded Jan 18 23:17:48 emard kernel: saa7134 :05:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 Jan 18 23:17:48 emard kernel: saa7133[0]: found at :05:00.0, rev: 209, irq: 16, latency: 64, mmio: 0xfebff800 Jan 18 23:17:48 emard kernel: saa7133[0]: subsystem: 185b:c900, board: Compro VideoMate T750 [card=139,autodetected] Jan 18 23:17:48 emard kernel: saa7133[0]: board init: gpio is 84bf00 Jan 18 23:17:48 emard kernel: saa7133[0]: Oops: IR config error [card=139] Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 03 01 08 ff 00 87 ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom 40: ff d7 00 c4 86 1e 05 ff 02 c2 ff 01 c6 ff 05 ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom 60: 35 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Jan 18 23:17:48 emard kernel: tuner' 4-0061: chip found @ 0xc2 (saa7133[0]) Jan 18 23:17:48 emard kernel: tuner' 4-0062: chip found @ 0xc4 (saa7133[0]) Jan 18 23:17:48 emard kernel: tuner' 4-0063: chip found @ 0xc6 (saa7133[0]) Jan 18 23:17:48 emard kernel: tuner' 4-0068: chip found @ 0xd0 (saa7133[0]) Jan 18 23:17:48 emard kernel: xc2028 4-0061: creating new instance Jan 18 23:17:48 emard kernel: xc2028 4-0061: type set to XCeive xc2028/xc3028 tuner Jan 18 23:17:48 emard kernel: BUG: unable to handle kernel NULL pointer dereference at Jan 18 23:17:48 emard kernel: IP: [] 0x0 Jan 18 23:17:48 emard kernel: PGD 70b8b067 PUD 7084f067 PMD 0 Jan 18 23:17:48 emard kernel: Oops: 0010 [#1] PREEMPT SMP Jan 18 23:17:48 emard kernel: last sysfs file: /sys/devices/pci:00/:00:1e.0/:05:03.0/resource Jan 18 23:17:48 emard kernel: CPU 2 Jan 18 23:17:48 emard kernel: Modules linked in: tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 saa7134(+) ir_common compat_ioctl32 v4l2_common tveeprom rfcomm l2cap battery ppdev lp xt_hashlimit iptable_raw xt_comment xt_owner xt_recent xt_iprange xt_policy xt_multiport ipt_ULOG ipt_TTL ipt_ttl ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_ah ipt_addrtype xt_tcpmss xt_pkttype xt_NFQUEUE xt_MARK xt_mark xt_mac xt_limit xt_length xt_helper xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat iptable_mangle nfnetlink iptable_filter ip_tables x_tables fuse aes_x86_64 aes_generic coretemp hwmon_vid hwmon parport_pc parport tun kvm_intel kvm sbp2 hid_dell hid_pl hid_cypress hid_gyration hid_bright hid_sony hid_samsung hid_microsoft hid_monterey hid_ezkey hid_apple hid_a4tech hid_logitech hci_usb bluetooth hid_cherry hid_sunplus hid_petalynx hid_belkin hid_chicony usbhid hid dvb_ttpci lnbp21 l64781 saa7146_vv saa7146 videobu Jan 18 23:17:48 emard kernel: _dma_sg videobuf_core snd_hda_intel videodev dvb_usb_a800 dvb_usb_dibusb_common dvb_pll v4l1_compat serio_raw mt2060 rtc_cmos rtc_core rtc_lib ves1820 tda8083 sp8870 stv0297 ves1x93 ttpci_eeprom dib3000mc dibx000_common stv0299 dvb_usb pcspkr snd_pcm_oss snd_mixer_oss dvb_core i2c_i801 snd_pcm iTCO_wdt iTCO_vendor_support snd_page_alloc snd_hwdep snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd button ohci1394 ieee1394 skge sky2 ehci_hcd uhci_hcd usbcore sg sr_mod cdrom thermal processor fan Jan 18 23:17:48 emard kernel: Pid: 18900,
[PULL] http://linuxtv.org/hg/~dougsland/em28xx
Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/em28xx/ for the following: - em28xx: Add entry for GADMEI TVR200 Thanks to Yohanes Nugroho yoha...@gmail.com for testing and data collection. Thanks, Douglas -- 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: Siano's patches
--- On Mon, 1/19/09, Mauro Carvalho Chehab mche...@infradead.org wrote: From: Mauro Carvalho Chehab mche...@infradead.org Subject: Re: Siano's patches To: uri...@yahoo.com Cc: Michael Krufky mkru...@linuxtv.org, linux-media@vger.kernel.org, linuxtv-comm...@linuxtv.org, linux-dvb linux-...@linuxtv.org Date: Monday, January 19, 2009, 1:29 PM Hi Uri, On Sun, 18 Jan 2009 10:37:32 -0800 (PST) Uri Shkolnik uri...@yahoo.com wrote: From: Michael Krufky mkru...@linuxtv.org Subject: Re: Siano's patches To: uri...@yahoo.com Cc: Mauro Carvalho mche...@infradead.org, linux-media@vger.kernel.org, linuxtv-comm...@linuxtv.org, linux-dvb linux-...@linuxtv.org Date: Sunday, January 18, 2009, 8:07 PM Uri Shkolnik wrote: Hi Mauro, Hope you had a great weekend :-) Yes, I had ;) I would like to know if you have already reached the conclusion whether to use the Mercurial tree option or the email option we discussed last week. Regarding the patches that have been already submitted to the linux-media@vger.kernel.org ML, any schedule for the merge? Uri, I've already responded to your last email -- You should continue to submit patches to the mailing list. Mauro suggested two options, I asked for the first (the Mercurial tree) which is more convenient for me. As it used by multiple parties here and if there is no objection based on some unknown (to me) reason, I would like to use that option. As for your pending patches, I explained in my email that they are in my queue. I am in the midst of reviewing the changes. As you're already aware, your changes break the Hauppauge device's functionality. After merging your changes, I will have to go back and re-implement the Hauppauge-specific changes in the driver, using the new methods in your pending patches. Some of the patches in the list are pending from early September, 2008. ( I think it's time they will be popped out of the queue :-) Regarding restoring, modifying, enhancing, etc. - Please do it successively, submitting my patches and your after them, so (1) the congruity between the Mercurial DVB tree change-sets and Siano's change-set will be kept, and (2) I, and other reviewers, may review your patches/changes in their own change-sets. Once I have reviewed merged your changes and after I can restore the proper functionality to the hauppauge devices, then I will post a new mercurial tree for testing against all siano-based devices. Please see above Please be patient -- this takes time. Since the current Siano implementation is needed by some existing cards and that, from what I understood from your request and Michael comments, those patches could cause some regressions with the supported boards, we should wait for Michael's reviews and tests, if this doesn't take that long. Uri, I'm assuming that you're familiar with kernel development. If not, I recommend you to read README.patches and the related docs at kernel's Documentation tree. If you have any doubts about that, we're here to answer. Those patches are late for kernel 2.6.29, since the merge window for that kernel were already closed. So, we will have some time until the next open window opens (we should have at least 5 weeks). This allows us to do a better review the changesets to be sure that: they don't cause any regressions; they don't violate the DVB API; they don't create undocumented userspace API's; they are using the best development practices on kernel development; individual patches don't break compilation (to avoid breaking git bissect). For a large changeset like Siano ones, such reviews take time. Ah, next time, please number your changesets with something like [PATCH 01/xx]. This helps me to properly identify and honour the correct patch order. Cheers, Mauro Hi Mauro, Thanks for your detailed response. Some comments and remarks - Please note that the vast majority of the added (new files) code is SDIO and SPI bus interfaces, (and also big endian support). I don't know anyone reading this ML (Mike is included), who has the tools to test this code, which has been tested thoroughly. However, comments about coding style and kernel-coding related remarks are most welcome (I already submitted a patch for review to fix some endianity issue Trent Piepho commented about). Please note that the SDIO patches has been written by none other than Pierre Ossman, who is the Linux kernel MMC maintainer (who wrote this code back in August 2008). Siano has some dozens of commercial Linux-based customers using the discussed sources. Those customers have their own QA engineers additionally to Siano internal QA team (which includes dedicated engineer for this task). Some of those companies products are already in the
Re: [PATCHv4] Add Freescale MC44S803 tuner driver
Hi Antti, +buf[0] = (val 0xFF) 16; I am not sure where it comes I have seen comments sometimes that we should use lower case hex numbers. OK, will fix. +return -EREMOTEIO; [...] +u8 ret, id; Error status (-EREMOTEIO) is stored to the u8, which leads ~254. This seems not to be problem currently because mc44s803_readreg() is used only in mc44s803_attach() that returns NULL in error case. Anyhow, I think it would be better to use int for clarity. This is definitely a BUG. I'll also fix this. Do you want me to post an update to the tuner or an incremental patch against your repository? Thanks, Jochen -- 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: [PATCHv4] Add Freescale MC44S803 tuner driver
Jochen Friedrich wrote: This is definitely a BUG. I'll also fix this. Do you want me to post an update to the tuner or an incremental patch against your repository? Post new patch. I hope Mauro will pick up your patch and add it to the master when no more comments are given. Anyhow, I don't know what's correct procedure. 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: Color FX User control proposal
-Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Wednesday, January 14, 2009 4:06 AM To: Hans Verkuil Cc: video4linux-l...@redhat.com; Aguirre Rodriguez, Sergio Alberto; linux- me...@vger.kernel.org; Curran, Dominic; Sakari Ailus; mikko.hurskai...@nokia.com; Tuukka.O Toivonen; Nagalla, Hari; Michael Schimek Subject: Re: Color FX User control proposal On Wed, 14 Jan 2009 08:16:14 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Tuesday 13 January 2009 23:36:53 Aguirre Rodriguez, Sergio Alberto wrote: Hi, Recently in TI and Nokia, we are working towards having for acceptance an OMAP3 camera driver, which uses an on-chip Image Signal Processor that has one feature of color effects. We were using a V4L2 private CID for that, but have been suggested that this could be common enough to propose to the V4L2 spec aswell for other devices to use. Below patch adds the control to include/linux/videodev2.h file, should this be enough? (This patch is taking as a codebase the latest linux-omap kernel, which I believe is v2.6.28 still) Seems good for me. Thanks and Regards, Sergio Signed-off-by: Hans Verkuil hverk...@xs4all.nl Mauro, Can you merge this patch? Looks good to me. For us to apply, We need also a patch updating V4L2 API docbook. Done. Hans has the patch for the new spec (0.25) on hold until the merge of this control is done... Thanks! 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: Color FX User control proposal
Hi,
On Tuesday 13 January 2009, Aguirre Rodriguez, Sergio Alberto wrote:
Hi,
Recently in TI and Nokia, we are working towards having for acceptance an
OMAP3 camera driver, which uses an on-chip Image Signal Processor that has
one feature of color effects. We were using a V4L2 private CID for that,
but have been suggested that this could be common enough to propose to the
V4L2 spec aswell for other devices to use.
Below patch adds the control to include/linux/videodev2.h file, should this
be enough? (This patch is taking as a codebase the latest linux-omap
kernel, which I believe is v2.6.28 still)
Thanks and Regards,
Sergio
From 022b87f3e7f3c3be141ab271a110948ea9567a69 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Tue, 13 Jan 2009 16:25:31 -0600
Subject: [PATCH] V4L2: Add COLORFX user control
This is a common feature on many cameras. the options are:
Default colors,
B W,
Sepia
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
include/linux/videodev2.h |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4669d7e..b02a10d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -876,8 +876,15 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_BACKLIGHT_COMPENSATION (V4L2_CID_BASE+28)
#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
+#define V4L2_CID_COLORFX (V4L2_CID_BASE+31)
+enum v4l2_colorfx {
+ V4L2_COLORFX_DEFAULT= 0,
If this option disables color effects, shouldn't it be called
V4L2_COLORFX_NONE instead ?
+ V4L2_COLORFX_BW = 1,
+ V4L2_COLORFX_SEPIA = 2,
+};
+
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+31)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
Best 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: Color FX User control proposal
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@skynet.be]
Sent: Monday, January 19, 2009 9:32 AM
To: Aguirre Rodriguez, Sergio Alberto
Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com; Nagalla,
Hari; Curran, Dominic; Kulkarni, Pallavi; Sakari Ailus; Tuukka.O Toivonen;
mikko.hurskai...@nokia.com
Subject: Re: Color FX User control proposal
Hi,
On Tuesday 13 January 2009, Aguirre Rodriguez, Sergio Alberto wrote:
Hi,
Recently in TI and Nokia, we are working towards having for acceptance
an
OMAP3 camera driver, which uses an on-chip Image Signal Processor that
has
one feature of color effects. We were using a V4L2 private CID for that,
but have been suggested that this could be common enough to propose to
the
V4L2 spec aswell for other devices to use.
Below patch adds the control to include/linux/videodev2.h file, should
this
be enough? (This patch is taking as a codebase the latest linux-omap
kernel, which I believe is v2.6.28 still)
Thanks and Regards,
Sergio
From 022b87f3e7f3c3be141ab271a110948ea9567a69 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Tue, 13 Jan 2009 16:25:31 -0600
Subject: [PATCH] V4L2: Add COLORFX user control
This is a common feature on many cameras. the options are:
Default colors,
B W,
Sepia
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
include/linux/videodev2.h |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4669d7e..b02a10d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -876,8 +876,15 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_BACKLIGHT_COMPENSATION(V4L2_CID_BASE+28)
#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
+#define V4L2_CID_COLORFX (V4L2_CID_BASE+31)
+enum v4l2_colorfx {
+ V4L2_COLORFX_DEFAULT= 0,
If this option disables color effects, shouldn't it be called
V4L2_COLORFX_NONE instead ?
You're right. Makes more sense, I'll update the patch.
Regards,
Sergio
+ V4L2_COLORFX_BW = 1,
+ V4L2_COLORFX_SEPIA = 2,
+};
+
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+31)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG |
0x900)
Best 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
[cron job] WARNINGS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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 Jan 19 19:00:07 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10265:f4d7d0b84940 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK 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: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29-rc2-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc2-armv5-ixp: WARNINGS linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc2-armv5-omap2: OK linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK 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-rc2-i686: OK linux-2.6.16.61-m32r: OK linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK 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-rc2-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc2-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc2-powerpc64: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK 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-rc2-x86_64: OK fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc2): 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 -- 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
haupauge remote keycode for av7110_loadkeys
Hi, I attached keycodes for http://www.hauppauge.eu/boutique_us/images_produits/111.jpg remote. Can it be added to dvb-apps/util/av7110_loadkeys/ repo. Matthieu PS : this is more or less a duplicate of keycode in ir_codes_hauppauge_new (ir-kbd-i2c.c) and it could be useful to merge them. But I like better the av7110_loadkeys approch, because with ir-kbd-i2c you can't use other remote without modifying the source code. 0x3d KEY_POWER 0x3b KEY_GOTO 0x1c KEY_TV 0x18 KEY_VIDEO 0x19 KEY_AUDIO 0x1a KEY_MHP 0x1b KEY_EPG 0x0c KEY_RADIO 0x14 KEY_UP 0x16 KEY_LEFT 0x17 KEY_RIGHT 0x15 KEY_DOWN 0x25 KEY_ENTER 0x1f KEY_EXIT 0x0d KEY_MENU 0x10 KEY_VOLUMEUP 0x11 KEY_VOLUMEDOWN 0x20 KEY_CHANNELUP 0x21 KEY_CHANNELDOWN 0x12 KEY_PREVIOUS 0x0f KEY_MUTE 0x32 KEY_REWIND 0x35 KEY_PLAY 0x34 KEY_FASTFORWARD 0x37 KEY_RECORD 0x36 KEY_STOP 0x30 KEY_PAUSE 0x24 KEY_PREVIOUSSONG 0x1e KEY_NEXTSONG 0x00 KEY_0 0x01 KEY_1 0x02 KEY_2 0x03 KEY_3 0x04 KEY_4 0x05 KEY_5 0x06 KEY_6 0x07 KEY_7 0x08 KEY_8 0x09 KEY_9 0x0a KEY_TEXT 0x0e KEY_SUBTITLE 0x0b KEY_RED 0x2e KEY_GREEN 0x38 KEY_YELLOW 0x29 KEY_BLUE
