Re: video4linux-list Digest, Vol 50, Issue 22

* 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