Michael Trimarchi wrote:
> Hi,
Hi,
> Sakari Ailus wrote:
>> Hi Michael,
...
>> The frame sizes in our sensor drivers are in width descending order. The
>> selection has been working somehow so far but it's definitely not
>> perfect.
>>
>
> Ok for the frame size but you need to test all the possi
Hey Andy,
On Thu, Feb 4, 2010 at 11:15 PM, Andy Walls wrote:
> Hmmm. The AGC (or static gain level?) of the amplifier in the SAA7113
> before the anti-alias filter may be set too high causing the clipping
> (intermods) there. It may be worth looking at the gain setting for that
> amp.
It's pos
On Thu, 2010-02-04 at 10:24 -0500, Devin Heitmueller wrote:
> On Wed, Feb 3, 2010 at 8:51 PM, Andy Walls wrote:
> > With all that said, if you have a baseband Luma or Chroma signal with
> > strong spurious high frequency components (crappy source, or you're
> > overdriving the front end and gettin
On Mon, 2010-02-01 at 12:50 -0200, Mauro Carvalho Chehab wrote:
> As dvb_dmx_swfilter_packet() is protected by a spinlock, it shouldn't sleep.
> However, vmalloc() may call sleep. So, move the initialization of
> dvb_demux::cnt_storage field to a better place.
>
> Signed-off-by: Mauro Carvalho Che
On Mon, 2010-02-01 at 11:35 -0200, Mauro Carvalho Chehab wrote:
> dvb_dmx_init tries to allocate virtual memory for 2 pointers: filter and feed.
>
> If the second vmalloc fails, filter is freed, but the pointer keeps pointing
> to the old place. Later, when dvb_dmx_release() is called, it will try
Hi Andy,
Am Donnerstag, den 04.02.2010, 21:21 -0500 schrieb Andy Walls:
> On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote:
> > Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls:
> > > On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote:
> > > > Am Dienstag, den 02.02.2010, 0
On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote:
> Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls:
> > On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote:
> > > Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:
> > > > On Tue, 2010-02-02 at 10:11 +0100, Chicken
Stefan Ringel wrote:
> Am 04.02.2010 03:43, schrieb Mauro Carvalho Chehab:
>> Stefan Ringel wrote:
>>
>>> Am 03.02.2010 21:49, schrieb Devin Heitmueller:
>>>
On Wed, Feb 3, 2010 at 3:38 PM, Stefan Ringel
wrote:
> signed-off-by: Stefan Ringel
>
>
I am user of Hauppauge HVR1120, using saa7134 module, and I have problem with
radio FM use in linux mode.
Distribution OpenSuse11.2
Kernel 2.6.31.8-0.1-desktop
Firmware dvb-fe-tda10048-1.0.fw loaded
Analog and Digital Television are OK in both Windows and Linux.
Windows is using Hauppauge WinTV7
m-kariche...@ti.com writes:
> From: Murali Karicheri
>
> This patch adds following changes:-
> 1) add sub device configuration data for TVP5146 used by vpfe capture
> 2) registers platform devices for vpfe_capture, isif and vpss
> 3) defines hardware resources for the devices li
Am 04.02.2010 03:43, schrieb Mauro Carvalho Chehab:
> Stefan Ringel wrote:
>
>> Am 03.02.2010 21:49, schrieb Devin Heitmueller:
>>
>>> On Wed, Feb 3, 2010 at 3:38 PM, Stefan Ringel
>>> wrote:
>>>
>>>
signed-off-by: Stefan Ringel
--- a/drivers/media/dvb/frontends/
(added two more persons to CC, because I think, this discussion can be
interesting for them too)
On Thu, 21 Jan 2010, Valentin Longchamp wrote:
> Guennadi Liakhovetski wrote:
> > On Wed, 20 Jan 2010, Valentin Longchamp wrote:
> >
> > > This prevents the registers to be different to the computed
To save power soc-camera powers subdevices down, when they are not in use,
if this is supported by the platform. However, the V4L standard dictates,
that video nodes shall preserve configuration between uses. This requires
runtime power management, which is implemented by this patch. It allows
Mauro Carvalho Chehab ha scritto:
andrea.amoros...@gmail.com wrote:
Mauro Carvalho Chehab ha scritto:
andrea.amoros...@gmail.com wrote:
So since it is necessary to create a new entry, is there any rules to
follow to choose it?
Just use the existing entry as a
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:Thu Feb 4 19:00:05 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 14138:8b2925e0c59f
gcc version: i686-
Am 04.02.2010 08:25, schrieb Hans Verkuil:
On Thursday 04 February 2010 04:16:03 Andy Walls wrote:
On Thu, 2010-02-04 at 01:18 +0100, Lars Hanisch wrote:
Hi,
I'm writing some code repacking the program stream that ivtv delivers
into a transport stream (BTW: is there existing code for this?)
On Thu, Feb 04, 2010 at 07:33:22PM +0100, Jiri Slaby wrote:
> On 02/04/2010 07:14 PM, Dmitry Torokhov wrote:
> > On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
> > +
> >> +static int dvb_event(struct hid_device *hdev, struct hid_field *field,
> >> + struct hid_usage *usage, _
On 02/04/2010 07:14 PM, Dmitry Torokhov wrote:
> On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
> +
>> +static int dvb_event(struct hid_device *hdev, struct hid_field *field,
>> +struct hid_usage *usage, __s32 value)
>> +{
>> +/* we won't get a "key up" event */
>> +
On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
+
> +static int dvb_event(struct hid_device *hdev, struct hid_field *field,
> + struct hid_usage *usage, __s32 value)
> +{
> + /* we won't get a "key up" event */
> + if (value) {
> + input_event(field->hid
Pekka Sarnila wrote:
> The problem here is that at least afatech ir receiver has the ir code to
> key code build in, so trough HID you can use only the remote whose ir to
> key translate table has been loaded to the aftech device. Unless that
> can be easily controlled by the user HID is no good f
On Wed, Feb 3, 2010 at 8:51 PM, Andy Walls wrote:
> With all that said, if you have a baseband Luma or Chroma signal with
> strong spurious high frequency components (crappy source, or you're
> overdriving the front end and getting intermods), then keep the
> anti-alias filter turned on as the ass
Hi,
Sakari Ailus wrote:
Hi Michael,
Michael Trimarchi wrote:
Aguirre, Sergio wrote:
...
So, if I got you right, you're saying that, there should be priorities
for sensor baseformats, depending on the preference specified
somewhere in the boardfile?
Yes, that is the idea. Try to provide a be
Mauro Carvalho Chehab wrote:
Pekka Sarnila wrote:
The problem using vendor class is that there is no standard. Each vendor
can define its own way using endpoints (and has done so e.g Logitech
joysticks). Thus each usb ir receiver must have its own specific driver.
However then you get the raw
Jarod Wilson wrote:
> On 02/04/2010 08:41 AM, Mauro Carvalho Chehab wrote:
>> Jiri Slaby wrote:
>>> On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
> I have 2 dvb-t receivers and both of them need fullspeed quirk.
> Further
> disable_rc_polling (a dvb_usb module parameter) must be
Hi Michael,
Michael Trimarchi wrote:
> Aguirre, Sergio wrote:
...
>> So, if I got you right, you're saying that, there should be priorities
>> for sensor baseformats, depending on the preference specified
>> somewhere in the boardfile?
>
> Yes, that is the idea. Try to provide a better patch late
Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls:
> On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote:
> > Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:
> > > On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote:
> > > > Am Montag, den 01.02.2010, 21:00 -0500 sch
On 02/04/2010 08:41 AM, Mauro Carvalho Chehab wrote:
Jiri Slaby wrote:
On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
disable_rc_polling (a dvb_usb module parameter) must be set to not get
doubled characters now. And
Jiri Slaby wrote:
> On 02/04/2010 02:41 PM, Mauro Carvalho Chehab wrote:
>> The point is that it is better to name the function right since the
>> beginning.
>
> Sorry, I misunderstood you for the first time. It's .event member of
> hid_driver. Hence I named it dvb_event (or now rc_event or whate
Yes, my comment maybe criticizes more the basic architectural structure
of usb putting it's own work up to higher layer. The only practical
thing is that, if there is a non-HID device suffering from that
FULLSPEED problem, the quirk won't help it. Anyway in current kernel
structure usb layer do
Pekka Sarnila wrote:
> The problem using vendor class is that there is no standard. Each vendor
> can define its own way using endpoints (and has done so e.g Logitech
> joysticks). Thus each usb ir receiver must have its own specific driver.
> However then you get the raw ir codes. When using HID
On 02/04/2010 02:41 PM, Mauro Carvalho Chehab wrote:
> The point is that it is better to name the function right since the beginning.
Sorry, I misunderstood you for the first time. It's .event member of
hid_driver. Hence I named it dvb_event (or now rc_event or whatever).
The function may contain
Jiri Slaby wrote:
> On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
>>> I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
>>> disable_rc_polling (a dvb_usb module parameter) must be set to not get
>>> doubled characters now. And then, it works like a charm.
>> Module para
On Thu, 4 Feb 2010, Pekka Sarnila wrote:
> The FULLSPEED thing is really not ir receiver specific problem. It can
> happen with any device with interrupt endpoint. That's the reason why I
> placed the quirk to HID driver.
>
> However even the HID driver is logically a wrong place. Really it sho
Well the thing is that this device (afatech) offers two different ways
to read the remote: vendor class bulk endpoint (0/81, used afatech
driver) and HID class interrupt endpoint (1/83, seen as an ordinary usb
keyboard by the usb/hid system). When I used unmodified kernel (with new
firmware) bo
On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote:
> Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls:
> > On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote:
> > > Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls:
> > > > On Mon, 2010-02-01 at 07:41 -0500, Andy Walls
On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
>> I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
>> disable_rc_polling (a dvb_usb module parameter) must be set to not get
>> doubled characters now. And then, it works like a charm.
>
> Module parameters always bothers
Hi Yoichi,
Yoichi Yuasa wrote:
> Signed-off-by: Yoichi Yuasa
> ---
> drivers/media/IR/ir-keytable.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
> index b521ed9..44501d9 100644
> --- a/drivers/me
Hi Richard,
On Thu, Feb 04, 2010 at 12:18:52PM +0100, Richard Röjfors wrote:
> The timberdale FPGA is found on the Intel in-Vehicle Infotainment reference
> board
> russelville.
>
> The driver is a PCI driver which chunks up the I/O memory and distributes
> interrupts
> to a number of platform
Huang Shijie wrote:
>
>> No, I don't meant that.
>>
>> The differences of FM radio standards are basically the preemphasis
>> and the
>> frequency ranges.
>>
>> For frequency ranges, V4L2_TUNER_RADIO allows specifying the
>> maximum/minimum values.
>>
>> For preemphasis, you should implement V4L2_
Jiri Slaby wrote:
> On 01/26/2010 02:08 PM, Jiri Kosina wrote:
>>> In my understanding the cause of the remote problem is chipset bug which
>>> sets
>>> USB2.0 polling interval to 4096ms. Therefore HID remote does not work at all
>>> or starts repeating. It is possible to implement remote as polli
The timberdale FPGA is found on the Intel in-Vehicle Infotainment reference
board
russelville.
The driver is a PCI driver which chunks up the I/O memory and distributes
interrupts
to a number of platform devices for each IP inside the FPGA.
Signed-off-by: Richard Röjfors
---
diff --git a/driv
Hi,
To follow is the timberdale patch (again), to sort out the merging as pointed
out by Mauro and Samuel.
--Richard
--
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/maj
On 01/26/2010 02:08 PM, Jiri Kosina wrote:
>> In my understanding the cause of the remote problem is chipset bug which sets
>> USB2.0 polling interval to 4096ms. Therefore HID remote does not work at all
>> or starts repeating. It is possible to implement remote as polling from the
>> driver which
Igor M. Liplianin wrote:
On 3 февраля 2010 00:07:36 Nameer Kazzaz wrote:
Nameer Kazzaz wrote:
Igor M. Liplianin wrote:
On 2 февраля 2010 17:21:46 Nameer Kazzaz wrote:
Hi Igor,
What do you think ? if I can help you solve this, let me know
what I
can do.
Thanks
Name
Hi Alan,
On Tue, Dec 15, 2009 at 12:07:43PM -0200, Alan Carvalho de Assis wrote:
> Please note: I just get it compiling and loaded correctly on the
> mainline kernel.
>
> If you have a board powered by i.MX27 and with a camera supported by
> soc_camera driver, I will be glad case you can do a try
On Wed, Feb 03, 2010 at 05:23:57PM +, Mauro Carvalho Chehab wrote:
> > Ok, thanks again for your understanding. This is definitely material for the
> > next merge window, so I'll merge it into my for-next branch.
>
> The last version of the driver is OK for merging. However, I noticed one
> i
No, I don't meant that.
The differences of FM radio standards are basically the preemphasis and the
frequency ranges.
For frequency ranges, V4L2_TUNER_RADIO allows specifying the maximum/minimum
values.
For preemphasis, you should implement V4L2_CID_TUNE_PREEMPHASIS ctrl. This
CTRL has 3 sta
Hi,
I've posted previously with this subject line [TT-Budget/S-1500 PCI
crashes with current hg (v4l-dvb-cdcf089168df)] and have finally figured
out what is happening.
If you remove your DVB drivers, and reload them, you will get a 100%
reproducible crash with todays HG repository (i.e the b
Hi,
This is a proof-of-concept patch to try to decode the JPEG with PixArt markers.
Please check whether it is working at your side. My experience is that the
number of frames with glitch are reduced.
Regards,
Márton Németh
---
From: Márton Németh
Before trying to decode the image da
49 matches
Mail list logo
