On Monday, January 17, 2011 08:35:21 Kamil Debski wrote:
> Hi Hans,
>
> > From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> > Hi Kamil,
> >
> > I still need to review this carefully since this is the first codec
> > driver.
> > I had hoped to do this during the weekend, but I didn't manage it. I
>
Hi Hans,
> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> Hi Kamil,
>
> I still need to review this carefully since this is the first codec
> driver.
> I had hoped to do this during the weekend, but I didn't manage it. I
> hope I
> can get to it on Friday.
This would be great.
> One thing I
Hi Kamil,
I still need to review this carefully since this is the first codec driver.
I had hoped to do this during the weekend, but I didn't manage it. I hope I
can get to it on Friday.
One thing I noticed: you aren't using the control framework in this driver.
Please switch to that. From now on
On Monday, January 17, 2011 04:44:54 Jonghun Han wrote:
>
> Hello,
>
> How to set global alpha to V4L2_BUF_TYPE_CAPTURE ?
>
> Samsung SoC S5PC210 has Camera interface and Video post processor named FIMC
> which can set the alpha value to V4L2_BUF_TYPE_CAPTURE.
> For example during color space c
Hi,
I don't see the need to do DQBUF on the source buffer that has the
I-frame with changed resolution. I think that one could notify the
application by setting size=0 on the CAPTURE buffer. So the OUTPUT
buffer would not be dequeued. It would be dequeued after it has
been decoded. Do you think a
Hello,
How to set global alpha to V4L2_BUF_TYPE_CAPTURE ?
Samsung SoC S5PC210 has Camera interface and Video post processor named FIMC
which can set the alpha value to V4L2_BUF_TYPE_CAPTURE.
For example during color space conversion from YUV422 to ARGB,
FIMC can set the alpha value to V4L2
On Sun, 2011-01-16 at 14:20 -0500, Andy Walls wrote:
> Mauro,
>
> Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes
> for 2.6.38.
>
> The one ir-kbd-i2c change is to put back a case to have ir-kbd-i2c set
> defaults for I2C client address 0x71. I know I was the one who
> reco
On Sun, 16 Jan 2011, Andy Walls wrote:
> On Sun, 2011-01-16 at 20:27 -0600, Mike Isely wrote:
[,,,]
>
> Right now, yes. In the near future, I need to use to to pass 3
> non-const items though:
>
> 1. A "struct mutex *transceiver_lock" so that the bridge driver can pass
> a mutex to multipl
On Sun, 2011-01-16 at 20:27 -0600, Mike Isely wrote:
> Andy:
>
> Is the IR_i2c_init_data struct instance required to remain around for
> the life of the driver's registration and is that why you stuffed it
> into the pvr2_hdw struct?
Yes.
The loading of ir-kbd-i2c or lirc_zilog can happen som
Andy:
Is the IR_i2c_init_data struct instance required to remain around for
the life of the driver's registration and is that why you stuffed it
into the pvr2_hdw struct? Second: If the first question is yes, then is
that struct considered to be read-only once it is set up and passed
through
When registering an IR Rx device with the I2C subsystem, provide more detailed
information about the IR device and default remote configuration for the IR
driver modules.
Also explicitly register any IR Tx device with the I2C subsystem.
Signed-off-by: Andy Walls
Cc: Mike Isely
--
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-09/msg12477.html
hg v4l today (01/16/2011). Doesn't do it when using linux-2.6.34 x64,
but when trying to compile under linux-2.6.37 on a 32bit:
/usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l/bttv-i2c.c: In function
'init_b
This feature will probably be moved to libv4l2.
Signed-off-by: Pawel Osciak
---
Documentation/DocBook/v4l/planar-apis.xml | 35 +---
Documentation/DocBook/v4l/vidioc-querycap.xml | 22 +++
2 files changed, 18 insertions(+), 39 deletions(-)
diff --git a/Do
On Sunday, January 16, 2011 18:55:22 Hans Verkuil wrote:
> On Sunday, January 16, 2011 16:36:34 Hans Verkuil wrote:
> > Hi Mauro,
> >
> > This fixes a nasty little bug that I just found with v4l2-compliance.
> >
> > I'm writing lots of compliance tests for control handling at the moment and
> > t
Fixing the very annoying tunning issue. When switching from DVB-S2 to DVB-S,
it often took minutes to have a lock.
This issue is known to Igor M. Liplianin and was also reported ie. in the
following posts:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/24573
http://article.
On Sun, 2011-01-16 at 16:27 -0200, Mauro Carvalho Chehab wrote:
> Jarod/Andy,
>
> For now, I'm marking all those ir-kbd-i2c/lirc_zilog patches as "RFC" at
> patchwork,
> as I'm not sure if they're ok, and because there are a few revisions of them
> and
> I'm afraid to apply some wrong version.
Add DocBook documentation for the new multi-planar API extensions to the
Video for Linux 2 API DocBook.
Signed-off-by: Pawel Osciak
---
Removed references to single-multi planar API conversion layer.
Documentation/DocBook/media-entities.tmpl |4 +
Documentation/DocBook/v4l/common.xml
video_device is already being freed in video_device.release callback on
release.
Signed-off-by: Pawel Osciak
Reported-by: Roland Kletzing
---
drivers/media/video/mem2mem_testdev.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mem2mem_testdev.c
b/d
Mauro,
Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes
for 2.6.38.
The one ir-kbd-i2c change is to put back a case to have ir-kbd-i2c set
defaults for I2C client address 0x71. I know I was the one who
recommend that ir-kbd-i2c not do this, but I discovered pvrusb2 and bttv
Em 15-01-2011 11:46, Helmut Auer escreveu:
> Hello List
>
> How long does it usually take til patches are integrated into the media build
> tree ( after posting these here ) ?
> I'm just wondering because I miss some patches posted here.
It takes as much it needs for the driver maintainer to loo
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 Jan 16 19:00:22 CET 2011
git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f
git media-master: gcc version: i6
Jarod/Andy,
For now, I'm marking all those ir-kbd-i2c/lirc_zilog patches as "RFC" at
patchwork,
as I'm not sure if they're ok, and because there are a few revisions of them and
I'm afraid to apply some wrong version.
Please, after finishing and testing, send me a patch series or, preferably, a
g
On Sunday, January 16, 2011 16:36:34 Hans Verkuil wrote:
> Hi Mauro,
>
> This fixes a nasty little bug that I just found with v4l2-compliance.
>
> I'm writing lots of compliance tests for control handling at the moment and
> the results are rather, erm, disheartening to use a polite word :-(
Add
Em 02-01-2011 10:01, Igor M. Liplianin escreveu:
> An Altera FPGA CI module for NetUP Dual DVB-T/C RF CI card.
>
> Signed-off-by: Igor M. Liplianin
Igor,
There's something wrong with this patch. I got lots of error after applying it:
drivers/media/video/cx23885/altera-ci.o: In function
`netup
Hi Mauro,
This fixes a nasty little bug that I just found with v4l2-compliance.
I'm writing lots of compliance tests for control handling at the moment and
the results are rather, erm, disheartening to use a polite word :-(
Regards,
Hans
The following changes since commit a9ac9ac36d6b1
Hello, I've recently faced kernel boo-boo using driver radio_usb_si470x with SI
chipset device, according to info in module I think I should post it here.
Here's crash report in syslog:
Jan 16 00:53:14 aclex kernel: usb 1-2.3: new full speed USB device using
ehci_hcd and address 9
Jan 16 00:53:
Em 07-01-2011 17:31, Ben Gamari escreveu:
> Hi Mauro,
>
> On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab
> wrote:
>> Em 31-12-2010 09:30, Laurent Pinchart escreveu:
>>> Hi Mauro,
>>>
>>> [snip]
>>>
>>> I understand this. However, a complete JTAG state machine in the kernel,
>>> plus
Em 13-01-2011 14:30, Jean-Francois Moine escreveu:
> On Thu, 13 Jan 2011 12:38:04 +0100
> Antonio Ospite wrote:
>
>>> Jean-François Moine (9):
>> [...]
>>> gspca - ov534: Use the new video control mechanism
>>
>> In this commit, is there a reason why you didn't rename also
>> sd_setagc(
Hi,
Thanks for the new patch, it looks much better.
Unfortunately I found what I can only describe as a bug in the
plugin rfc (which as you probasbly know I wrote). The problem is
2 fold:
1) The existence of v4l2_fd_open (and its active use by multiple
applications) means that we cannot let h
Commit e3c92215198cb6aa00ad38db2780faa6b72e0a3f ("[media] radio-aimslab.c: Fix
gcc 4.5+ bug") removed the include, but introduced new callers of msleep():
| drivers/media/radio/radio-aimslab.c: In function ‘rt_decvol’:
| drivers/media/radio/radio-aimslab.c:76: error: implicit declaration of
funct
Em 13-01-2011 10:58, Mauro Carvalho Chehab escreveu:
> Em 13-01-2011 06:46, Andrzej Pietrasiewicz escreveu:
>> Hello Mauro,
>>
>> On Wednesday, January 12, 2011 9:24 PM Mauro Carvalho Chehab wrote:
>>>
>>> Em 12-01-2011 08:25, Marek Szyprowski escreveu:
Hello Mauro,
I've rebased our
Em 14-01-2011 12:51, Patrick Boettcher escreveu:
> Hi Mauro,
>
> if it is not too late, here is a pull request for some new devices from
> DiBcom. It would be nice to have it in 2.6.38-rc1.
>
> Pull from
>
> git://linuxtv.org/pb/media_tree.git staging/for_2.6.38-rc1.dibcom
>
> for
>
> DiB
Antti Palosaari wrote Thu, 03 Dec 2009 13:48:01 -0800
> On 12/03/2009 10:09 PM, Peter Rasmussen wrote:
>
> as mentioned in the welcome email of this list, but it isn't
> apparent to
> me what the status in Linux of using a device based on this chip is?
>
> I have got today device having
After a recent update of xf86-input-evdev and xorg-server, I noticed
that X11 applications did not receive keypresses from the FireDTV
infrared remote control anymore. Instead, the Xorg log featured lots of
"FireDTV remote control: dropping event due to full queue!"
exclamations. The Linux
34 matches
Mail list logo
