v4l-dvb - Is it still usable for a distribution ?

v4l-dvb - Is it still usable for a distribution ?

[vdr]

Hello List,

I have a Gentoo based VDR Distribution named Gen2VDR.
As the name said its main application is VDR.
Until kernel 2.6.33 I bundled the v4l-dvb drivers emerged via the gentoo ebuild with my distribution.
Now with kernel 2.6.34 this doesn't work anymore, because v4l-dvb doesn't compile.
Another problem (after fixing the compile issues) is the IR Part of v4l-dvb which includes an Imon module.
This module doesn't provide any lirc devices, so how can this oe be used as an IR device ?
Til now I am using lirc_imon which fit all my needs.

The final question for me:
Does it make any sense anymore to stay with v4l-dvb or do I have to change to the kernel drivers ?
The major disadvantage of the kernel drivers is the fact that I cannot switch to newer dvb drivers, I am stuck to the ones included in the kernel.

Any comments are very welcome

Helmut Auer

Re: v4l-dvb - Is it still usable for a distribution ?

[Mauro Carvalho Chehab]

Em 07-06-2010 08:27, vdr@helmutauer.de escreveu:
> Hello List,
> 
> I have a Gentoo based VDR Distribution named Gen2VDR.
> As the name said its main application is VDR.
> Until kernel 2.6.33 I bundled the v4l-dvb drivers emerged via the gentoo ebuild with my distribution.
> Now with kernel 2.6.34 this doesn't work anymore, because v4l-dvb doesn't compile.

Douglas returned from this 2 week trip abroad and he is backporting the upstream stuff. Yesterday, he
reported to me that the tree is now compiling with 2.6.34.

> Another problem (after fixing the compile issues) is the IR Part of v4l-dvb which includes an Imon module.
> This module doesn't provide any lirc devices, so how can this oe be used as an IR device ?

You don't need lirc to use imon, since it now provides a standard input/event interface. So, the driver 
currently can be used with lirc event interface, or alone.

> Til now I am using lirc_imon which fit all my needs.

Lirc-dev patches are currently being discussed. There are just a few adjustments on it, in order to get it
finally merged. The kernel-userspace interface will likely need a few changes, so you'll likely need to update
lirc after the merge. Better to follow the IR threads at linux-media ML, in order to be in-tune with the changes.

> The final question for me:
> Does it make any sense anymore to stay with v4l-dvb or do I have to change to the kernel drivers ?
> The major disadvantage of the kernel drivers is the fact that I cannot switch to newer dvb drivers, I am stuck to the ones included in the kernel.

Well, this is something that you need to answer by yourself ;)

I don't recommend using a random snapshot of the tree on a distro package, as regressions may
happen during the development period.

Also, the backports are done at best efforts. There are no warranties, no QA and generally no 
tests with real hardware when a backport is done. So, while we hope that the backport will work, 
you may have a bug introduced on the backport stuff that may affect your card, not present
upstream.

IMHO, the better is to just upgrade to the next stable kernel. 

Another alternative is to manually apply on your distro the patches that you need there.
All patches with c/c to stable@kernel.org are bug fixes that needs to be backported to older
(stable) kernels. So, a good hint is to check for those stable patches. Unfortunately, not all
developers remind to add a c/c to stable. I try to do my best to re-tag those emails when
sending the patches upstream, but I generally opt to trust on the developers, since a fix may
apply only at the latest upstream kernel.

Cheers,
Mauro.

Re: v4l-dvb - Is it still usable for a distribution ?

[Jarod Wilson]

On Mon, Jun 7, 2010 at 9:16 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 07-06-2010 08:27, vdr@helmutauer.de escreveu:
...
>> Another problem (after fixing the compile issues) is the IR Part of v4l-dvb which includes an Imon module.
>> This module doesn't provide any lirc devices, so how can this oe be used as an IR device ?
>
> You don't need lirc to use imon, since it now provides a standard input/event interface. So, the driver
> currently can be used with lirc event interface, or alone.

