On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote:
> Not that my commit rate has been > 0 LOC lately, but I'd like to see
> lirc_dev, just to get transmit worked out for the CX23888 chip and
> cx23885 driver.
>
> I think this device will bring to light some assumptions LIRC currently
> ma
On Fri, Apr 23, 2010 at 01:40:34PM -0400, Jarod Wilson wrote:
> So now that I'm more or less done with porting the imon driver, I
> think I'm ready to start tackling the mceusb driver. But I'm debating
> on what approach to take with respect to lirc support. It sort of
> feels like we should have l
On Fri, 2010-04-23 at 14:06 -0400, Jon Smirl wrote:
> On Fri, Apr 23, 2010 at 1:40 PM, Jarod Wilson wrote:
> >
> > So now that I'm more or less done with porting the imon driver, I
> > think I'm ready to start tackling the mceusb driver. But I'm debating
> > on what approach to take with respect t
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:Fri Apr 23 19:00:18 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 14592:b438301e588f
git master:
Hi Mauro,
On Fri, Apr 23, 2010 at 2:14 PM, Mauro Carvalho Chehab
wrote:
> You don't need to be subscribed to be able to sending patches, but you need
> to be
> sure that you don't have any html attachments on your email, as vger will
> simply
> discard anything that it might contain a spam (inc
Jon Smirl wrote:
>> So now that I'm more or less done with porting the imon driver, I
>> think I'm ready to start tackling the mceusb driver. But I'm debating
>> on what approach to take with respect to lirc support. It sort of
>> feels like we should have lirc_dev ported as an ir "decoder"
>> driv
On Fri, Apr 23, 2010 at 1:40 PM, Jarod Wilson wrote:
> On Wed, Apr 7, 2010 at 5:32 AM, David Härdeman wrote:
>> On Mon, Apr 05, 2010 at 04:49:10PM -0400, Jarod Wilson wrote:
>>> On Fri, Apr 2, 2010 at 6:20 AM, David Härdeman wrote:
>>> > Porting the msmce driver to rc-core will be high on my lis
On Wed, Apr 7, 2010 at 5:32 AM, David Härdeman wrote:
> On Mon, Apr 05, 2010 at 04:49:10PM -0400, Jarod Wilson wrote:
>> On Fri, Apr 2, 2010 at 6:20 AM, David Härdeman wrote:
>> > Porting the msmce driver to rc-core will be high on my list of
>> > priorities once I've done some more changes to th
Ricardo Maraschini wrote:
> Please ignore this message.
>
> I've been trying to send a patch to this list since yesterday without success.
> This message is just to validate my mailing list subscription.
You don't need to be subscribed to be able to sending patches, but you need to
be
sure that
Stefan Ringel wrote:
> Am 23.04.2010 17:28, schrieb Bee Hock Goh:
>> So do you mean its required for tm6010 to set the registers?
>>
> that is not a register, please see you in lastest git, that this request
> a command is (send start and send stop!).
It is hard to know what it really does, but
From: Stefan Ringel
renaming tm6000-xc3028.fw to xc3028-v24.fw
Signed-off-by: Stefan Ringel
---
drivers/staging/tm6000/tm6000-cards.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index f
Am 23.04.2010 17:28, schrieb Bee Hock Goh:
> So do you mean its required for tm6010 to set the registers?
>
that is not a register, please see you in lastest git, that this request
a command is (send start and send stop!).
> On Fri, Apr 23, 2010 at 11:23 PM, Stefan Ringel
> wrote:
>
>> Am 2
So do you mean its required for tm6010 to set the registers?
On Fri, Apr 23, 2010 at 11:23 PM, Stefan Ringel wrote:
> Am 23.04.2010 04:20, schrieb Bee Hock Goh:
>> Mauro,
>>
>> Thanks.
>>
>> Previously, I have done some limited test and it seem that
>> xc2028_signal seem to be getting the correct
Am 23.04.2010 04:20, schrieb Bee Hock Goh:
> Mauro,
>
> Thanks.
>
> Previously, I have done some limited test and it seem that
> xc2028_signal seem to be getting the correct registered value for the
> detected a signal locked.
>
> Since I am now able to get video working(though somewhat limited sin
Am Freitag, den 23.04.2010, 10:24 -0300 schrieb Mauro Carvalho Chehab:
> For those that haven't notice yet, we're fixing some bugs at xawtv 3.
> Probably, we
> won't be adding new features on it, but we want to keep it on a sane state,
> in order
> to allow people to use it as a reference applica
Am 23.04.2010 02:48, schrieb Dmitri Belimov:
> Hi
>
> Rework I2C for read word from connected devices, now it works well.
> Add new functions for read/write blocks.
>
> diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000-i2c.c
> --- a/linux/drivers/staging/tm6000/tm6000-i2c.c Mon Apr 05
Hi,
Here is an old patch of mine which I tried to submit in 2006 but never
got it. I didn't really know who was xawtv's maintainer at that time.
The calculation to compute the 64bit alignement in struct-dump.c is
plain wrong. The alignment has to be computed with a structure
containing a char
For those that haven't notice yet, we're fixing some bugs at xawtv 3. Probably,
we
won't be adding new features on it, but we want to keep it on a sane state, in
order
to allow people to use it as a reference application on driver development.
I've just committed a few patches I wrote yesterday
Please ignore this message.
I've been trying to send a patch to this list since yesterday without success.
This message is just to validate my mailing list subscription.
-rm
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel
I am still able to watch tv after applying the patch but the return
code is bad and is causing unnecessary reloading of the same
firmwares.
[ 2482.599040] usb 1-1: firmware: requesting tm6000-xc3028.fw
[ 2482.607229] xc2028 2-0061: Loading 77 firmware images from
tm6000-xc3028.fw, type: xc2028 fir
Bee Hock Goh wrote:
> Mauro,
>
> Thanks.
>
> Previously, I have done some limited test and it seem that
> xc2028_signal seem to be getting the correct registered value for the
> detected a signal locked.
With the i2c reads working perfectly, it should be already providing the
signal strength wit
Hi,
Apologies for the nube ignorance/vagueness but
I'm seeking a bugfix to (I believe) the cx8800 module, related to an issue I
experienced in MythTV (http://svn.mythtv.org/trac/ticket/5744). The MythTV devs
are reluctant to incorporate the patch attached to the bug since they believe
it i
Hello Hans,
thank you for the comments.
On Fri, 2010-04-23 at 11:16 +0200, ext Hans Verkuil wrote:
> On Tuesday 20 April 2010 17:20:04 Matti J. Aaltonen wrote:
> > Hi.
> >
> > This is the initial version of my driver for Texas Instruments
> > WL1273 FM receiver transmitter. The driver is divided
On Tuesday 20 April 2010 17:20:04 Matti J. Aaltonen wrote:
> Hi.
>
> This is the initial version of my driver for Texas Instruments
> WL1273 FM receiver transmitter. The driver is divided into three parts:
> the MFD core which handles the communication with the chip and also
> keeps the chip state
Hello Mauro,
could you please pull the final version of mem-to-mem framework?
Relevant patchwork entries:
https://patchwork.kernel.org/patch/94646/
https://patchwork.kernel.org/patch/94647/
Thank you.
Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center
--
To unsubscr
Hello,
this is the fifth and final version of the mem-to-mem device framework.
I have added Vaibhav's Reviewed-by and Tested-by with his permission
(thank you).
Changes in v5:
- one additional empty line
- an opening brace moved one line above
Best regards
--
Pawel Osciak
Linux Platform Group
Sa
This is a virtual device driver for testing the memory-to-memory framework.
This virtual device uses in-memory buffers for both its source and destination.
It is capable of multi-instance, multi-buffer-per-transaction operation
(via the mem2mem framework).
Signed-off-by: Pawel Osciak
Signed-off-
A mem-to-mem device is a device that uses memory buffers passed by
userspace applications for both their source and destination data. This
is different from existing drivers, which utilize memory buffers for either
input or output, but not both.
In terms of V4L2 such a device would be both of OUTP
Hello,
The issue happens if VLC process hasn't been unloaded before executing
another instance. In this case killall command did not work as
supposed.
Hope this helps.
> We have a video camera which is connected to a capture card in a linux
> server (CentOS 5.4). VLC takes video dat
On 4/22/2010 5:29 PM, Daniel O'Connor wrote:
On Fri, 23 Apr 2010, Timothy D. Lenz wrote:
On 4/22/2010 6:11 AM, Daniel O'Connor wrote:
On Thu, 15 Apr 2010, Daniel O'Connor wrote:
I haven't delved much further yet (planning to printf my way
through the probe routines) as I am a Linux kernel no
>Mauro Carvalho Chehab wrote:
>Hans Verkuil wrote:
>> The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d:
>> Jonathan Corbet (1):
>> V4L/DVB: ov7670: silence some compiler warnings
>>
>> are available in the git repository at:
>>
>> git://linuxtv.org/hverkuil/v
On Friday 23 April 2010 08:21:14 Hans Verkuil wrote:
> On Friday 23 April 2010 08:08:01 Mauro Carvalho Chehab wrote:
> > Hans Verkuil wrote:
> > > The following changes since commit
> > > 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d:
> > > Jonathan Corbet (1):
> > > V4L/DVB: ov7670: silence
32 matches
Mail list logo
