Re: video4linux-list Digest, Vol 50, Issue 22
- Date: Tue, 22 Apr 2008 18:20:39 +0200
- From: "zied frikha" <frikha.zied@xxxxxxxxx>
- Subject: Re: video4linux-list Digest, Vol 50, Issue 22
HERE IS A PERSON THAT HE/SHE COULD HELP ME
IT IS URGENTLY
2008/4/22, zied frikha <frikha.zied@xxxxxxxxx>:
>
> I NEED A GUI FOR THE SI470X RADIO THAT RUN UNDER LINUX (MANDRIVA 2008)
> :(
> PLEEEEEEEEEEEEEEEEEEEASE
>
> 2008/4/22, video4linux-list-request@xxxxxxxxxx <
> video4linuxHERE-list-request@xxxxxxxxxx<video4linux-list-request@xxxxxxxxxx>
> >:
>>
>> Send video4linux-list mailing list submissions to
>> video4linux-list@xxxxxxxxxx
>>
>> 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@xxxxxxxxxx
>>
>> You can reach the person managing the list at
>> video4linux-list-owner@xxxxxxxxxx
>>
>> 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@xxxxxxxxx>
>> To: Kees Cook <kees@xxxxxxxxxxx>
>> 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@xxxxxxxxxxx>
>> To: Laurent Pinchart <laurent.pinchart@xxxxxxxxx>
>> 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@xxxxxxxx>
>> To: Gregor Jasny <jasny@xxxxxxxxxx>
>> 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@xxxxxxxx>
>> To: mschimek@xxxxxx
>> 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@xxxxxxxx>
>> To: Frej Drejhammar <frej.drejhammar@xxxxxxxxx>
>> 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@xxxxxxxx>
>> To: Frej Drejhammar <frej.drejhammar@xxxxxxxxx>
>> 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@xxxxxxxx>
>> To: Brandon Philips <brandon@xxxxxxxx>
>> 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@xxxxxxxx>
>> To: Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx>
>> 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@xxxxxxxxxxx>
>> To: linux-dvb <linux-dvb@xxxxxxxxxxx>, Linux and Kernel Video <
>> video4linux-list@xxxxxxxxxx>
>> 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@xxxxxxxx>
>> To: Steven Toth <stoth@xxxxxxxxxxx>
>> 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@xxxxxxxxxxx and video4linux-list@xxxxxxxxxx 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@xxxxxxxx>
>> To: Jon Lowe <jonlowe@xxxxxxx>
>> 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@xxxxxxxxx>
>> To: Brandon Philips <brandon@xxxxxxxx>
>> 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@xxxxxxxxx>
>> To: Linux and Kernel Video <video4linux-list@xxxxxxxxxx>
>> 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@xxxxxxxxx>
>> To: Mat <heavensdoor78@xxxxxxxxx>
>> Date: Tue, 22 Apr 2008 13:22:37 +0200
>> Subject: Re: Empia em28xx based USB video device... (2)
>> On 4/22/08, Mat <heavensdoor78@xxxxxxxxx> 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@xxxxxxxxxxx>
>> To: Brandon Philips <brandon@xxxxxxxx>
>> 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@xxxxxxxxxxx and video4linux-list@xxxxxxxxxx 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@xxxxxx>
>> To: 冯鑫 <fengxin215@xxxxxxxxx>
>> 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@xxxxxxxx>
>> To: Laurent Pinchart <laurent.pinchart@xxxxxxxxx>
>> 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@xxxxxxx>
>>
>> --- 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@xxxxxxxxxxxxx>
>> To: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>> 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@xxxxxxxxxxxxx>
>> To: Brandon Philips <brandon@xxxxxxxx>
>> 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@xxxxxxxx> 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@xxxxxxxxxxx and video4linux-list@xxxxxxxxxx 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@xxxxxxxxxxx>
>> To: video4linux-list@xxxxxxxxxx
>> 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@xxxxxxxxxx
>> ?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/video4linux-list
>>
>
>
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list