See http://wilsonet.com/jarod/imon_stuff/imon-devinput-lirc/ for the
config I use w/my own imon hardware.

>> Til now I am using lirc_imon which fit all my needs.
>
> Lirc-dev patches are currently being discussed. There are just a few adjustments on it, in order to get it
> finally merged. The kernel-userspace interface will likely need a few changes, so you'll likely need to update
> lirc after the merge. Better to follow the IR threads at linux-media ML, in order to be in-tune with the changes.

I've considered adding lirc_dev support back to the imon driver when
we get it merged, but it really doesn't make a whole lot of sense,
given that the imon devices do all IR decoding in hardware. As long as
the keymap is complete, there's no benefit to wiring up lirc_dev vs.
just using lircd's devinput access method for imon devices.


-- 
Jarod Wilson
jarod@wilsonet.com

Re: v4l-dvb - Is it still usable for a distribution ?

[Helmut Auer]

Hi
> ...
>>> Another problem (after fixing the compile issues) is the IR Part of v4l-dvb which includes an Imon module.
>>> This module doesn't provide any lirc devices, so how can this oe be used as an IR device ?
>>
>> You don't need lirc to use imon, since it now provides a standard input/event interface. So, the driver
>> currently can be used with lirc event interface, or alone.
> 
> See http://wilsonet.com/jarod/imon_stuff/imon-devinput-lirc/ for the
> config I use w/my own imon hardware.
> 
Tanks for the hint !

>>> Til now I am using lirc_imon which fit all my needs.
>>
>> Lirc-dev patches are currently being discussed. There are just a few adjustments on it, in order to get it
>> finally merged. The kernel-userspace interface will likely need a few changes, so you'll likely need to update
>> lirc after the merge. Better to follow the IR threads at linux-media ML, in order to be in-tune with the changes.
> 
> I've considered adding lirc_dev support back to the imon driver when
> we get it merged, but it really doesn't make a whole lot of sense,
> given that the imon devices do all IR decoding in hardware. As long as
> the keymap is complete, there's no benefit to wiring up lirc_dev vs.
> just using lircd's devinput access method for imon devices.
> 
You're right, also inputlircd can do the job.

Is your imon driver fully compatible with the lirc_imon in the display part ?

It would be very helpful to add a parameter for disabling the IR Part, I have many users which
are using only the display part.

-- 
Helmut Auer, helmut@helmutauer.de

Re: v4l-dvb - Is it still usable for a distribution ?

[Jarod Wilson]

On Mon, Jun 7, 2010 at 5:25 PM, Helmut Auer <vdr@helmutauer.de> wrote:
...
> Is your imon driver fully compatible with the lirc_imon in the display part ?

Yes, works perfectly fine with the exact same lcdproc setup here --
both vfd and lcd tested.

> It would be very helpful to add a parameter for disabling the IR Part, I have many users which
> are using only the display part.

Hm. I was going to suggest that if people aren't using the receiver,
there should be no need to disable IR, but I guess someone might want
to use an mce remote w/an mce receiver, and that would have
interesting results if they had one of the imon IR receivers
programmed for mce mode. I'll keep it in mind for the next time I'm
poking at the imon code in depth. Need to finish work on some of the
other new ir/rc bits first (you'll soon be seeing the mceusb driver
ported to the new infra also in v4l-dvb hg, as well as an lirc bridge
driver, which is currently my main focal point).

-- 
Jarod Wilson
jarod@wilsonet.com

Re: v4l-dvb - Is it still usable for a distribution ?

[Helmut Auer]

Hello

>> Is your imon driver fully compatible with the lirc_imon in the display part ?
> 
> Yes, works perfectly fine with the exact same lcdproc setup here --
> both vfd and lcd tested.
> 
fine - I will give it a try !

