On Thursday, May 05, 2011 05:58:51 Mauro Carvalho Chehab wrote:
> 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 pa
On Wed, May 4, 2011 at 3:16 AM, 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" wrote:
> Hi,
>
> Eutelsat made a recent migration from DVB-S to DVB
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 pat
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
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
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 ne
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
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 Pl
Currently the driver enables overlay when running
VIDIOC_S_FMT ioctl with fmt type V4L2_BUF_TYPE_VIDEO_OVERLAY.
Actually, this is wrong. Add proper VIDIOC_OVERLAY support
instead of using VIDIOC_S_FMT for overlay enable.
Signed-off-by: Anatolij Gustschin
---
drivers/media/video/fsl-viu.c | 32
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
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 follo
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 inst
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) 4.5
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
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
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
El 02/05/11 10:06, Mauro Carvalho Chehab escribió:
From this message:
[ 14.288626] Frontend revision 255 is unknown - aborting.
I suspect that the I2C gate needed to access the frontend is at the wrong
state. That's why you're
getting 0xff (255) value there.
I changed the value ".demod_addr
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:
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 - s
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 val
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 29-04-2011 05:08, David Härdeman escreveu:
> On Thu, 28 Apr 2011 21:13:22 +0100, Malcolm Priestley
> 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 it's b
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
Most
From: Andreas Oberritter
>
> 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 this list:
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 documen
On 05/04/2011 04:05 PM, Issa Gorissen wrote:
> From: Andreas Oberritter
>> 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
> /dev/dvb/adapter[01]/
I wrote
From: Andreas Oberritter
> >> 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 Ha
On 05/04/2011 01:07 PM, Issa Gorissen wrote:
> From: Andreas Oberritter
>>
>> 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 mak
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 no
From: Lutz Sammer
> 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" wrote:
>
> > Hi,
> >
> > Eutelsat made a recent migr
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
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
> > > /dev/d
Simon Farnsworth 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
>---
>Mauro,
>
>This is an incremental patch to apply on top of my clea
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_d
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
---
Mauro,
This is an incremental patch to apply on top of my cleanup patch - if
you would prefer a c
Em 04-05-2011 06:32, Simon Farnsworth escreveu:
> On Tuesday 3 May 2011, Andy Walls 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
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" wrote:
> Hi,
>
> Eutelsat made a recent migration from DVB-S to DVB-S2 (since
>>>
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 res
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 ch
From: Mauro Carvalho Chehab
>
> 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 different, when it s
From: Andreas Oberritter
>
> 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 answered too
On 05/04/2011 10:27 AM, Issa Gorissen wrote:
> From: Andreas Oberritter
>> 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 c
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:
> (cullin
On Tuesday 3 May 2011, Andy Walls 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 version
> for prop
(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
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 kernel
From: Andreas Oberritter
> 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 am I suppos
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
Hello Javier,
2011/5/4 javier Martin :
> 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
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
(http://download.
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
simp
On Wed, 4 May 2011, ÀÖÃô wrote:
> Dear Guennadi:
>
> Thanks for you help,now I think I can send emails to
> .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
> > > > s
52 matches
Mail list logo