* Re: video4linux-list Digest, Vol 50, Issue 22 [not found] <20080422160012.2C52C6195D0@hormel.redhat.com> @ 2008-04-22 16:19 ` zied frikha 2008-04-22 16:20 ` zied frikha 2008-04-22 16:36 ` Daniel Glöckner 0 siblings, 2 replies; 3+ messages in thread From: zied frikha @ 2008-04-22 16:19 UTC (permalink / raw) To: video4linux-list [-- Attachment #1: Type: text/plain, Size: 37707 bytes --] I NEED A GUI FOR THE SI470X RADIO THAT RUN UNDER LINUX (MANDRIVA 2008) :( PLEEEEEEEEEEEEEEEEEEEASE 2008/4/22, video4linux-list-request@redhat.com < video4linux-list-request@redhat.com>: > > Send video4linux-list mailing list submissions to > video4linux-list@redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/video4linux-list > or, via email, send a message with subject or body 'help' to > video4linux-list-request@redhat.com > > You can reach the person managing the list at > video4linux-list-owner@redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of video4linux-list digest..." > > Today's Topics: > > 1. Re: [PATCH 1/2] V4L: add "function" sysfs attribute to v4l > devices (Laurent Pinchart) > 2. Re: [PATCH 1/2] V4L: add "function" sysfs attribute to v4l > devices (Kees Cook) > 3. Re: 2.6.25 regression: vivi - scheduling while atomic > (Brandon Philips) > 4. [PATCH] v4l2-spec: write-only controls ('Brandon Philips') > 5. Re: [PATCH 4 of 6] v4l2-api: Define a standard control for > color killer functionality (Brandon Philips) > 6. Re: [PATCH 0 of 6] cx88: Enable additional cx2388x features. > Version 3 (Brandon Philips) > 7. Re: 2.6.25 regression: vivi - scheduling while atomic > (hermann pitton) > 8. Re: [PATCH] Support for write-only controls (Brandon Philips) > 9. Hauppauge HVR1400 DVB-T support / XC3028L (Steven Toth) > 10. Re: Hauppauge HVR1400 DVB-T support / XC3028L (Brandon Philips) > 11. Re: [BUG] HVR-1500 Hot swap causes lockup (Brandon Philips) > 12. Re: [PATCH] Support for write-only controls (Laurent Pinchart) > 13. Empia em28xx based USB video device... (2) (Mat) > 14. Re: Empia em28xx based USB video device... (2) (Markus Rechberger) > 15. Re: Hauppauge HVR1400 DVB-T support / XC3028L (Steven Toth) > 16. Re: question for soc-camera driver (Guennadi Liakhovetski) > 17. Re: [PATCH] Support for write-only controls (Brandon Philips) > 18. Re: 2.6.25 regression: vivi - scheduling while atomic > (Mauro Carvalho Chehab) > 19. Re: Hauppauge HVR1400 DVB-T support / XC3028L > (Mauro Carvalho Chehab) > 20. em28xx/xc3028: changeset 7651 breaks analog audio? > (Edward J. Sheldrake) > > > ---------- Message transféré ---------- > From: Laurent Pinchart <laurent.pinchart@skynet.be> > To: Kees Cook <kees@outflux.net> > Date: Mon, 21 Apr 2008 23:10:46 +0200 > Subject: Re: [PATCH 1/2] V4L: add "function" sysfs attribute to v4l devices > On Friday 18 April 2008, Kees Cook wrote: > > Hi Laurent, > > > > On Fri, Apr 18, 2008 at 09:33:21PM +0200, Laurent Pinchart wrote: > > > On Thursday 17 April 2008, Kees Cook wrote: > > > > +static const char *v4l2_function_type_names[] = { > > > > + [V4L2_FN_VIDEO_CAP] = "vid-cap", > > > > + [V4L2_FN_VIDEO_OUT] = "vid-out", > > > > + [V4L2_FN_MPEG_CAP] = "mpeg-cap", > > > > + [V4L2_FN_MPEG_OUT] = "mpeg-out", > > > > + [V4L2_FN_YUV_CAP] = "yuv-cap", > > > > + [V4L2_FN_YUV_OUT] = "yuv-out", > > > > > > I don't like those. Video capture devices can encode pixels in a > variety > > > of formats. MPEG and YUV are only two special cases. You will find > > > devices encoding in RGB, Bayer, MJPEG, ... as well as some proprietary > > > formats. > > > > If these devices have a variable encoding method, perhaps just use > > "vid-cap" as the general rule. (In the case that the output formats are > > selectable from a given device node at runtime.) > > That would indeed be better. The function name should be derived from the > v4l > type if possible. > > > > If I understand your problem correctly, you want to differentiate > between > > > multiple v4l devices created by a single driver for a single hardware > > > device. Using the above functions might work for ivtv but rules out > > > devices that output multiple streams in the same format. > > > > > > Wouldn't it be better to fix the ivtv driver to use a single device > node > > > for both compressed and uncompressed streams ? > > > > I'm not very familiar with the v4l code base, so I don't have a good > > answer about if it's right or not. The core problem does tend to boil > > down to dealing with drivers that create multiple device nodes for the > > same physical hardware (ivtv is not alone in this regard). > > > > I don't know what the semantics are for device mode vs device node in > > v4l, but it seems that since there are multiple nodes being created for > > a given piece of hardware, something needs to be exported to sysfs to > > distinguish them. > > Good point. > > v4l drivers create several device nodes for good or not-so-good reasons. I > think we can classify the hardware/drivers in several categories: > > 1. The device supports multiple concurrent data streams for different kind > of > data. The is most often found for audio/video or video/vbi. Audio is > handled > through alsa, and video and vbi are handled through v4l. The driver then > creates a device node for each video/vbi data stream. The devices can > easily > be distinguished by their v4l type. > > 2. The device supports a single data stream with a selectable data format. > The > driver will create a single device node, format selection is handled > through > the v4l API. > > 3. The device supports multiple concurrent data streams for a single kind > of > data. ivtv falls under this case. The most common use case is a device with > several video pipes (usually 2) that can be used simultaneously to stream > the > same data (in different or identical formats, either fixed or > configurable). > > Case 3 is the only one to cause device node naming issues. I'm not sure if > the > driver does the right thing when it creates several device nodes. Should > the > peripheral be seen as a single device that allows access by two users > simultaneously, or should it be seen as two fixed-format devices ? Each > solution will probably come with its own set of issues. > > Laurent Pinchart > > > > > ---------- Message transféré ---------- > From: Kees Cook <kees@outflux.net> > To: Laurent Pinchart <laurent.pinchart@skynet.be> > Date: Mon, 21 Apr 2008 14:47:17 -0700 > Subject: Re: [PATCH 1/2] V4L: add "function" sysfs attribute to v4l devices > Hi Laurent, > > On Mon, Apr 21, 2008 at 11:10:46PM +0200, Laurent Pinchart wrote: > > On Friday 18 April 2008, Kees Cook wrote: > > > On Fri, Apr 18, 2008 at 09:33:21PM +0200, Laurent Pinchart wrote: > > > > On Thursday 17 April 2008, Kees Cook wrote: > > > > > +static const char *v4l2_function_type_names[] = { > > > > > + [V4L2_FN_VIDEO_CAP] = "vid-cap", > > > > > + [V4L2_FN_VIDEO_OUT] = "vid-out", > > > > > + [V4L2_FN_MPEG_CAP] = "mpeg-cap", > > > > > + [V4L2_FN_MPEG_OUT] = "mpeg-out", > > > > > + [V4L2_FN_YUV_CAP] = "yuv-cap", > > > > > + [V4L2_FN_YUV_OUT] = "yuv-out", > > > > > > > > I don't like those. Video capture devices can encode pixels in a > variety > > > > of formats. MPEG and YUV are only two special cases. You will find > > > > devices encoding in RGB, Bayer, MJPEG, ... as well as some > proprietary > > > > formats. > > > > > > If these devices have a variable encoding method, perhaps just use > > > "vid-cap" as the general rule. (In the case that the output formats > are > > > selectable from a given device node at runtime.) > > > > That would indeed be better. The function name should be derived from the > v4l > > type if possible. > > Sure, but I think Kay's point was this it needs to be relatively > "static" so that userspace (and udev) can depend on it not changing very > much. I am not attached to any of the names in the proposed patch -- > they work for me, but I'd be happy to see a different list if it were > more sensible. > > > > I don't know what the semantics are for device mode vs device node in > > > v4l, but it seems that since there are multiple nodes being created for > > > a given piece of hardware, something needs to be exported to sysfs to > > > distinguish them. > > > > Good point. > > > > v4l drivers create several device nodes for good or not-so-good reasons. > I > > think we can classify the hardware/drivers in several categories: > > > > 1. The device supports multiple concurrent data streams for different > kind of > > data. The is most often found for audio/video or video/vbi. Audio is > handled > > through alsa, and video and vbi are handled through v4l. The driver then > > creates a device node for each video/vbi data stream. The devices can > easily > > be distinguished by their v4l type. > > > > 2. The device supports a single data stream with a selectable data > format. The > > driver will create a single device node, format selection is handled > through > > the v4l API. > > > > 3. The device supports multiple concurrent data streams for a single kind > of > > data. ivtv falls under this case. The most common use case is a device > with > > several video pipes (usually 2) that can be used simultaneously to stream > the > > same data (in different or identical formats, either fixed or > configurable). > > Right -- case 3 is where the main problems and special-cases appeared > when trying to work out a viable "static" path for udev to use to > address a given v4l device. > > > Case 3 is the only one to cause device node naming issues. I'm not sure > if the > > driver does the right thing when it creates several device nodes. Should > the > > peripheral be seen as a single device that allows access by two users > > simultaneously, or should it be seen as two fixed-format devices ? Each > > solution will probably come with its own set of issues. > > Whatever the situation, I doubt it will change soon for ivtv (or the > others), so I'd like to see the basic functionality of the patch adopted. > If there are things about it that aren't good, or could be improved > about it, can you provide an updated patch to address any concerns? I > think taking the patch through some iterations could help focus the > discussion about it. > > Thanks! > > -Kees > > -- > Kees Cook @outflux.net > > > > > ---------- Message transféré ---------- > From: Brandon Philips <brandon@ifup.org> > To: Gregor Jasny <jasny@vidsoft.de> > Date: Mon, 21 Apr 2008 15:37:51 -0700 > Subject: Re: 2.6.25 regression: vivi - scheduling while atomic > On 10:16 Mon 21 Apr 2008, Gregor Jasny wrote: > > Call Trace: > > [<ffffffff803efc9b>] schedule+0xe5/0x5c7 > > [<ffffffff80251c90>] __rmqueue_smallest+0x88/0x107 > > [<ffffffff8023e84b>] getnstimeofday+0x2f/0x83 > > [<ffffffff8023cf8a>] ktime_get_ts+0x17/0x48 > > [<ffffffff803f0424>] schedule_timeout+0x1e/0xad > > [<ffffffff80220498>] enqueue_task+0x13/0x1e > > [<ffffffff803efab8>] wait_for_common+0xf6/0x16b > > [<ffffffff802230a0>] default_wake_function+0x0/0xe > > [<ffffffff8023a270>] kthread_create+0xa3/0x108 > > [<ffffffff880d2471>] :vivi:vivi_thread+0x0/0x779 > > [<ffffffff802634cb>] remap_vmalloc_range+0xa1/0xe6 > > [<ffffffff80231242>] lock_timer_base+0x26/0x4c > > [<ffffffff8023138e>] __mod_timer+0xb6/0xc5 > > [<ffffffff880d23fc>] :vivi:vivi_start_thread+0x54/0xc9 > > [<ffffffff88053603>] :videobuf_core:videobuf_streamon+0x6c/0xaa > > [<ffffffff8809dba3>] :videodev:__video_do_ioctl+0x1327/0x2ad9 > > [<ffffffff80222d76>] __wake_up+0x38/0x4f > > [<ffffffff80242f1f>] futex_wake+0xdb/0xfa > > [<ffffffff8809f6ab>] :videodev:video_ioctl2+0x17c/0x210 > > [<ffffffff8025bb36>] handle_mm_fault+0x6b1/0x6cb > > [<ffffffff8027b47d>] vfs_ioctl+0x55/0x6b > > [<ffffffff8027b6e6>] do_vfs_ioctl+0x253/0x264 > > [<ffffffff8027b733>] sys_ioctl+0x3c/0x5d > > [<ffffffff8020afcb>] system_call_after_swapgs+0x7b/0x80 > > > > This happenes on a vanilla 2.6.25 with loaded nvidia graphics module. > > System architecture is x86_64. If it matters I'll try to reproduce this > > error on a non tainted kernel. > > No need to reproduce on a non-tainted Kernel. This is a known issue > with patches merged into the v4l-dvb tree several weeks ago but it seems > to not have made it into 2.6.25 :( > > http://linuxtv.org/hg/v4l-dvb/rev/06eb92ed0b18 > http://linuxtv.org/hg/v4l-dvb/rev/c50180f4ddfc > > I can rebase the patches for 2.6.25 but they are too big to go into the > stable 2.6.25 tree... > > Thanks for the report, > > Brandon > > > > > ---------- Message transféré ---------- > From: "'Brandon Philips'" <brandon@ifup.org> > To: mschimek@gmx.at > Date: Mon, 21 Apr 2008 16:15:04 -0700 > Subject: [PATCH] v4l2-spec: write-only controls > Hello Michael- > > Please fold this new control flag into the v4l2spec. > > Thanks, > > Brandon > > diff -Naur v4l2spec-0.24/vidioc-queryctrl.sgml > v4l2spec-0.24a/vidioc-queryctrl.sgml > --- v4l2spec-0.24/vidioc-queryctrl.sgml 2008-03-06 23:42:13.000000000 +0800 > +++ v4l2spec-0.24a/vidioc-queryctrl.sgml 2008-04-16 > 17:27:36.000000000 +0800 > @@ -361,6 +361,15 @@ > <entry>A hint that this control is best represented as a > slider-like element in a user interface.</entry> > </row> > + <row> > + <entry><constant>V4L2_CTRL_FLAG_WRITE_ONLY</constant></entry> > + <entry>0x0040</entry> > + <entry>This control is permanently writable only. Any > +attempt to read the control will result in an EACCES error code. This > +flag is typically present for relative controls or action controls where > +writing a value will cause the device to carry out a given action > +(e. g. motor control) but no meaningful value can be returned.</entry> > + </row> > </tbody> > </tgroup> > </table> > > > > > ---------- Message transféré ---------- > From: Brandon Philips <brandon@ifup.org> > To: Frej Drejhammar <frej.drejhammar@gmail.com> > Date: Mon, 21 Apr 2008 16:30:45 -0700 > Subject: Re: [PATCH 4 of 6] v4l2-api: Define a standard control for color > killer functionality > On 23:43 Sun 23 Mar 2008, Frej Drejhammar wrote: > > Define a pre-defined control ID for color killer functionality. > > Where is the patch to the V4L spec for this? What is a "color killer" > > Thanks, > > Brandon > > > > > ---------- Message transféré ---------- > From: Brandon Philips <brandon@ifup.org> > To: Frej Drejhammar <frej.drejhammar@gmail.com> > Date: Mon, 21 Apr 2008 16:34:41 -0700 > Subject: Re: [PATCH 0 of 6] cx88: Enable additional cx2388x features. > Version 3 > On 23:43 Sun 23 Mar 2008, Frej Drejhammar wrote: > > + <row> > > + <entry><constant>V4L2_CID_COLOR_KILLER</constant></entry> > > + <entry>boolean</entry> > > + <entry>Enables color killer functionality.</entry> > > + </row> > > Ok, so I found the doc patch but it isn't very helpful... > > Could we please get an explanation of what a color killer is for other > driver writers? > > Thanks, > > Brandon > > > > > ---------- Message transféré ---------- > From: hermann pitton <hermann-pitton@arcor.de> > To: Brandon Philips <brandon@ifup.org> > Date: Tue, 22 Apr 2008 02:08:32 +0200 > Subject: Re: 2.6.25 regression: vivi - scheduling while atomic > Hi, > > Am Montag, den 21.04.2008, 15:37 -0700 schrieb Brandon Philips: > > On 10:16 Mon 21 Apr 2008, Gregor Jasny wrote: > > > Call Trace: > > > [<ffffffff803efc9b>] schedule+0xe5/0x5c7 > > > [<ffffffff80251c90>] __rmqueue_smallest+0x88/0x107 > > > [<ffffffff8023e84b>] getnstimeofday+0x2f/0x83 > > > [<ffffffff8023cf8a>] ktime_get_ts+0x17/0x48 > > > [<ffffffff803f0424>] schedule_timeout+0x1e/0xad > > > [<ffffffff80220498>] enqueue_task+0x13/0x1e > > > [<ffffffff803efab8>] wait_for_common+0xf6/0x16b > > > [<ffffffff802230a0>] default_wake_function+0x0/0xe > > > [<ffffffff8023a270>] kthread_create+0xa3/0x108 > > > [<ffffffff880d2471>] :vivi:vivi_thread+0x0/0x779 > > > [<ffffffff802634cb>] remap_vmalloc_range+0xa1/0xe6 > > > [<ffffffff80231242>] lock_timer_base+0x26/0x4c > > > [<ffffffff8023138e>] __mod_timer+0xb6/0xc5 > > > [<ffffffff880d23fc>] :vivi:vivi_start_thread+0x54/0xc9 > > > [<ffffffff88053603>] :videobuf_core:videobuf_streamon+0x6c/0xaa > > > [<ffffffff8809dba3>] :videodev:__video_do_ioctl+0x1327/0x2ad9 > > > [<ffffffff80222d76>] __wake_up+0x38/0x4f > > > [<ffffffff80242f1f>] futex_wake+0xdb/0xfa > > > [<ffffffff8809f6ab>] :videodev:video_ioctl2+0x17c/0x210 > > > [<ffffffff8025bb36>] handle_mm_fault+0x6b1/0x6cb > > > [<ffffffff8027b47d>] vfs_ioctl+0x55/0x6b > > > [<ffffffff8027b6e6>] do_vfs_ioctl+0x253/0x264 > > > [<ffffffff8027b733>] sys_ioctl+0x3c/0x5d > > > [<ffffffff8020afcb>] system_call_after_swapgs+0x7b/0x80 > > > > > > This happenes on a vanilla 2.6.25 with loaded nvidia graphics module. > > > System architecture is x86_64. If it matters I'll try to reproduce this > > > error on a non tainted kernel. > > > > No need to reproduce on a non-tainted Kernel. This is a known issue > > with patches merged into the v4l-dvb tree several weeks ago but it seems > > to not have made it into 2.6.25 :( > > > > http://linuxtv.org/hg/v4l-dvb/rev/06eb92ed0b18 > > http://linuxtv.org/hg/v4l-dvb/rev/c50180f4ddfc > > > > I can rebase the patches for 2.6.25 but they are too big to go into the > > stable 2.6.25 tree... > > > > Thanks for the report, > > > > Brandon > > > > hmm, because of that 100 lines only rule including offsets? > > The current v4l-dvb on 2.6.24 has 233 modules. > > It is usual that changes, if needed, are going over lots of them. > > How far one can come with _such_ rules, given that one single line > changed counts up to seven with the offsets? > > How can one even comment on that brain damage? > > Cheers, > Hermann > > > > > > > > > > > > ---------- Message transféré ---------- > From: Brandon Philips <brandon@ifup.org> > To: Mauro Carvalho Chehab <mchehab@infradead.org> > Date: Mon, 21 Apr 2008 19:22:21 -0700 > Subject: Re: [PATCH] Support for write-only controls > On 00:19 Tue 15 Apr 2008, Mauro Carvalho Chehab wrote: > > Brandon, Could you please add this on one of your trees, together with > those > > pending V4L2 API patches for UVC? I want to merge those changes together > with the > > in-kernel driver that firstly requires such changes. > > I have a tree with the change sets. Please don't pull from the tip > though: hg pull -r 4ca1ed646f89 http://ifup.org/hg/v4l-uvc > > The tip of that tree has UVC and all of the Kconfig/Makefile bits too. > > The patch set for the tree: http://ifup.org/hg/uvc-v4l-patches > > If Laurent wants to add his sign off to that last patch (based on r204) > we can commit that too :D > > Cheers, > > Brandon > > > > > ---------- Message transféré ---------- > From: Steven Toth <stoth@linuxtv.org> > To: linux-dvb <linux-dvb@linuxtv.org>, Linux and Kernel Video < > video4linux-list@redhat.com> > Date: Mon, 21 Apr 2008 23:26:49 -0400 > Subject: Hauppauge HVR1400 DVB-T support / XC3028L > Hi, > > I've passed some patches to Mauro that add support for the Hauppauge > HVR1400 Expresscard in DVB-T mode. (cx23885 bridge, dib7000p demodulator and > the xceive xc3028L silicon tuner) > > If you're interested in testing then wait for the patches to appear in the > http://linuxtv.org/hg/v4l-dvb tree. > > You'll need to download firmware from http://steventoth.net/linux/hvr1400 > > Post any questions or issues here. > > Thanks, > > Steve > > > > > ---------- Message transféré ---------- > From: Brandon Philips <brandon@ifup.org> > To: Steven Toth <stoth@linuxtv.org> > Date: Mon, 21 Apr 2008 20:44:49 -0700 > Subject: Re: Hauppauge HVR1400 DVB-T support / XC3028L > On 23:26 Mon 21 Apr 2008, Steven Toth wrote: > > I've passed some patches to Mauro that add support for the Hauppauge > > HVR1400 Expresscard in DVB-T mode. (cx23885 bridge, dib7000p > > demodulator and the xceive xc3028L silicon tuner) > > > > If you're interested in testing then wait for the patches to appear > > in the http://linuxtv.org/hg/v4l-dvb tree. > > > > You'll need to download firmware from > > http://steventoth.net/linux/hvr1400 > > > > Post any questions or issues here. > > Could you post the patches to the lists for review? CC'ing both > linux-dvb@linuxtv.org and video4linux-list@redhat.com is appropriate. > > It is really difficult staying on top of V4L with private trees and > private mails going around :( > > Thanks, > > Brandon > > > > > ---------- Message transféré ---------- > From: Brandon Philips <brandon@ifup.org> > To: Jon Lowe <jonlowe@aol.com> > Date: Mon, 21 Apr 2008 21:07:28 -0700 > Subject: Re: [BUG] HVR-1500 Hot swap causes lockup > On 09:59 Sat 19 Apr 2008, Jon Lowe wrote: > > Hope this is the right place to do this. > > > > Hauppauge HVR-1500 Expresscard, Ubuntu 8.04, latest V4L drivers. > > > > Removing (hotswap) this card from a ASUS F3SV laptop running Ubuntu > > 8.04 causes a hard lock up of the computer.? Unresponsive to any > > input. Requires complete shutdown of the computer and restart.? Easily > > repeatable.? Same card is hot swappable under Windows Vista.? > > > > This is critical because Expresscards are notoriously easy to dislodge > > in notebooks.? > > Could you please setup a netconsole and try and get some debugging > output? > > For details on setting up a netconsole see the documentation: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/networking/netconsole.txt;hb=HEAD > > Thanks, > > Brandon > > > > > ---------- Message transféré ---------- > From: Laurent Pinchart <laurent.pinchart@skynet.be> > To: Brandon Philips <brandon@ifup.org> > Date: Tue, 22 Apr 2008 10:40:29 +0200 > Subject: Re: [PATCH] Support for write-only controls > On Tuesday 22 April 2008 04:22, Brandon Philips wrote: > > On 00:19 Tue 15 Apr 2008, Mauro Carvalho Chehab wrote: > > > Brandon, Could you please add this on one of your trees, together with > > > those pending V4L2 API patches for UVC? I want to merge those changes > > > together with the in-kernel driver that firstly requires such changes. > > > > I have a tree with the change sets. Please don't pull from the tip > > though: hg pull -r 4ca1ed646f89 http://ifup.org/hg/v4l-uvc > > > > The tip of that tree has UVC and all of the Kconfig/Makefile bits too. > > > > The patch set for the tree: http://ifup.org/hg/uvc-v4l-patches > > > > If Laurent wants to add his sign off to that last patch (based on r204) > > we can commit that too :D > > I want the driver to be properly reviewed on both video4linux-list and > linux-usb. I will post a patch on both mailing lists today. > > Thanks for taking care of the Kconfig/Makefile bits. Could you send them to > me > so that I can include them in the patch to be reviewed ? > > Cheers, > > Laurent Pinchart > > > > > ---------- Message transféré ---------- > From: Mat <heavensdoor78@gmail.com> > To: Linux and Kernel Video <video4linux-list@redhat.com> > Date: Tue, 22 Apr 2008 12:24:13 +0200 > Subject: Empia em28xx based USB video device... (2) > > Hi all. > How do I test if the current driver support a specific kind of field type? > > The device I'm working with seems to work only in interlaced mode. > V4L2_FIELD_NONE is ignored. > > From v4l-info: > > video capture > VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE) > index : 0 > type : VIDEO_CAPTURE > flags : 0 > description : "Packed YUY2" > pixelformat : 0x56595559 [YUYV] > VIDIOC_G_FMT(VIDEO_CAPTURE) > type : VIDEO_CAPTURE > fmt.pix.width : 720 > fmt.pix.height : 576 > fmt.pix.pixelformat : 0x56595559 [YUYV] > fmt.pix.field : INTERLACED > fmt.pix.bytesperline : 1440 > fmt.pix.sizeimage : 829440 > fmt.pix.colorspace : SMPTE170M > fmt.pix.priv : 0 > > Is it a module driver limit or an hardware limit? > In Windows it seems ok... I don't think VLC ( I use it for testing on Win ) > de-interlace automatically. > > Ideas? > I have to de-interlace myself the frames I suppose... > > Thanks in advance. > -Mat- > > > > > ---------- Message transféré ---------- > From: "Markus Rechberger" <mrechberger@gmail.com> > To: Mat <heavensdoor78@gmail.com> > Date: Tue, 22 Apr 2008 13:22:37 +0200 > Subject: Re: Empia em28xx based USB video device... (2) > On 4/22/08, Mat <heavensdoor78@gmail.com> wrote: > > > > Hi all. > > How do I test if the current driver support a specific kind of field > type? > > > > The device I'm working with seems to work only in interlaced mode. > > V4L2_FIELD_NONE is ignored. > > > > From v4l-info: > > > > video capture > > VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE) > > index : 0 > > type : VIDEO_CAPTURE > > flags : 0 > > description : "Packed YUY2" > > pixelformat : 0x56595559 [YUYV] > > VIDIOC_G_FMT(VIDEO_CAPTURE) > > type : VIDEO_CAPTURE > > fmt.pix.width : 720 > > fmt.pix.height : 576 > > fmt.pix.pixelformat : 0x56595559 [YUYV] > > fmt.pix.field : INTERLACED > > fmt.pix.bytesperline : 1440 > > fmt.pix.sizeimage : 829440 > > fmt.pix.colorspace : SMPTE170M > > fmt.pix.priv : 0 > > > > Is it a module driver limit or an hardware limit? > > In Windows it seems ok... I don't think VLC ( I use it for testing on > > Win ) de-interlace automatically. > > > > Ideas? > > I have to de-interlace myself the frames I suppose... > > > > The driver delivers full frames already since many TV applications > don't support deinterlacing of halfframes at all. That way is > hardcoded at the moment. > > Markus > > > > > ---------- Message transféré ---------- > From: Steven Toth <stoth@linuxtv.org> > To: Brandon Philips <brandon@ifup.org> > Date: Tue, 22 Apr 2008 09:03:43 -0400 > Subject: Re: Hauppauge HVR1400 DVB-T support / XC3028L > > Hi Brandon, > > On 23:26 Mon 21 Apr 2008, Steven Toth wrote: >> >>> I've passed some patches to Mauro that add support for the Hauppauge >>> HVR1400 Expresscard in DVB-T mode. (cx23885 bridge, dib7000p >>> demodulator and the xceive xc3028L silicon tuner) >>> >>> If you're interested in testing then wait for the patches to appear >>> in the http://linuxtv.org/hg/v4l-dvb tree. >>> >>> You'll need to download firmware from >>> http://steventoth.net/linux/hvr1400 >>> >>> Post any questions or issues here. >>> >> >> Could you post the patches to the lists for review? CC'ing both >> linux-dvb@linuxtv.org and video4linux-list@redhat.com is appropriate. >> > > The last time I mailed personal tree info to the lists I had people > referencing my local trees for way too long, posting support messages for > code that was getting older and more and more out of date. > > It created more of a problem than it solved so I rarely do that any more. > > I like to engage the non-developers on this list only when it makes sense. > > > >> It is really difficult staying on top of V4L with private trees and >> private mails going around :( >> >> > Agreed, I guess. > > I posted the patches to the appropriate maintainers for review, along with > all of the dvb/v4l maintainers and Mauro. Nothing nefarious here, I've > always done this. > > The only difference is that I'm informing a number of people who've > contacted me personally to ask for support - that support is about to > arrive. (I did that over the weekend also with the HVR1200/HVR1700/TDA10048 > email, and it kick-started a rather nice thread for people trying to bring > up the TDA10048 on another product). > > In summary, I have sign-off from the only other maintainer effected by the > patches so I'd expect them to get merged very quickly into hg/v4l-dvb. > > Comments / feedback welcome. > > Regards, > > - Steve > > > > > ---------- Message transféré ---------- > From: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > To: 冯鑫 <fengxin215@gmail.com> > Date: Tue, 22 Apr 2008 16:25:29 +0200 (CEST) > Subject: Re: question for soc-camera driver > On Sat, 19 Apr 2008, ·ëöÎ wrote: > > > Thanks I will try according to what you said. Mybe I can find why I > > have this problem.But a driver come from MontaVista can also work > > well.No frame is dropped. > > > > Now I find MontaVista driver have a problem.I execute VIDIOC_REQBUFS > > failed After I execute VIDIOC_STREAMOFF and munmap() .This time > > soc-camera driver can work well.You can give me some advice. > > I looked at the Montavista driver you provided. It does indeed initialize > some registers slightly differently, but all those values are either > default, i.e., would be implicitly the same in the pxa-camera driver, or > are explicitly overwritten in the driver. So, I cannot see how first using > the Montavista driver and then switching to the pxa-camera driver can > change performance of the latter. > > One thing you might find interesting - they seem to be configuring the > capture interface to run at 13MHz, which is close enough to my 10MHz > guess. So, make sure you're not configuring anything higher in your > platform code. But, again, it does get reconfigured when pxa-camera is > loaded, so, it wouldn't produce the improvement you describe. > > Thanks > Guennadi > --- > Guennadi Liakhovetski > > > > > ---------- Message transféré ---------- > From: Brandon Philips <brandon@ifup.org> > To: Laurent Pinchart <laurent.pinchart@skynet.be> > Date: Tue, 22 Apr 2008 07:25:33 -0700 > Subject: Re: [PATCH] Support for write-only controls > On 10:40 Tue 22 Apr 2008, Laurent Pinchart wrote: > > On Tuesday 22 April 2008 04:22, Brandon Philips wrote: > > > On 00:19 Tue 15 Apr 2008, Mauro Carvalho Chehab wrote: > > > > Brandon, Could you please add this on one of your trees, together > with > > > > those pending V4L2 API patches for UVC? I want to merge those changes > > > > together with the in-kernel driver that firstly requires such > changes. > > > > > > I have a tree with the change sets. Please don't pull from the tip > > > though: hg pull -r 4ca1ed646f89 http://ifup.org/hg/v4l-uvc > > > > > > The tip of that tree has UVC and all of the Kconfig/Makefile bits too. > > > > > > The patch set for the tree: http://ifup.org/hg/uvc-v4l-patches > > > > > > If Laurent wants to add his sign off to that last patch (based on r204) > > > we can commit that too :D > > > > I want the driver to be properly reviewed on both video4linux-list and > > linux-usb. I will post a patch on both mailing lists today. > > Certainly :D > > I put the UVC patch on my tree just to ensure I got all the right bits > together ;) > > > Thanks for taking care of the Kconfig/Makefile bits. Could you send > > them to me so that I can include them in the patch to be reviewed ? > > Signed-off-by: Brandon Philips <bphilips@suse.de> > > --- a/linux/drivers/media/video/Kconfig > +++ b/linux/drivers/media/video/Kconfig > @@ -741,6 +741,14 @@ menuconfig V4L_USB_DRIVERS > > if V4L_USB_DRIVERS && USB > > +config USB_UVC > + tristate "USB Video Class (UVC)" > + ---help--- > + Support for the USB Video Class (UVC). Currently only video > + input devices, such as webcams, are supported. > + > + For more information see: <http://linux-uvc.berlios.de/> > + > source "drivers/media/video/pvrusb2/Kconfig" > > source "drivers/media/video/em28xx/Kconfig" > --- a/linux/drivers/media/video/Makefile > +++ b/linux/drivers/media/video/Makefile > @@ -144,6 +144,8 @@ obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m > obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o > obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o > > +obj-$(CONFIG_USB_UVC) += uvc/ > + > obj-$(CONFIG_VIDEO_AU0828) += au0828/ > > EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core > --- /dev/null > +++ b/linux/drivers/media/video/uvc/Makefile > @@ -0,0 +1,3 @@ > +uvcvideo-objs := uvc_driver.o uvc_queue.o uvc_v4l2.o uvc_video.o > uvc_ctrl.o\ > + uvc_status.o uvc_isight.o > +obj-$(CONFIG_USB_UVC) := uvcvideo.o > > > > > ---------- Message transféré ---------- > From: Mauro Carvalho Chehab <mchehab@infradead.org> > To: Andrew Morton <akpm@linux-foundation.org> > Date: Tue, 22 Apr 2008 11:35:39 -0300 > Subject: Re: 2.6.25 regression: vivi - scheduling while atomic > > > > > This happenes on a vanilla 2.6.25 with loaded nvidia graphics > module. > > > > > System architecture is x86_64. If it matters I'll try to reproduce > this > > > > > error on a non tainted kernel. > > > > > > > > No need to reproduce on a non-tainted Kernel. This is a known issue > > > > with patches merged into the v4l-dvb tree several weeks ago but it > seems > > > > to not have made it into 2.6.25 :( > > > > > > > > http://linuxtv.org/hg/v4l-dvb/rev/06eb92ed0b18 > > > > http://linuxtv.org/hg/v4l-dvb/rev/c50180f4ddfc > > > > > > > > I can rebase the patches for 2.6.25 but they are too big to go into > the > > > > stable 2.6.25 tree... > > Unfortunately, the tests for the patches fixing several videobuf issues > finished later on -rc9, when Linus were releasing 2.6.25. > > I should send the videobuf patches to Linus tree, together with other > patches, > probably today. After that, I think we should backport the fixes for > 2.6.25, > and test it again, with vanilla 2.6.25. > > The issue here is that videobuf suffered several changes on this > development > cycle. Probably, only a few of those patches are needed to fix the issue. > So, > we need to handle this with care, to avoid the risk of damaging other > drivers that > relies on videobuf. > > Cheers, > Mauro > > > > > ---------- Message transféré ---------- > From: Mauro Carvalho Chehab <mchehab@infradead.org> > To: Brandon Philips <brandon@ifup.org> > Date: Tue, 22 Apr 2008 12:22:01 -0300 > Subject: Re: Hauppauge HVR1400 DVB-T support / XC3028L > On Mon, 21 Apr 2008 20:44:49 -0700 > Brandon Philips <brandon@ifup.org> wrote: > > > On 23:26 Mon 21 Apr 2008, Steven Toth wrote: > > > I've passed some patches to Mauro that add support for the Hauppauge > > > HVR1400 Expresscard in DVB-T mode. (cx23885 bridge, dib7000p > > > demodulator and the xceive xc3028L silicon tuner) > > > > > > If you're interested in testing then wait for the patches to appear > > > in the http://linuxtv.org/hg/v4l-dvb tree. > > > > > > You'll need to download firmware from > > > http://steventoth.net/linux/hvr1400 > > > > > > Post any questions or issues here. > > > > Could you post the patches to the lists for review? CC'ing both > > linux-dvb@linuxtv.org and video4linux-list@redhat.com is appropriate. > > > > It is really difficult staying on top of V4L with private trees and > > private mails going around :( > > The better way for you to track about committed patches is what's described > on > item 5: "Knowing about newer patches committed at master hg repository", of > http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches. > > Basically, if you subscribe to linuxtv-commits ML[1], you'll receive an > email for > every newly committed changeset. > > This tracks all patches added to the staging tree. If you want to review a > changeset, you may just reply to the mailbomb email. > > I think it is better to have a separate list for this, to avoid increasing > the > traffic at the main lists, since we have a large number of commits, > especially > during the merge window. For example, it is expected a 50 patch series with > improvements to pvrusb2. Just flooding those emails to the main lists seems > overkill to most users. Better to keep this in track on a separate ML. > > This is just my 2 cents. I'm open to discuss improvements on this process. > > [1] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits > > Cheers, > Mauro > > > > > ---------- Message transféré ---------- > From: "Edward J. Sheldrake" <ejs1920@yahoo.co.uk> > To: video4linux-list@redhat.com > Date: Tue, 22 Apr 2008 16:38:32 +0100 (BST) > Subject: em28xx/xc3028: changeset 7651 breaks analog audio? > Hello > > I have a Hauppauge HVR-900 rev B3C0, and until very recently it was > working fine with the em28xx driver in the main v4l-dvb repository. I > live in England, so have set the option pal=i for the tuner module. It > was working fine with with the repository from 20080420. I'm watching > analog TV. > > However, with the repository from 20080422, I just get static from the > audio output. None of the audio_std options for the tuner_xc2028 module > made any difference. The only changeset I could see for the modules I > use is 7651, about the firmware for the xc3028 tuner. > > Here's relevant dmesg output for the older working driver: > http://pastebin.com/f399535d5 > > And here's the same with the non-working driver: > http://pastebin.com/fdd8e82e > > I extracted the firmware again with the 20080422 repo, but the new > firmware file worked fine with the older driver. > > Let me know how I can help fix this, or is there some module option > that I've missed? > > -- > > Edward Sheldrake > > > ___________________________________________________________ > Yahoo! For Good. Give and get cool things for free, reduce waste and help > our planet. Plus find hidden Yahoo! treasure > > http://green.yahoo.com/uk/earth-day/ > > > > -- > video4linux-list mailing list > Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/video4linux-list > [-- Attachment #2: Type: text/plain, Size: 164 bytes --] -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: video4linux-list Digest, Vol 50, Issue 22 2008-04-22 16:19 ` video4linux-list Digest, Vol 50, Issue 22 zied frikha @ 2008-04-22 16:20 ` zied frikha 2008-04-22 16:36 ` Daniel Glöckner 1 sibling, 0 replies; 3+ messages in thread From: zied frikha @ 2008-04-22 16:20 UTC (permalink / raw) To: video4linux-list [-- Attachment #1: Type: text/plain, Size: 38947 bytes --] HERE IS A PERSON THAT HE/SHE COULD HELP ME IT IS URGENTLY 2008/4/22, zied frikha <frikha.zied@gmail.com>: > > I NEED A GUI FOR THE SI470X RADIO THAT RUN UNDER LINUX (MANDRIVA 2008) > :( > PLEEEEEEEEEEEEEEEEEEEASE > > 2008/4/22, video4linux-list-request@redhat.com < > video4linuxHERE-list-request@redhat.com<video4linux-list-request@redhat.com> > >: >> >> Send video4linux-list mailing list submissions to >> video4linux-list@redhat.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.redhat.com/mailman/listinfo/video4linux-list >> or, via email, send a message with subject or body 'help' to >> video4linux-list-request@redhat.com >> >> You can reach the person managing the list at >> video4linux-list-owner@redhat.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of video4linux-list digest..." >> >> Today's Topics: >> >> 1. Re: [PATCH 1/2] V4L: add "function" sysfs attribute to v4l >> devices (Laurent Pinchart) >> 2. Re: [PATCH 1/2] V4L: add "function" sysfs attribute to v4l >> devices (Kees Cook) >> 3. Re: 2.6.25 regression: vivi - scheduling while atomic >> (Brandon Philips) >> 4. [PATCH] v4l2-spec: write-only controls ('Brandon Philips') >> 5. Re: [PATCH 4 of 6] v4l2-api: Define a standard control for >> color killer functionality (Brandon Philips) >> 6. Re: [PATCH 0 of 6] cx88: Enable additional cx2388x features. >> Version 3 (Brandon Philips) >> 7. Re: 2.6.25 regression: vivi - scheduling while atomic >> (hermann pitton) >> 8. Re: [PATCH] Support for write-only controls (Brandon Philips) >> 9. Hauppauge HVR1400 DVB-T support / XC3028L (Steven Toth) >> 10. Re: Hauppauge HVR1400 DVB-T support / XC3028L (Brandon Philips) >> 11. Re: [BUG] HVR-1500 Hot swap causes lockup (Brandon Philips) >> 12. Re: [PATCH] Support for write-only controls (Laurent Pinchart) >> 13. Empia em28xx based USB video device... (2) (Mat) >> 14. Re: Empia em28xx based USB video device... (2) (Markus Rechberger) >> 15. Re: Hauppauge HVR1400 DVB-T support / XC3028L (Steven Toth) >> 16. Re: question for soc-camera driver (Guennadi Liakhovetski) >> 17. Re: [PATCH] Support for write-only controls (Brandon Philips) >> 18. Re: 2.6.25 regression: vivi - scheduling while atomic >> (Mauro Carvalho Chehab) >> 19. Re: Hauppauge HVR1400 DVB-T support / XC3028L >> (Mauro Carvalho Chehab) >> 20. em28xx/xc3028: changeset 7651 breaks analog audio? >> (Edward J. Sheldrake) >> >> >> ---------- Message transféré ---------- >> From: Laurent Pinchart <laurent.pinchart@skynet.be> >> To: Kees Cook <kees@outflux.net> >> Date: Mon, 21 Apr 2008 23:10:46 +0200 >> Subject: Re: [PATCH 1/2] V4L: add "function" sysfs attribute to v4l >> devices >> On Friday 18 April 2008, Kees Cook wrote: >> > Hi Laurent, >> > >> > On Fri, Apr 18, 2008 at 09:33:21PM +0200, Laurent Pinchart wrote: >> > > On Thursday 17 April 2008, Kees Cook wrote: >> > > > +static const char *v4l2_function_type_names[] = { >> > > > + [V4L2_FN_VIDEO_CAP] = "vid-cap", >> > > > + [V4L2_FN_VIDEO_OUT] = "vid-out", >> > > > + [V4L2_FN_MPEG_CAP] = "mpeg-cap", >> > > > + [V4L2_FN_MPEG_OUT] = "mpeg-out", >> > > > + [V4L2_FN_YUV_CAP] = "yuv-cap", >> > > > + [V4L2_FN_YUV_OUT] = "yuv-out", >> > > >> > > I don't like those. Video capture devices can encode pixels in a >> variety >> > > of formats. MPEG and YUV are only two special cases. You will find >> > > devices encoding in RGB, Bayer, MJPEG, ... as well as some proprietary >> > > formats. >> > >> > If these devices have a variable encoding method, perhaps just use >> > "vid-cap" as the general rule. (In the case that the output formats are >> > selectable from a given device node at runtime.) >> >> That would indeed be better. The function name should be derived from the >> v4l >> type if possible. >> >> > > If I understand your problem correctly, you want to differentiate >> between >> > > multiple v4l devices created by a single driver for a single hardware >> > > device. Using the above functions might work for ivtv but rules out >> > > devices that output multiple streams in the same format. >> > > >> > > Wouldn't it be better to fix the ivtv driver to use a single device >> node >> > > for both compressed and uncompressed streams ? >> > >> > I'm not very familiar with the v4l code base, so I don't have a good >> > answer about if it's right or not. The core problem does tend to boil >> > down to dealing with drivers that create multiple device nodes for the >> > same physical hardware (ivtv is not alone in this regard). >> > >> > I don't know what the semantics are for device mode vs device node in >> > v4l, but it seems that since there are multiple nodes being created for >> > a given piece of hardware, something needs to be exported to sysfs to >> > distinguish them. >> >> Good point. >> >> v4l drivers create several device nodes for good or not-so-good reasons. I >> think we can classify the hardware/drivers in several categories: >> >> 1. The device supports multiple concurrent data streams for different kind >> of >> data. The is most often found for audio/video or video/vbi. Audio is >> handled >> through alsa, and video and vbi are handled through v4l. The driver then >> creates a device node for each video/vbi data stream. The devices can >> easily >> be distinguished by their v4l type. >> >> 2. The device supports a single data stream with a selectable data format. >> The >> driver will create a single device node, format selection is handled >> through >> the v4l API. >> >> 3. The device supports multiple concurrent data streams for a single kind >> of >> data. ivtv falls under this case. The most common use case is a device >> with >> several video pipes (usually 2) that can be used simultaneously to stream >> the >> same data (in different or identical formats, either fixed or >> configurable). >> >> Case 3 is the only one to cause device node naming issues. I'm not sure if >> the >> driver does the right thing when it creates several device nodes. Should >> the >> peripheral be seen as a single device that allows access by two users >> simultaneously, or should it be seen as two fixed-format devices ? Each >> solution will probably come with its own set of issues. >> >> Laurent Pinchart >> >> >> >> >> ---------- Message transféré ---------- >> From: Kees Cook <kees@outflux.net> >> To: Laurent Pinchart <laurent.pinchart@skynet.be> >> Date: Mon, 21 Apr 2008 14:47:17 -0700 >> Subject: Re: [PATCH 1/2] V4L: add "function" sysfs attribute to v4l >> devices >> Hi Laurent, >> >> On Mon, Apr 21, 2008 at 11:10:46PM +0200, Laurent Pinchart wrote: >> > On Friday 18 April 2008, Kees Cook wrote: >> > > On Fri, Apr 18, 2008 at 09:33:21PM +0200, Laurent Pinchart wrote: >> > > > On Thursday 17 April 2008, Kees Cook wrote: >> > > > > +static const char *v4l2_function_type_names[] = { >> > > > > + [V4L2_FN_VIDEO_CAP] = "vid-cap", >> > > > > + [V4L2_FN_VIDEO_OUT] = "vid-out", >> > > > > + [V4L2_FN_MPEG_CAP] = "mpeg-cap", >> > > > > + [V4L2_FN_MPEG_OUT] = "mpeg-out", >> > > > > + [V4L2_FN_YUV_CAP] = "yuv-cap", >> > > > > + [V4L2_FN_YUV_OUT] = "yuv-out", >> > > > >> > > > I don't like those. Video capture devices can encode pixels in a >> variety >> > > > of formats. MPEG and YUV are only two special cases. You will find >> > > > devices encoding in RGB, Bayer, MJPEG, ... as well as some >> proprietary >> > > > formats. >> > > >> > > If these devices have a variable encoding method, perhaps just use >> > > "vid-cap" as the general rule. (In the case that the output formats >> are >> > > selectable from a given device node at runtime.) >> > >> > That would indeed be better. The function name should be derived from >> the v4l >> > type if possible. >> >> Sure, but I think Kay's point was this it needs to be relatively >> "static" so that userspace (and udev) can depend on it not changing very >> much. I am not attached to any of the names in the proposed patch -- >> they work for me, but I'd be happy to see a different list if it were >> more sensible. >> >> > > I don't know what the semantics are for device mode vs device node in >> > > v4l, but it seems that since there are multiple nodes being created >> for >> > > a given piece of hardware, something needs to be exported to sysfs to >> > > distinguish them. >> > >> > Good point. >> > >> > v4l drivers create several device nodes for good or not-so-good reasons. >> I >> > think we can classify the hardware/drivers in several categories: >> > >> > 1. The device supports multiple concurrent data streams for different >> kind of >> > data. The is most often found for audio/video or video/vbi. Audio is >> handled >> > through alsa, and video and vbi are handled through v4l. The driver then >> > creates a device node for each video/vbi data stream. The devices can >> easily >> > be distinguished by their v4l type. >> > >> > 2. The device supports a single data stream with a selectable data >> format. The >> > driver will create a single device node, format selection is handled >> through >> > the v4l API. >> > >> > 3. The device supports multiple concurrent data streams for a single >> kind of >> > data. ivtv falls under this case. The most common use case is a device >> with >> > several video pipes (usually 2) that can be used simultaneously to >> stream the >> > same data (in different or identical formats, either fixed or >> configurable). >> >> Right -- case 3 is where the main problems and special-cases appeared >> when trying to work out a viable "static" path for udev to use to >> address a given v4l device. >> >> > Case 3 is the only one to cause device node naming issues. I'm not sure >> if the >> > driver does the right thing when it creates several device nodes. Should >> the >> > peripheral be seen as a single device that allows access by two users >> > simultaneously, or should it be seen as two fixed-format devices ? Each >> > solution will probably come with its own set of issues. >> >> Whatever the situation, I doubt it will change soon for ivtv (or the >> others), so I'd like to see the basic functionality of the patch adopted. >> If there are things about it that aren't good, or could be improved >> about it, can you provide an updated patch to address any concerns? I >> think taking the patch through some iterations could help focus the >> discussion about it. >> >> Thanks! >> >> -Kees >> >> -- >> Kees Cook @outflux.net >> >> >> >> >> ---------- Message transféré ---------- >> From: Brandon Philips <brandon@ifup.org> >> To: Gregor Jasny <jasny@vidsoft.de> >> Date: Mon, 21 Apr 2008 15:37:51 -0700 >> Subject: Re: 2.6.25 regression: vivi - scheduling while atomic >> On 10:16 Mon 21 Apr 2008, Gregor Jasny wrote: >> > Call Trace: >> > [<ffffffff803efc9b>] schedule+0xe5/0x5c7 >> > [<ffffffff80251c90>] __rmqueue_smallest+0x88/0x107 >> > [<ffffffff8023e84b>] getnstimeofday+0x2f/0x83 >> > [<ffffffff8023cf8a>] ktime_get_ts+0x17/0x48 >> > [<ffffffff803f0424>] schedule_timeout+0x1e/0xad >> > [<ffffffff80220498>] enqueue_task+0x13/0x1e >> > [<ffffffff803efab8>] wait_for_common+0xf6/0x16b >> > [<ffffffff802230a0>] default_wake_function+0x0/0xe >> > [<ffffffff8023a270>] kthread_create+0xa3/0x108 >> > [<ffffffff880d2471>] :vivi:vivi_thread+0x0/0x779 >> > [<ffffffff802634cb>] remap_vmalloc_range+0xa1/0xe6 >> > [<ffffffff80231242>] lock_timer_base+0x26/0x4c >> > [<ffffffff8023138e>] __mod_timer+0xb6/0xc5 >> > [<ffffffff880d23fc>] :vivi:vivi_start_thread+0x54/0xc9 >> > [<ffffffff88053603>] :videobuf_core:videobuf_streamon+0x6c/0xaa >> > [<ffffffff8809dba3>] :videodev:__video_do_ioctl+0x1327/0x2ad9 >> > [<ffffffff80222d76>] __wake_up+0x38/0x4f >> > [<ffffffff80242f1f>] futex_wake+0xdb/0xfa >> > [<ffffffff8809f6ab>] :videodev:video_ioctl2+0x17c/0x210 >> > [<ffffffff8025bb36>] handle_mm_fault+0x6b1/0x6cb >> > [<ffffffff8027b47d>] vfs_ioctl+0x55/0x6b >> > [<ffffffff8027b6e6>] do_vfs_ioctl+0x253/0x264 >> > [<ffffffff8027b733>] sys_ioctl+0x3c/0x5d >> > [<ffffffff8020afcb>] system_call_after_swapgs+0x7b/0x80 >> > >> > This happenes on a vanilla 2.6.25 with loaded nvidia graphics module. >> > System architecture is x86_64. If it matters I'll try to reproduce this >> > error on a non tainted kernel. >> >> No need to reproduce on a non-tainted Kernel. This is a known issue >> with patches merged into the v4l-dvb tree several weeks ago but it seems >> to not have made it into 2.6.25 :( >> >> http://linuxtv.org/hg/v4l-dvb/rev/06eb92ed0b18 >> http://linuxtv.org/hg/v4l-dvb/rev/c50180f4ddfc >> >> I can rebase the patches for 2.6.25 but they are too big to go into the >> stable 2.6.25 tree... >> >> Thanks for the report, >> >> Brandon >> >> >> >> >> ---------- Message transféré ---------- >> From: "'Brandon Philips'" <brandon@ifup.org> >> To: mschimek@gmx.at >> Date: Mon, 21 Apr 2008 16:15:04 -0700 >> Subject: [PATCH] v4l2-spec: write-only controls >> Hello Michael- >> >> Please fold this new control flag into the v4l2spec. >> >> Thanks, >> >> Brandon >> >> diff -Naur v4l2spec-0.24/vidioc-queryctrl.sgml >> v4l2spec-0.24a/vidioc-queryctrl.sgml >> --- v4l2spec-0.24/vidioc-queryctrl.sgml 2008-03-06 23:42:13.000000000 >> +0800 >> +++ v4l2spec-0.24a/vidioc-queryctrl.sgml 2008-04-16 >> 17:27:36.000000000 +0800 >> @@ -361,6 +361,15 @@ >> <entry>A hint that this control is best represented as a >> slider-like element in a user interface.</entry> >> </row> >> + <row> >> + <entry><constant>V4L2_CTRL_FLAG_WRITE_ONLY</constant></entry> >> + <entry>0x0040</entry> >> + <entry>This control is permanently writable only. Any >> +attempt to read the control will result in an EACCES error code. This >> +flag is typically present for relative controls or action controls where >> +writing a value will cause the device to carry out a given action >> +(e. g. motor control) but no meaningful value can be returned.</entry> >> + </row> >> </tbody> >> </tgroup> >> </table> >> >> >> >> >> ---------- Message transféré ---------- >> From: Brandon Philips <brandon@ifup.org> >> To: Frej Drejhammar <frej.drejhammar@gmail.com> >> Date: Mon, 21 Apr 2008 16:30:45 -0700 >> Subject: Re: [PATCH 4 of 6] v4l2-api: Define a standard control for color >> killer functionality >> On 23:43 Sun 23 Mar 2008, Frej Drejhammar wrote: >> > Define a pre-defined control ID for color killer functionality. >> >> Where is the patch to the V4L spec for this? What is a "color killer" >> >> Thanks, >> >> Brandon >> >> >> >> >> ---------- Message transféré ---------- >> From: Brandon Philips <brandon@ifup.org> >> To: Frej Drejhammar <frej.drejhammar@gmail.com> >> Date: Mon, 21 Apr 2008 16:34:41 -0700 >> Subject: Re: [PATCH 0 of 6] cx88: Enable additional cx2388x features. >> Version 3 >> On 23:43 Sun 23 Mar 2008, Frej Drejhammar wrote: >> > + <row> >> > + <entry><constant>V4L2_CID_COLOR_KILLER</constant></entry> >> > + <entry>boolean</entry> >> > + <entry>Enables color killer functionality.</entry> >> > + </row> >> >> Ok, so I found the doc patch but it isn't very helpful... >> >> Could we please get an explanation of what a color killer is for other >> driver writers? >> >> Thanks, >> >> Brandon >> >> >> >> >> ---------- Message transféré ---------- >> From: hermann pitton <hermann-pitton@arcor.de> >> To: Brandon Philips <brandon@ifup.org> >> Date: Tue, 22 Apr 2008 02:08:32 +0200 >> Subject: Re: 2.6.25 regression: vivi - scheduling while atomic >> Hi, >> >> Am Montag, den 21.04.2008, 15:37 -0700 schrieb Brandon Philips: >> > On 10:16 Mon 21 Apr 2008, Gregor Jasny wrote: >> > > Call Trace: >> > > [<ffffffff803efc9b>] schedule+0xe5/0x5c7 >> > > [<ffffffff80251c90>] __rmqueue_smallest+0x88/0x107 >> > > [<ffffffff8023e84b>] getnstimeofday+0x2f/0x83 >> > > [<ffffffff8023cf8a>] ktime_get_ts+0x17/0x48 >> > > [<ffffffff803f0424>] schedule_timeout+0x1e/0xad >> > > [<ffffffff80220498>] enqueue_task+0x13/0x1e >> > > [<ffffffff803efab8>] wait_for_common+0xf6/0x16b >> > > [<ffffffff802230a0>] default_wake_function+0x0/0xe >> > > [<ffffffff8023a270>] kthread_create+0xa3/0x108 >> > > [<ffffffff880d2471>] :vivi:vivi_thread+0x0/0x779 >> > > [<ffffffff802634cb>] remap_vmalloc_range+0xa1/0xe6 >> > > [<ffffffff80231242>] lock_timer_base+0x26/0x4c >> > > [<ffffffff8023138e>] __mod_timer+0xb6/0xc5 >> > > [<ffffffff880d23fc>] :vivi:vivi_start_thread+0x54/0xc9 >> > > [<ffffffff88053603>] :videobuf_core:videobuf_streamon+0x6c/0xaa >> > > [<ffffffff8809dba3>] :videodev:__video_do_ioctl+0x1327/0x2ad9 >> > > [<ffffffff80222d76>] __wake_up+0x38/0x4f >> > > [<ffffffff80242f1f>] futex_wake+0xdb/0xfa >> > > [<ffffffff8809f6ab>] :videodev:video_ioctl2+0x17c/0x210 >> > > [<ffffffff8025bb36>] handle_mm_fault+0x6b1/0x6cb >> > > [<ffffffff8027b47d>] vfs_ioctl+0x55/0x6b >> > > [<ffffffff8027b6e6>] do_vfs_ioctl+0x253/0x264 >> > > [<ffffffff8027b733>] sys_ioctl+0x3c/0x5d >> > > [<ffffffff8020afcb>] system_call_after_swapgs+0x7b/0x80 >> > > >> > > This happenes on a vanilla 2.6.25 with loaded nvidia graphics module. >> > > System architecture is x86_64. If it matters I'll try to reproduce >> this >> > > error on a non tainted kernel. >> > >> > No need to reproduce on a non-tainted Kernel. This is a known issue >> > with patches merged into the v4l-dvb tree several weeks ago but it seems >> > to not have made it into 2.6.25 :( >> > >> > http://linuxtv.org/hg/v4l-dvb/rev/06eb92ed0b18 >> > http://linuxtv.org/hg/v4l-dvb/rev/c50180f4ddfc >> > >> > I can rebase the patches for 2.6.25 but they are too big to go into the >> > stable 2.6.25 tree... >> > >> > Thanks for the report, >> > >> > Brandon >> > >> >> hmm, because of that 100 lines only rule including offsets? >> >> The current v4l-dvb on 2.6.24 has 233 modules. >> >> It is usual that changes, if needed, are going over lots of them. >> >> How far one can come with _such_ rules, given that one single line >> changed counts up to seven with the offsets? >> >> How can one even comment on that brain damage? >> >> Cheers, >> Hermann >> >> >> >> >> >> >> >> >> >> >> >> ---------- Message transféré ---------- >> From: Brandon Philips <brandon@ifup.org> >> To: Mauro Carvalho Chehab <mchehab@infradead.org> >> Date: Mon, 21 Apr 2008 19:22:21 -0700 >> Subject: Re: [PATCH] Support for write-only controls >> On 00:19 Tue 15 Apr 2008, Mauro Carvalho Chehab wrote: >> > Brandon, Could you please add this on one of your trees, together with >> those >> > pending V4L2 API patches for UVC? I want to merge those changes together >> with the >> > in-kernel driver that firstly requires such changes. >> >> I have a tree with the change sets. Please don't pull from the tip >> though: hg pull -r 4ca1ed646f89 http://ifup.org/hg/v4l-uvc >> >> The tip of that tree has UVC and all of the Kconfig/Makefile bits too. >> >> The patch set for the tree: http://ifup.org/hg/uvc-v4l-patches >> >> If Laurent wants to add his sign off to that last patch (based on r204) >> we can commit that too :D >> >> Cheers, >> >> Brandon >> >> >> >> >> ---------- Message transféré ---------- >> From: Steven Toth <stoth@linuxtv.org> >> To: linux-dvb <linux-dvb@linuxtv.org>, Linux and Kernel Video < >> video4linux-list@redhat.com> >> Date: Mon, 21 Apr 2008 23:26:49 -0400 >> Subject: Hauppauge HVR1400 DVB-T support / XC3028L >> Hi, >> >> I've passed some patches to Mauro that add support for the Hauppauge >> HVR1400 Expresscard in DVB-T mode. (cx23885 bridge, dib7000p demodulator and >> the xceive xc3028L silicon tuner) >> >> If you're interested in testing then wait for the patches to appear in the >> http://linuxtv.org/hg/v4l-dvb tree. >> >> You'll need to download firmware from http://steventoth.net/linux/hvr1400 >> >> Post any questions or issues here. >> >> Thanks, >> >> Steve >> >> >> >> >> ---------- Message transféré ---------- >> From: Brandon Philips <brandon@ifup.org> >> To: Steven Toth <stoth@linuxtv.org> >> Date: Mon, 21 Apr 2008 20:44:49 -0700 >> Subject: Re: Hauppauge HVR1400 DVB-T support / XC3028L >> On 23:26 Mon 21 Apr 2008, Steven Toth wrote: >> > I've passed some patches to Mauro that add support for the Hauppauge >> > HVR1400 Expresscard in DVB-T mode. (cx23885 bridge, dib7000p >> > demodulator and the xceive xc3028L silicon tuner) >> > >> > If you're interested in testing then wait for the patches to appear >> > in the http://linuxtv.org/hg/v4l-dvb tree. >> > >> > You'll need to download firmware from >> > http://steventoth.net/linux/hvr1400 >> > >> > Post any questions or issues here. >> >> Could you post the patches to the lists for review? CC'ing both >> linux-dvb@linuxtv.org and video4linux-list@redhat.com is appropriate. >> >> It is really difficult staying on top of V4L with private trees and >> private mails going around :( >> >> Thanks, >> >> Brandon >> >> >> >> >> ---------- Message transféré ---------- >> From: Brandon Philips <brandon@ifup.org> >> To: Jon Lowe <jonlowe@aol.com> >> Date: Mon, 21 Apr 2008 21:07:28 -0700 >> Subject: Re: [BUG] HVR-1500 Hot swap causes lockup >> On 09:59 Sat 19 Apr 2008, Jon Lowe wrote: >> > Hope this is the right place to do this. >> > >> > Hauppauge HVR-1500 Expresscard, Ubuntu 8.04, latest V4L drivers. >> > >> > Removing (hotswap) this card from a ASUS F3SV laptop running Ubuntu >> > 8.04 causes a hard lock up of the computer.? Unresponsive to any >> > input. Requires complete shutdown of the computer and restart.? Easily >> > repeatable.? Same card is hot swappable under Windows Vista.? >> > >> > This is critical because Expresscards are notoriously easy to dislodge >> > in notebooks.? >> >> Could you please setup a netconsole and try and get some debugging >> output? >> >> For details on setting up a netconsole see the documentation: >> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/networking/netconsole.txt;hb=HEAD >> >> Thanks, >> >> Brandon >> >> >> >> >> ---------- Message transféré ---------- >> From: Laurent Pinchart <laurent.pinchart@skynet.be> >> To: Brandon Philips <brandon@ifup.org> >> Date: Tue, 22 Apr 2008 10:40:29 +0200 >> Subject: Re: [PATCH] Support for write-only controls >> On Tuesday 22 April 2008 04:22, Brandon Philips wrote: >> > On 00:19 Tue 15 Apr 2008, Mauro Carvalho Chehab wrote: >> > > Brandon, Could you please add this on one of your trees, together with >> > > those pending V4L2 API patches for UVC? I want to merge those changes >> > > together with the in-kernel driver that firstly requires such changes. >> > >> > I have a tree with the change sets. Please don't pull from the tip >> > though: hg pull -r 4ca1ed646f89 http://ifup.org/hg/v4l-uvc >> > >> > The tip of that tree has UVC and all of the Kconfig/Makefile bits too. >> > >> > The patch set for the tree: http://ifup.org/hg/uvc-v4l-patches >> > >> > If Laurent wants to add his sign off to that last patch (based on r204) >> > we can commit that too :D >> >> I want the driver to be properly reviewed on both video4linux-list and >> linux-usb. I will post a patch on both mailing lists today. >> >> Thanks for taking care of the Kconfig/Makefile bits. Could you send them >> to me >> so that I can include them in the patch to be reviewed ? >> >> Cheers, >> >> Laurent Pinchart >> >> >> >> >> ---------- Message transféré ---------- >> From: Mat <heavensdoor78@gmail.com> >> To: Linux and Kernel Video <video4linux-list@redhat.com> >> Date: Tue, 22 Apr 2008 12:24:13 +0200 >> Subject: Empia em28xx based USB video device... (2) >> >> Hi all. >> How do I test if the current driver support a specific kind of field type? >> >> The device I'm working with seems to work only in interlaced mode. >> V4L2_FIELD_NONE is ignored. >> >> From v4l-info: >> >> video capture >> VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE) >> index : 0 >> type : VIDEO_CAPTURE >> flags : 0 >> description : "Packed YUY2" >> pixelformat : 0x56595559 [YUYV] >> VIDIOC_G_FMT(VIDEO_CAPTURE) >> type : VIDEO_CAPTURE >> fmt.pix.width : 720 >> fmt.pix.height : 576 >> fmt.pix.pixelformat : 0x56595559 [YUYV] >> fmt.pix.field : INTERLACED >> fmt.pix.bytesperline : 1440 >> fmt.pix.sizeimage : 829440 >> fmt.pix.colorspace : SMPTE170M >> fmt.pix.priv : 0 >> >> Is it a module driver limit or an hardware limit? >> In Windows it seems ok... I don't think VLC ( I use it for testing on Win >> ) de-interlace automatically. >> >> Ideas? >> I have to de-interlace myself the frames I suppose... >> >> Thanks in advance. >> -Mat- >> >> >> >> >> ---------- Message transféré ---------- >> From: "Markus Rechberger" <mrechberger@gmail.com> >> To: Mat <heavensdoor78@gmail.com> >> Date: Tue, 22 Apr 2008 13:22:37 +0200 >> Subject: Re: Empia em28xx based USB video device... (2) >> On 4/22/08, Mat <heavensdoor78@gmail.com> wrote: >> > >> > Hi all. >> > How do I test if the current driver support a specific kind of field >> type? >> > >> > The device I'm working with seems to work only in interlaced mode. >> > V4L2_FIELD_NONE is ignored. >> > >> > From v4l-info: >> > >> > video capture >> > VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE) >> > index : 0 >> > type : VIDEO_CAPTURE >> > flags : 0 >> > description : "Packed YUY2" >> > pixelformat : 0x56595559 [YUYV] >> > VIDIOC_G_FMT(VIDEO_CAPTURE) >> > type : VIDEO_CAPTURE >> > fmt.pix.width : 720 >> > fmt.pix.height : 576 >> > fmt.pix.pixelformat : 0x56595559 [YUYV] >> > fmt.pix.field : INTERLACED >> > fmt.pix.bytesperline : 1440 >> > fmt.pix.sizeimage : 829440 >> > fmt.pix.colorspace : SMPTE170M >> > fmt.pix.priv : 0 >> > >> > Is it a module driver limit or an hardware limit? >> > In Windows it seems ok... I don't think VLC ( I use it for testing on >> > Win ) de-interlace automatically. >> > >> > Ideas? >> > I have to de-interlace myself the frames I suppose... >> > >> >> The driver delivers full frames already since many TV applications >> don't support deinterlacing of halfframes at all. That way is >> hardcoded at the moment. >> >> Markus >> >> >> >> >> ---------- Message transféré ---------- >> From: Steven Toth <stoth@linuxtv.org> >> To: Brandon Philips <brandon@ifup.org> >> Date: Tue, 22 Apr 2008 09:03:43 -0400 >> Subject: Re: Hauppauge HVR1400 DVB-T support / XC3028L >> >> Hi Brandon, >> >> On 23:26 Mon 21 Apr 2008, Steven Toth wrote: >>> >>>> I've passed some patches to Mauro that add support for the Hauppauge >>>> HVR1400 Expresscard in DVB-T mode. (cx23885 bridge, dib7000p >>>> demodulator and the xceive xc3028L silicon tuner) >>>> >>>> If you're interested in testing then wait for the patches to appear >>>> in the http://linuxtv.org/hg/v4l-dvb tree. >>>> >>>> You'll need to download firmware from >>>> http://steventoth.net/linux/hvr1400 >>>> >>>> Post any questions or issues here. >>>> >>> >>> Could you post the patches to the lists for review? CC'ing both >>> linux-dvb@linuxtv.org and video4linux-list@redhat.com is appropriate. >>> >> >> The last time I mailed personal tree info to the lists I had people >> referencing my local trees for way too long, posting support messages for >> code that was getting older and more and more out of date. >> >> It created more of a problem than it solved so I rarely do that any more. >> >> I like to engage the non-developers on this list only when it makes sense. >> >> >> >>> It is really difficult staying on top of V4L with private trees and >>> private mails going around :( >>> >>> >> Agreed, I guess. >> >> I posted the patches to the appropriate maintainers for review, along with >> all of the dvb/v4l maintainers and Mauro. Nothing nefarious here, I've >> always done this. >> >> The only difference is that I'm informing a number of people who've >> contacted me personally to ask for support - that support is about to >> arrive. (I did that over the weekend also with the HVR1200/HVR1700/TDA10048 >> email, and it kick-started a rather nice thread for people trying to bring >> up the TDA10048 on another product). >> >> In summary, I have sign-off from the only other maintainer effected by the >> patches so I'd expect them to get merged very quickly into hg/v4l-dvb. >> >> Comments / feedback welcome. >> >> Regards, >> >> - Steve >> >> >> >> >> ---------- Message transféré ---------- >> From: Guennadi Liakhovetski <g.liakhovetski@gmx.de> >> To: 冯鑫 <fengxin215@gmail.com> >> Date: Tue, 22 Apr 2008 16:25:29 +0200 (CEST) >> Subject: Re: question for soc-camera driver >> On Sat, 19 Apr 2008, ·ëöÎ wrote: >> >> > Thanks I will try according to what you said. Mybe I can find why I >> > have this problem.But a driver come from MontaVista can also work >> > well.No frame is dropped. >> > >> > Now I find MontaVista driver have a problem.I execute VIDIOC_REQBUFS >> > failed After I execute VIDIOC_STREAMOFF and munmap() .This time >> > soc-camera driver can work well.You can give me some advice. >> >> I looked at the Montavista driver you provided. It does indeed initialize >> some registers slightly differently, but all those values are either >> default, i.e., would be implicitly the same in the pxa-camera driver, or >> are explicitly overwritten in the driver. So, I cannot see how first using >> the Montavista driver and then switching to the pxa-camera driver can >> change performance of the latter. >> >> One thing you might find interesting - they seem to be configuring the >> capture interface to run at 13MHz, which is close enough to my 10MHz >> guess. So, make sure you're not configuring anything higher in your >> platform code. But, again, it does get reconfigured when pxa-camera is >> loaded, so, it wouldn't produce the improvement you describe. >> >> Thanks >> Guennadi >> --- >> Guennadi Liakhovetski >> >> >> >> >> ---------- Message transféré ---------- >> From: Brandon Philips <brandon@ifup.org> >> To: Laurent Pinchart <laurent.pinchart@skynet.be> >> Date: Tue, 22 Apr 2008 07:25:33 -0700 >> Subject: Re: [PATCH] Support for write-only controls >> On 10:40 Tue 22 Apr 2008, Laurent Pinchart wrote: >> > On Tuesday 22 April 2008 04:22, Brandon Philips wrote: >> > > On 00:19 Tue 15 Apr 2008, Mauro Carvalho Chehab wrote: >> > > > Brandon, Could you please add this on one of your trees, together >> with >> > > > those pending V4L2 API patches for UVC? I want to merge those >> changes >> > > > together with the in-kernel driver that firstly requires such >> changes. >> > > >> > > I have a tree with the change sets. Please don't pull from the tip >> > > though: hg pull -r 4ca1ed646f89 http://ifup.org/hg/v4l-uvc >> > > >> > > The tip of that tree has UVC and all of the Kconfig/Makefile bits too. >> > > >> > > The patch set for the tree: http://ifup.org/hg/uvc-v4l-patches >> > > >> > > If Laurent wants to add his sign off to that last patch (based on >> r204) >> > > we can commit that too :D >> > >> > I want the driver to be properly reviewed on both video4linux-list and >> > linux-usb. I will post a patch on both mailing lists today. >> >> Certainly :D >> >> I put the UVC patch on my tree just to ensure I got all the right bits >> together ;) >> >> > Thanks for taking care of the Kconfig/Makefile bits. Could you send >> > them to me so that I can include them in the patch to be reviewed ? >> >> Signed-off-by: Brandon Philips <bphilips@suse.de> >> >> --- a/linux/drivers/media/video/Kconfig >> +++ b/linux/drivers/media/video/Kconfig >> @@ -741,6 +741,14 @@ menuconfig V4L_USB_DRIVERS >> >> if V4L_USB_DRIVERS && USB >> >> +config USB_UVC >> + tristate "USB Video Class (UVC)" >> + ---help--- >> + Support for the USB Video Class (UVC). Currently only video >> + input devices, such as webcams, are supported. >> + >> + For more information see: <http://linux-uvc.berlios.de/> >> + >> source "drivers/media/video/pvrusb2/Kconfig" >> >> source "drivers/media/video/em28xx/Kconfig" >> --- a/linux/drivers/media/video/Makefile >> +++ b/linux/drivers/media/video/Makefile >> @@ -144,6 +144,8 @@ obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m >> obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o >> obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o >> >> +obj-$(CONFIG_USB_UVC) += uvc/ >> + >> obj-$(CONFIG_VIDEO_AU0828) += au0828/ >> >> EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core >> --- /dev/null >> +++ b/linux/drivers/media/video/uvc/Makefile >> @@ -0,0 +1,3 @@ >> +uvcvideo-objs := uvc_driver.o uvc_queue.o uvc_v4l2.o uvc_video.o >> uvc_ctrl.o\ >> + uvc_status.o uvc_isight.o >> +obj-$(CONFIG_USB_UVC) := uvcvideo.o >> >> >> >> >> ---------- Message transféré ---------- >> From: Mauro Carvalho Chehab <mchehab@infradead.org> >> To: Andrew Morton <akpm@linux-foundation.org> >> Date: Tue, 22 Apr 2008 11:35:39 -0300 >> Subject: Re: 2.6.25 regression: vivi - scheduling while atomic >> > > > > This happenes on a vanilla 2.6.25 with loaded nvidia graphics >> module. >> > > > > System architecture is x86_64. If it matters I'll try to reproduce >> this >> > > > > error on a non tainted kernel. >> > > > >> > > > No need to reproduce on a non-tainted Kernel. This is a known issue >> > > > with patches merged into the v4l-dvb tree several weeks ago but it >> seems >> > > > to not have made it into 2.6.25 :( >> > > > >> > > > http://linuxtv.org/hg/v4l-dvb/rev/06eb92ed0b18 >> > > > http://linuxtv.org/hg/v4l-dvb/rev/c50180f4ddfc >> > > > >> > > > I can rebase the patches for 2.6.25 but they are too big to go into >> the >> > > > stable 2.6.25 tree... >> >> Unfortunately, the tests for the patches fixing several videobuf issues >> finished later on -rc9, when Linus were releasing 2.6.25. >> >> I should send the videobuf patches to Linus tree, together with other >> patches, >> probably today. After that, I think we should backport the fixes for >> 2.6.25, >> and test it again, with vanilla 2.6.25. >> >> The issue here is that videobuf suffered several changes on this >> development >> cycle. Probably, only a few of those patches are needed to fix the issue. >> So, >> we need to handle this with care, to avoid the risk of damaging other >> drivers that >> relies on videobuf. >> >> Cheers, >> Mauro >> >> >> >> >> ---------- Message transféré ---------- >> From: Mauro Carvalho Chehab <mchehab@infradead.org> >> To: Brandon Philips <brandon@ifup.org> >> Date: Tue, 22 Apr 2008 12:22:01 -0300 >> Subject: Re: Hauppauge HVR1400 DVB-T support / XC3028L >> On Mon, 21 Apr 2008 20:44:49 -0700 >> Brandon Philips <brandon@ifup.org> wrote: >> >> > On 23:26 Mon 21 Apr 2008, Steven Toth wrote: >> > > I've passed some patches to Mauro that add support for the Hauppauge >> > > HVR1400 Expresscard in DVB-T mode. (cx23885 bridge, dib7000p >> > > demodulator and the xceive xc3028L silicon tuner) >> > > >> > > If you're interested in testing then wait for the patches to appear >> > > in the http://linuxtv.org/hg/v4l-dvb tree. >> > > >> > > You'll need to download firmware from >> > > http://steventoth.net/linux/hvr1400 >> > > >> > > Post any questions or issues here. >> > >> > Could you post the patches to the lists for review? CC'ing both >> > linux-dvb@linuxtv.org and video4linux-list@redhat.com is appropriate. >> > >> > It is really difficult staying on top of V4L with private trees and >> > private mails going around :( >> >> The better way for you to track about committed patches is what's >> described on >> item 5: "Knowing about newer patches committed at master hg repository", >> of >> http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches. >> >> Basically, if you subscribe to linuxtv-commits ML[1], you'll receive an >> email for >> every newly committed changeset. >> >> This tracks all patches added to the staging tree. If you want to review a >> changeset, you may just reply to the mailbomb email. >> >> I think it is better to have a separate list for this, to avoid increasing >> the >> traffic at the main lists, since we have a large number of commits, >> especially >> during the merge window. For example, it is expected a 50 patch series >> with >> improvements to pvrusb2. Just flooding those emails to the main lists >> seems >> overkill to most users. Better to keep this in track on a separate ML. >> >> This is just my 2 cents. I'm open to discuss improvements on this process. >> >> [1] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits >> >> Cheers, >> Mauro >> >> >> >> >> ---------- Message transféré ---------- >> From: "Edward J. Sheldrake" <ejs1920@yahoo.co.uk> >> To: video4linux-list@redhat.com >> Date: Tue, 22 Apr 2008 16:38:32 +0100 (BST) >> Subject: em28xx/xc3028: changeset 7651 breaks analog audio? >> Hello >> >> I have a Hauppauge HVR-900 rev B3C0, and until very recently it was >> working fine with the em28xx driver in the main v4l-dvb repository. I >> live in England, so have set the option pal=i for the tuner module. It >> was working fine with with the repository from 20080420. I'm watching >> analog TV. >> >> However, with the repository from 20080422, I just get static from the >> audio output. None of the audio_std options for the tuner_xc2028 module >> made any difference. The only changeset I could see for the modules I >> use is 7651, about the firmware for the xc3028 tuner. >> >> Here's relevant dmesg output for the older working driver: >> http://pastebin.com/f399535d5 >> >> And here's the same with the non-working driver: >> http://pastebin.com/fdd8e82e >> >> I extracted the firmware again with the 20080422 repo, but the new >> firmware file worked fine with the older driver. >> >> Let me know how I can help fix this, or is there some module option >> that I've missed? >> >> -- >> >> Edward Sheldrake >> >> >> ___________________________________________________________ >> Yahoo! For Good. Give and get cool things for free, reduce waste and help >> our planet. Plus find hidden Yahoo! treasure >> >> http://green.yahoo.com/uk/earth-day/ >> >> >> >> -- >> video4linux-list mailing list >> Unsubscribe mailto:video4linux-list-request@redhat.com >> ?subject=unsubscribe >> https://www.redhat.com/mailman/listinfo/video4linux-list >> > > [-- Attachment #2: Type: text/plain, Size: 164 bytes --] -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: video4linux-list Digest, Vol 50, Issue 22 2008-04-22 16:19 ` video4linux-list Digest, Vol 50, Issue 22 zied frikha 2008-04-22 16:20 ` zied frikha @ 2008-04-22 16:36 ` Daniel Glöckner 1 sibling, 0 replies; 3+ messages in thread From: Daniel Glöckner @ 2008-04-22 16:36 UTC (permalink / raw) To: zied frikha; +Cc: video4linux-list On Tue, Apr 22, 2008 at 06:19:06PM +0200, zied frikha wrote: > I NEED A GUI FOR THE SI470X RADIO THAT RUN UNDER LINUX (MANDRIVA 2008) > :( > PLEEEEEEEEEEEEEEEEEEEASE Please don't shout. Please use a better Subject line. Please don't quote a full 1000 line digest. Please don't start new threads by replying to unrelated discussions. http://linuxtv.org/v4lwiki/index.php/Radio_Listening_Applications Daniel -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-04-22 16:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20080422160012.2C52C6195D0@hormel.redhat.com>
2008-04-22 16:19 ` video4linux-list Digest, Vol 50, Issue 22 zied frikha
2008-04-22 16:20 ` zied frikha
2008-04-22 16:36 ` Daniel Glöckner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox