Dear Guennadi:
Thanks for you help,now I think I can send emails to
linux-media@vger.kernel.org .there is still one thing I can not
understand.The
question is in the end of this email.
(3) There is a host only, so I think if there are two camera
sensors,when one sensor is
On Wed, 4 May 2011, ÀÖÃô wrote:
Dear Guennadi:
Thanks for you help,now I think I can send emails to
linux-media@vger.kernel.org .there is still one thing I can not
understand.The
question is in the end of this email.
(3) There is a host only, so I think if there are two
On 05/04/2011 01:11 AM, Mauro Carvalho Chehab wrote:
Em 24-04-2011 08:38, Issa Gorissen escreveu:
On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
Em 27-03-2011 21:44, Ralph Metzler escreveu:
Hi,
since I just saw cxd2099 appear in staging in the latest git kernel, a
simple question which has
Hi,
for those interested on mt9p031 working on the Beagleboard xM. I
attach 2 patches here that must be applied to kernel-2.6.39-rc commit
e8dad69408a9812d6bb42d03e74d2c314534a4fa
These patches include a fix for the USB ethernet.
What currently works:
- Test suggested by Guennadi
Hello Javier,
2011/5/4 javier Martin javier.mar...@vista-silicon.com:
Hi,
for those interested on mt9p031 working on the Beagleboard xM. I
attach 2 patches here that must be applied to kernel-2.6.39-rc commit
e8dad69408a9812d6bb42d03e74d2c314534a4fa
These patches include a fix for the USB
Hi Teresa
I'm adding Mauro to CC, because we were discussing adding these (this one
and mt9m111) patches to .39.
On Thu, 14 Apr 2011, Teresa Gámez wrote:
The setup of the pixel clock is done wrong in the mt9v022 driver.
The 'Invert Pixel Clock' bit has to be set to 1 for falling edge
and
From: Andreas Oberritter o...@linuxtv.org
Also, there's still no mapping between ca and caio devices. Imagine a
built-in descrambler ca0 and two CI slots ca1 and ca2.
ca0 won't get a caio device, at least for now.
ca1 and ca2 might or might not have a caio device.
If there is caio0, how
Update:
I noticed I was using the desktop kernel this time, and reinstalled the
default kernel. The audio now works fine (once this patch is installed).
Works every time.
This rings a bell, like I've had to do this to a system in the past.
I don't really understand what desktop vs default
(culling cc list)
hubstar wrote:
Update:
I noticed I was using the desktop kernel this time, and reinstalled the
default kernel. The audio now works fine (once this patch is installed).
Works every time.
This rings a bell, like I've had to do this to a system in the past.
I don't really
On Tuesday 3 May 2011, Andy Walls awa...@md.metrocast.net wrote:
Simon,
If these two changes are going in, please also bump the driver version to
1.5.0 in cx18-version.c. These changes are significant enough
perturbation.
End users are going to look to driver version 1.4.1 as the first
Will do , just for limited into
Distro OpenSuSE though I think I've seen Ubuntu has it as well.
desktop -- supposed to be more responsive to user (timer set to 1000hz + other
tunings)
default -- supposed to be better for server and others
On 04/05/11 10:23, Jonathan Nieder wrote:
On 05/04/2011 10:27 AM, Issa Gorissen wrote:
From: Andreas Oberritter o...@linuxtv.org
Also, there's still no mapping between ca and caio devices. Imagine a
built-in descrambler ca0 and two CI slots ca1 and ca2.
ca0 won't get a caio device, at least for now.
ca1 and ca2 might or might not
From: Andreas Oberritter o...@linuxtv.org
Of course I'm referring to devices connected to the same physical
adapter. Otherwise they would all be called ca0. Device enumeration
always starts at 0, for each adapter. What you're describing just
doesn't make sense.
Yes indeed you're right, I
From: Mauro Carvalho Chehab mche...@redhat.com
It is not that simple. The question is not just how to name the interface,
but that such interface will work on a different way than the current
ca interface.
In other words, the DVB API should clearly explain why this
interface is
stb0899: Fix not locking DVB-S transponder
When stb0899_check_data is entered, it could happen, that the data is
already locked and the data search looped. stb0899_check_data fails to
lock on a good frequency. stb0899_search_data uses an extrem big search
step and fails to lock.
The new code
Andreas Oberritter writes:
- ca0 would be reached from /dev/dvb/adapter0/ca0
- ca[12], depending on if they are connected to the same physical adapter
(PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or
/dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective
On 05/04/11 01:16, Mauro Carvalho Chehab wrote:
Em 13-04-2011 21:05, Lutz Sammer escreveu:
On 05/04/11 21:07, Steffen Barszus wrote:
On Tue, 05 Apr 2011 13:00:14 +0200
Issa Gorissen flop.m@xxx wrote:
Hi,
Eutelsat made a recent migration from DVB-S to DVB-S2 (since
31/3/2011) on two
Em 04-05-2011 06:32, Simon Farnsworth escreveu:
On Tuesday 3 May 2011, Andy Walls awa...@md.metrocast.net wrote:
Simon,
If these two changes are going in, please also bump the driver version to
1.5.0 in cx18-version.c. These changes are significant enough
perturbation.
End users are going
To simplify maintainer support of this driver, bump the version to
1.5.0 - this will be the first version that is expected to support
mmap() for raw video frames.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Mauro,
This is an incremental patch to apply on top of my cleanup
Hi Sylwester,
On Tuesday 03 May 2011 20:07:43 Sylwester Nawrocki wrote:
On 05/03/2011 11:16 AM, Laurent Pinchart wrote:
On Thursday 21 April 2011 17:21:04 Sylwester Nawrocki wrote:
[snip]
+ struct media_pad pads[CSIS_PADS_NUM];
+ struct v4l2_subdev sd;
+ struct platform_device
Simon Farnsworth simon.farnswo...@onelan.co.uk wrote:
To simplify maintainer support of this driver, bump the version to
1.5.0 - this will be the first version that is expected to support
mmap() for raw video frames.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Mauro,
This
On 05/04/2011 01:20 PM, Ralph Metzler wrote:
Andreas Oberritter writes:
- ca0 would be reached from /dev/dvb/adapter0/ca0
- ca[12], depending on if they are connected to the same physical adapter
(PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or
Andreas Oberritter writes:
Of course it does since it is not feasible to use the same adapter
number even on the same card when it provides multi-standard
frontends which share dvr and demux devices. E.g., frontend0 and
frontend1 can belong to the same demod which can be DVB-C and -T
From: Lutz Sammer john...@gmx.net
On 05/04/11 01:16, Mauro Carvalho Chehab wrote:
Em 13-04-2011 21:05, Lutz Sammer escreveu:
On 05/04/11 21:07, Steffen Barszus wrote:
On Tue, 05 Apr 2011 13:00:14 +0200
Issa Gorissen flop.m@xxx wrote:
Hi,
Eutelsat made a recent migration from
Or is there a standard way this is supposed to be handled?
Yes. Since ages. The ioctl is called DMX_SET_SOURCE.
DMX_SET_SOURCE seems to not be implemented anywhere, all it does is
return EINVAL. I also fail to find any useful documentation about what
it is supposed to do.
There are
On 05/04/2011 01:07 PM, Issa Gorissen wrote:
From: Andreas Oberritter o...@linuxtv.org
Of course I'm referring to devices connected to the same physical
adapter. Otherwise they would all be called ca0. Device enumeration
always starts at 0, for each adapter. What you're describing just
From: Andreas Oberritter o...@linuxtv.org
Last but not least, using a different adapter number wouldn't fit
either, because a DVB adapter is supposed to
- be one independent piece of hardware
- provide at least a frontend and a demux device
How would you support device like the
On 05/04/2011 04:05 PM, Issa Gorissen wrote:
From: Andreas Oberritter o...@linuxtv.org
It wouldn't have multiple adapters numbers either.
What do you mean by they shouldn't have mulitple adapters numbers ? Multiple
WinTV-CI devices should have distinct node parents, ie
On 05/04/2011 03:35 PM, Martin Vidovic wrote:
Or is there a standard way this is supposed to be handled?
Yes. Since ages. The ioctl is called DMX_SET_SOURCE.
DMX_SET_SOURCE seems to not be implemented anywhere, all it does is
return EINVAL. I also fail to find any useful documentation
From: Andreas Oberritter o...@linuxtv.org
I don't think this is going to happen, as nobody really seems to care
(me included). I was just pointing out ways that I consider more likely
to succeed.
Regards,
Andreas
If you don't care, why fueling all this fuss ???
--
To unsubscribe from
Em 28-04-2011 12:13, David Härdeman escreveu:
The RC_TYPE_* defines are currently used both where a single protocol is
expected and where a bitmap of protocols is expected. This patch tries
to separate the two in preparation for the following patches.
Signed-off-by: David Härdeman
Em 29-04-2011 05:08, David Härdeman escreveu:
On Thu, 28 Apr 2011 21:13:22 +0100, Malcolm Priestley tvbox...@gmail.com
wrote:
On Thu, 2011-04-28 at 17:13 +0200, David Härdeman wrote:
The following series is what's in my current patch queue for rc-core.
It only been lightly tested so far and
Em 28-04-2011 12:13, David Härdeman escreveu:
Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
and the nec decoder without any loss of functionality.
This seems to be a good strategy. However, it breaks the existing NEC keymap
tables (/me is not considering patch 6/10
Em 28-04-2011 12:13, David Härdeman escreveu:
Now that the protocol is part of the scancode, it is pretty easy to merge
the rc5 and streamzap decoders. An additional advantage is that the decoder
is now stricter as it waits for the trailing silence before determining that
a command is a valid
Em 28-04-2011 12:13, David Härdeman escreveu:
Durations can never be negative, so it makes sense to consistently use
unsigned int for LIRC transmission. Contrary to the initial impression,
this shouldn't actually change the userspace API.
Patch looked ok to me (except for one small issue - see
Em 29-04-2011 14:05, Antti Palosaari escreveu:
Moikka Mauro,
PULL following patches for the 2.6.40.
This basically adds support for two Anysee satellite models:
1. E30 S2 Plus
2. E7 S2
t. Antti
The following changes since commit f5bc5d1d4730bce69fbfdc8949ff50b49c70d934:
Dmitri,
I have tested your patch, but is doesn't work (big crash - long, long,
long beep).
--
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
Hi,
I'm trying to make a BEST BUY EASY TV USB HYBRID PRO work. When I do
lsusb this is what I get:
Bus 001 Device 006: ID eb1a:2881 eMPIA Technology, Inc. EM2881 Video
Controller
Could you help me with this?
I attach the dmesg log
[2.011536] powernow-k8:2 : fid 0x2 (1000 MHz), vid 0xa
[
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:Wed May 4 19:01:27 CEST 2011
git hash:96ca8620ba574b9b74e04fda857b360edbfdd11b
gcc version: i686-linux-gcc (GCC)
Hello,
On Wed, Apr 13, 2011 at 02:56:54PM +0200, Mauro Carvalho Chehab wrote:
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] V4L: mx3_camera: select VIDEOBUF2_DMA_CONTIG instead
Hi Linus,
Please pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
v4l_for_linus
For one regression at v4l2 sub-devices, a few remote controler driver fixes,
one Kconfig
missing dependency and one regression at ngene driver.
Thanks!
Mauro.
-
The
Hi Lawerence,
Em 03-05-2011 14:19, Jarod Wilson escreveu:
On May 3, 2011, at 3:25 AM, Lawrence Rust wrote:
On Mon, 2011-05-02 at 15:50 -0300, Mauro Carvalho Chehab wrote:
Em 08-04-2011 09:50, Lawrence Rust escreveu:
This patch restores remote control input for cx2388x based boards on
Linux
Updated PULL requested!
Cc: Steven Toth as cx24116 driver author.
On 05/04/2011 07:03 PM, Mauro Carvalho Chehab wrote:
Em 29-04-2011 14:05, Antti Palosaari escreveu:
Moikka Mauro,
PULL following patches for the 2.6.40.
This basically adds support for two Anysee satellite models:
1. E30 S2
On Wed, May 04, 2011 at 05:16:29PM -0300, Mauro Carvalho Chehab wrote:
Hi Lawerence,
Em 03-05-2011 14:19, Jarod Wilson escreveu:
On May 3, 2011, at 3:25 AM, Lawrence Rust wrote:
On Mon, 2011-05-02 at 15:50 -0300, Mauro Carvalho Chehab wrote:
Em 08-04-2011 09:50, Lawrence Rust
Moikka Mauro,
PULL following patches for the 2.6.40. I want these master as soon as
possible to get some test reports before Kernel 2.6.40 merge.
This patch series add support PCTV nanoStick T2 290e stick, which is
first DVB-T2 capable computer receiver.
Main part of this patch series is
Em 04-05-2011 17:36, Greg KH escreveu:
Yes, as long as .39 is working properly. We take patches in -stable for
stuff like this at times, it just needs to be specified exactly like you
did above.
OK.
Want me to take this patch as-is for .38-stable?
Yes, please. I'm forwarding you bellow
Dear Guennadi:
You should use different IDs. Look at arch/sh/boards/mach-migor/setup.c or
arch/arm/mach-mx3/mach-pcm037.c for examples.
Thank you for your help,The above sentence gives me the answer.Today
I studied the platform_device subsystem again,and understant that if
you want to
I did a big effort those days to cleanup the patchwork queue. I'm still
finishing to
handle the git pull requests.
As several noticed, we had a very bad time with patchwork on the last weeks,
due to
some troubles at patchwork.kernel.org. That included:
- Patches that disappeared from
On Wed, May 4, 2011 at 3:16 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 13-04-2011 21:05, Lutz Sammer escreveu:
On 05/04/11 21:07, Steffen Barszus wrote:
On Tue, 05 Apr 2011 13:00:14 +0200
Issa Gorissen flop.m@xxx wrote:
Hi,
Eutelsat made a recent migration from DVB-S to
49 matches
Mail list logo
