Ralph/Oliver,
As I said before,the DRX-K logic to select DVB-C annex A seems wrong.
Basically, it sets Annex A at setEnvParameters, but this var is not
used anywhere. However, as setParamParameters[2] is not used, I suspect
that this is a typo.
The enclosed patch fixes it, but, on my tests
Hi Devin,
Em 23-07-2011 22:17, Devin Heitmueller escreveu:
The following patch addresses the regression introduced in the cx231xx
driver which stopped the Hauppauge USBLive2 from working.
Confirmed working by both myself and the user who reported the issue
on the KernelLabs blog (Robert
On Sun, Jul 24, 2011 at 8:57 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
I proposed the same fix sometime ago, when Gerd reported this issue
for me. His feedback was that this partially fixed the issue, but
he reported that he also needed to increase the set_power_mode delay
from 5 to
On Sun, Jul 24, 2011 at 9:02 AM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
I don't dispute the possibility that there is some *other* bug that
effects users who have some other value for HZ, but neither I nor the
other use saw it. Without this patch though, the device is broken for
Hi Mauro,
Please pull from my tree for 2 bug fixes patches + support for
control events for the pwc driver. Note that the control events
patch depends upon the patches from hverkuils poll tree
(and those patches are thus also in my tree, but not part of this
pull req).
The following changes
Hi,
Thanks I've added your patch to my gspca/pwc tree and
send an updated pull request to Mauro including your patch.
Regards,
Hans
On 07/23/2011 08:53 PM, Dan Carpenter wrote:
'!' has higher precedence than'' so we need parenthesis here.
Signed-off-by: Dan Carpentererro...@gmail.com
diff
Hello,
s2ram and resume a docked ThinkPad T400 with a plugged in DVB-stick gives
this with the new kernel 3.0 under an almost stable Gentoo linux :
2011-07-24T17:53:34.252+02:00 n22 kernel: PM: resume of devices complete after
2093.868 msecs
2011-07-24T17:53:34.252+02:00 n22 kernel: dvb-usb:
Hi,
On 07/22/2011 05:39 PM, Yordan Kamenov wrote:
Hi Hans,
Hans de Goede wrote:
Hi,
Sorry it took so long, but I've just merged the plugin
support into v4l-utils git. I did make some minor mods /
bugfixes before merging, see the commit message in git.
Regards,
Hans
p.s.
I think we should
23.07.2011 19:09, Mauro Carvalho Chehab wrote:
In this case, it will not be autounmuted after tuning.
Hard to tell about your solution without seeing a patch.
OK, it turns out the automute code is already there,
but it doesn't work. The driver for some reasons
starts the scan on
Em 24-07-2011 14:45, Stas Sergeev escreveu:
23.07.2011 19:09, Mauro Carvalho Chehab wrote:
In this case, it will not be autounmuted after tuning.
Hard to tell about your solution without seeing a patch.
OK, it turns out the automute code is already there,
but it doesn't work. The driver for
Attached is a patch which addresses the issue discussed by Mauro and
Gerd for the -32 errors seen with the Hauppauge USBLive 2.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
cx231xx: Fix power ramp time to be consistent regardless of CONFIG_HZ
From: Devin Heitmueller
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 Jul 24 19:00:38 CEST 2011
git hash:f0a21151140da01c71de636f482f2eddec2840cc
gcc version: i686-linux-gcc (GCC)
24.07.2011 22:36, Mauro Carvalho Chehab wrote:
So, only people that has saa7134 with alsa stream that opted
to wire the saa7134 device to the sound card, and with a strong
interference at the default tunning frequency (400 MHz) would
notice a problem.
No, the strong interference thing have
The attached patch reports the signal lock statistics to userland,
which allows apps to know if there is a signal present even in cases
where it cannot rely on G_TUNER since it won't make calls for such if
the device lacks a tuner.
Devin
--
Devin J. Heitmueller - Kernel Labs
This patch makes the HVR-950q behave consistently with other drivers,
which is to show the signal level as 100% in cases where we have a
signal present but given we are unable to determine an actual signal
level. The old code would set the value to 1, which divided by
65535 is rounded down to 0%.
Hi Jon,
There is a misunderstanding here. This patch will call buf_finish for
some buffers twice. A buffer does not get removed from queued_list
even if it is on the done_list. A buffer gets into the queued_list on
qbuf, gets into the done_list after an operation is finished and is
removed from
Hi Jon and Marek,
On Thu, Jun 30, 2011 at 15:18, Jonathan Corbet cor...@lwn.net wrote:
On Wed, 29 Jun 2011 16:10:45 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:
I do still wonder why this is an issue - why not pass the buffers through
to the driver at VIDIOC_QBUF time? I assume
I have a Microsoft LifeCam VX-3000. My desktop computer has two USB
buses. 4 external ports on one bus in the back of the computer, and 2
external ports on another bus in the front. The webcam only works
properly on the front-facing ports. I'm using the lastest stable
release of the gspca_sonixj
18 matches
Mail list logo
