Re: [PATCH v5 5/6] V4L: Events: Support event handling in do_ioctl
On Sunday 21 February 2010 23:31:43 Sakari Ailus wrote:
> Hans Verkuil wrote:
> > More comments...
> >
> > On Friday 19 February 2010 20:21:59 Sakari Ailus wrote:
> >> Add support for event handling to do_ioctl.
> >>
> >> Signed-off-by: Sakari Ailus
> >> ---
> >> drivers/media/video/v4l2-ioctl.c | 58
> >> ++
> >> include/media/v4l2-ioctl.h |7
> >> 2 files changed, 65 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/media/video/v4l2-ioctl.c
> >> b/drivers/media/video/v4l2-ioctl.c
> >> index 34c7d6e..f7d6177 100644
> >> --- a/drivers/media/video/v4l2-ioctl.c
> >> +++ b/drivers/media/video/v4l2-ioctl.c
> >> @@ -25,6 +25,8 @@
> >> #endif
> >> #include
> >> #include
> >> +#include
> >> +#include
> >> #include
> >>
> >> #define dbgarg(cmd, fmt, arg...) \
> >> @@ -1944,7 +1946,63 @@ static long __video_do_ioctl(struct file *file,
> >>}
> >>break;
> >>}
> >> + case VIDIOC_DQEVENT:
> >> + {
> >> + struct v4l2_event *ev = arg;
> >> + struct v4l2_fh *vfh = fh;
> >> +
> >> + if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)
> >> + || vfh->events == NULL)
> >> + break;
> >
> > Change this to:
> >
> > if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags))
> > break;
> > if (vfh->events == NULL)
> > return -ENOENT;
> >
> > But see also the next comment.
> >
> >> +
> >> + ret = v4l2_event_dequeue(fh, ev);
> >
> > There is a crucial piece of functionality missing here: if the filehandle is
> > in blocking mode, then it should wait until an event arrives. That also
> > means
> > that if vfh->events == NULL, you should still call v4l2_event_dequeue, and
> > that function should initialize vfh->events and wait for an event if the fh
> > is in blocking mode.
>
> I originally left this out intentionally. Most applications using events
> would use select / poll as well by default. For completeness it should
> be there, I agree.
It has to be there. This is important functionality. For e.g. ivtv I would use
this to wait until the MPEG decoder flushed all buffers and displayed the last
frame of the stream. That's something you would often do in blocking mode.
> This btw. suggests that we perhaps should put back the struct file
> argument for the event functions in video_ioctl_ops. The blocking flag
> is indeed part of the file structure. I'm open to better suggestions, too.
My long term goal is that the file struct is only used inside v4l2-ioctl.c
and not in drivers. Drivers should not need this struct at all. The easiest
way to ensure this is by not passing it to the drivers at all :-)
> >> + if (ret < 0) {
> >> + dbgarg(cmd, "no pending events?");
> >> + break;
> >> + }
> >> + dbgarg(cmd,
> >> + "pending=%d, type=0x%8.8x, sequence=%d, "
> >> + "timestamp=%lu.%9.9lu ",
> >> + ev->pending, ev->type, ev->sequence,
> >> + ev->timestamp.tv_sec, ev->timestamp.tv_nsec);
> >> + break;
> >> + }
> >> + case VIDIOC_SUBSCRIBE_EVENT:
> >> + {
> >> + struct v4l2_event_subscription *sub = arg;
> >> + struct v4l2_fh *vfh = fh;
> >>
> >> + if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)
> >
> > Testing for this bit is unnecessarily. Just test for
> > ops->vidioc_subscribe_event.
> >
> >> + || vfh->events == NULL
> >
> > Remove this test. If you allocate the event queue only when you first
> > subscribe to an event (as ivtv will do), then you have to be able to
> > call vidioc_subscribe_event even if vfh->events == NULL.
>
> How about calling v4l2_event_alloc() with zero events? That allocates
> and initialises the v4l2_events structure. That's easier to handle in
> drivers as well since they don't need to consider special cases like
> fh->events happens to be NULL even if events are supported by the
> driver. This is how I first thought it'd work.
Proposal: export a v4l2_event_init() call that sets up fh->events. Calling
v4l2_event_alloc(0) feels like a hack. So drivers that want to be able to
handle events should call v4l2_event_init after initializing the file handle.
Or (and that might even be nicer) test in v4l2_fh_init whether there is a
subscribe op in the ioctl_ops struct and let v4l2_fh_init set up fh->events
automatically.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 5/6] V4L: Events: Support event handling in do_ioctl
Laurent Pinchart wrote: > Hi Sakari, Salut Laurent, >>> There is a crucial piece of functionality missing here: if the filehandle >>> is in blocking mode, then it should wait until an event arrives. That >>> also means that if vfh->events == NULL, you should still call >>> v4l2_event_dequeue, and that function should initialize vfh->events and >>> wait for an event if the fh is in blocking mode. >> >> I originally left this out intentionally. Most applications using events >> would use select / poll as well by default. For completeness it should >> be there, I agree. >> >> This btw. suggests that we perhaps should put back the struct file >> argument for the event functions in video_ioctl_ops. The blocking flag >> is indeed part of the file structure. I'm open to better suggestions, too. > > If the only information we need from struct file is the flags, they could be > copied to v4l2_fh in the open handler. We could also put a struct file * > member in v4l2_fh. That could be one possibility. Copying the flags in open() isn't enough as they can change as a result of fcntl call. As we're not handling that call the flags in struct v4l2_fh would have to be updated for every ioctl. I'm not a big fan of caching information in general either. :-) I could accept this, though. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible memory corruption in bttv driver ?
Hi Leandro There are no crash oops available, as this is a memory corruption that occurs. The effects differ strongly each time. In most cases the system just stops (as the cpu has run over some corrupted code). In some rare cases one can see strange program behaviour, e.g. the sound library libasound.so responded with a symbol not found error (in this case clearing the kernel cache reloaded the uncorrupted libasound code into memory). After a couple of weeks of tests, I found that this memory corruption only occurs if: - data from the bttv device is directly displayed on the video screen using xv hardware acceleration on an geode lx system It does NOT occur if: - data from the bttv driver is displayed on the video screen using NO hardware acceleration (x11) - data from the bttv driver is transferred first to the hard disk and then (in a second) step displayed on the video screen using xv hardware acceleration - data from the bttv driver is directly displayed on the video screen using xv hardware acceleration, but on an intel based system (also faster, more memory) - data from a NON bttv based video card (em28xx, tw68) is directly displayed on the video screen using xv hardware acceleration on the geode lx system So, that seems to be a strange interaction of the bttv driver with the geode lx video driver. I am pretty sure nobody will easily find this one. :-( So, we finally switched to a TW6805 based card using the new tw68 driver from William Brack. Thanks for your consideration and best regards Michael Am Montag, 22. Februar 2010 schrieb leandro Costantino: > Hi Michael, > > could you attach any of the crash oops? That would be of help for bttv > developers here. > > Best Regards > > On Wed, Feb 3, 2010 at 2:10 PM, Michael wrote: > > Hello > > > > We use embedded devices running debian lenny (kernel 2.6.31.4 with bttv > > driver 0.9.18) to monitor an incoming video signal digitized via a video > > grabber. The /dev/video0 device is opened and closed several hundred > > times a > > day. > > > > We used to use an em28xx USB based grabber but now switched to an > > Mini-PCI bttv card (Commel MP-878) due to USB issues. > > > > With the bttv card we experience different crashes, usually after a > > couple of days, while the systems using the em28xx show none even after > > an extended > > time frame. > > > > The crashes differ strongly. We saw system freezes and also a very > > interesting problem, where libasound.so.2 couldn't find some symbol. We > > debugged the latter case, finding that all applications using > > libasound.so.2 > > no longer worked, giving the same error of a symbol not found. The > > problem could be remedied by flushing the kernel cashes (echo 1 > > > /proc/sys/vm/drop_caches). > > > > So it might be possible that the systems using the bttv Mini-PCI card > > corrupt memory after a couple of days, resulting into different failures. > > > > To examine the crashes I wrote a small test program, which simply opens > > and closes the bttv video device repeatedly: > > > > #!/bin/bash > > > > count=0 > > while [ 1 == 1 ] > > do > >((count++)) > >date; echo "COUNT = " $count > >mplayer -frames 10 -fs -vo xv tv:// -tv norm=pal:input=1 > > > /dev/null sleep 0.1 > > done > > > > With this program I experienced full hard crashes after 85 counts, 760 > > counts and 3870 counts today, comprising between a couple of minutes and > > hours. In all cases the hardware watchdog timer resetted the system. > > > > The exact same system using an USB ex28xx based grabber instead of the > > bttv does not crash. > > > > 1.) Is there a way to diagnose memory corruption in order to ensure that > > it is really a corruption problem and to locate the possible bug? > > > > 2.) Do newer kernel versions have improved bttv drivers (maybe even with > > patched memory corruption issues)? > > > > 3.) As a last resort: Do you know of other Mini-PCI video grabber cards > > that > > are based on other chipsets that are supported by the kernel? > > > > Thanks a lot for any help > > > > Michael > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chroma gain configuration
I am doing some work on the saa711x driver, and ran into a case where I need to disable the chroma AGC and manually set the chroma gain. I see there is an existing boolean control called V4L2_CID_CHROMA_AGC, which would be the logical candidate for allowing the user to disable the chroma AGC. However, once this is done I still need to expose the ability to set the gain manually (bits 6-0 of register 0x0f). Is there some existing control I am just missing? Or do I need to do this through a private control. I'm asking because it seems a bit strange that someone would introduce a v4l2 standard control to disable the AGC but not have the ability to manually set the gain once it was disabled. Suggestions welcome. I obviously would only want to introduce a private control if absolutely necessary. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Possible memory corruption in bttv driver ?
Hello We use embedded devices running debian lenny (kernel 2.6.31.4 with bttv driver 0.9.18) to monitor an incoming video signal digitized via a video grabber. The /dev/video0 device is opened and closed several hundred times a day. We used to use an em28xx USB based grabber but now switched to an Mini-PCI bttv card (Commel MP-878) due to USB issues. With the bttv card we experience different crashes, usually after a couple of days, while the systems using the em28xx show none even after an extended time frame. The crashes differ strongly. We saw system freezes and also a very interesting problem, where libasound.so.2 couldn't find some symbol. We debugged the latter case, finding that all applications using libasound.so.2 no longer worked, giving the same error of a symbol not found. The problem could be remedied by flushing the kernel cashes (echo 1 > /proc/sys/vm/drop_caches). So it might be possible that the systems using the bttv Mini-PCI card corrupt memory after a couple of days, resulting into different failures. To examine the crashes I wrote a small test program, which simply opens and closes the bttv video device repeatedly: #!/bin/bash count=0 while [ 1 == 1 ] do ((count++)) date; echo "COUNT = " $count mplayer -frames 10 -fs -vo xv tv:// -tv norm=pal:input=1 > /dev/null sleep 0.1 done With this program I experienced full hard crashes after 85 counts, 760 counts and 3870 counts today, comprising between a couple of minutes and hours. In all cases the hardware watchdog timer resetted the system. The exact same system using an USB ex28xx based grabber instead of the bttv does not crash. 1.) Is there a way to diagnose memory corruption in order to ensure that it is really a corruption problem and to locate the possible bug? 2.) Do newer kernel versions have improved bttv drivers (maybe even with patched memory corruption issues)? 3.) As a last resort: Do you know of other Mini-PCI video grabber cards that are based on other chipsets that are supported by the kernel? Thanks a lot for any help Michael -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More videobuf and streaming I/O questions
Hi Hans, On Saturday 20 February 2010 15:00:21 Hans Verkuil wrote: > I have a few more questions regarding the streaming I/O API: > > 1) The spec mentions that the memory field should be set for VIDIOC_DQBUF. > But videobuf doesn't need it and it makes no sense to me either unless it > is for symmetry with VIDIOC_QBUF. Strictly speaking QBUF doesn't need it > either, but it is a good sanity check. > > Can I remove the statement in the spec that memory should be set for DQBUF? > The alternative is to add a check against the memory field in videobuf, but > that's rather scary. In that case I would remove it for QBUF as well, and state that the memory field must be ignored by drivers (but should they fill it when returning from QBUF/DQBUF ?) > 2) What to do with REQBUFS when called with a count of 0? Thinking it over > I agree that it shouldn't do an implicit STREAMOFF. But I do think that it > is useful to allow as a simple check whether the I/O method is supported. REQBUFS(0) should also free allocated buffers (if any). > So a count of 0 will either return an error if streaming is still in > progress or if the proposed I/O method is not supported, otherwise it will > return 0 while leaving count to 0. > > This allows one to use REQBUFS to test which I/O methods are supported by > the driver without having the driver allocating any buffers. > > This will become more important with embedded systems where almost > certainly additional I/O methods will be introduced (in particular > non-contiguous plane support). > > Currently a count of 0 will result in an error in videobuf. > > Note that drivers do not generally check for valid values of the memory > field at the moment. So that is another thing we need to improve. But > before I start working on that, I first want to know exactly how REQBUFS > should work. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 5/6] V4L: Events: Support event handling in do_ioctl
Hi Sakari,
On Sunday 21 February 2010 23:31:43 Sakari Ailus wrote:
> Hans Verkuil wrote:
> > More comments...
> >
> > On Friday 19 February 2010 20:21:59 Sakari Ailus wrote:
> >> Add support for event handling to do_ioctl.
> >>
> >> Signed-off-by: Sakari Ailus
> >> ---
> >>
> >> drivers/media/video/v4l2-ioctl.c | 58
> >> ++ include/media/v4l2-ioctl.h
> >> |7
> >> 2 files changed, 65 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/media/video/v4l2-ioctl.c
> >> b/drivers/media/video/v4l2-ioctl.c index 34c7d6e..f7d6177 100644
> >> --- a/drivers/media/video/v4l2-ioctl.c
> >> +++ b/drivers/media/video/v4l2-ioctl.c
> >> @@ -25,6 +25,8 @@
> >>
> >> #endif
> >> #include
> >> #include
> >>
> >> +#include
> >> +#include
> >>
> >> #include
> >>
> >> #define dbgarg(cmd, fmt, arg...) \
> >>
> >> @@ -1944,7 +1946,63 @@ static long __video_do_ioctl(struct file *file,
> >>
> >>}
> >>break;
> >>
> >>}
> >>
> >> + case VIDIOC_DQEVENT:
> >> + {
> >> + struct v4l2_event *ev = arg;
> >> + struct v4l2_fh *vfh = fh;
> >> +
> >> + if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)
> >> + || vfh->events == NULL)
> >> + break;
> >
> > Change this to:
> > if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags))
> >
> > break;
> >
> > if (vfh->events == NULL)
> >
> > return -ENOENT;
> >
> > But see also the next comment.
> >
> >> +
> >> + ret = v4l2_event_dequeue(fh, ev);
> >
> > There is a crucial piece of functionality missing here: if the filehandle
> > is in blocking mode, then it should wait until an event arrives. That
> > also means that if vfh->events == NULL, you should still call
> > v4l2_event_dequeue, and that function should initialize vfh->events and
> > wait for an event if the fh is in blocking mode.
>
> I originally left this out intentionally. Most applications using events
> would use select / poll as well by default. For completeness it should
> be there, I agree.
>
> This btw. suggests that we perhaps should put back the struct file
> argument for the event functions in video_ioctl_ops. The blocking flag
> is indeed part of the file structure. I'm open to better suggestions, too.
If the only information we need from struct file is the flags, they could be
copied to v4l2_fh in the open handler. We could also put a struct file *
member in v4l2_fh.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 5/6] V4L: Events: Support event handling in do_ioctl
Hans Verkuil wrote:
> More comments...
>
> On Friday 19 February 2010 20:21:59 Sakari Ailus wrote:
>> Add support for event handling to do_ioctl.
>>
>> Signed-off-by: Sakari Ailus
>> ---
>> drivers/media/video/v4l2-ioctl.c | 58
>> ++
>> include/media/v4l2-ioctl.h |7
>> 2 files changed, 65 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/video/v4l2-ioctl.c
>> b/drivers/media/video/v4l2-ioctl.c
>> index 34c7d6e..f7d6177 100644
>> --- a/drivers/media/video/v4l2-ioctl.c
>> +++ b/drivers/media/video/v4l2-ioctl.c
>> @@ -25,6 +25,8 @@
>> #endif
>> #include
>> #include
>> +#include
>> +#include
>> #include
>>
>> #define dbgarg(cmd, fmt, arg...) \
>> @@ -1944,7 +1946,63 @@ static long __video_do_ioctl(struct file *file,
>> }
>> break;
>> }
>> +case VIDIOC_DQEVENT:
>> +{
>> +struct v4l2_event *ev = arg;
>> +struct v4l2_fh *vfh = fh;
>> +
>> +if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)
>> +|| vfh->events == NULL)
>> +break;
>
> Change this to:
>
> if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags))
> break;
> if (vfh->events == NULL)
> return -ENOENT;
>
> But see also the next comment.
>
>> +
>> +ret = v4l2_event_dequeue(fh, ev);
>
> There is a crucial piece of functionality missing here: if the filehandle is
> in blocking mode, then it should wait until an event arrives. That also means
> that if vfh->events == NULL, you should still call v4l2_event_dequeue, and
> that function should initialize vfh->events and wait for an event if the fh
> is in blocking mode.
I originally left this out intentionally. Most applications using events
would use select / poll as well by default. For completeness it should
be there, I agree.
This btw. suggests that we perhaps should put back the struct file
argument for the event functions in video_ioctl_ops. The blocking flag
is indeed part of the file structure. I'm open to better suggestions, too.
>> +if (ret < 0) {
>> +dbgarg(cmd, "no pending events?");
>> +break;
>> +}
>> +dbgarg(cmd,
>> + "pending=%d, type=0x%8.8x, sequence=%d, "
>> + "timestamp=%lu.%9.9lu ",
>> + ev->pending, ev->type, ev->sequence,
>> + ev->timestamp.tv_sec, ev->timestamp.tv_nsec);
>> +break;
>> +}
>> +case VIDIOC_SUBSCRIBE_EVENT:
>> +{
>> +struct v4l2_event_subscription *sub = arg;
>> +struct v4l2_fh *vfh = fh;
>>
>> +if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)
>
> Testing for this bit is unnecessarily. Just test for
> ops->vidioc_subscribe_event.
>
>> +|| vfh->events == NULL
>
> Remove this test. If you allocate the event queue only when you first
> subscribe to an event (as ivtv will do), then you have to be able to
> call vidioc_subscribe_event even if vfh->events == NULL.
How about calling v4l2_event_alloc() with zero events? That allocates
and initialises the v4l2_events structure. That's easier to handle in
drivers as well since they don't need to consider special cases like
fh->events happens to be NULL even if events are supported by the
driver. This is how I first thought it'd work.
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] DVB API v5 Documentation (was: Re: Documentation questions)
On Thu, Feb 18, 2010 at 07:19:27PM -0500, Andy Walls wrote:
> On Thu, 2010-02-18 at 21:12 +, Hugo Mills wrote:
> > (Please cc: me, I'm not subscribed yet)
> >
> >After struggling to work out how stuff worked from the existing DVB
> > API docs(+), I'm currently attempting to improve the API
> > documentation, to cover the v5 API, and I've got a few questions:
> >
> > * Is anyone else working on docs right now? (i.e. am I wasting my time?)
>
> About a year ago, I stated I was going to add the DVB API v5 additions.
> Well, you see how far that has gotten: nowhere. :P
>
> So please, your are welcome to help.
OK, here's a first stab at cleaning up, and adding as much
information as I know about for frontend devices. I've tried to
separate out the v5 API and put that first, then the v3 API.
I know little about the non-DVB specifications, so the summary
table and documentation is rather incomplete in that area. The ISDB-T
documentation I've left in its original place and state for now (with
a modified title), because I don't know much about the technology.
That section does need the attentions of a good copy editor though,
and should probably go in an appendix. I'll have a go at that in the
next revision. It's also not clear to me whether I should make
ISDB-Tsb a separate column in the properties summary table or not, as
there are properties which are ISDB-Tsb only.
I've put up a copy of the HTML docs generated after this patch, at:
http://carfax.org.uk/kdoc/media/pt02.html
Hugo.
Index: linux-2.6/Documentation/DocBook/dvb/frontend.xml
===
--- linux-2.6.orig/Documentation/DocBook/dvb/frontend.xml 2010-02-17
13:54:28.0 +
+++ linux-2.6/Documentation/DocBook/dvb/frontend.xml2010-02-21
21:40:27.0 +
@@ -6,19 +6,34 @@
ioctl definitions can be accessed by including linux/dvb/frontend.h in your application.
-DVB frontends come in three varieties: DVB-S (satellite), DVB-C
-(cable) and DVB-T (terrestrial). Transmission via the internet (DVB-IP)
-is not yet handled by this API but a future extension is possible. For
-DVB-S the frontend device also supports satellite equipment control
-(SEC) via DiSEqC and V-SEC protocols. The DiSEqC (digital SEC)
-specification is available from
-http://www.eutelsat.com/satellites/4_5_5.html";>Eutelsat.
+DVB frontends come in a large number of varieties (most with few
+drivers). The most common three are DVB-S (satellite), DVB-C (cable)
+and DVB-T (terrestrial). Transmission via the internet (DVB-IP) is not
+yet handled by this API but a future extension is possible. For DVB-S
+the frontend device also supports satellite equipment control (SEC)
+via DiSEqC and V-SEC protocols. The DiSEqC (digital SEC) specification
+is available from http://www.eutelsat.com/satellites/4_5_5.html";>Eutelsat.
Note that the DVB API may also be used for MPEG decoder-only PCI
cards, in which case there exists no frontend device.
+There are two main ways of interacting with a frontend device:
+the v3 API, which comprises a set of 18 ioctls and which supports only
+DVB-T, DVB-C and DVB-S, and the v5 API (previously known as S2API),
+which is only two ioctls, and can support any type of frontend device.
+These two APIs may be mixed if necessary. There are some operations
+which are only possible in one API or the other, but the v5 API is
+rapidly gaining the full feature set of the v3 API. It is recommended
+that the v5 API is used for new applications.
+
-Frontend Data Types
+Frontend Enumeration Types
+
+There are many parameters for tuning and controlling frontend
+devices. Most of these parameters fall into a small range of
+possibilities, and have enumerated types defined for them in the DVB
+API. These are listed below.
frontend type
@@ -64,59 +79,17 @@
FE_CAN_BANDWIDTH_AUTO = 0x4,
FE_CAN_GUARD_INTERVAL_AUTO= 0x8,
FE_CAN_HIERARCHY_AUTO = 0x10,
- FE_CAN_MUTE_TS= 0x8000,
- FE_CAN_CLEAN_SETUP= 0x4000
+ FE_CAN_8VSB = 0x20,
+ FE_CAN_16VSB = 0x40,
+ FE_HAS_EXTENDED_CAPS = 0x80, /* We need more bitspace
for newer APIs, indicate this. */
+ FE_CAN_2G_MODULATION = 0x1000, /* frontend supports "2nd
generation modulation" (DVB-S2) */
+ FE_NEEDS_BENDING = 0x2000, /* not supported anymore,
don't use (frontend requires frequency bending) */
+ FE_CAN_RECOVER= 0x4000, /* frontend can recover
from a cable unplug automatically */
+ FE_CAN_MUTE_TS= 0x8000
} fe_caps_t;
-
-frontend information
-
-Information about the frontend ca be queried with
- FE_GET_INFO.
-
-
- struct dvb_frontend_info {
- char name[128];
- fe_type_t type;
- uint32_t frequency_min;
-
Re: [PATCH v5 4/6] V4L: Events: Add backend
Hans Verkuil wrote:
> Hi Sakari,
Hi Hans,
And many thanks for the comments again!
> Here are some more comments.
>
...
>> +int v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event)
>> +{
>> +struct v4l2_events *events = fh->events;
>> +struct v4l2_kevent *kev;
>> +unsigned long flags;
>> +
>> +spin_lock_irqsave(&fh->vdev->fh_lock, flags);
>> +
>> +if (list_empty(&events->available)) {
>> +spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
>> +return -ENOENT;
>> +}
>> +
>> +WARN_ON(events->navailable == 0);
>> +
>> +kev = list_first_entry(&events->available, struct v4l2_kevent, list);
>> +list_move(&kev->list, &events->free);
>> +events->navailable--;
>> +
>> +kev->event.pending = events->navailable;
>> +*event = kev->event;
>> +
>> +spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_event_dequeue);
>> +
>> +static struct v4l2_subscribed_event *v4l2_event_subscribed(
>> +struct v4l2_fh *fh, u32 type)
>
> Add a comment before this function that mentions that fh->vdev->fh_lock must
> be held before calling this.
Ack.
I'll add WARN_ON(!lock_acquired()) as well.
>> +{
>> +struct v4l2_events *events = fh->events;
>> +struct v4l2_subscribed_event *sev;
>> +
>> +list_for_each_entry(sev, &events->subscribed, list) {
>> +if (sev->type == type)
>> +return sev;
>> +}
>> +
>> +return NULL;
>> +}
>> +
>> +void v4l2_event_queue(struct video_device *vdev, const struct v4l2_event
>> *ev)
>> +{
>> +struct v4l2_fh *fh;
>> +unsigned long flags;
>> +struct timespec timestamp;
>> +
>> +ktime_get_ts(×tamp);
>> +
>> +spin_lock_irqsave(&vdev->fh_lock, flags);
>> +
>> +list_for_each_entry(fh, &vdev->fh_list, list) {
>> +struct v4l2_events *events = fh->events;
>> +struct v4l2_kevent *kev;
>> +u32 sequence;
>> +
>> +/* Are we subscribed? */
>> +if (!v4l2_event_subscribed(fh, ev->type))
>> +continue;
>> +
>> +/* Increase event sequence number on fh. */
>> +events->sequence++;
>> +sequence = events->sequence;
>
> There is no need for a temp sequence variable...
Good point.
>> +
>> +/* Do we have any free events? */
>> +if (list_empty(&events->free))
>> +continue;
>> +
>> +/* Take one and fill it. */
>> +kev = list_first_entry(&events->free, struct v4l2_kevent, list);
>> +kev->event.type = ev->type;
>> +kev->event.u = ev->u;
>> +kev->event.timestamp = timestamp;
>> +kev->event.sequence = sequence;
>
> ... you can just use events->sequence directly here.
>
>> +list_move_tail(&kev->list, &events->available);
>> +
>> +events->navailable++;
>> +
>> +wake_up_all(&events->wait);
>> +}
>> +
>> +spin_unlock_irqrestore(&vdev->fh_lock, flags);
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_event_queue);
>> +
>> +int v4l2_event_pending(struct v4l2_fh *fh)
>> +{
>> +return fh->events->navailable;
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_event_pending);
>> +
>> +int v4l2_event_subscribe(struct v4l2_fh *fh,
>> + struct v4l2_event_subscription *sub)
>> +{
>> +struct v4l2_events *events = fh->events;
>> +struct v4l2_subscribed_event *sev;
>> +unsigned long flags;
>> +
>
> Add this:
>
> if (events == NULL) {
> /* If we get here, then the driver forgot to allocate events. */
> WARN_ON(1);
> return -ENOMEM;
> }
>
> If subscribe is called without the event queue being allocated, then the
> driver did something wrong.
Ok.
> See also my review for patch 5/6.
>
>> +sev = kmalloc(sizeof(*sev), GFP_KERNEL);
>> +if (!sev)
>> +return -ENOMEM;
>> +
>> +spin_lock_irqsave(&fh->vdev->fh_lock, flags);
>> +
>> +if (v4l2_event_subscribed(fh, sub->type) == NULL) {
>> +INIT_LIST_HEAD(&sev->list);
>> +sev->type = sub->type;
>> +
>> +list_add(&sev->list, &events->subscribed);
>> +}
>> +
>> +spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
>
> If the event was already subscribed, then you need to kfree the earlier
> allocated sev here. Otherwise you have a memory leak.
Thanks for catching this!
No matter how many times you read the code through yourself this kind of
bugs may still lie there.
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_event_subscribe);
>> +
>> +/* subscribe a zero-terminated array of events */
>> +int v4l2_event_subscribe_many(struct v4l2_fh *fh, const u32 *all)
>> +{
>> +int ret;
>> +
>> +for (; *all; all++) {
>> +struct v4l2_event_subscription sub;
>> +
>> +sub.type = *all;
>> +
>> +ret = v4l2_event_subscribe(fh, &sub);
>> +if (ret)
>>
Re: [PATCH v5 4/6] V4L: Events: Add backend
Aguirre, Sergio wrote:
> Heippa!
Hi, Sergio!
Your lines seem to be over 80 characters long. :I
...
>> +int v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event)
>> +{
>> +struct v4l2_events *events = fh->events;
>> +struct v4l2_kevent *kev;
>> +unsigned long flags;
>> +
>> +spin_lock_irqsave(&fh->vdev->fh_lock, flags);
>> +
>> +if (list_empty(&events->available)) {
>> +spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
>> +return -ENOENT;
>> +}
>> +
>> +WARN_ON(events->navailable == 0);
>
> I don't think the above warning will ever happen. Looks a bit over protective
> to me.
If it does it's a bug somewhere.
> Whenever you update your "events->available" list, you're holding the fh_lock
> spinlock, so there's no chance that the list of events would contan a
> different number of elents to what the navailable var is holding. Is it?
>
> Please correct me if I'm missing something...
At the moment that is true as far as I see it. But if it's changed in
future chances are something goes wrong. It's a simple check but might
save some headaches.
> Or if you insist in checking, you could just have done this instead:
>
> if (list_empty(&events->available) || (events->navailable == 0)) {
> spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
> return -ENOENT;
> }
>
> As it doesn't make sense to proceed if navailable is zero, I believe...
It'd be a bug in the code so it must be WARN_ON().
I think the question is whether the check should be left there or removed.
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/6] V4L: File handles
Aguirre, Sergio wrote: > Heippa! Hi, Sergio! Thanks for comments! ... >> @@ -0,0 +1,64 @@ >> +/* >> + * drivers/media/video/v4l2-fh.c > > [1] AFAIK, putting file paths is frowned upon. > > Makes maintenance harder if in the future, this files get moved somewhere > else. Ack. >> + * >> + * V4L2 file handles. >> + * >> + * Copyright (C) 2009 Nokia Corporation. > > [2] Shouldn't it be "(C) 2010" already? :) It is. The patches have been floating around since 2009 and I've just forgotten to update this. I hope no-one will notify 2010 must be replaced by 2011 at some point... ;-) ... >> +#endif /* V4L2_EVENT_H */ > > Wrong comment, must have been: > > /* V4L2_FH_H */ Will fix. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] tm6000: bugfix reading problems with demodulator zl10353
From: Stefan Ringel
Signed-off-by: Stefan Ringel
---
drivers/staging/tm6000/tm6000-i2c.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index b563129..6ae02b8 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -54,9 +54,20 @@ int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned
char addr, __u8 reg,
int tm6000_i2c_recv_regs(struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
{
int rc;
+ u8 b[2];
+ if ((dev->caps.has_zl10353) && (dev->demod_addr << 1 == addr) && (reg %
2 == 0)) {
+ reg -= 1;
+ len += 1;
+
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_VENDOR_TYPE |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, b, len);
+
+ *buf = b[1];
+ } else {
rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_VENDOR_TYPE |
USB_RECIP_DEVICE,
REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
len);
+ }
return rc;
}
--
1.6.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] tm6000: bugfix i2c addr
From: Stefan Ringel
Signed-off-by: Stefan Ringel
---
drivers/staging/tm6000/tm6000-i2c.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 6ae02b8..029cf74 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -125,7 +125,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
i++;
- if (addr == dev->tuner_addr) {
+ if (addr == dev->tuner_addr << 1) {
tm6000_set_reg(dev, 0x32, 0,0);
tm6000_set_reg(dev, 0x33, 0,0);
}
@@ -140,7 +140,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
msgs[i].buf + 1, msgs[i].len - 1);
- if (addr == dev->tuner_addr) {
+ if (addr == dev->tuner_addr << 1) {
tm6000_set_reg(dev, 0x32, 0,0);
tm6000_set_reg(dev, 0x33, 0,0);
}
--
1.6.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] tm6000: add send and recv function
From: Stefan Ringel
Signed-off-by: Stefan Ringel
---
drivers/staging/tm6000/tm6000-i2c.c | 48 +-
1 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 656cd19..b563129 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -44,6 +44,32 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages [i2c]");
printk(KERN_DEBUG "%s at %s: " fmt, \
dev->name, __FUNCTION__ , ##args); } while (0)
+int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
+{
+ return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf, len);
+}
+
+/* read from a 8bit register */
+int tm6000_i2c_recv_regs(struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
+{
+ int rc;
+
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_VENDOR_TYPE |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
len);
+
+ return rc;
+}
+
+/* read from a 16bit register
+ * for example xc2028, xc3028 or xc3028L
+ */
+int tm6000_i2c_recv_regs16(struct tm6000_core *dev, unsigned char addr, __u16
reg, char *buf, int len)
+{
+ return tm6000_read_write_usb(dev, USB_DIR_IN | USB_VENDOR_TYPE |
USB_RECIP_DEVICE,
+ REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
+}
+
static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg msgs[], int num)
{
@@ -78,13 +104,14 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
i2c_dprintk(2, "; joined to read %s len=%d:",
i == num - 2 ? "stop" : "nonstop",
msgs[i + 1].len);
- rc = tm6000_read_write_usb (dev,
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- msgs[i].len == 1 ? REQ_16_SET_GET_I2C_WR1_RDN
-: REQ_14_SET_GET_I2C_WR2_RDN,
- addr | msgs[i].buf[0] << 8,
- msgs[i].len == 1 ? 0 : msgs[i].buf[1],
+ if (msgs{i].len == 1) {
+ rc = tm6000_i2c_recv_regs(dev, addr,
msgs[i].buf[0],
msgs[i + 1].buf, msgs[i + 1].len);
+ } else {
+ rc = tm6000_i2c_recv_regs(dev, addr,
msgs[i].buf[0] << 8 | msgs[i].buf[1],
+ msgs[i + 1].buf, msgs[i + 1].len);
+ }
+
i++;
if (addr == dev->tuner_addr) {
@@ -99,10 +126,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
if (i2c_debug >= 2)
for (byte = 0; byte < msgs[i].len; byte++)
printk(" %02x", msgs[i].buf[byte]);
- rc = tm6000_read_write_usb(dev,
- USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN,
- addr | msgs[i].buf[0] << 8, 0,
+ rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
msgs[i].buf + 1, msgs[i].len - 1);
if (addr == dev->tuner_addr) {
@@ -134,9 +158,7 @@ static int tm6000_i2c_eeprom(struct tm6000_core *dev,
bytes[16] = '\0';
for (i = 0; i < len; ) {
*p = i;
- rc = tm6000_read_write_usb (dev,
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, 0xa0 | i<<8, 0, p, 1);
+ rc = tm6000_i2c_revc_regs(dev, 0xa0, i, p, 1);
if (rc < 1) {
if (p == eedata)
goto noeeprom;
--
1.6.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/master] V4L/DVB: em28xx : Terratec Cinergy Hybrid T USB XS FR is working
Catimimi wrote: i, > > This patch works well on a 32bits kernel but not on a 64 bits one. > (openSUSE 11.2) > I'm working on that problem. 64bits kernel with 64 bit usespace or are you using a 32bits application with a 64 bits kernel? Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Feb 21 19:01:33 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14218:7de7f5eb5ca1 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-rc5-armv5-davinci: ERRORS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-rc5-x86_64: OK spec: OK sparse (v4l-dvb-git): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4lconvert_rotate90() leaves bytesperline wrong
Hi,
Thanks for the patch, but this has been long fixed
(in pretty much the same way, the v4lconvert_fixup_fmt() call
was put inside the v4lconvert_rotate90 function).
Regards,
Hans
On 02/21/2010 12:51 AM, Richard Hirst wrote:
I have a cheap webcam (ID 093a:262a Pixart Imaging, Inc.), and Ubuntu
9.10 64 bit, Skype 2.1.0.81, and lib32v4l-0 version 0.6.0-1. I start
skype with LD_PRELOAD=/usr/lib32/libv4l/v4l1compat.so, and the video
image is garbled. I believe the problem is that the webcam image starts
off at 480x640 and skype asks for YU12 at 320x240 for a test image. This
results in v4lconvert_rotate90() being called to rotate the image, and
then v4lconvert_reduceandcrop_yuv420() being called to down-size the
image from 640x480 to 320x240. Unfortunately
v4lconvert_reduceandcrop_yuv420() relies on
src_fmt->fmt.pix.bytesperline for the source image, and that is still
480 (should be 640, since the image has been rotated).
This fixes it for me:
--- ori/libv4lconvert/libv4lconvert.c 2010-02-20 22:44:28.0 +
+++ libv4l-0.6.0/libv4lconvert/libv4lconvert.c 2010-02-20
23:01:12.0 +
@@ -1088,8 +1088,10 @@
v4lprocessing_processing(data->processing, convert2_dest, &my_src_fmt);
}
- if (rotate90)
+ if (rotate90) {
v4lconvert_rotate90(rotate90_src, rotate90_dest, &my_src_fmt);
+ v4lconvert_fixup_fmt(&my_src_fmt);
+ }
if (hflip || vflip)
v4lconvert_flip(flip_src, flip_dest, &my_src_fmt, hflip, vflip);
I didn't look closely at the latest source, so it is possible this
already fixed some other way.
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.34] - vpfe capture support on DM365
Mauro, I have removed the IOCTL handling and also dropped a patch that is related to ioctl handling relative to last pull request. This is based on our discussion since then. The following changes since commit d142708594fd5a0828371b31721a8289800d015a: Mauro Carvalho Chehab (1): V4L/DVB: tuner-xc2028: Fix demod breakage for XC3028L are available in the git repository at: git://linuxtv.org/mkaricheri/vpfe-vpbe-video.git for_upstream_02_21 Murali Karicheri (5): DaVinci - Adding platform & board changes for vpfe capture on DM365 V4L - vpfe capture - header files for ISIF driver V4L - vpfe capture - source for ISIF driver on DM365 V4L - vpfe capture - vpss driver enhancements for DM365 V4L - vpfe capture - build environment for isif driver arch/arm/mach-davinci/board-dm365-evm.c| 71 ++ arch/arm/mach-davinci/dm365.c | 102 +++- arch/arm/mach-davinci/include/mach/dm365.h |2 + drivers/media/video/Kconfig| 14 +- drivers/media/video/davinci/Makefile |1 + drivers/media/video/davinci/isif.c | 1172 drivers/media/video/davinci/isif_regs.h| 269 +++ drivers/media/video/davinci/vpss.c | 289 ++-- include/media/davinci/isif.h | 531 + include/media/davinci/vpss.h | 41 +- 10 files changed, 2435 insertions(+), 57 deletions(-) create mode 100644 drivers/media/video/davinci/isif.c create mode 100644 drivers/media/video/davinci/isif_regs.h create mode 100644 include/media/davinci/isif.h -- Murali Karicheri mkarich...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-patches
Please from http://linuxtv.org/hg/~mcisely/pvrusb2-patches for the following pvrusb2 driver fixes / improvements: - pvrusb2: Enforce a 300msec stabilization interval during stream strart - pvrusb2: Reduce encoder quiet period - pvrusb2: Adjust 300msec digitizer wait to be more selective pvrusb2-hdw-internal.h | 12 - pvrusb2-hdw.c | 61 - pvrusb2-hdw.h |1 3 files changed, 61 insertions(+), 13 deletions(-) These fixes improve mpeg streaming startup stability for any pvrusb2-driven device which contains an saa7115 video digitizer. Thanks, -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pac207: problem with Trust USB webcam
On Wednesday 17 February 2010, Frans Pop wrote: > Thanks a lot to you both for the pointers! I've gotten vlc to work using > v4l1compat.so. The image is recognizable, but the color etc is way off. > Haven't found a way to correct that yet. > > But the main thing for me ATM is that it's working now. JFYI I've backported vlc 1.0.5 (which has proper v4l2 support) to Debian stable and that works beautifully. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/master] V4L/DVB: em28xx : Terratec Cinergy Hybrid T USB XS FR is working
Le 19/02/2010 04:32, Patch from Catimimi a écrit :
From: Catimimi
I succeeded in running Cinergy Hybrid T USB XS FR in both modes.
Signed-off-by: Mauro Carvalho Chehab
drivers/media/video/em28xx/em28xx-cards.c |3 ++-
drivers/media/video/em28xx/em28xx-dvb.c |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
---
http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=a6e03bf56cb824507fff424eac193eca7a2fe17f
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 77870a6..ecbcefb 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -745,11 +745,12 @@ struct em28xx_board em28xx_boards[] = {
[EM2880_BOARD_TERRATEC_HYBRID_XS_FR] = {
.name = "Terratec Hybrid XS Secam",
- .valid= EM28XX_BOARD_NOT_VALIDATED,
.has_msp34xx = 1,
.tuner_type = TUNER_XC2028,
.tuner_gpio = default_tuner_gpio,
.decoder = EM28XX_TVP5150,
+ .has_dvb = 1,
+ .dvb_gpio = default_digital,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c
b/drivers/media/video/em28xx/em28xx-dvb.c
index fcf8c10..1b96356 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -502,6 +502,7 @@ static int dvb_init(struct em28xx *dev)
}
break;
case EM2880_BOARD_TERRATEC_HYBRID_XS:
+ case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
case EM2882_BOARD_DIKOM_DK300:
dvb->frontend = dvb_attach(zl10353_attach,
Hi,
This patch works well on a 32bits kernel but not on a 64 bits one.
(openSUSE 11.2)
I'm working on that problem.
Sorry.
Michel alias Catimimi.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