>> It would be very helpful to add a parameter for disabling the IR Part, I have many users which
>> are using only the display part.
> 
> Hm. I was going to suggest that if people aren't using the receiver,
> there should be no need to disable IR, but I guess someone might want
> to use an mce remote w/an mce receiver, and that would have
> interesting results if they had one of the imon IR receivers
> programmed for mce mode. 
>
Thats what I meant :)

> I'll keep it in mind for the next time I'm
> poking at the imon code in depth. 
Maybe you can use the already available ir_protocol parameter.

-- 
Helmut Auer, helmut@helmutauer.de

Re: v4l-dvb - Is it still usable for a distribution ?

[vdr]

Hi

> > Is your imon driver fully compatible with the lirc_imon in the display part ?
> 
> Yes, works perfectly fine with the exact same lcdproc setup here --
> both vfd and lcd tested.
> 
> > It would be very helpful to add a parameter for disabling the IR Part, I have many users which
> > are using only the display part.
> 
> Hm. I was going to suggest that if people aren't using the receiver,
> there should be no need to disable IR, but I guess someone might want
> to use an mce remote w/an mce receiver, and that would have
> interesting results if they had one of the imon IR receivers
> programmed for mce mode. I'll keep it in mind for the next time I'm
> poking at the imon code in depth. Need to finish work on some of the
> other new ir/rc bits first (you'll soon be seeing the mceusb driver
> ported to the new infra also in v4l-dvb hg, as well as an lirc bridge
> driver, which is currently my main focal point).
> 
Just one more question.
Your driver is missing the ir_protocol parameter. How can I switch between Native Imon and RC-6 ?

Bye
Helmut Auer

Re: v4l-dvb - Is it still usable for a distribution ?

[Mauro Carvalho Chehab]

Em 08-06-2010 05:56, vdr@helmutauer.de escreveu:
> Hi
> 
>>> Is your imon driver fully compatible with the lirc_imon in the display part ?
>>
>> Yes, works perfectly fine with the exact same lcdproc setup here --
>> both vfd and lcd tested.
>>
>>> It would be very helpful to add a parameter for disabling the IR Part, I have many users which
>>> are using only the display part.
>>
>> Hm. I was going to suggest that if people aren't using the receiver,
>> there should be no need to disable IR, but I guess someone might want
>> to use an mce remote w/an mce receiver, and that would have
>> interesting results if they had one of the imon IR receivers
>> programmed for mce mode. I'll keep it in mind for the next time I'm
>> poking at the imon code in depth. Need to finish work on some of the
>> other new ir/rc bits first (you'll soon be seeing the mceusb driver
>> ported to the new infra also in v4l-dvb hg, as well as an lirc bridge
>> driver, which is currently my main focal point).
>>
> Just one more question.
> Your driver is missing the ir_protocol parameter. How can I switch between Native Imon and RC-6 ?

With the IR subsystem, the protocol changes are done via sysfs. The 
ir-keytable program, at v4l-utils git tree, allows controlling the 
enabled protocols and changing the IR keytable.

Cheers,
Mauro.

Re: v4l-dvb - Is it still usable for a distribution ?

[Helmut Auer]

Hello

>> Now with kernel 2.6.34 this doesn't work anymore, because v4l-dvb doesn't compile.
> 
> Douglas returned from this 2 week trip abroad and he is backporting the upstream stuff. Yesterday, he
> reported to me that the tree is now compiling with 2.6.34.
> 
Ok - I also got it compiling, but budget-ci is causing kernel oops (see other ML thread)
> 
>> The final question for me:
>> Does it make any sense anymore to stay with v4l-dvb or do I have to change to the kernel drivers ?
>> The major disadvantage of the kernel drivers is the fact that I cannot switch to newer dvb drivers, I am stuck to the ones included in the kernel.
> 
> Well, this is something that you need to answer by yourself ;)
> 
Thats not what I wanted to hear ;)

