On Monday 13 June 2011 10:13 AM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Monday, June 13, 2011 10:17 AM
To: Hiremath, Vaibhav
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH 2/2] OMAP_VOUT: Create separate file for VRFB related
API's
Hi Vaibhav,
On F
On Mon, 13 Jun 2011, Kassey Lee wrote:
> On Fri, Jun 10, 2011 at 5:16 PM, Guennadi Liakhovetski <
> g.liakhovet...@gmx.de> wrote:
>
> > On Fri, 10 Jun 2011, Kassey Lee wrote:
> >
> > > hi, Guennadi:
> > >
> > > in drivers/media/video/soc_camera.c
> > > static int soc_camera_open(struct
Hello,
On Friday, June 10, 2011 6:29 PM Uwe Kleine-König wrote:
> On Fri, Jun 10, 2011 at 01:50:37PM +0200, Marek Szyprowski wrote:
> > Hello,
> >
> > On Wednesday, June 08, 2011 10:48 PM Uwe Kleine-König wrote:
> >
> > > I'm still debugging my new video overlay device driver. The current
> > > p
> -Original Message-
> From: Taneja, Archit
> Sent: Monday, June 13, 2011 10:17 AM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org
> Subject: Re: [PATCH 2/2] OMAP_VOUT: Create separate file for VRFB related
> API's
>
> Hi Vaibhav,
>
> On Friday 27 May 2011 12:31 PM, Taneja, Arc
Hi Vaibhav,
On Friday 27 May 2011 12:31 PM, Taneja, Archit wrote:
Introduce omap_vout_vrfb.c and omap_vout_vrfb.h, for all VRFB related API's,
making OMAP_VOUT driver independent from VRFB. This is required for OMAP4 DSS,
since OMAP4 doesn't have VRFB block.
Added new enum vout_rotation_type an
On Jun 12, 2011, at 7:03 PM, Xiaofan Chen wrote:
On Mon, Jun 13, 2011 at 5:20 AM, Theodore Kilgore
wrote:
On Sun, 12 Jun 2011, Hans de Goede wrote:
Actually libusb and libgphoto have been using the rebind orginal
driver
functionality of the code for quite a while now,
Oh? I can see that
On Mon, Jun 13, 2011 at 5:20 AM, Theodore Kilgore
wrote:
> On Sun, 12 Jun 2011, Hans de Goede wrote:
>> Actually libusb and libgphoto have been using the rebind orginal driver
>> functionality of the code for quite a while now,
>
> Oh? I can see that libusb is doing that, and I can also see that t
On Mon, Jun 13, 2011 at 02:46:10AM +0300, Antti Palosaari wrote:
> On 06/13/2011 02:01 AM, Juergen Lock wrote:
> > On Mon, Jun 13, 2011 at 01:50:54AM +0300, Antti Palosaari wrote:
> >> On 06/13/2011 01:34 AM, Juergen Lock wrote:
> >>> On Mon, Jun 13, 2011 at 01:24:54AM +0300, Antti Palosaari wrote:
On 06/13/2011 02:01 AM, Juergen Lock wrote:
On Mon, Jun 13, 2011 at 01:50:54AM +0300, Antti Palosaari wrote:
On 06/13/2011 01:34 AM, Juergen Lock wrote:
On Mon, Jun 13, 2011 at 01:24:54AM +0300, Antti Palosaari wrote:
On 06/13/2011 01:15 AM, Juergen Lock wrote:
About the repeating bug you men
On Mon, Jun 13, 2011 at 01:50:54AM +0300, Antti Palosaari wrote:
> On 06/13/2011 01:34 AM, Juergen Lock wrote:
> > On Mon, Jun 13, 2011 at 01:24:54AM +0300, Antti Palosaari wrote:
> >> On 06/13/2011 01:15 AM, Juergen Lock wrote:
> About the repeating bug you mention, are you using latest drive
On 06/13/2011 01:34 AM, Juergen Lock wrote:
On Mon, Jun 13, 2011 at 01:24:54AM +0300, Antti Palosaari wrote:
On 06/13/2011 01:15 AM, Juergen Lock wrote:
About the repeating bug you mention, are you using latest driver
version? I am not aware such bug. There have been this kind of incorrect
beha
On Mon, Jun 13, 2011 at 01:24:54AM +0300, Antti Palosaari wrote:
> On 06/13/2011 01:15 AM, Juergen Lock wrote:
> >> About the repeating bug you mention, are you using latest driver
> >> version? I am not aware such bug. There have been this kind of incorrect
> >> behaviour old driver versions which
I also confirmed it works with s2-liplianin on Debian's 2.6.38-bpo2
kernel without such problems.
Another thing I've tested is to compile the media_tree with the stb6100,
but the problem persist, so it seems it's not related to the component
that both devices share.
Any ideas what might be t
Hi all,
hope you can help me this one, because there's not a whole of info about
similar problems to be found.
I have a Technotrend S2-3200 with CI and on three different distros I
get this
"dvb_ca adaptor 0: PC card did not respond :(
in /var/log/messages.
I guess this is the reason wh
On 06/13/2011 01:15 AM, Juergen Lock wrote:
About the repeating bug you mention, are you using latest driver
version? I am not aware such bug. There have been this kind of incorrect
behaviour old driver versions which are using HID. It was coming from
wrong HID interval.
Also you can dump remote
In article <4df52828.2070...@iki.fi> you write:
>I assume device uses vendor reference design USB ID (15a4:9016 or
>15a4:9015)?
>
Yeah 15a4:9016.
>About the repeating bug you mention, are you using latest driver
>version? I am not aware such bug. There have been this kind of incorrect
>behaviou
Em 12-06-2011 15:09, Hans Verkuil escreveu:
> On Sunday, June 12, 2011 19:27:21 Mauro Carvalho Chehab wrote:
>> Em 12-06-2011 13:07, Hans Verkuil escreveu:
>>> On Sunday, June 12, 2011 16:37:55 Mauro Carvalho Chehab wrote:
Em 12-06-2011 07:59, Hans Verkuil escreveu:
> From: Hans Verkuil
>
Em 12-06-2011 16:41, Hans Verkuil escreveu:
> On Sunday, June 12, 2011 19:08:03 Mauro Carvalho Chehab wrote:
>>> I think in the longer term we need to change the spec so that:
>>>
>>> 1) Opening a radio node no longer switches to radio mode. Instead, you need
>>> to
>>>call VIDIOC_S_FREQUENCY
Hi,
The entry for Channel 44 in Sydney needs to be modified in order to
tune in TVS in Sydney.
The following changes need to be made: (update to frequency)
# D44 UHF35
#T 57850 7MHz 2/3 NONE QAM64 8k 1/32 NONE
T 536625000 7MHz 2/3 NONE QAM64 8k 1/32 NONE
This information was derived from ht
On 2.6.32.5 with s2-liplianin tree this is not observed, i.e. everything
works as expected - the S2-3650 does not cause the TBS device to stutter.
На 12.6.2011 г. 23:27 ч., Doychin Dokov написа:
The same thing happens when the devices are on different USB buses:
Bus 002 Device 004: ID 0b48:300a
On Sun, 12 Jun 2011, Hans de Goede wrote:
> Hi,
>
> On 06/11/2011 06:19 PM, Theodore Kilgore wrote:
> >
> >
> > On Sat, 11 Jun 2011, Hans de Goede wrote:
> >
> > > Hi,
> > >
> > > Given the many comments in this thread, I'm just
> > > going reply to this one, and try to also answer any
> >
I assume device uses vendor reference design USB ID (15a4:9016 or
15a4:9015)?
About the repeating bug you mention, are you using latest driver
version? I am not aware such bug. There have been this kind of incorrect
behaviour old driver versions which are using HID. It was coming from
wrong H
The same thing happens when the devices are on different USB buses:
Bus 002 Device 004: ID 0b48:300a TechnoTrend AG TT-connect S2-3650 CI
Bus 001 Device 007: ID 0b48:3006 TechnoTrend AG TT-connect S-2400 DVB-S
Bus 001 Device 004: ID 734c:5980 TBS Technologies China
When the S2-3650 CI scans, the
That's this tuner:
http://www.lc-power.de/index.php?id=146&L=1
The credit card sized remote more or less works if I set remote=4,
so I added the hash to get it autodetected. (`more or less' there
meaning sometimes buttons are `stuck on repeat', i.e. ir-keytable -t
keeps repeating the sam
On Sunday, June 12, 2011 19:08:03 Mauro Carvalho Chehab wrote:
> > I think in the longer term we need to change the spec so that:
> >
> > 1) Opening a radio node no longer switches to radio mode. Instead, you need
> > to
> >call VIDIOC_S_FREQUENCY for that.
> > 2) When VIDIOC_S_FREQUENCY the
At Sun, 12 Jun 2011 19:48:47 +0200,
Hans Verkuil wrote:
>
> On Sunday, June 12, 2011 18:52:56 Takashi Iwai wrote:
> > At Sat, 11 Jun 2011 15:36:39 +0200,
> > Hans Verkuil wrote:
> > >
> > > On Saturday, June 11, 2011 15:28:59 Ondrej Zary wrote:
> > > > Change locking to allow tea575x-radio device
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 Jun 12 19:00:33 CEST 2011
git hash:f49c454fe981d955d7c3d620f6baa04fb9876adc
gcc version: i686-linux-gcc (GCC) 4.5
On Jun 11, 2011, at 9:38 AM, Mauro Carvalho Chehab wrote:
> Em 03-06-2011 18:28, Jarod Wilson escreveu:
>> This is a custom IR protocol decoder, for the RC-6-ish protocol used by
>> the Microsoft Remote Keyboard.
>>
>> http://www.amazon.com/Microsoft-Remote-Keyboard-Windows-ZV1-4/dp/B000AOAAN
On Sunday, June 12, 2011 19:27:21 Mauro Carvalho Chehab wrote:
> Em 12-06-2011 13:07, Hans Verkuil escreveu:
> > On Sunday, June 12, 2011 16:37:55 Mauro Carvalho Chehab wrote:
> >> Em 12-06-2011 07:59, Hans Verkuil escreveu:
> >>> From: Hans Verkuil
> >>>
> >>> The check_mode function checks wheth
When I plugin that USB receiver into a docked ThinkPad T400, s2ram it and
resume it, I got this line within /var/log/message :
2011-06-12T19:49:10.030+02:00 n22 kernel: firmware[29666]: segfault at 46 ip
b770b0a8 sp bfb21560 error 4 in libc-2.12.2.so[b76af000+156000]
2011-06-12T19:49:10.000+02:00
On Sunday, June 12, 2011 18:52:56 Takashi Iwai wrote:
> At Sat, 11 Jun 2011 15:36:39 +0200,
> Hans Verkuil wrote:
> >
> > On Saturday, June 11, 2011 15:28:59 Ondrej Zary wrote:
> > > Change locking to allow tea575x-radio device to be opened multiple times.
> >
> > Very nice!
> >
> > Signed-off-b
Em 12-06-2011 12:34, Andy Walls escreveu:
> Devin Heitmueller wrote:
>
>> On Sun, Jun 12, 2011 at 9:44 AM, Andy Walls
>> wrote:
>>> BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds
>>> the device nodes open, pinning the cx18-alsa and cx18 modules in
>> kernel.
>>> When kille
Em 12-06-2011 14:27, Mauro Carvalho Chehab escreveu:
> Em 12-06-2011 13:07, Hans Verkuil escreveu:
>> On Sunday, June 12, 2011 16:37:55 Mauro Carvalho Chehab wrote:
>>> Em 12-06-2011 07:59, Hans Verkuil escreveu:
From: Hans Verkuil
The check_mode function checks whether a mode is su
Em 12-06-2011 13:07, Hans Verkuil escreveu:
> On Sunday, June 12, 2011 16:37:55 Mauro Carvalho Chehab wrote:
>> Em 12-06-2011 07:59, Hans Verkuil escreveu:
>>> From: Hans Verkuil
>>>
>>> The check_mode function checks whether a mode is supported. So calling it
>>> supported_mode is more appropriat
Em 12-06-2011 12:46, Hans Verkuil escreveu:
> On Sunday, June 12, 2011 16:36:11 Mauro Carvalho Chehab wrote:
>> Em 12-06-2011 07:59, Hans Verkuil escreveu:
>>> From: Hans Verkuil
>>>
>>> The subdevs are supposed to receive a valid tuner type for the g_frequency
>>> and g/s_tuner subdev ops. Some d
At Sat, 11 Jun 2011 15:36:39 +0200,
Hans Verkuil wrote:
>
> On Saturday, June 11, 2011 15:28:59 Ondrej Zary wrote:
> > Change locking to allow tea575x-radio device to be opened multiple times.
>
> Very nice!
>
> Signed-off-by: Hans Verkuil
Hans, would you apply this and another one via v4l tre
On Sunday, June 12, 2011 16:37:55 Mauro Carvalho Chehab wrote:
> Em 12-06-2011 07:59, Hans Verkuil escreveu:
> > From: Hans Verkuil
> >
> > The check_mode function checks whether a mode is supported. So calling it
> > supported_mode is more appropriate. In addition it returned either 0 or
> > -EI
On Sunday, June 12, 2011 16:36:11 Mauro Carvalho Chehab wrote:
> Em 12-06-2011 07:59, Hans Verkuil escreveu:
> > From: Hans Verkuil
> >
> > The subdevs are supposed to receive a valid tuner type for the g_frequency
> > and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill
> > t
Devin Heitmueller wrote:
>On Sun, Jun 12, 2011 at 9:44 AM, Andy Walls
>wrote:
>> BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds
>> the device nodes open, pinning the cx18-alsa and cx18 modules in
>kernel.
>> When killed, PulseAudio respawns rapidly and reopens the nodes.
>
Hans Verkuil wrote:
>On Sunday, June 12, 2011 16:11:30 Mauro Carvalho Chehab wrote:
>> Em 12-06-2011 09:23, Hans Verkuil escreveu:
>> > That's not unreasonably to do at some point in time, but it doesn't
>actually
>> > answer my question, which is: should the core refuse
>VIDIOC_S_FREQUENCY calls
Em 12-06-2011 07:59, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> The tuner-core subdev requires that the type field of v4l2_tuner is
> filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
> use that yet, so we have to do it manually based on whether the current
> input is ra
Em 12-06-2011 07:59, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> Fix typo: g_tuner should have been s_tuner.
>
> Tested with a bttv card.
OK.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/video/bt8xx/bttv-driver.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
Em 12-06-2011 07:59, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> set_mode is called with t->type, which is the tuner type. Instead, use
> t->mode which is the actual tuner mode (i.e. radio vs tv).
>
> Signed-off-by: Hans Verkuil
Not tested, but it seems ok.
> ---
> drivers/media/video/tu
Em 12-06-2011 07:59, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> Both s_std and s_tuner are broken because set_mode_freq is called before the
> new std (for s_std) and audmode (for s_tuner) are set.
>
> This patch splits set_mode_freq in a set_mode and a set_freq and in s_std
> first calls s
Em 12-06-2011 07:59, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> Get rid of a number of unnecessary tuner_dbg messages by simplifying
> the std fixup function.
Seems ok to me.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/video/tuner-core.c | 92
> +++---
Em 12-06-2011 07:59, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> set_mode_freq currently returns 0 or -EINVAL. But -EINVAL does not
> indicate a error that should be passed on, it just indicates that the
> tuner does not supportthe requested mode. So change the return type to
> bool.
NACK. T
Em 12-06-2011 07:59, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> The check_mode function checks whether a mode is supported. So calling it
> supported_mode is more appropriate. In addition it returned either 0 or
> -EINVAL which suggests that the -EINVAL error should be passed on. However,
>
Em 12-06-2011 07:59, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> The subdevs are supposed to receive a valid tuner type for the g_frequency
> and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill
> this in v4l2-ioctl.c based on whether the device node from which this is
> c
On Sunday, June 12, 2011 16:11:30 Mauro Carvalho Chehab wrote:
> Em 12-06-2011 09:23, Hans Verkuil escreveu:
> > That's not unreasonably to do at some point in time, but it doesn't actually
> > answer my question, which is: should the core refuse VIDIOC_S_FREQUENCY
> > calls
> > where the type doe
Em 12-06-2011 10:57, Devin Heitmueller escreveu:
> On Sun, Jun 12, 2011 at 9:44 AM, Andy Walls wrote:
>> BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds
>> the device nodes open, pinning the cx18-alsa and cx18 modules in kernel.
>> When killed, PulseAudio respawns rapidly and
Em 12-06-2011 09:23, Hans Verkuil escreveu:
> On Sunday, June 12, 2011 13:59:59 Mauro Carvalho Chehab wrote:
>> Em 12-06-2011 08:36, Hans Verkuil escreveu:
>>> On Saturday, June 11, 2011 21:04:57 Mauro Carvalho Chehab wrote:
Em 11-06-2011 14:27, Hans Verkuil escreveu:
> On Saturday, June 1
On Sunday, June 12, 2011 15:44:45 Andy Walls wrote:
> On Sun, 2011-06-12 at 15:23 +0200, Hans Verkuil wrote:
> > On Sunday, June 12, 2011 14:53:06 Andy Walls wrote:
> > > On Sun, 2011-06-12 at 14:30 +0200, Hans Verkuil wrote:
> > > > On Sunday, June 12, 2011 14:13:30 Mauro Carvalho Chehab wrote:
>
On Sun, Jun 12, 2011 at 9:44 AM, Andy Walls wrote:
> BTW, the cx18-alsa module annoys me as a developer. PulseAudio holds
> the device nodes open, pinning the cx18-alsa and cx18 modules in kernel.
> When killed, PulseAudio respawns rapidly and reopens the nodes.
> Unloading cx18 for development p
On Sun, 2011-06-12 at 15:23 +0200, Hans Verkuil wrote:
> On Sunday, June 12, 2011 14:53:06 Andy Walls wrote:
> > On Sun, 2011-06-12 at 14:30 +0200, Hans Verkuil wrote:
> > > On Sunday, June 12, 2011 14:13:30 Mauro Carvalho Chehab wrote:
> > > > Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu:
>
On Sunday, June 12, 2011 14:53:06 Andy Walls wrote:
> On Sun, 2011-06-12 at 14:30 +0200, Hans Verkuil wrote:
> > On Sunday, June 12, 2011 14:13:30 Mauro Carvalho Chehab wrote:
> > > Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu:
> > > > Em 12-06-2011 08:36, Hans Verkuil escreveu:
> > > W
On Sun, 2011-06-12 at 14:30 +0200, Hans Verkuil wrote:
> On Sunday, June 12, 2011 14:13:30 Mauro Carvalho Chehab wrote:
> > Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu:
> > > Em 12-06-2011 08:36, Hans Verkuil escreveu:
> > What about this:
> >
> > Opening /dev/radio effective
On Sun, 2011-06-12 at 12:59 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The subdevs are supposed to receive a valid tuner type for the g_frequency
> and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill
> this in v4l2-ioctl.c based on whether the device node from which
On Sunday, June 12, 2011 14:13:30 Mauro Carvalho Chehab wrote:
> Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu:
> > Em 12-06-2011 08:36, Hans Verkuil escreveu:
> What about this:
>
> Opening /dev/radio effectively starts the radio mode. So if there is TV
> capture in progr
On Sunday, June 12, 2011 13:59:59 Mauro Carvalho Chehab wrote:
> Em 12-06-2011 08:36, Hans Verkuil escreveu:
> > On Saturday, June 11, 2011 21:04:57 Mauro Carvalho Chehab wrote:
> >> Em 11-06-2011 14:27, Hans Verkuil escreveu:
> >>> On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote:
>
Em 12-06-2011 08:59, Mauro Carvalho Chehab escreveu:
> Em 12-06-2011 08:36, Hans Verkuil escreveu:
>> On Saturday, June 11, 2011 21:04:57 Mauro Carvalho Chehab wrote:
>>> Em 11-06-2011 14:27, Hans Verkuil escreveu:
On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote:
> Em 11-06
Em 12-06-2011 08:36, Hans Verkuil escreveu:
> On Saturday, June 11, 2011 21:04:57 Mauro Carvalho Chehab wrote:
>> Em 11-06-2011 14:27, Hans Verkuil escreveu:
>>> On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote:
Em 11-06-2011 10:34, Hans Verkuil escreveu:
> From: Hans Verkui
Hi,
On 06/11/2011 06:19 PM, Theodore Kilgore wrote:
On Sat, 11 Jun 2011, Hans de Goede wrote:
Hi,
Given the many comments in this thread, I'm just
going reply to this one, and try to also answer any
other ones in this mail.
As far as the dual mode camera is involved, I agree
that that shou
On Saturday, June 11, 2011 21:04:57 Mauro Carvalho Chehab wrote:
> Em 11-06-2011 14:27, Hans Verkuil escreveu:
> > On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote:
> >> Em 11-06-2011 10:34, Hans Verkuil escreveu:
> >>> From: Hans Verkuil
> >>>
> >>> According to the spec the tuner
Could you send lsusb -vvd output from that device?
Also remote controller keytable is needed. You can enable remote debug
by modprobe dvb_usb_af9015 debug=2. After that it should output remote
codes to the message.log.
regards,
Antti
On 06/11/2011 12:38 PM, Lopez Lopez wrote:
Hello:
I ha
On 06/12/2011 11:23 AM, Rune Evjen wrote:
I just tested a PCTV 290e device using the latest media_build drivers
in MythTV as a DVB-C device, and ran into some problems.
The adapter is recognized by the em28xx-dvb driver [1] and dmesg
output seems to be correct [2]. I can successfully scan for ch
From: Hans Verkuil
Fix typo: g_tuner should have been s_tuner.
Tested with a bttv card.
Signed-off-by: Hans Verkuil
---
drivers/media/video/bt8xx/bttv-driver.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/vi
From: Hans Verkuil
The subdevs are supposed to receive a valid tuner type for the g_frequency
and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill
this in v4l2-ioctl.c based on whether the device node from which this is
called is a radio node or not.
The spec does not require
From: Hans Verkuil
The tuner-core subdev requires that the type field of v4l2_tuner is
filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
use that yet, so we have to do it manually based on whether the current
input is radio or not.
Tested with my pvrusb2.
Signed-off-by: Han
From: Hans Verkuil
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil
---
drivers/media/video/tuner-core.c | 92 +++---
1 files changed, 27 insertions(+), 65 deletions(-)
diff --git a/drive
From: Hans Verkuil
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in s_std
first calls set_mode, and if that returns true (i.e. the mode is suppor
From: Hans Verkuil
set_mode is called with t->type, which is the tuner type. Instead, use
t->mode which is the actual tuner mode (i.e. radio vs tv).
Signed-off-by: Hans Verkuil
---
drivers/media/video/tuner-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/driver
From: Hans Verkuil
set_mode_freq currently returns 0 or -EINVAL. But -EINVAL does not
indicate a error that should be passed on, it just indicates that the
tuner does not support the requested mode. So change the return type to
bool.
Signed-off-by: Hans Verkuil
---
drivers/media/video/tuner-co
From: Hans Verkuil
The check_mode function checks whether a mode is supported. So calling it
supported_mode is more appropriate. In addition it returned either 0 or
-EINVAL which suggests that the -EINVAL error should be passed on. However,
that's not the case so change the return type to bool.
OK, this is the fourth version of this patch series.
The first five patches are the same as before. But for fixing the g_frequency
and g/s_tuner subdev ops I've decided to follow Mauro's lead and let the core
fill in the tuner type for those ioctls. Trying to do this in the drivers is
a tricky bus
Hi,
I just tested a PCTV 290e device using the latest media_build drivers
in MythTV as a DVB-C device, and ran into some problems.
The adapter is recognized by the em28xx-dvb driver [1] and dmesg
output seems to be correct [2]. I can successfully scan for channels
using the scan utility in dvb-ap
75 matches
Mail list logo
