Re: [REVIEWv2] bttv v4l2_subdev conversion
On Thu, 19 Mar 2009, Hans Verkuil wrote:
> Please note that the somewhat awkward i2c address lists are temporary.
This should be mentioned in the patch description. No one in the future
wondering why these address lists are here is going to find this email
message. I know they're supposed to go away. There's still stuff in the
bttv driver that Gerd declared obsolete and going away a half dozen years
ago.
> Without autoprobing the autoload module option has become obsolete. A warning
> is generated if it is set, but it is otherwise ignored.
It seems like one could still disable loading modules for that bttv might
think it needs. When you're testing modules that have not been installed,
any calls to request_module() will load the wrong version and cause all
sorts of breakage. It should still be possible to disable any attempts by
the driver to do that.
> diff -r 7191463177cd -r 68050e782acb
> linux/drivers/media/video/bt8xx/bttv-cards.c
> --- a/linux/drivers/media/video/bt8xx/bttv-cards.cThu Mar 19 20:53:32
> 2009 +0100
> +++ b/linux/drivers/media/video/bt8xx/bttv-cards.cThu Mar 19 21:15:53
> 2009 +0100
> @@ -97,12 +97,12 @@
> static unsigned int tuner[BTTV_MAX] = { [ 0 ... (BTTV_MAX-1) ] = UNSET };
> static unsigned int svhs[BTTV_MAX] = { [ 0 ... (BTTV_MAX-1) ] = UNSET };
> static unsigned int remote[BTTV_MAX] = { [ 0 ... (BTTV_MAX-1) ] = UNSET };
> +static unsigned int msp3400[BTTV_MAX];
> +static unsigned int tda7432[BTTV_MAX];
> +static unsigned int tvaudio[BTTV_MAX];
> +static unsigned int saa6588[BTTV_MAX];
Are any of these audio chips mutually exclusive? Does the driver even
support having more than one of them for the same card? It looks like it
doesn't. In that case you could replace some/all of these options with a
"audio chip type" option where 0 is none, 1 is tvaudio, 2 is msp3400, etc.
I think that's nicer than adding lots of new options and if you can't have
multiple audio chips, why allow one to specify that?
> + 0x22 >> 1,
> + I2C_CLIENT_END
> + };
> +
> + btv->sd_saa6588 = v4l2_i2c_new_probed_subdev(&btv->c.i2c_adap,
> + "saa6588", "saa6588", addrs);
Why do you save the the subdev returned here? AFAICS it's not ever used
anywhere. You said that v4l2 subdevs automatically go away when the device
they are attacked to is removed, right? So we don't need the pointer to
free it.
> --- a/linux/drivers/media/video/bt8xx/bttv.h Thu Mar 19 20:53:32 2009 +0100
> +++ b/linux/drivers/media/video/bt8xx/bttv.h Thu Mar 19 21:15:53 2009 +0100
> @@ -242,6 +242,7 @@
> unsigned int msp34xx_alt:1;
>
> unsigned int no_video:1; /* video pci function is unused */
> + unsigned int has_saa6588:1;
How about not adding this? It's unused and I just removed a bunch of
unused fields from here. Add it when someone can actually make use of it.
> unsigned int tuner_type; /* tuner chip type */
> unsigned int tda9887_conf;
> unsigned int svhs, dig;
> + unsigned int has_saa6588:1;
You're better off not using a bitfield here. Because of padding, it still
takes 32 bits (or more, depending on the alignment of bttv_pll_info) in the
struct but takes more code to use.
--
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: Results of the 'dropping support for kernels <2.6.22' poll
On Sat, 21 Mar 2009, Mauro Carvalho Chehab wrote: > On Fri, 20 Mar 2009 22:03:21 -0400 > Devin Heitmueller wrote: > > > On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab > > wrote: > > > My suggestion is to keep a backporting system, but more targeted at the > > > end-users. The reasons are the ones explained above. Basically: > > > > Ok, so just so we're all on the same page - we're telling all the > > developers not willing to run a bleeding edge rc kernel to screw off? > > > > Got an Nvidia video card? Go away! > > The wireless broken in this week's -rc candidate? Go away! > > Your distro doesn't yet support the bleeding edge kernel? Go away! > > Want to have a stable base on which to work so you can focus on > > v4l-dvb development? Go away! > > > > I can tell you quite definitely that you're going to lose some > > developers with this approach. You better be damn sure that the lives > > you're making easier are going to significantly outweigh the > > developers willing to contribute who you are casting aside. > > Devin, > > Please, don't invert the things. > > I am the one that is trying to defend the need of keeping the backport, while > most of you are trying to convince to me to just drop it, since developers > will > run the bleeding edge -rc. I don't run bleeding edge rc. I have one computer. I need it to work. I like to go months without rebooting. > With the argument that developers shouldn't run the bleeding edge kernel, I'd > say you should do it. This is the way kernel development is. You shouldn't > send > something upstream, if your patch doesn't run with the latest -rc. In my case, Isn't developer time better spent working on drivers that the developer has knownedlge of instead of compiling kernels, rebooting, updating nvidia drivers, etc? > I have my alpha environment for such tests, separated from the environment I > write my code. This allows me to do development on a more stable environment, > being sure that it will keep running with the latest kernel. You must have multiple computers then. Not of all us do. Or have space. Or want to use the energy to run them. > With the respect of using the backported environment for developing, you can > do > it, if you want. It will be available for all usages. Have you ever seen the > approach I'm proposing at my backported tree? I can't see why you couldn't use > it for development also. Because you'll have to port the patches to the git tree. -- 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: Results of the 'dropping support for kernels <2.6.22' poll
On Fri, 20 Mar 2009, Devin Heitmueller wrote: > On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab > wrote: > > My suggestion is to keep a backporting system, but more targeted at the > > end-users. The reasons are the ones explained above. Basically: > > Ok, so just so we're all on the same page - we're telling all the > developers not willing to run a bleeding edge rc kernel to screw off? > > Got an Nvidia video card? Go away! > The wireless broken in this week's -rc candidate? Go away! > Your distro doesn't yet support the bleeding edge kernel? Go away! > Want to have a stable base on which to work so you can focus on > v4l-dvb development? Go away! Maybe you're supposed to have ten computers running different kernels? -- 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: Failure to read saa7134/saa6752hs MPEG output
Hi,
Am Freitag, den 20.03.2009, 14:24 -0600 schrieb Gordon Smith:
> Hello -
>
> I'm unable to read or stream compressed data from saa7134/saa6752hs.
>
> I have a RTD Technologies VFG7350 (saa7134 based, two channel,
> hardware encoder per channel, no tuner) running current v4l-dvb in
> debian 2.6.26-1.
>
> MPEG2-TS data is normally available on /dev/video2 and /dev/video3.
>
> Previously there were parameters for the saa6752hs module named
> "force" and "ignore" to modify i2c addresses. The current module
> appears to lack those parameters and may be using incorrect i2c addresses.
>
> Current dmesg:
>
> [ 13.388944] saa6752hs 3-0020: chip found @ 0x40 (saa7133[0])
> [ 13.588458] saa6752hs 4-0020: chip found @ 0x40 (saa7133[1])
>
> Prior dmesg (~2.6.25-gentoo-r7 + v4l-dvb ???):
>
> saa6752hs 1-0021: saa6752hs: chip found @ 0x42
> saa6752hs 1-0021: saa6752hs: chip found @ 0x42
>
> Prior modprobe.conf entry:
> options saa6752hs force=0x1,0x21,0x2,0x21 ignore=0x0,0x20,0x1,0x20,0x2,0x20
>
>
> $ v4l2-dbg --device /dev/video2 --info
> Driver info:
> Driver name : saa7134
> Card type : RTD Embedded Technologies VFG73
> Bus info : PCI::02:08.0
> Driver version: 526
> Capabilities : 0x0501
> Video Capture
> Read/Write
> Streaming
>
> Streaming is a listed capability but the capture example at
> http://v4l2spec.bytesex.org/spec/capture-example.html fails
> during request for buffers.
>
> $ v4l2-capture --device /dev/video2 --mmap
> /dev/video2 does not support memory mapping
>
> v4l2-capture.c:
> req.count = 4;
> req.type= V4L2_BUF_TYPE_VIDEO_CAPTURE;
> req.memory = V4L2_MEMORY_MMAP;
>
> if (-1 == xioctl (fd, VIDIOC_REQBUFS, &req)) {
> if (EINVAL == errno) {
> fprintf (stderr, "%s does not support "
> "memory mapping\n", dev_name);
>
>
> A read() results in EIO error:
>
> $ v4l2-capture --device /dev/video0 --read
> read error 5, Input/output error
>
> v4l2-capture.c:
> if (-1 == read (fd, buffers[0].start, buffers[0].length)) {
> switch (errno) {
> ...
> default:
> errno_exit ("read");
>
>
> This behavior does not change if the saa6752hs module is not loaded.
>
> Is there still a way to modify the i2c address(es) for the saa6752hs module?
>
> Any pointers are appreciated.
>
> Gordon
>
thanks for the report.
It was probably forgotten that the prior insmod option had a reason.
Try to change it to 0x21 in saa7134-i2c.c
static char *i2c_devs[128] = {
[ 0x20 ] = "mpeg encoder (saa6752hs)",
[ 0xa0 >> 1 ] = "eeprom",
[ 0xc0 >> 1 ] = "tuner (analog)",
[ 0x86 >> 1 ] = "tda9887",
[ 0x5a >> 1 ] = "remote control",
};
and report if your cards a usable again.
Seems we need the chip address per card without that insmod option and
reliable probing.
Cheers,
Hermann
--
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: Results of the 'dropping support for kernels <2.6.22' poll
On Fri, 20 Mar 2009 22:03:21 -0400 Devin Heitmueller wrote: > On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab > wrote: > > My suggestion is to keep a backporting system, but more targeted at the > > end-users. The reasons are the ones explained above. Basically: > > Ok, so just so we're all on the same page - we're telling all the > developers not willing to run a bleeding edge rc kernel to screw off? > > Got an Nvidia video card? Go away! > The wireless broken in this week's -rc candidate? Go away! > Your distro doesn't yet support the bleeding edge kernel? Go away! > Want to have a stable base on which to work so you can focus on > v4l-dvb development? Go away! > > I can tell you quite definitely that you're going to lose some > developers with this approach. You better be damn sure that the lives > you're making easier are going to significantly outweigh the > developers willing to contribute who you are casting aside. Devin, Please, don't invert the things. I am the one that is trying to defend the need of keeping the backport, while most of you are trying to convince to me to just drop it, since developers will run the bleeding edge -rc. With the argument that developers shouldn't run the bleeding edge kernel, I'd say you should do it. This is the way kernel development is. You shouldn't send something upstream, if your patch doesn't run with the latest -rc. In my case, I have my alpha environment for such tests, separated from the environment I write my code. This allows me to do development on a more stable environment, being sure that it will keep running with the latest kernel. With the respect of using the backported environment for developing, you can do it, if you want. It will be available for all usages. Have you ever seen the approach I'm proposing at my backported tree? I can't see why you couldn't use it for development also. 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: Results of the 'dropping support for kernels <2.6.22' poll
On Fri, Mar 20, 2009 at 6:20 PM, Mauro Carvalho Chehab wrote: > My suggestion is to keep a backporting system, but more targeted at the > end-users. The reasons are the ones explained above. Basically: Ok, so just so we're all on the same page - we're telling all the developers not willing to run a bleeding edge rc kernel to screw off? Got an Nvidia video card? Go away! The wireless broken in this week's -rc candidate? Go away! Your distro doesn't yet support the bleeding edge kernel? Go away! Want to have a stable base on which to work so you can focus on v4l-dvb development? Go away! I can tell you quite definitely that you're going to lose some developers with this approach. You better be damn sure that the lives you're making easier are going to significantly outweigh the developers willing to contribute who you are casting aside. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: HD PVR question
Hi Simon, answering to linux-media@vger.kernel.org since such things should be asked and archieved on a mailing list. On Sat, Mar 21, 2009 at 02:23:33AM +0100, Simon Peter wrote: > > is there a way to set the resolution to 720x576 in the Linux driver > when capturing S-Video? If you feed a pal signal into the S-Video input the resolution should be 720 or 704 to 576. You have to select the s-video input and set the standard to pal variant with 50Hz. But if you don't do that you won't get any data. There is to my knowledge no scaler in the device. Janne -- 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: [linux-dvb] FusionHDTV7 and v4l causes kernel panic
On Fri, 2009-03-20 at 11:22 -0700, Timothy D. Lenz wrote:
> Not sure where I was suposed to reply to. When replying I find the replys are
> coming from diffrent lists and out look is picking
> that up. At the bottom it says v4l related stuff should go to
> linux-media@vger.kernel.org, but the thread started in
> linux-...@linuxtv.org. So I'm re-replying in linux-...@linuxtv.org.
>
> After searching the internet for ways to redirect the error to serial or
> other system and not getting to work, I typed out by hand
> what is on the screen minus the cpu dump which is mostly scrolled off anyway
> and thus gone. In trying to get the dump out ttyS0 I
> found I was getting different dumps to screen.
> When I use:
> kernel /boot/vmlinuz-2.6.26.8.20090311.1 root=/dev/hda1 ro quiet
> console=ttyS0,115200n8 console=tty0
>
> I get:
> Call Trace:
> [] netup_ci_slot_status+0x2e/0x34 [cx23885]
> [] cx23885_irq+0x327/0x3d8 [cx23885]
> [] handle_IRQ_event+0x1a/0x3f
> [] handle_fasteoi_irq+0x76/0xab
> [] do_IRQ+0x4f/0x65
> [] common_interrupt+0x23/0x28
> ===
> Code: 00 74 04 0f 0b eb fe 89 d8 e8 ed a3 ff ff ba 01 00 00 00 5b 89 d0 5e c3
> 51
> 89 d1 8b 15 20 ba 3e c0 e8 52 ff ff ff 5a c3 53 89 c3 0f ba 2a 00 19 c0
> 31
> c9 85 c0 75 54 8d 42 04 39 42 04 74 04
> EIP: [] queue_work+0x3/0x68 SS:ESR 0068:f7733f40
> Kernel panic - not syncing: Fatal exception in interrupt
>
> When I use the default setting:
> kernel /boot/vmlinuz-2.6.26.8.20090311.1 root=/dev/hda1 ro quiet
>
> I get:
> Call Trace:
> [] netup_ci_slot_status+0x2e/0x34 [cx23885]
> [] cx23885_irq+0x327/0x3d8 [cx23885]
> [] handle_IRQ_event+0x1a/0x3f
> [] handle_fasteoi_irq+0x76/0xab
> [] do_IRQ+0x4f/0x65
> [] common_interrupt+0x23/0x28
> [] _spin_unlock_irq+0x5/0x19
> [] do_syslog+0x12f/0x2f1
> [] reschedule_interrupt+0x28/0x30
> [] autoremove_wake_function+0x0/0x2d
> [] kmsg_read+0x0/0x36
> [] proc_reg_read+0x60/0x73
> [] proc_reg_read+0x0/0x73
> [] vfs_read+0x81/0xf4
> [] sys_read+0x3c/0x63
> [] sysenter_past_esp+0x6a/0x91
> ===
> Code: 00 74 04 0f 0b eb fe 89 d8 e8 ed a3 ff ff ba 01 00 00 00 5b 89 d0 5e c3
> 51
> 89 d1 8b 15 20 ba 3e c0 e8 52 ff ff ff 5a c3 53 89 c3 0f ba 2a 00 19 c0
> 31
> c9 85 c0 75 54 8d 42 04 39 42 04 74 04
> EIP: [] queue_work+0x3/0x68 SS:ESR 0068:f7693e7c
> Kernel panic - not syncing: Fatal exception in interrupt
Here is the kernel source code that corresponds to where the panic
occurs in linux/kernel/workqueue.c:
#define work_data_bits(work) ((unsigned long *)(&(work)->data))
#define WORK_STRUCT_PENDING 0
int queue_work(struct workqueue_struct *wq, struct work_struct *work)
{
int ret;
ret = queue_work_on(get_cpu(), wq, work);
put_cpu();
return ret;
}
int
queue_work_on(int cpu, struct workqueue_struct *wq, struct work_struct *work)
{
int ret = 0;
if (!test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work))) {
BUG_ON(!list_empty(&work->entry));
__queue_work(wq_per_cpu(wq, cpu), work);
ret = 1;
}
return ret;
}
Here is the disassembled code bytes from the oops:
ffd9: 74 04 je 0xffdf
ffdb: 0f 0b ud2a
ffdd: eb fe jmp0xffdd
ffdf: 89 d8 mov%ebx,%eax
ffe1: e8 ed a3 ff ff call 0xa3d3
ffe6: ba 01 00 00 00 mov$0x1,%edx
ffeb: 5b pop%ebx
ffec: 89 d0 mov%edx,%eax
ffee: 5e pop%esi
ffef: c3 ret
fff0: 51 push %ecx
fff1: 89 d1 mov%edx,%ecx
fff3: 8b 15 20 ba 3e c0 mov0xc03eba20,%edx
fff9: e8 52 ff ff ff call 0xff50
fffe: 5a pop%edx
: c3 ret
0: 53 push %ebx <--- queue_work() with
queue_work_on() inlined starts here
1: 89 c3 mov%eax,%ebx
3: f0 0f ba 2a 00 lock btsl $0x0,(%edx) <--- Ooops here:
test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work))
8: 19 c0 sbb%eax,%eax
a: 31 c9 xor%ecx,%ecx
c: 85 c0 test %eax,%eax
e: 75 54 jne0x64
10: 8d 42 04lea0x4(%edx),%eax
13: 39 42 04cmp%eax,0x4(%edx)
16: 74 04 je 0x1c
So "work" is NULL. No big surprise there.
Work was never initialized. Here's how the code got there:
(IRQ line fires, kernel call the cx23885 irq handler)
linux/drivers/media/video/cx23885/cx23885-core.c:cx23885_irq():line 1716
linux/drivers/media/video/cx23885/cimax2.c:netup_ci_slot_status():line
345
linux/kernel/workqueue.c:schedule_work():line 621
linux/kernel/w
Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers
On Thu, 19 Mar 2009 15:43:42 -0700 (PDT) Trent Piepho wrote: > On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote: > > On Thu, 19 Mar 2009 17:18:47 +0300 > > Alexey Klimov wrote: > > over what we currently have on our complex Kbuilding system. > > > > For the out-of-system building, one alternative would be to create some make > > syntax for building just some drivers, like: > > > > make driver=cx88,ivtv > > The problem with this is that it's really hard to do decently. True. > For instance, if you want cx88 dvb support, you need some front-ends to do > anything with it. Well, what front-ends should be turned on? You can turn > on any number from none to all. Probably all of them would be best. But > there are tons of other tuners, front-ends, decoders, drivers, etc. that > cx88 doesn't use. Those should be off. > > So you give an algorithm the config variables you want set (e.g., > VIDEO_CX88) and then tell it to find a valid solution to the rest of the > variables given the constraints from Kconfig. This is the classic > NP-complete SAT problem. It is hard, but we can solve this. > > But we get a solution that has all the tuners, etc. that cx88 can't used > turned on. That's not what we want! So, we say we want the solution that > has the fewest modules turned on. Well, you've just made the problem much > much harder to solve as SAT solving heuristics won't do you any good now. > > But suppose we solve it anyway and get the solution with the fewest modules > turned on. It's going to have all the frontends cx88 can use turned OFF. > That's not what we want either! How is the algorithm supposed to know what > we want on and what we want off? We basically have to do it so that 'make > cx88' means use certain exact config options that someone has manually > pre-configured. It is hard to have a tool that will truly compile just the minimum amount of things that the user needs. Yet, it seems valid to have a make to select some specific subsets. For example, we may select the the "common" configs, like: CONFIG_VIDEO_DEV=y CONFIG_VIDEO_V4L2_COMMON=m CONFIG_VIDEO_ALLOW_V4L1=y CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_DVB_CORE=y CONFIG_VIDEO_MEDIA=y CONFIG_DVB_DYNAMIC_MINORS=y (we need to add here also the menu-only group of configs) And allowing the automation of the helper chips: CONFIG_VIDEO_HELPER_CHIPS_AUTO=y # CONFIG_MEDIA_TUNER_CUSTOMISE is not set # CONFIG_DVB_FE_CUSTOMISE is not set Then, the make will add just the modules for that specific driver. In the case of cx88, an interesting subset would be to select CX88*: CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_MPEG=m CONFIG_VIDEO_CX88_VP3054=m For sure this is _not_ the minimal set of cx88. People may not want blackbird, or their device may not need xc5000, for example. Yet, it is faster to compile the above 42 kernel modules than all the 200+ modules of a full build. The advantages are bigger if we think on those smaller drivers, like for example opera1: CONFIG_DVB_USB_OPERA1=m Such config will compile only 15 drivers: LD [M] /home/v4l/master/v4l/dvb-usb-opera.ko LD [M] /home/v4l/master/v4l/dvb-usb.ko LD [M] /home/v4l/master/v4l/tea5767.ko LD [M] /home/v4l/master/v4l/stv0299.ko LD [M] /home/v4l/master/v4l/dvb-pll.ko LD [M] /home/v4l/master/v4l/mt20xx.ko LD [M] /home/v4l/master/v4l/mc44s803.ko LD [M] /home/v4l/master/v4l/xc5000.ko LD [M] /home/v4l/master/v4l/tuner-simple.ko LD [M] /home/v4l/master/v4l/tuner-types.ko LD [M] /home/v4l/master/v4l/tda8290.ko LD [M] /home/v4l/master/v4l/v4l2-common.ko LD [M] /home/v4l/master/v4l/tea5761.ko LD [M] /home/v4l/master/v4l/tuner-xc2028.ko LD [M] /home/v4l/master/v4l/tda9887.ko 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: Results of the 'dropping support for kernels <2.6.22' poll
On Fri, 20 Mar 2009 21:47:07 +0100 "Hans Werner" wrote: > > That's said, the backport tree is still an experimental work. The scripts > > require more time to be tested, and the Makefiles need some cleanups. > > Mauro, > > neat, but I still think time spent on backporting work would be better > spent on cutting-edge development. Two hours here ... two hours there > ... it all adds up to a significant investment of time. True. Yet, the more easy for end users to have their devices working on their environments, the more number of "end tail" contributions we'll have, fixing issues on specific devices whose the main developers don't have. > > Beside the fact that we don't need to strip support for legacy kernels, > > the > > advantage of using this method is that we can evolute to a new development > > model. As several developers already required, we should really use the > > standard -git tree as everybody's else. This will simplify a lot the way > > we > > work, and give us more agility to send patches upstream. > > Great! Do you have a plan for how soon a move to the standard git tree > will happen? The sooner the better IMO. Let's first finish 2.6.30 merge window. Then, we'll have more time to cleanup the tree and think on moving to git. Now, everyone is focused on having their work done for the next tree. > If I understand correctly you are suggesting that a backporting > system would continue to exist? > > Why? Surely this would be a heavy ball-and-chain to drag around for > eternity. Why not lose the backporting and go for the simplicity and > agility you mentioned above? My suggestion is to keep a backporting system, but more targeted at the end-users. The reasons are the ones explained above. Basically: - Allow end-users to test the drivers without requiring immediate kernel upgrade to the latest -rc-git tree, on their environments; - Offer a tree where people can use to generate contributions like adding new devices at cards table. It should also be clear for all that the backported system is not targeted on offering any kind of implicit or explicit warranty that a driver will work on a legacy kernel. It is a paper of the distros to provide such kind of support. Also, to provide such warranty, other files outside linux/media would need to be patched [1]. So, the backport should keep being provided as a best-effort model, just like what we have right now with all the backports on our tree: we expect it to work, but it may not work on some environments. No warranties are given. I intend to write a proposal about it sometime after the merge window, for people to comment and to contribute with. [1] Just as an example, the USB video drivers leak memory if you're using isoc USB transfers on kernels bellow 2.6.29. So, after some stress conditions, you can eventually run out of memory on legacy kernels. The fix is outside the linux media scope (it is due to a bug at ehci_hcd scheduler). 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: [linux-dvb] FusionHDTV7 and v4l causes kernel panic
On Fri, 2009-03-20 at 11:22 -0700, Timothy D. Lenz wrote: > Not sure where I was suposed to reply to. When replying I find the replys are > coming from diffrent lists and out look is picking > that up. At the bottom it says v4l related stuff should go to > linux-media@vger.kernel.org, but the thread started in > linux-...@linuxtv.org. So I'm re-replying in linux-...@linuxtv.org. Tim, I didn't forget. I saw your message. (I've been busy with yardwork today.) Linux-media or linux-dvb are both appropriate lists. > After searching the internet for ways to redirect the error to serial or > other system and not getting to work, I typed out by hand > what is on the screen minus the cpu dump which is mostly scrolled off anyway > and thus gone. In trying to get the dump out ttyS0 I > found I was getting different dumps to screen. > When I use: > kernel /boot/vmlinuz-2.6.26.8.20090311.1 root=/dev/hda1 ro quiet > console=ttyS0,115200n8 console=tty0 > > I get: > Call Trace: > [] netup_ci_slot_status+0x2e/0x34 [cx23885] > [] cx23885_irq+0x327/0x3d8 [cx23885] > [] handle_IRQ_event+0x1a/0x3f > [] handle_fasteoi_irq+0x76/0xab > [] do_IRQ+0x4f/0x65 > [] common_interrupt+0x23/0x28 > === > Code: 00 74 04 0f 0b eb fe 89 d8 e8 ed a3 ff ff ba 01 00 00 00 5b 89 d0 5e c3 > 51 > 89 d1 8b 15 20 ba 3e c0 e8 52 ff ff ff 5a c3 53 89 c3 0f ba 2a 00 19 c0 > 31 > c9 85 c0 75 54 8d 42 04 39 42 04 74 04 > EIP: [] queue_work+0x3/0x68 SS:ESR 0068:f7733f40 > Kernel panic - not syncing: Fatal exception in interrupt > > When I use the default setting: > kernel /boot/vmlinuz-2.6.26.8.20090311.1 root=/dev/hda1 ro quiet > > I get: > Call Trace: > [] netup_ci_slot_status+0x2e/0x34 [cx23885] > [] cx23885_irq+0x327/0x3d8 [cx23885] > [] handle_IRQ_event+0x1a/0x3f > [] handle_fasteoi_irq+0x76/0xab > [] do_IRQ+0x4f/0x65 > [] common_interrupt+0x23/0x28 > [] _spin_unlock_irq+0x5/0x19 > [] do_syslog+0x12f/0x2f1 > [] reschedule_interrupt+0x28/0x30 > [] autoremove_wake_function+0x0/0x2d > [] kmsg_read+0x0/0x36 > [] proc_reg_read+0x60/0x73 > [] proc_reg_read+0x0/0x73 > [] vfs_read+0x81/0xf4 > [] sys_read+0x3c/0x63 > [] sysenter_past_esp+0x6a/0x91 > === > Code: 00 74 04 0f 0b eb fe 89 d8 e8 ed a3 ff ff ba 01 00 00 00 5b 89 d0 5e c3 > 51 > 89 d1 8b 15 20 ba 3e c0 e8 52 ff ff ff 5a c3 53 89 c3 0f ba 2a 00 19 c0 > 31 > c9 85 c0 75 54 8d 42 04 39 42 04 74 04 > EIP: [] queue_work+0x3/0x68 SS:ESR 0068:f7693e7c > Kernel panic - not syncing: Fatal exception in interrupt > > It may be a bit different each time because I think I've seen longer "Call > Trace" dumps OK. This is the failure mode I thought. I'm not sure how it can happen: the driver treats your device like a NetUp unit, but you have a FusionHDTV7. I'll take a harder look later tonight. In the meantime, as a workaround you can "#if 0" out the following block of code in linux/driver/media/video/cx23885/cx23885-core.c:cx23885_irq(): #if 0 if (cx23885_boards[dev->board].cimax > 0 && ((pci_status & PCI_MSK_GPIO0) || (pci_status & PCI_MSK_GPIO1))) /* handled += cx23885_irq_gpio(dev, pci_status); */ handled += netup_ci_slot_status(dev, pci_status); #endif that should stop this particular panic for you. Things still may not work right though... Regards, Andy > - Original Message - > From: "Andy Walls" > To: > Cc: > Sent: Wednesday, March 18, 2009 7:48 PM > Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic > > > > On Wed, 2009-03-18 at 19:16 -0700, Timothy D. Lenz wrote: > > > I've added > > > console=ttyS0,115200 console=tty0 > > > to the kernel command line options and with out the console=tty0 part the > > > dump no longer shows on the monitor, so redirect seems > to > > > work but loging the serial port on a second computer gets nothing. I > > > tested the connection with echo and that worked but the > kernel > > > dump won't go out the port. The last 2 lines of the screen are: > > > > > > EIP: [] queue_work+0x3/0x68 SS:ESP 0068:f778dd24 > > > Kernel panic - not syncing: Fatal exception in interrupt > > > > Hmm. The only thing in the cx23885 driver that tries to schedule work, > > and thus the only thing that could possibly pass in a bad argument, is > > the netup_ci_slot_status() function. It gets called when an IRQ comes > > in indicating a GPIO[01] event, and the driver thinks the card is a > > NetUp Dual DVB-S2 CI card. > > > > That's consistent with the "fatal exception in interrupt", but without > > the backtrace, one can't be completely sure this call to queue work was > > initiated by the cx23885 driver and a problem with cx23885 data > > structures. (But it is the most likely scenario, IMO) > > I just can't see how netup_ci_slot_status() get's called for your card. > > > > > > > Any way to get the dump to go out the serial port? > > > > Does 9600 baud help? (Just a guess.) > > > > Regards, > > Andy
Re: Results of the 'dropping support for kernels <2.6.22' poll
> Hans, > > On Mon, 2 Mar 2009 22:18:24 +0100 > Hans Verkuil wrote: > > > In the final analysis I'm the boss of my own time. And I've decided that > > once the conversion of all the i2c modules is finished I'll stop > spending > > time on the compatibility code for kernels <2.6.22 as it is simply no > > longer an effective use of my time. If someone else wants to spend time > on > > that, then that's great and I will of course answer questions or help in > > whatever way is needed. > > > > I know that Mauro thinks he can keep the backwards compat code in by > doing > > nifty code transformations. It would be nice if he succeeds (and I have > no > > doubt that it is possible given enough time and effort), but personally > I > > think it is time better spent elsewhere. > > It required just a couple of hours today, in order to add the I2C > conversion > rules on the backport tree: > > http://linuxtv.org/hg/~mchehab/backport/ > > There, I used, as example, the tea6415c.c file that you sent me, meant to > be an > example of a driver converted to use just the new I2C API. I've removed > from it > all the other #ifdefs for 2.6.26, so, the module doesn't have any compat > bits > (except for "compat.h" that can also be handled by the script). I didn't > compile > the entire tree, since several drivers will break, as they aren't ported > yet > to the new I2C style. > > Maybe a few adjustments on the backport.pl may be needed, after having all > drivers converted to 2.6.22, since the final version may need some other > patching rules. > > That's said, the backport tree is still an experimental work. The scripts > require more time to be tested, and the Makefiles need some cleanups. Mauro, neat, but I still think time spent on backporting work would be better spent on cutting-edge development. Two hours here ... two hours there ... it all adds up to a significant investment of time. > Beside the fact that we don't need to strip support for legacy kernels, > the > advantage of using this method is that we can evolute to a new development > model. As several developers already required, we should really use the > standard -git tree as everybody's else. This will simplify a lot the way > we > work, and give us more agility to send patches upstream. Great! Do you have a plan for how soon a move to the standard git tree will happen? The sooner the better IMO. > With this backport script, plus the current v4l-dvb building systems, and > after > having all backport rules properly mapped, we can generate a "test tree" > based on -git drivers/media, for the users to test the drivers against > their > kernels, and still use a clean tree for development. > > Cheers, > Mauro If I understand correctly you are suggesting that a backporting system would continue to exist? Why? Surely this would be a heavy ball-and-chain to drag around for eternity. Why not lose the backporting and go for the simplicity and agility you mentioned above? Regards, Hans W. -- Release early, release often. Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, 20 Mar 2009, Devin Heitmueller wrote: > On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho wrote: > >> The argument being put forth is based on the relative efficiency of > >> the multiply versus divide opcodes on modern CPU architectures?? ?And > > > > Maybe I just like writing efficient code to do interesting things? > > Wow, um, ok. You realize that getting the SNR on most devices is > probably going to require an i2c call that is going to take a couple > hundred CPU instructions, not to mention I/O, right? And that you're > doing this in an expensive ioctl call? So perhaps a > micro-optimization with no visible gain, at the cost of readability > and complexity shouldn't be a overriding consideration? Did I submit a patch to modify dvb-apps? I just wanted to show how to convert fixed point numbers to IEEE 754 floating using only integer math. I think such things are interesting. > >> that you're going to be able to get an SNR with a higher level of > >> precision than 0.1 dB?? (if the hardware suggests that it can then > >> it's LYING to you) > > > > Not really. ?Absolute accuracy is not going to be that good of course. ?But > > the error measurements from which SNR is calculated do support precision of > > better than 0.1 dB. ?That precision does give you more power when fine > > tuning antenna position. > > > > Put another way, what advantage is there of less precision? > > Well, here is one disadvantage: The driver decides the SNR is 23.1. > So I convert that to your format: 0x1719. Then userland gets it back You've assumed the driver will find SNR in decimal fixed point. The lgdt demods and the oren demods all *start* with binary fixed point. So you have the opposite problem were converting to decimal fixed point changes the result. > and goes to display it. I'm going to show the user an SNR of > 23.09765625, and I have no way to know what the expected precision > (and thus I don't know where to round). So the end result is the user > sees a really stupid number in the GUI (and might actually think it is > more accurate than it really is). Or when I push patches to > applications I just round to 0.1dB anyway. It also means apps like > femon and zap are going to have to change to support a non-fixed width > result with no appreciable gain in value. Since 8 binary digits is 2.4 decimal digits, it's perfectly ok to display SNR with 3 fixed decimal digits. You could just as well round to 1 fixed decimal digit too, in which case you've got exactly what you'd get if you started with the decimal fixed point, except the extra precision is there for a situation where it is useful. > By saying explicitly there is one digit of precision - it allows for > applications to know how to round, and I continue to disagree with Binary fixed point says explicitly that there are 8 binary digits of precision. Decimal fixed point says there are 3.3219281 binary digits of precision. We stopped using BCD 30 years ago, computers do everything in binary now. -- 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:Fri Mar 20 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11126:61d2e6e33e90 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-rc8-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29-rc8-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: ERRORS linux-2.6.29-rc8-armv5-omap2: ERRORS 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-rc8-i686: 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-rc8-m32r: OK linux-2.6.22.19-mips: WARNINGS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29-rc8-mips: ERRORS linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29-rc8-powerpc64: ERRORS 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-rc8-x86_64: OK fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc8): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: ISP Configuration for RAW Bayer sensor
Hi Sergio,
Thanks for the update. Sure, I love to get hands on it.
Regards,
Suresh
On Fri, Mar 20, 2009 at 7:49 AM, Aguirre Rodriguez, Sergio Alberto
wrote:
>
>> -Original Message-
>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>> ow...@vger.kernel.org] On Behalf Of Suresh Rao
>> Sent: Thursday, March 19, 2009 7:59 AM
>> To: linux-media@vger.kernel.org
>> Cc: Tuukka.O Toivonen
>> Subject: Re: ISP Configuration for RAW Bayer sensor
>>
>> Hi Tuukka,
>>
>> Thanks a lot for the patch, I will try this.
>>
>> I tried similar thing but on the sensor side and it worked, ie., I
>> skip the very first line from readout and get the desired format for
>> the ISP.
>
> Hi Suresh,
>
> I am currently working on a patch for solving these type of adjustments.
>
> The main idea is to specify from the sensor to the ISP, which is the output
> Raw sequence: RGGB, GRBG, BGGR, GBRG. And then adjust internal ISP reading
> offset to interpret the image adequately...
>
> I'll post the patch as soon as I have it ready (I'm currently busy with some
> other higher priority tasks for these remaining 2 weeks of the month :I)
>
> Regards,
> Sergio
>>
>> Thanks,
>> Suresh
>>
>> On Thu, Mar 19, 2009 at 1:12 PM, Tuukka.O Toivonen
>> wrote:
>> > On Wednesday 18 March 2009 18:17:56 ext Suresh Rao wrote:
>> >> I am working with MT9V023 RAW sensor. The data format from the sensor
>> is
>> >>
>> >> B G B G B G B G ...
>> >> G R G R G R G R ...
>> >> B G B G B G B G ...
>> >> G R G R G R G R [ Format 1]
>> > [...]
>> >> I want to use the ISP on the OMAP for doing interpolation and format
>> >> conversion to UYVY. I am able to capture the images from the sensor,
>> >> however I notice that the color information is missing. I dug the
>> >> sources and found that in the RAW capture mode ISP is getting
>> >> configured to input format
>> >>
>> >> G R G R G R G R ...
>> >> B G B G B G B G ...
>> >> G R G R G R G R ...
>> >> B G B G B G B G ... [Format 2]
>> >>
>> >> Has anyone tried sensors with BGGR ( Format 1) on OMAP?
>> >>
>> >> Can anyone give me some pointers or information on how to configure
>> >> ISP for BGGR (Format 1)
>> >
>> > If you can live with losing a few pixels (maybe sensor has a few extra)
>> > I recommend to configure ISP to crop away the topmost line.
>> >
>> > Here's couple of old _example_ patches how to configure the cropping.
>> > Just gives an idea where to start...
>> >
>> > - Tuukka
>> >
>> >
>> > diff --git a/drivers/media/video/isp/ispccdc.c
>> b/drivers/media/video/isp/ispccdc.c
>> > index 2288bc9..87870f1 100644
>> > --- a/drivers/media/video/isp/ispccdc.c
>> > +++ b/drivers/media/video/isp/ispccdc.c
>> > @@ -1189,13 +1189,13 @@ int ispccdc_config_size(u32 input_w, u32 input_h,
>> u32 output_w, u32 output_h)
>> > ISPCCDC_HORZ_INFO);
>> > } else {
>> > if (ispccdc_obj.ccdc_inpfmt == CCDC_RAW) {
>> > - omap_writel(1 <<
>> ISPCCDC_HORZ_INFO_SPH_SHIFT
>> > - |
>> ((ispccdc_obj.ccdcout_w - 1)
>> > + omap_writel(0 <<
>> ISPCCDC_HORZ_INFO_SPH_SHIFT
>> > + | (ispccdc_obj.ccdcout_w
>> > <<
>> ISPCCDC_HORZ_INFO_NPH_SHIFT),
>> > ISPCCDC_HORZ_INFO);
>> > } else {
>> > omap_writel(0 <<
>> ISPCCDC_HORZ_INFO_SPH_SHIFT
>> > - |
>> ((ispccdc_obj.ccdcout_w - 1)
>> > + | (ispccdc_obj.ccdcout_w
>> > <<
>> ISPCCDC_HORZ_INFO_NPH_SHIFT),
>> > ISPCCDC_HORZ_INFO);
>> > }
>> > @@ -1227,7 +1227,7 @@ int ispccdc_config_size(u32 input_w, u32 input_h,
>> u32 output_w, u32 output_h)
>> > ISPCCDC_VP_OUT_VERT_NUM_SHIFT),
>> > ISPCCDC_VP_OUT);
>> > omap_writel(0 << ISPCCDC_HORZ_INFO_SPH_SHIFT |
>> > - ((ispccdc_obj.ccdcout_w - 1) <<
>> > + (ispccdc_obj.ccdcout_w <<
>> > ISPCCDC_HORZ_INFO_NPH_SHIFT),
>> > ISPCCDC_HORZ_INFO);
>> > omap_writel(0 << ISPCCDC_VERT_START_SLV0_SHIFT,
>> > diff --git a/drivers/media/video/isp/ispccdc.c
>> > b/drivers/media/video/isp/ispccdc.c
>> > index f5957b2..6afaabf 100644
>> > --- a/drivers/media/video/isp/ispccdc.c
>> > +++ b/drivers/media/video/isp/ispccdc.c
>> > @@ -478,7 +478,7 @@ EXPORT_SYMBOL(ispccdc_enable_lsc);
>> > **/
>> > void ispccdc_config_crop(u32 left, u32 top, u32 height, u32 width)
>> > {
>> > - is
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, Mar 19, 2009 at 11:55 PM, Manu Abraham wrote: > Well, that said positioning could be explained for those who on't > have an understanding on how to do it. > > Let's assume, currently at position "X" there is no signal, no > frontend LOCK. You can move the antenna to the approximate X-Y > co-ordinates for the Azimuth and Elevation for your required > transponder, while having an eye on FE_SIGNAL_LEVEL. > > While the FE_SIGNAL_LEVEL peaks for a given position, try to acquire > a frontend LOCK, with the transponder parameters. Most likely you > will get a frontend LOCK with the coarse positioning with AGC peak > values. > > Now, with the frontend LOCK, you can look for initially the peak > again, not the FE_SIGNAL_LEVEL peak in this case, but the > FE_SIGNAL_STATS peak. > > In this case you should not be looking at just the strength > parameter alone. > > * At the peak, you will get the maximum quality > * falling down the slope to the left and right you will get falling > signal strengths > * Still rolling down, you will get increasing ERROR's, with still > UNCORRECTABLES being steady. > * Still falling down at the thresholds where you are about to loose > frontend LOCK, you will see UNCORRECTABLE's getting incremented. > > Couple this logic into a program, with a feedback to the ROTOR and > you get an automated satellite positioner, with a good fine tuned > position. This would make for a very very useful tool to have. I can't count the number of times I've seen people inquire about tools to help them aim their dish and this sounds like the perfect solution to that long standing problem. Especially if it returned the network id once it's achieve a lock so the user can see if he's pointed to the correct satellite. -- 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: [linux-dvb] Linux driver for Hauppauge WinTV-HVR 950Q
On Fri, Mar 20, 2009 at 10:19 AM, Steven Toth wrote: > > ZhanMa wrote: >> Hi Steven, >> >> I am working on porting the Hauppauge WinTV-Hvr 950Q tuner driver to a >> TI DaVinci platform which uses linux kernel 2.6.18 (MontaVista). After I >> pluged in the tuner into the board's usb port, I got the following >> message. It looks that the registration procedure finished but I saw the >> message that xc5000 firmware not load yet (I already put the firmware, >> dvb-fe-xc5000-1.1.fw, under /lib/firmware). >> >> So I believe it should load the firmware, otherwise the tuner would not >> work, right? But why it didn't load? >> >> Please advise me how I can fix this problem, thank you so much!! >> >> Jason Ma >> >> >> >> >> r...@192.168.1.208:~# >> usb 1-1.1: new high speed USB device using musb_hdrc and address 4 >> usb 1-1.1: Product: WinTV HVR-950 >> usb 1-1.1: Manufacturer: Hauppauge >> usb 1-1.1: SerialNumber: 4031281567 >> usb 1-1.1: configuration #1 chosen from 1 choice >> au0828_init() Debugging is enabled >> au0828_init() USB Debugging is enabled >> au0828 driver loaded >> au0828_usb_probe() vendor id 0x2040 >> au0828_usb_probe() device id 0x7200 >> au0828_gpio_setup() >> au0828_i2c_register() >> davinci_i2c_probe_adapter: 0xc06fe858 >> davinci_evm_expander1 i2c attach [addr=0x3a,client=davinci_evm_expander1] >> board_i2c_expander_setup=0xc001ae8c, 0xc001ae8c >> aic3x I2C Codec i2c attach [addr=0x1b,client=AIC3X] >> asoc: aic3x <-> davinci-i2s mapping ok >> au0828: i2c bus registered >> [au0828_usb_probe], au0828_card_setup >> i2c_readbytes() >> [hauppauge_eeprom] >> tveeprom 1-0050: Hauppauge model 72001, rev B3F0, serial# 4749727 >> tveeprom 1-0050: MAC address is 00-0D-FE-48-79-9F >> tveeprom 1-0050: tuner model is Xceive XC5000 (idx 150, type 4) >> tveeprom 1-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) >> tveeprom 1-0050: audio processor is AU8522 (idx 44) >> tveeprom 1-0050: decoder processor is AU8522 (idx 42) >> tveeprom 1-0050: has no radio, has IR receiver, has no IR transmitter >> hauppauge_eeprom: hauppauge eeprom: model=72001 >> xc5000_attach() >> xc5000 1-0061: creating new instance >> xc5000_attach() new tuner instance >> xc5000: Successfully identified at address 0x61 >> xc5000: Firmware has not been loaded previously >> DVB: registering new adapter (au0828) >> DVB: registering adapter 0 frontend -8388625 (Auvitek AU8522 QAM/8VSB >> Frontend)... >> Registered device AU0828 [Hauppauge HVR950Q] >> Registered device AU0828 [Hauppauge HVR950Q] >> usbcore: registered new driver au0828 >> [au0828_init], usb_register success, ret=0 >> >> >> >> r...@192.168.1.208:~# lsusb >> Bus 001 Device 004: ID 2040:7200 >> Bus 001 Device 003: ID 0596:0001 MicroTouch Systems, Inc. Touchscreen >> Bus 001 Device 002: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 >> USB-2.0 "TetraHub" >> Bus 001 Device 001: ID : >> >> > > Hi, > > What makes you think the firmware has not loaded? > > - Steve > > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > Hello Steven, Perhaps he got confused by the "has not been loaded previously". It might also be good to find out what version of the code he is running, since it looks like the analog support isn't being loaded. > DVB: registering adapter 0 frontend -8388625 Also, looks like perhaps a kalloc() was done instead of a kzalloc() [I have seen this with s5h1411 as well]. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho wrote: >> The argument being put forth is based on the relative efficiency of >> the multiply versus divide opcodes on modern CPU architectures?? And > > Maybe I just like writing efficient code to do interesting things? Wow, um, ok. You realize that getting the SNR on most devices is probably going to require an i2c call that is going to take a couple hundred CPU instructions, not to mention I/O, right? And that you're doing this in an expensive ioctl call? So perhaps a micro-optimization with no visible gain, at the cost of readability and complexity shouldn't be a overriding consideration? >> that you're going to be able to get an SNR with a higher level of >> precision than 0.1 dB?? (if the hardware suggests that it can then >> it's LYING to you) > > Not really. Absolute accuracy is not going to be that good of course. But > the error measurements from which SNR is calculated do support precision of > better than 0.1 dB. That precision does give you more power when fine > tuning antenna position. > > Put another way, what advantage is there of less precision? Well, here is one disadvantage: The driver decides the SNR is 23.1. So I convert that to your format: 0x1719. Then userland gets it back and goes to display it. I'm going to show the user an SNR of 23.09765625, and I have no way to know what the expected precision (and thus I don't know where to round). So the end result is the user sees a really stupid number in the GUI (and might actually think it is more accurate than it really is). Or when I push patches to applications I just round to 0.1dB anyway. It also means apps like femon and zap are going to have to change to support a non-fixed width result with no appreciable gain in value. By saying explicitly there is one digit of precision - it allows for applications to know how to round, and I continue to disagree with your assertion that you will get any better accuracy with that anyway. We could *in theory* provide a separate ioctl so the driver can know what the expected precision is, but I do not believe it is worthwhile to over-engineer the interface. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, Mar 20, 2009 at 2:55 AM, Manu Abraham wrote: > When you position an antenna, you do not get a LOCK in most cases. > The signal statistics for any demodulator are valid only with a > frontend LOCK. This is absolutely true, and a very common problem in the drivers (at least with the ATSC/QAM devices). Most of the drivers blindly return whatever value is in the register regardless of whether there is lock. One of the things I plan to do for the ATSC devices is go through each of them and make sure they properly return ENOSIGNAL when there is not a lock (this is actually already the defined behavior in the dvb v3 spec), as well as submitting patches for Kaffeine to properly reflect this state to the user. Cheers, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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 3/3] V4L2 Driver for OMAP3/3 DSS.
> -Original Message-
> From: Alexey Klimov [mailto:klimov.li...@gmail.com]
> Sent: Friday, March 20, 2009 6:02 PM
> To: Shah, Hardik
> Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R;
> Hiremath, Vaibhav
> Subject: Re: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
>
>
>
> Hello again,
> my previous message due to bad connection was send with no end.
> Sorry about that.
>
> > + vout->vid = k;
> > + vid_dev->vouts[k] = vout;
> > + vout->vid_info.vid_dev = vid_dev;
> > + vout->vid_info.overlays[0] = vid_dev->overlays[k + 1];
> > + vout->vid_info.num_overlays = 1;
> > + vout->vid_info.id = k + 1;
> > + vid_dev->num_videos++;
> > +
> > + /* Setup the default configuration for the video devices
> > +*/
> > + if (omap_vout_setup_video_data(vout) != 0) {
> > + r = -ENOMEM;
> > + goto error;
> > + }
> > +
> > + /* Allocate default number of buffers for the video
> streaming
> > +* and reserve the VRFB space for rotation
> > +*/
> > + if (omap_vout_setup_video_bufs(pdev, k) != 0) {
> > + r = -ENOMEM;
> > + goto error1;
> > + }
> > +
> > + /* Register the Video device with V4L2
> > +*/
> > + vfd = vout->vfd;
> > + if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) < 0)
> {
> > + printk(KERN_ERR VOUT_NAME ": could not register \
> > + Video for Linux device\n");
> > + vfd->minor = -1;
> > + r = -ENODEV;
> > + goto error2;
> > + }
> > +
> > + if (k == 0)
> > + saved_v1out = vout;
> > + else
> > + saved_v2out = vout;
> > +
> > + r = omapvid_apply_changes(vid_dev->vouts[k], 0, 1);
> > +
> > + if (r)
> > + goto error2;
> > + else
> > + goto success;
> > +error2:
> > + omap_vout_release_vrfb(vout);
> > + omap_vout_free_buffers(vout);
> > +error1:
> > + video_device_release(vfd);
> > +error:
> > + kfree(vout);
> > + return r;
> > +
> > +success:
> > + printk(KERN_INFO VOUT_NAME ": registered and initialized\
> > + video device %d [v4l2]\n", vfd->minor);
> > + if (k == (pdev->num_resources - 1))
> > + return 0;
> > + }
> > + return -ENODEV;
> > +
> > +}
> > +
> > +int omapvid_apply_changes(struct omap_vout_device *vout, u32 addr, int
> init)
> > +{
> > + int r = 0;
> > + struct omapvideo_info *ovid = &(vout->vid_info);
> > + struct omap_overlay *ovl;
> > + int posx, posy;
> > + int outw, outh, temp, rotation;
> > + int i;
> > + struct v4l2_window *win;
> > + struct omap_video_timings *timing;
> > + struct omap_display *cur_display;
> > +
> > + win = &vout->win;
> > + rotation = vout->rotation;
> > + for (i = 0; i < ovid->num_overlays; i++) {
> > + ovl = ovid->overlays[i];
> > + if (!ovl->manager || !ovl->manager->display)
> > + return -EINVAL;
> > +
> > + timing = &ovl->manager->display->panel->timings;
> > + cur_display = ovl->manager->display;
> > +
> > + if (init || (ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) {
> > + outw = win->w.width;
> > + outh = win->w.height;
> > +
> > + } else {
> > + outw = win->w.width;
> > + outh = win->w.height;
> > + }
> > + if (init) {
> > + posx = 0;
> > + posy = 0;
> > + } else {
> > + switch (rotation) {
> > +
> > + case 1:
> > + /* Invert the height and widht for 90
> > +* and 270 degree rotation
> > +*/
> > + temp = outw;
> > + outw = outh;
> > + outh = temp;
> > + posy = (timing->y_res - win->w.width)-
> > + win->w.left;
> > + posx = win->w.top;
> > + break;
> > +
> > + case 2:
> > + posx = (timing->x_res - win->w.width) -
> > + win->w.left;
> > + posy = (timing->y_res - win->w.height)
Re: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
Hello again,
my previous message due to bad connection was send with no end.
Sorry about that.
> + vout->vid = k;
> + vid_dev->vouts[k] = vout;
> + vout->vid_info.vid_dev = vid_dev;
> + vout->vid_info.overlays[0] = vid_dev->overlays[k + 1];
> + vout->vid_info.num_overlays = 1;
> + vout->vid_info.id = k + 1;
> + vid_dev->num_videos++;
> +
> + /* Setup the default configuration for the video devices
> + */
> + if (omap_vout_setup_video_data(vout) != 0) {
> + r = -ENOMEM;
> + goto error;
> + }
> +
> + /* Allocate default number of buffers for the video streaming
> + * and reserve the VRFB space for rotation
> + */
> + if (omap_vout_setup_video_bufs(pdev, k) != 0) {
> + r = -ENOMEM;
> + goto error1;
> + }
> +
> + /* Register the Video device with V4L2
> + */
> + vfd = vout->vfd;
> + if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) < 0) {
> + printk(KERN_ERR VOUT_NAME ": could not register \
> + Video for Linux device\n");
> + vfd->minor = -1;
> + r = -ENODEV;
> + goto error2;
> + }
> +
> + if (k == 0)
> + saved_v1out = vout;
> + else
> + saved_v2out = vout;
> +
> + r = omapvid_apply_changes(vid_dev->vouts[k], 0, 1);
> +
> + if (r)
> + goto error2;
> + else
> + goto success;
> +error2:
> + omap_vout_release_vrfb(vout);
> + omap_vout_free_buffers(vout);
> +error1:
> + video_device_release(vfd);
> +error:
> + kfree(vout);
> + return r;
> +
> +success:
> + printk(KERN_INFO VOUT_NAME ": registered and initialized\
> + video device %d [v4l2]\n", vfd->minor);
> + if (k == (pdev->num_resources - 1))
> + return 0;
> + }
> + return -ENODEV;
> +
> +}
> +
> +int omapvid_apply_changes(struct omap_vout_device *vout, u32 addr, int init)
> +{
> + int r = 0;
> + struct omapvideo_info *ovid = &(vout->vid_info);
> + struct omap_overlay *ovl;
> + int posx, posy;
> + int outw, outh, temp, rotation;
> + int i;
> + struct v4l2_window *win;
> + struct omap_video_timings *timing;
> + struct omap_display *cur_display;
> +
> + win = &vout->win;
> + rotation = vout->rotation;
> + for (i = 0; i < ovid->num_overlays; i++) {
> + ovl = ovid->overlays[i];
> + if (!ovl->manager || !ovl->manager->display)
> + return -EINVAL;
> +
> + timing = &ovl->manager->display->panel->timings;
> + cur_display = ovl->manager->display;
> +
> + if (init || (ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) {
> + outw = win->w.width;
> + outh = win->w.height;
> +
> + } else {
> + outw = win->w.width;
> + outh = win->w.height;
> + }
> + if (init) {
> + posx = 0;
> + posy = 0;
> + } else {
> + switch (rotation) {
> +
> + case 1:
> + /* Invert the height and widht for 90
> + * and 270 degree rotation
> + */
> + temp = outw;
> + outw = outh;
> + outh = temp;
> + posy = (timing->y_res - win->w.width)-
> + win->w.left;
> + posx = win->w.top;
> + break;
> +
> + case 2:
> + posx = (timing->x_res - win->w.width) -
> + win->w.left;
> + posy = (timing->y_res - win->w.height) -
> + win->w.top;
> + break;
> +
> + case 3:
> + temp = outw;
> + outw = outh;
> + outh = temp;
> + posy = win->w.left;
> + posx = (timing->x_res - win->w.height)
> + - win->w.top;
> + break;
> +
> + default:
> +
Re: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
Op 20 mrt 2009, om 06:20 heeft Hardik Shah het volgende geschreven: --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -711,6 +711,26 @@ config VIDEO_CAFE_CCIC CMOS camera controller. This is the controller found on first- generation OLPC systems. +#config VIDEO_OMAP3 +#tristate "OMAP 3 Camera support" +# select VIDEOBUF_GEN +# select VIDEOBUF_DMA_SG +# depends on VIDEO_V4L2 && ARCH_OMAP34XX +# ---help--- +#Driver for an OMAP 3 camera controller. + +config VIDEO_OMAP3 + bool "OMAP2/OMAP3 Camera and V4L2-DSS drivers" + select VIDEOBUF_GEN + select VIDEOBUF_DMA_SG + select OMAP2_DSS + depends on VIDEO_DEV && (ARCH_OMAP24XX || ARCH_OMAP34XX) + default y + ---help--- +V4L2 DSS and Camera driver support for OMAP2/3 based boards. Copy/paste error? regards, Koen PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
RE: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
> -Original Message- > From: Koen Kooi [mailto:k.k...@student.utwente.nl] > Sent: Friday, March 20, 2009 2:34 PM > To: Shah, Hardik > Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R; > Hiremath, Vaibhav > Subject: Re: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS. > > > Op 20 mrt 2009, om 06:20 heeft Hardik Shah het volgende geschreven: > > > > --- a/drivers/media/video/Kconfig > > +++ b/drivers/media/video/Kconfig > > @@ -711,6 +711,26 @@ config VIDEO_CAFE_CCIC > > CMOS camera controller. This is the controller found on first- > > generation OLPC systems. > > > > +#config VIDEO_OMAP3 > > +#tristate "OMAP 3 Camera support" > > +# select VIDEOBUF_GEN > > +# select VIDEOBUF_DMA_SG > > +# depends on VIDEO_V4L2 && ARCH_OMAP34XX > > +# ---help--- > > +#Driver for an OMAP 3 camera controller. > > + > > +config VIDEO_OMAP3 > > + bool "OMAP2/OMAP3 Camera and V4L2-DSS drivers" > > + select VIDEOBUF_GEN > > + select VIDEOBUF_DMA_SG > > + select OMAP2_DSS > > + depends on VIDEO_DEV && (ARCH_OMAP24XX || ARCH_OMAP34XX) > > + default y > > + ---help--- > > +V4L2 DSS and Camera driver support for OMAP2/3 based boards. > > > Copy/paste error? > > regards, > > Koen [Shah, Hardik] Yes, I will correct it, Its indeed copy paste error Regards, Hardik -- 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: [linux-dvb] Weird TS Stream from DMX_SET_PES_FILTER
Bob Ingraham wrote: > Hello, > > I've been using the Linux DVB API to grab DBV-S MPEG2 video packets using a > TechniSat S2 card. > > But something seems odd about DMX_SET_PES_FILTER. > > It returns a TS packets for my pid just fine, but by MPEG2 frames have no PES > headers! The raw compressed MPEG2 frames just immediately follow the > TS/adapation-field headers directly. > > When I wrote my TS packet decoder, I was expecting to have to decode PES > headers after the TS header. But instead I found the raw compressed frames. > > They decode fine (with ffmpeg's libavcodec mpeg2 decoder,) and they look fine > when rendered using SDL. > > But besides my own program, I can't get vlc or mplayer to decode this stream. > Both vlc and mplayer sense a TS stream, but then they never render anything > because, I suspect, that they can't find PES headers. > > So, two questions: > > 1. Am I crazy or is DMX_SET_PES_FILTER returning a non-standard TS stream? > > 2. Is there a way to receive a compliant MPEG-TS (or MPEG2-PS,) stream? > > 3. Should I use DMX_SET_FILTER instead? > > 4. If so, what goes in the filter/mask members of the dmx_filter_t struct? > > > Thanks, > Bob > > PS: I use the following to filter on my video stream pid (0x1344): > > struct dmx_pes_filter_params f; > > memset(&f, 0, sizeof(f)); > f.pid = (uint16_t) pid; > f.input = DMX_IN_FRONTEND; > f.output = DMX_OUT_TS_TAP; > f.pes_type = DMX_PES_OTHER; > f.flags = DMX_IMMEDIATE_START; > > Hello, I use exactly the same parameters and I get a raw mpeg2-TS stream (ie packet of 188 bytes with the TS headers as defined in the mpeg2-ts norm) If you want your stream to be read with VLC you need also the PAT and the PMT pids. If you want the sound you'll need also the PCR pid. I don't know how to get the PES headers Hope this information will help you Regards -- Brice -- 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: About white balance control.
DO_WHITE_BALANCE is intended to do a one-shot white balance calibration and then hold it. So you would hold up, for example, a white piece of paper in front of the camera and click the do white balance. Then the white balance should be correct as long as the lighting doesn't change. This can work better than auto white balance which can be fooled by colored walls, etc. Some video cameras used to have a button like this. Bill. Dongsoo, Nathaniel Kim wrote: Thank you Pingchart. So, V4L2_CID_DO_WHITE_BALANCE acts WB adjustment at every single time it has issued when device is in manual WB mode like V4L2_CID_WHITE_BALANCE_TEMPERATURE? Now I get it. But CID still missing for white balance presets like "cloudy", "sunny", "fluorescent"and so on. I think some sort of menu type CID could be useful to handle them, because WB presets differ for each devices. Cheers, Nate 2009/3/18 Laurent Pinchart : Hi Kim, On Wednesday 18 March 2009 05:32:08 Dongsoo, Nathaniel Kim wrote: Hello, I accidently realized today that I was using white balance control in wrong way. As far as I understand we've got V4L2_CID_AUTO_WHITE_BALANCE which activate auto white balance adjustment in runtime, V4L2_CID_DO_WHITE_BALANCE_TEMPERATURE specifying absolute kelvin value I suppose you mean V4L2_CID_WHITE_BALANCE_TEMPERATURE here. but can't get what V4L2_CID_DO_WHITE_BALANCE is for. I think after issuing V4L2_CID_AUTO_WHITE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE, the white balance functionality works immediately. Isn't it right? What exactly is the button type V4L2_CID_DO_WHITE_BALANCE for? Because the V4L2 API document says that "(the value is ignored)". Does that mean that even we have issued V4L2_CID_AUTO_WHITE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE, we can't see the white balance working at that moment? V4L2_CID_AUTO_WHITE_BALANCE to enables or disables automatic white balance adjustment. When automatic white balance is enabled the device adjusts the white balance continuously. V4L2_CID_WHITE_BALANCE_TEMPERATURE controls the white balance adjustment manually. The control is only effective when automatic white balance is disabled. V4L2_CID_DO_WHITE_BALANCE instructs the device to run the automatic white balance adjustment algorithm once and use the results for white balance correction. It only makes sense when automatic white balance is disabled. And one more thing. If I want to serve several white balance presets, like cloudy, dawn, sunny and so on, what should I do? I think it should be supported as menu type, but most of drivers are using white balance CID with integer type...then what should I do? Define preset names with kelvin number like this? #define WB_CLOUDY 8000 Pretty confusing... anyone knows what should I do? 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: Is v4l2 loopback needed in kernel? Invitation for code review
Hi Vasily! On Thursday 05 March 2009 22:13:24 vas...@gmail.com wrote: > Hello, my v4l2 loopback device is now at working state: it can do > streaming and basic IO, works with Skype, luvcview and mplayer. next > feature planned is allowing multiply readers. > Benefits from having this driver are: video effects for video > conferencing programms aware only about v4l, driver can serve as > adapter between v4l1 and v4l2 and allow multiply readers for webcam. > > Is it worth to push this driver to kernel? I have already done some > work to comply with kernel coding style, and need a code review to > make shure if I managed to follow common practicies. > > current version is tested only with 2.6.26 kernel, I will add 2.6.28 > support(if any work needed) soon. > code hosted on google code > http://code.google.com/p/v4l2loopback/ This reply has been on my todo list for ages, but I finally gotten around to it :-) Yes, I think it is useful to have this as part of the kernel. But the first step will have to be to make your code compile and work with the v4l-dvb master repository: http://linuxtv.org/hg/v4l-dvb/ See also: http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches Note that there have been a lot of changes lately, so you should use the master repository as the starting point for your driver. 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
Re: [PATCH 0/3] V4L2 driver for OMAP2/3 with new CIDs.
On Friday 20 March 2009 06:18:44 Shah, Hardik wrote: > Hi All, > I will be posting series of three patches for the V4L2 driver on the > OMAP2/3 DSS. Thanks! I'll review this within the week. Regards, Hans > Patch 1 - > This is the second revision of the patch. > Documentation added for the following new CIDs and bit fields added in > V4L2 framework. > > V4L2_CID_BG_COLOR: Added new CID for setting of the back ground color on > the output device. V4L2_CID_ROTATION: Added new CID for setting up of the > rotation on the device. Both of the above ioctls are discussed in detail. > > V4L2_FBUF_FLAG_SRC_CHROMAKEY: Added the flags bit field to the flags > field of the v4l2_framebuffer structure for supporting the source chroma > keying. It's exactly opposite of the chroma keying supported with the > flag V4L2_FBUF_FLAG_CHROMAKEY. > > V4L2_FBUF_CAP_SRC_CHROMAKEY: Added the capability bit field for the > capability field of the v4l2_framebuffer structure. > > Documentation change related to the new bit field for the source chroma > keying is new from the previous version. > > Patch 2 - > Added New Control IDs for OMAP class of Devices as discussed above. This > is the third revision of the patch of adding the new control IDs and bit > fields. > > V4L2_FBUF_CAP_SRC_CHROMAKEY and V4L2_FBUF_FLAG_SRC_CHROMAKEY are newly > added compared to previous revision of patch. > > New Ioctl for programming the color space conversion matrix is dropped > from this patch as the accompanying driver with this patch is not still > having implementation for the same. Related documentation is also > removed. > > I will submit a separate patch for that with the necessary changes in > driver to support the programming of the color space conversion. Some > changes are required in DSS2 library also for doing the same. > > Patch 3 - > This is a review patch since the DSS2 library is still to be accepted in > community This is the third revision of the patch. > This patch contains the V4L2 driver on the OMAP3 DSS2 using all of the > above newly implemented CIDS and bit fields. Following are the changes > in the driver compared to the previous version. > > 1. Added the chroma keying support. > 2. Added alpha blending support. > 3. Minor community comment fixed. > 4. Ported to work with Tomi's latest DSS2 library with minor > modification in DSS2 library. Path to Tomi's DSS2 library is > http://www.bat.org/~tomba/git/linux-omap-dss.git/ commit id > bc6dc4c7fabb8ba3bfe637a6c5dc271595a1bef6 > > All the comments and inputs are welcomed. > > Thanks and Regards > Hardik Shah > > > > -- > 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 -- 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
Re: Some possible missing v4l2_subdev IOCTLs.
On Friday 20 March 2009 03:24:49 Aguirre Rodriguez, Sergio Alberto wrote: > Hi Hans, > > I did a quick analysis of the subdev, and noticed that some video ioctls > for the subdevices aren't there... > > [gs]_crop > [gs]_parm > enum_frameintervals > enum_framesizes > enum_fmt_cap > > I noticed this because we currently use them for a "best sensor output" > selection before sending the image to the OMAP3 ISP. > > Any particular reason why these aren't there? Because no other i2c drivers needed them until now. I try to avoid adding code that nobody is using. Note that gs_parm was just added. And in video_ops there is already an enum_fmt. Feel free to add crop and the enum_frame* ops. If you mail me a patch, then I'll commit it. 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
Re: v4l2-subdev missing video ops
On Friday 20 March 2009 00:55:20 Pete Eberlein wrote: > Hello Hans, > > I'm looking at converting the go7007 staging driver to use the subdev > API. Hoorah! :-) > I don't see any v4l2_subdev_video_ops for VIDIOC_S_INPUT nor > VIDIOC_S_STD. Were those overlooked, or should I use the generic > v4l2_subdev_core_ops->ioctl? (The chip in particular does not have a > tuner, but it does have multiple inputs (svidio, composite) and supports > NTSC or PAL.) S_STD exists, but it is in tuner_ops. I know, I know, that's the wrong place. I'll move it to video_ops once all conversions are done. S_INPUT must not be used in subdevices. S_INPUT deals with user-level inputs (e.g. "Composite", "S-Video", "Tuner"), not with the sub-device-level inputs/outputs (e.g. PIN-X, PIN-Y). Sub-devices know nothing about the user-level since that's a board-level informations. Sub-devices only know about their own input and output pins. The adapter driver is responsible for mapping an S_INPUT ioctl to video/s_routing and audio/s_routing subdev ops. These routing commands tell the sub-device on what pin(s) it receives its input data and what pin(s) are used for the output. What values you put in the v4l2_routing struct is sub-device dependent and is defined in the include/media/.h header. 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