> I don't recommend using a random snapshot of the tree on a distro package, as regressions may
> happen during the development period.
> 
> Also, the backports are done at best efforts. There are no warranties, no QA and generally no 
> tests with real hardware when a backport is done. So, while we hope that the backport will work, 
> you may have a bug introduced on the backport stuff that may affect your card, not present
> upstream.
> 
> IMHO, the better is to just upgrade to the next stable kernel. 
> 
Ok -  that what I also thought
formerly v4l-dvb was the bleeding edge and the kernel draivers were about 2 Versions behind.
Now the kernel drivers are often the newer ones, so I have to switch.

> Another alternative is to manually apply on your distro the patches that you need there.
> All patches with c/c to stable@kernel.org are bug fixes that needs to be backported to older
> (stable) kernels. So, a good hint is to check for those stable patches. Unfortunately, not all
> developers remind to add a c/c to stable. I try to do my best to re-tag those emails when
> sending the patches upstream, but I generally opt to trust on the developers, since a fix may
> apply only at the latest upstream kernel.
> 
Thats surely an option, but an average user of my distri can't compile a kernel ;)
Emerging v4l-dvb is much easier ;)

-- 
Helmut Auer, helmut@helmutauer.de

Re: v4l-dvb - Is it still usable for a distribution ?

[Mauro Carvalho Chehab]

Em 07-06-2010 18:33, Helmut Auer escreveu:
> Hello
> 
>>> Now with kernel 2.6.34 this doesn't work anymore, because v4l-dvb doesn't compile.
>>
>> Douglas returned from this 2 week trip abroad and he is backporting the upstream stuff. Yesterday, he
>> reported to me that the tree is now compiling with 2.6.34.
>>
> Ok - I also got it compiling, but budget-ci is causing kernel oops (see other ML thread)

There's already a patch for it at -git, but I suspect that Douglas didn't have time to backport the newer
87 patches that were committed there.

>>> The final question for me:
>>> Does it make any sense anymore to stay with v4l-dvb or do I have to change to the kernel drivers ?
>>> The major disadvantage of the kernel drivers is the fact that I cannot switch to newer dvb drivers, I am stuck to the ones included in the kernel.
>>
>> Well, this is something that you need to answer by yourself ;)
>>
> Thats not what I wanted to hear ;)

:)

>> I don't recommend using a random snapshot of the tree on a distro package, as regressions may
>> happen during the development period.
>>
>> Also, the backports are done at best efforts. There are no warranties, no QA and generally no 
>> tests with real hardware when a backport is done. So, while we hope that the backport will work, 
>> you may have a bug introduced on the backport stuff that may affect your card, not present
>> upstream.
>>
>> IMHO, the better is to just upgrade to the next stable kernel. 
>>
> Ok -  that what I also thought
> formerly v4l-dvb was the bleeding edge and the kernel draivers were about 2 Versions behind.
> Now the kernel drivers are often the newer ones, so I have to switch.

There's still a delay if you're getting the latest stable kernel, that ranges from 1 to 2 versions
for improvements, and a few weeks, for bug fixes. Eventually, you may provide -rc kernels as an 
alternative for those that needs the bleeding edge kernels and are brave enough ;)

>> Another alternative is to manually apply on your distro the patches that you need there.
>> All patches with c/c to stable@kernel.org are bug fixes that needs to be backported to older
>> (stable) kernels. So, a good hint is to check for those stable patches. Unfortunately, not all
>> developers remind to add a c/c to stable. I try to do my best to re-tag those emails when
>> sending the patches upstream, but I generally opt to trust on the developers, since a fix may
>> apply only at the latest upstream kernel.
>>
> Thats surely an option, but an average user of my distri can't compile a kernel ;)
> Emerging v4l-dvb is much easier ;)

Yes, but you may manually apply those patches from my git tree on your distro kernels. User will need to
emerge the kernel package. It will require you a little more work, or some magic script.

You may also keep using the -hg backport tree, but the delay is higher than before, since the
patches go first to -git.

Cheers,
Mauro.