Hi All,
With v4l1 support going completely away, the question is
raised what to do with linux/videodev.h .
Since v4l1 apps can still use the old API through libv4l1,
these apps will still need linux/videodev.h to compile.
So I see 3 options:
1) Keep videodev.h in the kernel tree even after
On some camera systems we do not tolerate the losing of
captured frames. We observed losing of the first frame
from CSI when double buffering is used (multiple buffers
queued by the mx3-camera driver).
The patches provide fixes for the observed problem.
Anatolij Gustschin (2):
v4l: soc-camera:
Some camera systems have strong requirement for capturing
an exact number of frames after starting the stream and do
not tolerate losing captured frames. By starting the stream
after the videobuf has queued the buffers, we ensure that
no frame will be lost.
Signed-off-by: Anatolij Gustschin
Currently when two or more buffers are queued by the camera driver
and so the double buffering is enabled in the idmac, we lose the
first frame comming from CSI since it is just dropped by the
interrupt handler. The reason for this dropping is that the interrupt
handler misleadingly assumes that
Update stv0900 status when LOCK is missed
Signed-off-by: Abylay Ospan aos...@netup.ru
---
drivers/media/dvb/frontends/stv0900_core.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/frontends/stv0900_core.c
Hi Hans,
Em 26-01-2011 06:26, Hans de Goede escreveu:
Hi All,
With v4l1 support going completely away, the question is
raised what to do with linux/videodev.h .
Since v4l1 apps can still use the old API through libv4l1,
these apps will still need linux/videodev.h to compile.
So I see
Em 25-01-2011 20:54, Peter Hüwe escreveu:
Am Dienstag 25 Januar 2011, 23:20:44 schrieb Julia Lawall:
On Tue, 25 Jan 2011, Peter Huewe wrote:
This patch fixes the warning Using plain integer as NULL pointer,
generated by sparse, by replacing the offending 0s with NULL.
I recall (a number of
Em 25-01-2011 14:55, Dmitry Torokhov escreveu:
On Tue, Jan 25, 2011 at 12:42:57PM -0200, Mauro Carvalho Chehab wrote:
Em 25-01-2011 04:52, Dmitry Torokhov escreveu:
On Mon, Jan 24, 2011 at 09:31:17PM -0800, Dmitry Torokhov wrote:
On Tue, Jan 25, 2011 at 12:07:29AM -0500, Mark Lord wrote:
On
Hello,
On Wed, Jan 26, 2011 at 12:55 AM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
On Tue, Jan 25, 2011 at 6:29 PM, Torfinn Ingolfsen tin...@gmail.com wrote:
Anybody?
If Terratec provided the driver, any support related questions should
be directed to them, not to this list.
That
Hi Hans,
Em 26-01-2011 06:26, Hans de Goede escreveu:
Hi All,
With v4l1 support going completely away, the question is
raised what to do with linux/videodev.h .
Since v4l1 apps can still use the old API through libv4l1,
these apps will still need linux/videodev.h to compile.
So I see 3
Hi Mauro!
This is problematic, as it seems to be country-specific and/or
demod-specific.
We'll need to work on a different solution for it. On what Country do you
live?
By looking at HVR1400 entry, it uses a dibcom 7000p demod.
We need to know what are country/demod for the users for whose
Hi Dmitry,
Em 26-01-2011 00:00, Dmitry Torokhov escreveu:
On Tue, Jan 25, 2011 at 03:29:14PM -0800, Dmitry Torokhov wrote:
On Tue, Jan 25, 2011 at 05:22:09PM -0500, Mark Lord wrote:
On 11-01-25 05:00 PM, Mauro Carvalho Chehab wrote:
Em 25-01-2011 18:54, Dmitry Torokhov escreveu:
On Wed, Jan
Em 26-01-2011 07:47, Hans Verkuil escreveu:
Hi Hans,
Em 26-01-2011 06:26, Hans de Goede escreveu:
Hi All,
With v4l1 support going completely away, the question is
raised what to do with linux/videodev.h .
Since v4l1 apps can still use the old API through libv4l1,
these apps will still
Hi,
Btw, I took some time to take analyse the input-kbd stuff.
As said at the README:
This is a small collection of input layer utilities. I wrote them
mainly for testing and debugging, but maybe others find them useful
too :-)
...
Gerd
Em 26-01-2011 11:08, Gerd Hoffmann escreveu:
Hi,
Btw, I took some time to take analyse the input-kbd stuff.
As said at the README:
This is a small collection of input layer utilities. I wrote them
mainly for testing and debugging, but maybe others find them useful
too :-)
On Wed, Jan 26, 2011 at 6:36 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
We should touch the tools that we care of. Maybe Devin could change tvtime,
we should remove V4L1 driver from xawtv3/xawtv4.
Yeah, I have some tvtime work planned, and dropping v4l1 was
definitely on the list. I
On Jan 26, 2011, at 12:11 AM, VDR User wrote:
On Tue, Jan 25, 2011 at 8:30 PM, Jarod Wilson ja...@wilsonet.com wrote:
I'm getting the following now:
git pull ssh://linuxtv.org/git/media_build master
Permission denied (publickey).
Works here just fine. Looks like your ssh key setup is
Hi,
Hmm, doesn't apply cleanly ...
I suspect that Dmitry did the patch against the Debian package, based on a 2007
version of it, as it seems that Debian is using an older version of the package.
Applied, thanks.
cheers,
Gerd
--
To unsubscribe from this list: send the line unsubscribe
On 11-01-26 06:26 AM, Mauro Carvalho Chehab wrote:
..
However, as said previously in this thread, input-kbd won't work with any
RC table that uses NEC extended (and there are several devices on the
current Kernels with those tables), since it only reads up to 16 bits.
ir-keytable works with
On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
On Tue, Jan 25, 2011 at 03:29:14PM -0800, Dmitry Torokhov wrote:
On Tue, Jan 25, 2011 at 05:22:09PM -0500, Mark Lord wrote:
On 11-01-25 05:00 PM, Mauro Carvalho Chehab wrote:
Em 25-01-2011 18:54, Dmitry Torokhov escreveu:
..
That has been done as
On Wed, Jan 26, 2011 at 9:38 AM, Jarod Wilson ja...@wilsonet.com wrote:
Seems that an explicit 'pull over ssh' command was recently added
to media_build, which only works if you've got a shell account on
linuxtv.org. I'll ask Mauro about it and/or just fix it.
He should just have to do git://
On Wed, Jan 26, 2011 at 10:05:57AM -0500, Mark Lord wrote:
On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
On Tue, Jan 25, 2011 at 03:29:14PM -0800, Dmitry Torokhov wrote:
On Tue, Jan 25, 2011 at 05:22:09PM -0500, Mark Lord wrote:
On 11-01-25 05:00 PM, Mauro Carvalho Chehab wrote:
Em
On Wed, Jan 26, 2011 at 12:18:29PM -0200, Mauro Carvalho Chehab wrote:
Em 26-01-2011 11:08, Gerd Hoffmann escreveu:
Hi,
Btw, I took some time to take analyse the input-kbd stuff.
As said at the README:
This is a small collection of input layer utilities. I wrote them
On Wed, Jan 26, 2011 at 12:18:29PM -0200, Mauro Carvalho Chehab wrote:
diff --git a/input.c b/input.c
index d57a31e..a9bd5e8 100644
--- a/input.c
+++ b/input.c
@@ -101,8 +101,8 @@ int device_open(int nr, int verbose)
close(fd);
return -1;
}
- if
Mauro,
Please pull these additional IR driver fixes against Linus' tree in for
2.6.38 merge. Without these, mceusb is still broken (keybounce issues),
the HD-PVR tx won't work, and ir-kbd-i2c behaves badly with both the
HD-PVR and the HVR-1950.
Thanks much!
The following changes since commit
Mauro,
I plan to make extensive lirc_zilog changes starting tonight, so the sooner
Jarrod's lirc_zilog.c fix is in a media_tree branch, the less rebase I'll have
to do. :)
Thanks.
Andy
Jarod Wilson ja...@redhat.com wrote:
Mauro,
Please pull these additional IR driver fixes against Linus'
Torfinn Ingolfsen tin...@gmail.com writes:
That is the point: TerraTec states that these are third-party drivers,
and they provide no support (as far as we can't give you a better
answer).
So I am just trying to find out where those drivers came from, and if
somebody has any experience / a
Em 26-01-2011 12:58, Mark Lord escreveu:
On 11-01-26 06:26 AM, Mauro Carvalho Chehab wrote:
..
However, as said previously in this thread, input-kbd won't work with any
RC table that uses NEC extended (and there are several devices on the
current Kernels with those tables), since it only
On Wed, Jan 26, 2011 at 03:41:01PM -0200, Mauro Carvalho Chehab wrote:
Em 26-01-2011 12:58, Mark Lord escreveu:
On 11-01-26 06:26 AM, Mauro Carvalho Chehab wrote:
..
However, as said previously in this thread, input-kbd won't work with any
RC table that uses NEC extended (and there are
Em 26-01-2011 15:23, Andy Walls escreveu:
Mauro,
I plan to make extensive lirc_zilog changes starting tonight, so the sooner
Jarrod's lirc_zilog.c fix is in a media_tree branch, the less rebase I'll
have to do. :)
Andy,
Then, it is better to use Jarod's tree for it. His patches are
Em 26-01-2011 13:05, Mark Lord escreveu:
On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
On Tue, Jan 25, 2011 at 03:29:14PM -0800, Dmitry Torokhov wrote:
On Tue, Jan 25, 2011 at 05:22:09PM -0500, Mark Lord wrote:
On 11-01-25 05:00 PM, Mauro Carvalho Chehab wrote:
Em 25-01-2011 18:54, Dmitry
Em 26-01-2011 14:51, Dmitry Torokhov escreveu:
On Wed, Jan 26, 2011 at 12:18:29PM -0200, Mauro Carvalho Chehab wrote:
diff --git a/input.c b/input.c
index d57a31e..a9bd5e8 100644
--- a/input.c
+++ b/input.c
@@ -101,8 +101,8 @@ int device_open(int nr, int verbose)
close(fd);
On Wed, Jan 26, 2011 at 03:29:09PM -0200, Mauro Carvalho Chehab wrote:
Em 26-01-2011 14:51, Dmitry Torokhov escreveu:
On Wed, Jan 26, 2011 at 12:18:29PM -0200, Mauro Carvalho Chehab wrote:
diff --git a/input.c b/input.c
index d57a31e..a9bd5e8 100644
--- a/input.c
+++ b/input.c
@@
Hi,
The check should be against concrete version (0x1 in this case).
Stepping back: what does the version mean?
0x1 == 1.0 ?
0x10001 == 1.1 ?
Can I expect the interface stay backward compatible if only the minor
revision changes, i.e. makes it sense to accept 1.x?
Will the
On 11-01-26 01:24 PM, Dmitry Torokhov wrote:
On Wed, Jan 26, 2011 at 03:29:09PM -0200, Mauro Carvalho Chehab wrote:
Em 26-01-2011 14:51, Dmitry Torokhov escreveu:
On Wed, Jan 26, 2011 at 12:18:29PM -0200, Mauro Carvalho Chehab wrote:
diff --git a/input.c b/input.c
index d57a31e..a9bd5e8
On 11-01-26 02:16 PM, Gerd Hoffmann wrote:
Hi,
The check should be against concrete version (0x1 in this case).
Stepping back: what does the version mean?
0x1 == 1.0 ?
0x10001 == 1.1 ?
Can I expect the interface stay backward compatible if only the minor revision
changes,
Em 26-01-2011 17:16, Gerd Hoffmann escreveu:
Hi,
The check should be against concrete version (0x1 in this case).
Dmitry,
Ok, now I see what you're meaning. Yeah, an absolute version check like
what you've proposed is better than a relative version check.
Stepping back: what does
On 11-01-26 12:59 PM, Dmitry Torokhov wrote:
On Wed, Jan 26, 2011 at 03:41:01PM -0200, Mauro Carvalho Chehab wrote:
Em 26-01-2011 12:58, Mark Lord escreveu:
On 11-01-26 06:26 AM, Mauro Carvalho Chehab wrote:
..
However, as said previously in this thread, input-kbd won't work with any
RC
On 11-01-26 11:44 AM, Dmitry Torokhov wrote:
On Wed, Jan 26, 2011 at 10:05:57AM -0500, Mark Lord wrote:
..
Nope. Does not work here:
$ lsinput
protocol version mismatch (expected 65536, got 65537)
It would be much more helpful if you tried to test what has been fixed
(hint: version
On Wed, Jan 26, 2011 at 08:16:09PM +0100, Gerd Hoffmann wrote:Hi,
The check should be against concrete version (0x1 in this case).
Stepping back: what does the version mean?
Nothing, it is just a number.
0x1 == 1.0 ?
0x10001 == 1.1 ?
No, not really.
Can I expect the
On 11-01-26 12:32 PM, Mauro Carvalho Chehab wrote:
Em 26-01-2011 13:05, Mark Lord escreveu:
..
Nope. Does not work here:
$ lsinput
protocol version mismatch (expected 65536, got 65537)
You need to relax the version test at the tree. As I said before, this is
a development tool from the
Hello,
When I modprobe omap3-isp I get a segfault. I'm attempting to use a
Gumstix Overo with Micron MT9V032.
root@overo:~# modprobe omap3-isp
Linux media interface: v0.10
Linux video capture interface: v2.00
omap3isp omap3isp: Revision 2.0 found
Unable to handle kernel NULL
On Wed, Jan 26, 2011 at 02:31:44PM -0500, Mark Lord wrote:
On 11-01-26 11:44 AM, Dmitry Torokhov wrote:
On Wed, Jan 26, 2011 at 10:05:57AM -0500, Mark Lord wrote:
..
Nope. Does not work here:
$ lsinput
protocol version mismatch (expected 65536, got 65537)
It would be much more
On Wed, Jan 26, 2011 at 02:33:17PM -0500, Mark Lord wrote:
On 11-01-26 12:32 PM, Mauro Carvalho Chehab wrote:
Em 26-01-2011 13:05, Mark Lord escreveu:
..
Nope. Does not work here:
$ lsinput
protocol version mismatch (expected 65536, got 65537)
You need to relax the version test at
On 11-01-26 02:41 PM, Dmitry Torokhov wrote:
I do not consider lsinput refusing to work a regression.
Obviously, since you don't use that tool.
Those of us who do use it see this as broken userspace compatibility.
Who the hell reviews this crap, anyway?
Code like that should never have made it
On Wed, Jan 26, 2011 at 02:47:18PM -0500, Mark Lord wrote:
On 11-01-26 02:41 PM, Dmitry Torokhov wrote:
I do not consider lsinput refusing to work a regression.
Obviously, since you don't use that tool.
Those of us who do use it see this as broken userspace compatibility.
Who the hell
On Jan 26, 2011, at 10:14 AM, Devin Heitmueller wrote:
On Wed, Jan 26, 2011 at 9:38 AM, Jarod Wilson ja...@wilsonet.com wrote:
Seems that an explicit 'pull over ssh' command was recently added
to media_build, which only works if you've got a shell account on
linuxtv.org. I'll ask Mauro about
Hi,
It depends. We do not have a clear way to see if new ioctls are
supported (and I do not consider try new ioctl and see if data sticks
being a good way) so that facilitated protocol version rev-up.
Yea, EVIOCGKEYCODE_V2 on a old kernel returns EINVAL. Not good. There
is another one
Hi,
Will the major revision ever change? Does it make sense to check the version at
all?
As already established earlier in this thread,
by Linus Torvalds as well as by myself,
NO!
Check removed.
thanks,
Gerd
--
To unsubscribe from this list: send the line unsubscribe linux-media in
Hi,
On Wed, Jan 26, 2011 at 6:35 PM, Bjørn Mork bj...@mork.no wrote:
Sure is. But even if you get past the build errors, you'll soon
discover that Terratec forgot to include the necessary firmware as
well. You can find it and some other hints in this thread:
On 11-01-26 02:50 PM, Dmitry Torokhov wrote:
On Wed, Jan 26, 2011 at 02:47:18PM -0500, Mark Lord wrote:
On 11-01-26 02:41 PM, Dmitry Torokhov wrote:
I do not consider lsinput refusing to work a regression.
Obviously, since you don't use that tool.
Those of us who do use it see this as
Or perhaps get rid of that unworkable version number thing
(just freeze it in time with the 2.6.35 value returned),
and implement a get_feature_flags ioctl or something for going forward.
Then you can just turn on new bits in the flags as new features are added.
It's a kludge (to get around the
On Wed, Jan 26, 2011 at 04:41:07PM -0500, Mark Lord wrote:
On 11-01-26 02:50 PM, Dmitry Torokhov wrote:
On Wed, Jan 26, 2011 at 02:47:18PM -0500, Mark Lord wrote:
On 11-01-26 02:41 PM, Dmitry Torokhov wrote:
I do not consider lsinput refusing to work a regression.
Obviously, since you
On Wed, Jan 26, 2011 at 04:49:14PM -0500, Mark Lord wrote:
Or perhaps get rid of that unworkable version number thing
(just freeze it in time with the 2.6.35 value returned),
and implement a get_feature_flags ioctl or something for going forward.
Then you can just turn on new bits in the flags
On Wed, 2011-01-26 at 15:44 -0200, Mauro Carvalho Chehab wrote:
Andy,
Then, it is better to use Jarod's tree for it. His patches are against
upstream, and are meant to be applied to .38. So, I need first to send
them to linux-next, then to upstream and then merge from upstream,
otherwise,
On Tue, 25 Jan 2011, Laurent Pinchart wrote:
Hi Michael,
On Tuesday 25 January 2011 10:10:50 Michael Jones wrote:
On 01/24/2011 08:45 PM, Laurent Pinchart wrote:
On Monday 24 January 2011 15:16:28 Michael Jones wrote:
On 01/24/2011 02:57 PM, Laurent Pinchart wrote:
snip
As
On 11-01-26 10:05 AM, Mark Lord wrote:
On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
..
I wonder if the patch below is all that is needed...
Nope. Does not work here:
$ lsinput
protocol version mismatch (expected 65536, got 65537)
Heh.. I just noticed something *new* in the bootlogs on my
On 11-01-26 08:01 PM, Mark Lord wrote:
On 11-01-26 10:05 AM, Mark Lord wrote:
On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
..
I wonder if the patch below is all that is needed...
Nope. Does not work here:
$ lsinput
protocol version mismatch (expected 65536, got 65537)
Heh.. I just
Ok I solved the segfault problem by updating some of my v4l2 files
(specifically v4l2-common.c). Now I only get nice sounding console messages.
Linux media interface: v0.10
Linux video capture interface: v2.00
omap3isp omap3isp: Revision 2.0 found
omap-iommu omap-iommu.0: isp:
On Wed, Jan 26, 2011 at 08:07:29PM -0500, Mark Lord wrote:
On 11-01-26 08:01 PM, Mark Lord wrote:
On 11-01-26 10:05 AM, Mark Lord wrote:
On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
..
I wonder if the patch below is all that is needed...
Nope. Does not work here:
$ lsinput
On 11-01-26 09:12 PM, Dmitry Torokhov wrote:
On Wed, Jan 26, 2011 at 08:07:29PM -0500, Mark Lord wrote:
On 11-01-26 08:01 PM, Mark Lord wrote:
On 11-01-26 10:05 AM, Mark Lord wrote:
On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
..
I wonder if the patch below is all that is needed...
Nope.
On Wed, Jan 26, 2011 at 10:18:53PM -0500, Mark Lord wrote:
On 11-01-26 09:12 PM, Dmitry Torokhov wrote:
On Wed, Jan 26, 2011 at 08:07:29PM -0500, Mark Lord wrote:
On 11-01-26 08:01 PM, Mark Lord wrote:
On 11-01-26 10:05 AM, Mark Lord wrote:
On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
62 matches
Mail list logo
