Remote control at Zolid Hybrid TV Tuner

Remote control at Zolid Hybrid TV Tuner

[Sander Pientka]

Hi,

my Zolid Hybrid TV Tuner has been working like a charm for over two
months now. The remote control is not working though, which is a
showstopper. I don't have experience with remote controls in any kind,
I've heard of LIRC but I would rather choose a more elegant solution,
for instance evdev in X11.

It's wiki page: http://www.linuxtv.org/wiki/index.php/Zolid_Hybrid_TV_Tuner


Thanks in advance!

Re: Remote control at Zolid Hybrid TV Tuner

[hermann pitton]

Hi Sander,

Am Dienstag, den 16.02.2010, 20:16 +0100 schrieb Sander Pientka:
> Hi,
> 
> my Zolid Hybrid TV Tuner has been working like a charm for over two
> months now. The remote control is not working though, which is a
> showstopper. I don't have experience with remote controls in any kind,
> I've heard of LIRC but I would rather choose a more elegant solution,
> for instance evdev in X11.
> 
> It's wiki page: http://www.linuxtv.org/wiki/index.php/Zolid_Hybrid_TV_Tuner

gpio init of your board is reported as 0x240000.

So gpio18/0x40000 is high.

Assuming the IR receiver is plugged during that, unplug it on next boot
and see if gpio init is now only 0x200000.

Cheers,
Hermann

Re: Remote control at Zolid Hybrid TV Tuner

[Sander Pientka]

Hi Hermann,

I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.

Yes, with the IR transmitter not plugged in, the gpio is reported as
00000 by dmesg.

I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.

NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c.

Besides, dmesg outputs a section of error messages I don't understand:

[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041


Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?


--

Sander Pientka

2010/2/17 hermann pitton <hermann-pitton@arcor.de>:
> Hi,
>
> Am Mittwoch, den 17.02.2010, 17:38 +0100 schrieb Sander Pientka:
>> Thanks for your answer. If I understand you correctly, I should
>> disattach the IR receiver, which is a cable with a diode at the end?
>> It is plugged in to a port like the green one for audio.
>
> did you remove the copy to the list by will?
>
> Then I will not complain about top posting here ;)
>
> I think we have only a photo of the frontside of that card.
>
> One line from the IR input connector vanishes to the backside.
>
> If on the backside is not a dedicated IR controller chip, gpio18 might
> be in use for the remote. This gpio is capable of triggering IRQs and is
> also connected to the clock.
>
> On recent Asus saa713x cards it is used for some RC5 protocol derived
> from those IRQs, gpio18 is the up/down button and the only changing gpio
> pin concerning the remote. That pin goes low, if the receiver is not
> plugged on the Asus cards.
>
> Mauro recently added also support for NEC IR protocol also on that gpio.
>
> You should be able to track rc5 and nec support from the mercurial/cvs
> interface or from the lists. Maybe it gets you started.
>
> Cheers,
> Hermann
>
>> 2010/2/17 hermann pitton <hermann-pitton@arcor.de>:
>> > Hi Sander,
>> >
>> > Am Dienstag, den 16.02.2010, 20:16 +0100 schrieb Sander Pientka:
>> >> Hi,
>> >>
>> >> my Zolid Hybrid TV Tuner has been working like a charm for over two
>> >> months now. The remote control is not working though, which is a
>> >> showstopper. I don't have experience with remote controls in any kind,
>> >> I've heard of LIRC but I would rather choose a more elegant solution,
>> >> for instance evdev in X11.
>> >>
>> >> It's wiki page: http://www.linuxtv.org/wiki/index.php/Zolid_Hybrid_TV_Tuner
>> >
>> > gpio init of your board is reported as 0x240000.
>> >
>> > So gpio18/0x40000 is high.
>> >
>> > Assuming the IR receiver is plugged during that, unplug it on next boot
>> > and see if gpio init is now only 0x200000.
>> >
>> > Cheers,
>> > Hermann
>> >
>> >
>> >
>
>

Re: Remote control at Zolid Hybrid TV Tuner

[hermann pitton]

Hi Sander,

Am Samstag, den 08.05.2010, 16:12 +0200 schrieb Sander Pientka:
> Hi Hermann,
> 
> I am going to revive this old thread, I completely forgot about it and
> I still want to solve this problem.
> 
> Yes, with the IR transmitter not plugged in, the gpio is reported as
> 00000 by dmesg.
> 
> I am aware there is a picture of the backside missing on the wiki, I
> will try to make one a.s.a.p.
> 
> NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c.
> 
> Besides, dmesg outputs a section of error messages I don't understand:
> 
> [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
> i2c_transfer returned: -5
> [ 1585.548229] tda18271_toggle_output: error -5 on line 47
> [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
> i2c_transfer returned: -5
> [ 1585.720129] tda18271_init: error -5 on line 826
> [ 1585.720136] tda18271_tune: error -5 on line 904
> [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
> [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
> i2c_transfer returned: -5
> [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
> i2c_transfer returned: -5
> [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
> i2c_transfer returned: -5
> [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
> [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
> 
> 
> Do you have any idea about the origin of these errors? Do you think
> they affect the IR functionality?
> 

you are still welcome with such delayed reports.

But I don't have any influence anymore, how such are treated.

For the tda18271 stuff, you must be on latest and Michael Krufky should
take it on.

For to be on latest, I also can't give any advice anymore.

For the IR/remote stuff, try with Mauro and all others working through.

Cheers,
Hermann

> --
> 
> Sander Pientka
> 
> 2010/2/17 hermann pitton <hermann-pitton@arcor.de>:
> > Hi,
> >
> > Am Mittwoch, den 17.02.2010, 17:38 +0100 schrieb Sander Pientka:
> >> Thanks for your answer. If I understand you correctly, I should
> >> disattach the IR receiver, which is a cable with a diode at the end?
> >> It is plugged in to a port like the green one for audio.
> >
> > did you remove the copy to the list by will?
> >
> > Then I will not complain about top posting here ;)
> >
> > I think we have only a photo of the frontside of that card.
> >
> > One line from the IR input connector vanishes to the backside.
> >
> > If on the backside is not a dedicated IR controller chip, gpio18 might
> > be in use for the remote. This gpio is capable of triggering IRQs and is
> > also connected to the clock.
> >
> > On recent Asus saa713x cards it is used for some RC5 protocol derived
> > from those IRQs, gpio18 is the up/down button and the only changing gpio
> > pin concerning the remote. That pin goes low, if the receiver is not
> > plugged on the Asus cards.
> >
> > Mauro recently added also support for NEC IR protocol also on that gpio.
> >
> > You should be able to track rc5 and nec support from the mercurial/cvs
> > interface or from the lists. Maybe it gets you started.
> >
> > Cheers,
> > Hermann
> >
> >> 2010/2/17 hermann pitton <hermann-pitton@arcor.de>:
> >> > Hi Sander,
> >> >
> >> > Am Dienstag, den 16.02.2010, 20:16 +0100 schrieb Sander Pientka:
> >> >> Hi,
> >> >>
> >> >> my Zolid Hybrid TV Tuner has been working like a charm for over two
> >> >> months now. The remote control is not working though, which is a
> >> >> showstopper. I don't have experience with remote controls in any kind,
> >> >> I've heard of LIRC but I would rather choose a more elegant solution,
> >> >> for instance evdev in X11.
> >> >>
> >> >> It's wiki page: http://www.linuxtv.org/wiki/index.php/Zolid_Hybrid_TV_Tuner
> >> >
> >> > gpio init of your board is reported as 0x240000.
> >> >
> >> > So gpio18/0x40000 is high.
> >> >
> >> > Assuming the IR receiver is plugged during that, unplug it on next boot
> >> > and see if gpio init is now only 0x200000.
> >> >
> >> > Cheers,
> >> > Hermann
> >> >
> >> >
> >> >
> >
> >

Re: Remote control at Zolid Hybrid TV Tuner

[Mauro Carvalho Chehab]

Sander Pientka wrote:
> Hi Hermann,
> 
> I am going to revive this old thread, I completely forgot about it and
> I still want to solve this problem.
> 
> Yes, with the IR transmitter not plugged in, the gpio is reported as
> 00000 by dmesg.
> 
> I am aware there is a picture of the backside missing on the wiki, I
> will try to make one a.s.a.p.
> 
> NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c.
> 
> Besides, dmesg outputs a section of error messages I don't understand:
> 
> [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
> i2c_transfer returned: -5
> [ 1585.548229] tda18271_toggle_output: error -5 on line 47
> [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
> i2c_transfer returned: -5
> [ 1585.720129] tda18271_init: error -5 on line 826
> [ 1585.720136] tda18271_tune: error -5 on line 904
> [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
> [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
> i2c_transfer returned: -5
> [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
> i2c_transfer returned: -5
> [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
> i2c_transfer returned: -5
> [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
> [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
> 
> 
> Do you have any idea about the origin of these errors? Do you think
> they affect the IR functionality?

The above errors won't change anything at IR side. For IR, the better approach
is to start using raw_decode mode. I've enabled it only for Avermedia M135A, 
since this is the board I'm using at the IR refactoring tests, but the same approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For GPIO18,
all you need is to use something like:

        case SAA7134_BOARD_AVERMEDIA_M135A:
                ir_codes     = RC_MAP_AVERMEDIA_M135A_RM_JX;
                mask_keydown = 0x0040000;
                mask_keyup   = 0x0040000;
                mask_keycode = 0xffff;
                raw_decode   = 1;
                break;

(Of course, replacing the board name by your board name (SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write one table for
the IR that were shipped with your board.

To do that, you'll need to enable debug at ir_core (modprobe ir_core debug=1), and type every
key on your keyboard, associating the scancode number with a key name. See http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of the most comon keycodes.

For example, pressing the power button of an IR I have here (for Leadtek PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300

All I need to do is to write a new keymap:

add a new media/rc-map.h


 as, for example:
	drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:

static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
	{ 0x300, KEY_POWER2 },

for every key that it is there. Then, add the new file at drivers/media/IR/keymaps/Makefile.

I've tried to summarize the above patches on a change I just did at the wiki page. Feel 
free to improve it, if needed.

Cheers,
Mauro

Re: Remote control at Zolid Hybrid TV Tuner

[hermann pitton]

Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
> Sander Pientka wrote:
> > Hi Hermann,
> > 
> > I am going to revive this old thread, I completely forgot about it and
> > I still want to solve this problem.
> > 
> > Yes, with the IR transmitter not plugged in, the gpio is reported as
> > 00000 by dmesg.
> > 
> > I am aware there is a picture of the backside missing on the wiki, I
> > will try to make one a.s.a.p.
> > 
> > NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c.
> > 
> > Besides, dmesg outputs a section of error messages I don't understand:
> > 
> > [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
> > i2c_transfer returned: -5
> > [ 1585.548229] tda18271_toggle_output: error -5 on line 47
> > [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
> > i2c_transfer returned: -5
> > [ 1585.720129] tda18271_init: error -5 on line 826
> > [ 1585.720136] tda18271_tune: error -5 on line 904
> > [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
> > [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
> > i2c_transfer returned: -5
> > [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
> > i2c_transfer returned: -5
> > [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
> > i2c_transfer returned: -5
> > [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
> > [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
> > 
> > 
> > Do you have any idea about the origin of these errors? Do you think
> > they affect the IR functionality?
> 
> The above errors won't change anything at IR side. For IR, the better approach
> is to start using raw_decode mode. I've enabled it only for Avermedia M135A, 
> since this is the board I'm using at the IR refactoring tests, but the same approach
> should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For GPIO18,
> all you need is to use something like:
> 
>         case SAA7134_BOARD_AVERMEDIA_M135A:
>                 ir_codes     = RC_MAP_AVERMEDIA_M135A_RM_JX;
>                 mask_keydown = 0x0040000;
>                 mask_keyup   = 0x0040000;
>                 mask_keycode = 0xffff;
>                 raw_decode   = 1;
>                 break;
> 
> (Of course, replacing the board name by your board name (SAA7134_BOARD_ZOLID_HYBRID_PCI?),
> and pointing to the proper ir_codes table. You'll likely need to write one table for
> the IR that were shipped with your board.
> 
> To do that, you'll need to enable debug at ir_core (modprobe ir_core debug=1), and type every
> key on your keyboard, associating the scancode number with a key name. See http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of the most comon keycodes.
> 
> For example, pressing the power button of an IR I have here (for Leadtek PVR3000), it
> gives this info at the dmesg log:
> ir_nec_decode: NEC scancode 0x0300
> 
> All I need to do is to write a new keymap:
> 
> add a new media/rc-map.h
> 
> 
>  as, for example:
> 	drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
> (copying one of the existing keymaps) and add:
> 
> static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
> 	{ 0x300, KEY_POWER2 },
> 
> for every key that it is there. Then, add the new file at drivers/media/IR/keymaps/Makefile.
> 
> I've tried to summarize the above patches on a change I just did at the wiki page. Feel 
> free to improve it, if needed.
> 
> Cheers,
> Mauro

Hi Mauro,

what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.

To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.

Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?

We are out of sync else.

Cheers,
Hermann

Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

[Mauro Carvalho Chehab]

hermann pitton wrote:
> Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
>> Sander Pientka wrote:
>>> Hi Hermann,
>>>
>>> I am going to revive this old thread, I completely forgot about it and
>>> I still want to solve this problem.
>>>
>>> Yes, with the IR transmitter not plugged in, the gpio is reported as
>>> 00000 by dmesg.
>>>
>>> I am aware there is a picture of the backside missing on the wiki, I
>>> will try to make one a.s.a.p.
>>>
>>> NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c.
>>>
>>> Besides, dmesg outputs a section of error messages I don't understand:
>>>
>>> [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
>>> i2c_transfer returned: -5
>>> [ 1585.548229] tda18271_toggle_output: error -5 on line 47
>>> [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
>>> i2c_transfer returned: -5
>>> [ 1585.720129] tda18271_init: error -5 on line 826
>>> [ 1585.720136] tda18271_tune: error -5 on line 904
>>> [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
>>> [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
>>> i2c_transfer returned: -5
>>> [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
>>> i2c_transfer returned: -5
>>> [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
>>> i2c_transfer returned: -5
>>> [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
>>> [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
>>>
>>>
>>> Do you have any idea about the origin of these errors? Do you think
>>> they affect the IR functionality?
>> The above errors won't change anything at IR side. For IR, the better approach
>> is to start using raw_decode mode. I've enabled it only for Avermedia M135A, 
>> since this is the board I'm using at the IR refactoring tests, but the same approach
>> should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For GPIO18,
>> all you need is to use something like:
>>
>>         case SAA7134_BOARD_AVERMEDIA_M135A:
>>                 ir_codes     = RC_MAP_AVERMEDIA_M135A_RM_JX;
>>                 mask_keydown = 0x0040000;
>>                 mask_keyup   = 0x0040000;
>>                 mask_keycode = 0xffff;
>>                 raw_decode   = 1;
>>                 break;
>>
>> (Of course, replacing the board name by your board name (SAA7134_BOARD_ZOLID_HYBRID_PCI?),
>> and pointing to the proper ir_codes table. You'll likely need to write one table for
>> the IR that were shipped with your board.
>>
>> To do that, you'll need to enable debug at ir_core (modprobe ir_core debug=1), and type every
>> key on your keyboard, associating the scancode number with a key name. See http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of the most comon keycodes.
>>
>> For example, pressing the power button of an IR I have here (for Leadtek PVR3000), it
>> gives this info at the dmesg log:
>> ir_nec_decode: NEC scancode 0x0300
>>
>> All I need to do is to write a new keymap:
>>
>> add a new media/rc-map.h
>>
>>
>>  as, for example:
>> 	drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
>> (copying one of the existing keymaps) and add:
>>
>> static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
>> 	{ 0x300, KEY_POWER2 },
>>
>> for every key that it is there. Then, add the new file at drivers/media/IR/keymaps/Makefile.
>>
>> I've tried to summarize the above patches on a change I just did at the wiki page. Feel 
>> free to improve it, if needed.
>>
>> Cheers,
>> Mauro
> 
> Hi Mauro,
> 
> what I did try to point to, with some sarcasm involved, is that I can't
> advice any v4l-dvb as reference anymore.
> 
> To start to look such up, with all patches involved, per user, who
> likely does not know himself on what he exactly is, find the last
> building kernel for him then, guess on pending pull requests that time,
> and so on, is not making any sense for me.
> 
> Should we not state, that is nothing against Douglas at all or Hans with
> his build reports, please be on latest .rc and git to test anything we
> have around?
> 
> We are out of sync else.

Hermann,

Sorry, but, sometimes, it is very hard to understand your English. I'm suspecting
that you're referring to the sync between hg and git.

Short answer:
============

 - AFAIK, Douglas finished syncing the trees at the night of May, 12.

 - Developers primary reference tree:
	http://git.linuxtv.org/v4l-dvb.git

 - Backport tree:
	http://linuxtv.org/hg/v4l-dvb

   As the backport is manual, some delay is expected at the backport tree. Also,
backports are made at the best efforts basis. So, nobody can warrant that the
drivers will behave correctly with an old kernel. Also, eventually, the backport tree
can break when compiled with an older kernel.

   Developers are encouraged to use git for development, but patches and pull
requests against the backport tree are accepted.

Long answer:
===========

As I have about 100 pending patches at Patchwork, plus 4 or 5 pull requests not
handled yet, mercurial tree will be soon out of sync. I'll try to merge most of the
pending stuff during this weekend.

The main developers reference is -git. We merge all patches there. 
So, new stuff arrives there before being backported.

That's said, we should be using git since 2.6.12, together with the kernel 
community. By not using it, our merge process became very complex
and it weren't scaling anymore. It is also impossible to merge the current
embedded patches with -hg, since we would need to keep several arch trees
inside hg, properly synchronized, which would make -hg tree very big
and full of hacks.

Due to our late adoption of git on our development trees, we're still
needing to adjust the process. I'll likely need to do some improvements for
the next kernel cycle, since I'm still suffering some merge issues upstream,
that will likely affect developers if I don't adjust the procedures.

The solution will likely be merging at git inside separate branches for separate
topics.

I'm trying to keep one branch (currently, master) with the latest final kernel 
version. For example, if you use it right now, it is the vanilla 2.6.33 kernel, 
plus v4l-dvb new stuff. This allows not only developers to use, but also advanced
users that know how to compile a kernel (that's not that hard: in general,
"make oldconfig && make" is enough, if the distro kernel is not very old).

Unfortunately, I don't have any time anymore to maintain the backport tree. We've
broke our record in terms of number of patches per release at -rc6: almost 
800 patches for linux next, on a shorter kernel development cycle. So, we had about
19 patches committed by day, 7 days by week, plus the ones that needed to be 
re-designed, due to some troubles, plus all architectural discussions we're having
about videobuf, events interface, mem2mem, etc.

I suspect that part of growth on the number of patches is due to the usage of git, as
I'm seeing more upstream kernel hackers sending patches to drivers/media lately.

So, Douglas assumed the maintainership of the hg tree. As all upstream patches
need to be backported, he's likely having a high demand bandwidth, because of the high 
number of patches.

As far as I know (Douglas, please correct me if I'm wrong), he started by
applying patches, testing against a selected number of legacy kernels and publish
after the tests. Also, he needs to identify the origin of a patch before applying
on his tree, to avoid breaking developers tree based on mercurial to require rebasing
after his merge. Life would probably be easier for him if everybody would be generating
patches against git when submitting upstream.

As people complained about the high delay, he decided just a few days ago 
to just sync the tree, and then adding backport patches with the help of the 
community. Of course, this means that the current -hg tree will compile only 
against 2.6.33, until someone backports the tree to the earlier kernels.

I suspect that people will also complain about that. Not sure what strategy would
be the better.

The fact is that, even with -hg, when we were close to the next merge window, the
number of patches tend to increase (as everybody tries to send their code for the
next merge window), and the need for backport increases, as other maintainers are
always improving the kernel ABI's. So, during a period of up to 4 weeks (one or 
two weeks before and the two weeks of the merge window), it would almost certain
that backport support would be broken.

Anyway, it is up to Douglas to define what would be the better way to maintain the
backport tree, as he is the one that is feeling all the pain of backporting
stuff, of course listening to the community feedback. It would be nice if
people could also help him by sending backport patches were needed.

-- 

Cheers,
Mauro

Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

[hermann pitton]

Am Donnerstag, den 13.05.2010, 01:49 -0300 schrieb Mauro Carvalho
Chehab:
> hermann pitton wrote:
> > Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
> >> Sander Pientka wrote:
> >>> Hi Hermann,
> >>>
> >>> I am going to revive this old thread, I completely forgot about it and
> >>> I still want to solve this problem.
> >>>
> >>> Yes, with the IR transmitter not plugged in, the gpio is reported as
> >>> 00000 by dmesg.
> >>>
> >>> I am aware there is a picture of the backside missing on the wiki, I
> >>> will try to make one a.s.a.p.
> >>>
> >>> NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c.
> >>>
> >>> Besides, dmesg outputs a section of error messages I don't understand:
> >>>
> >>> [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
> >>> i2c_transfer returned: -5
> >>> [ 1585.548229] tda18271_toggle_output: error -5 on line 47
> >>> [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
> >>> i2c_transfer returned: -5
> >>> [ 1585.720129] tda18271_init: error -5 on line 826
> >>> [ 1585.720136] tda18271_tune: error -5 on line 904
> >>> [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
> >>> [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
> >>> i2c_transfer returned: -5
> >>> [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
> >>> i2c_transfer returned: -5
> >>> [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
> >>> i2c_transfer returned: -5
> >>> [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
> >>> [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
> >>>
> >>>
> >>> Do you have any idea about the origin of these errors? Do you think
> >>> they affect the IR functionality?
> >> The above errors won't change anything at IR side. For IR, the better approach
> >> is to start using raw_decode mode. I've enabled it only for Avermedia M135A, 
> >> since this is the board I'm using at the IR refactoring tests, but the same approach
> >> should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For GPIO18,
> >> all you need is to use something like:
> >>
> >>         case SAA7134_BOARD_AVERMEDIA_M135A:
> >>                 ir_codes     = RC_MAP_AVERMEDIA_M135A_RM_JX;
> >>                 mask_keydown = 0x0040000;
> >>                 mask_keyup   = 0x0040000;
> >>                 mask_keycode = 0xffff;
> >>                 raw_decode   = 1;
> >>                 break;
> >>
> >> (Of course, replacing the board name by your board name (SAA7134_BOARD_ZOLID_HYBRID_PCI?),
> >> and pointing to the proper ir_codes table. You'll likely need to write one table for
> >> the IR that were shipped with your board.
> >>
> >> To do that, you'll need to enable debug at ir_core (modprobe ir_core debug=1), and type every
> >> key on your keyboard, associating the scancode number with a key name. See http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of the most comon keycodes.
> >>
> >> For example, pressing the power button of an IR I have here (for Leadtek PVR3000), it
> >> gives this info at the dmesg log:
> >> ir_nec_decode: NEC scancode 0x0300
> >>
> >> All I need to do is to write a new keymap:
> >>
> >> add a new media/rc-map.h
> >>
> >>
> >>  as, for example:
> >> 	drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
> >> (copying one of the existing keymaps) and add:
> >>
> >> static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
> >> 	{ 0x300, KEY_POWER2 },
> >>
> >> for every key that it is there. Then, add the new file at drivers/media/IR/keymaps/Makefile.
> >>
> >> I've tried to summarize the above patches on a change I just did at the wiki page. Feel 
> >> free to improve it, if needed.
> >>
> >> Cheers,
> >> Mauro
> > 
> > Hi Mauro,
> > 
> > what I did try to point to, with some sarcasm involved, is that I can't
> > advice any v4l-dvb as reference anymore.
> > 
> > To start to look such up, with all patches involved, per user, who
> > likely does not know himself on what he exactly is, find the last
> > building kernel for him then, guess on pending pull requests that time,
> > and so on, is not making any sense for me.
> > 
> > Should we not state, that is nothing against Douglas at all or Hans with
> > his build reports, please be on latest .rc and git to test anything we
> > have around?
> > 
> > We are out of sync else.
> 
> Hermann,
> 
> Sorry, but, sometimes, it is very hard to understand your English. I'm suspecting
> that you're referring to the sync between hg and git.
> 
> Short answer:
> ============
> 
>  - AFAIK, Douglas finished syncing the trees at the night of May, 12.
> 
>  - Developers primary reference tree:
> 	http://git.linuxtv.org/v4l-dvb.git
> 
>  - Backport tree:
> 	http://linuxtv.org/hg/v4l-dvb
> 
>    As the backport is manual, some delay is expected at the backport tree. Also,
> backports are made at the best efforts basis. So, nobody can warrant that the
> drivers will behave correctly with an old kernel. Also, eventually, the backport tree
> can break when compiled with an older kernel.
> 
>    Developers are encouraged to use git for development, but patches and pull
> requests against the backport tree are accepted.
> 
> Long answer:
> ===========
> 
> As I have about 100 pending patches at Patchwork, plus 4 or 5 pull requests not
> handled yet, mercurial tree will be soon out of sync. I'll try to merge most of the
> pending stuff during this weekend.
> 
> The main developers reference is -git. We merge all patches there. 
> So, new stuff arrives there before being backported.
> 
> That's said, we should be using git since 2.6.12, together with the kernel 
> community. By not using it, our merge process became very complex
> and it weren't scaling anymore. It is also impossible to merge the current
> embedded patches with -hg, since we would need to keep several arch trees
> inside hg, properly synchronized, which would make -hg tree very big
> and full of hacks.
> 
> Due to our late adoption of git on our development trees, we're still
> needing to adjust the process. I'll likely need to do some improvements for
> the next kernel cycle, since I'm still suffering some merge issues upstream,
> that will likely affect developers if I don't adjust the procedures.
> 
> The solution will likely be merging at git inside separate branches for separate
> topics.
> 
> I'm trying to keep one branch (currently, master) with the latest final kernel 
> version. For example, if you use it right now, it is the vanilla 2.6.33 kernel, 
> plus v4l-dvb new stuff. This allows not only developers to use, but also advanced
> users that know how to compile a kernel (that's not that hard: in general,
> "make oldconfig && make" is enough, if the distro kernel is not very old).
> 
> Unfortunately, I don't have any time anymore to maintain the backport tree. We've
> broke our record in terms of number of patches per release at -rc6: almost 
> 800 patches for linux next, on a shorter kernel development cycle. So, we had about
> 19 patches committed by day, 7 days by week, plus the ones that needed to be 
> re-designed, due to some troubles, plus all architectural discussions we're having
> about videobuf, events interface, mem2mem, etc.
> 
> I suspect that part of growth on the number of patches is due to the usage of git, as
> I'm seeing more upstream kernel hackers sending patches to drivers/media lately.
> 
> So, Douglas assumed the maintainership of the hg tree. As all upstream patches
> need to be backported, he's likely having a high demand bandwidth, because of the high 
> number of patches.
> 
> As far as I know (Douglas, please correct me if I'm wrong), he started by
> applying patches, testing against a selected number of legacy kernels and publish
> after the tests. Also, he needs to identify the origin of a patch before applying
> on his tree, to avoid breaking developers tree based on mercurial to require rebasing
> after his merge. Life would probably be easier for him if everybody would be generating
> patches against git when submitting upstream.
> 
> As people complained about the high delay, he decided just a few days ago 
> to just sync the tree, and then adding backport patches with the help of the 
> community. Of course, this means that the current -hg tree will compile only 
> against 2.6.33, until someone backports the tree to the earlier kernels.
> 
> I suspect that people will also complain about that. Not sure what strategy would
> be the better.
> 
> The fact is that, even with -hg, when we were close to the next merge window, the
> number of patches tend to increase (as everybody tries to send their code for the
> next merge window), and the need for backport increases, as other maintainers are
> always improving the kernel ABI's. So, during a period of up to 4 weeks (one or 
> two weeks before and the two weeks of the merge window), it would almost certain
> that backport support would be broken.
> 
> Anyway, it is up to Douglas to define what would be the better way to maintain the
> backport tree, as he is the one that is feeling all the pain of backporting
> stuff, of course listening to the community feedback. It would be nice if
> people could also help him by sending backport patches were needed.
> 

Hi Mauro, Sander, Douglas,

I can see all that.

But the question was very simple.

What revision of v4l-dvb I should have suggested to Sander on the day of
his request to work further on it?

I don't know, without very detailed input and a lot of looking up and
broken build as next condition. So I do suggest to go to .rc and latest
git. De facto it happened already.

If this is within Sander's plans, not only Devin did list some
shortcomings already for being on latest, I doubt. And a well maintained
2.6.18 seems to have still many fans :)

I also can see, on a first look, that Sander is not in sync with
Michael's latest.

More patches still come in from older stuff. (Compro T750/T750F, we run
into detection troubles again)

Until Douglas should complain, I'll stay quiet, but I guess it will turn
into some "stable" mercurial v4l-dvb release every few weeks and I doubt
to be interested to dig around in such and compare.

Gerd did hold the v4l backward compat on 2.4.x during the introduction
of v4l2, xawtv and nvrec have been the only working v4l2 apps for long,
tvtime followed then, somehow forced, and much later mplayer, with lots
of cries in between.

Full v4l1 compat, it always had bugs like the mute ioctl on saa713x, is
broken anyway since long on hybrid tuners, see fmtools on recent tuners.

I always was for it, to have the broadest possible testing base, but if
there is no clear fall back anymore, I luckily can miss support for a
few cards the OEMs never did care about.

Cheers,
Hermann
 





Cheers,
Hermann

Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

[Mauro Carvalho Chehab]

hermann pitton wrote:
> Am Donnerstag, den 13.05.2010, 01:49 -0300 schrieb Mauro Carvalho
> Chehab:
>> hermann pitton wrote:
>>> Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
>>>> Sander Pientka wrote:
>>>>> Hi Hermann,
>>>>>
>>>>> I am going to revive this old thread, I completely forgot about it and
>>>>> I still want to solve this problem.
>>>>>
>>>>> Yes, with the IR transmitter not plugged in, the gpio is reported as
>>>>> 00000 by dmesg.
>>>>>
>>>>> I am aware there is a picture of the backside missing on the wiki, I
>>>>> will try to make one a.s.a.p.
>>>>>
>>>>> NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c.
>>>>>
>>>>> Besides, dmesg outputs a section of error messages I don't understand:
>>>>>
>>>>> [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
>>>>> i2c_transfer returned: -5
>>>>> [ 1585.548229] tda18271_toggle_output: error -5 on line 47
>>>>> [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
>>>>> i2c_transfer returned: -5
>>>>> [ 1585.720129] tda18271_init: error -5 on line 826
>>>>> [ 1585.720136] tda18271_tune: error -5 on line 904
>>>>> [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
>>>>> [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
>>>>> i2c_transfer returned: -5
>>>>> [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
>>>>> i2c_transfer returned: -5
>>>>> [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
>>>>> i2c_transfer returned: -5
>>>>> [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
>>>>> [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
>>>>>
>>>>>
>>>>> Do you have any idea about the origin of these errors? Do you think
>>>>> they affect the IR functionality?
>>>> The above errors won't change anything at IR side. For IR, the better approach
>>>> is to start using raw_decode mode. I've enabled it only for Avermedia M135A, 
>>>> since this is the board I'm using at the IR refactoring tests, but the same approach
>>>> should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For GPIO18,
>>>> all you need is to use something like:
>>>>
>>>>         case SAA7134_BOARD_AVERMEDIA_M135A:
>>>>                 ir_codes     = RC_MAP_AVERMEDIA_M135A_RM_JX;
>>>>                 mask_keydown = 0x0040000;
>>>>                 mask_keyup   = 0x0040000;
>>>>                 mask_keycode = 0xffff;
>>>>                 raw_decode   = 1;
>>>>                 break;
>>>>
>>>> (Of course, replacing the board name by your board name (SAA7134_BOARD_ZOLID_HYBRID_PCI?),
>>>> and pointing to the proper ir_codes table. You'll likely need to write one table for
>>>> the IR that were shipped with your board.
>>>>
>>>> To do that, you'll need to enable debug at ir_core (modprobe ir_core debug=1), and type every
>>>> key on your keyboard, associating the scancode number with a key name. See http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of the most comon keycodes.
>>>>
>>>> For example, pressing the power button of an IR I have here (for Leadtek PVR3000), it
>>>> gives this info at the dmesg log:
>>>> ir_nec_decode: NEC scancode 0x0300
>>>>
>>>> All I need to do is to write a new keymap:
>>>>
>>>> add a new media/rc-map.h
>>>>
>>>>
>>>>  as, for example:
>>>> 	drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
>>>> (copying one of the existing keymaps) and add:
>>>>
>>>> static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
>>>> 	{ 0x300, KEY_POWER2 },
>>>>
>>>> for every key that it is there. Then, add the new file at drivers/media/IR/keymaps/Makefile.
>>>>
>>>> I've tried to summarize the above patches on a change I just did at the wiki page. Feel 
>>>> free to improve it, if needed.
>>>>
>>>> Cheers,
>>>> Mauro
>>> Hi Mauro,
>>>
>>> what I did try to point to, with some sarcasm involved, is that I can't
>>> advice any v4l-dvb as reference anymore.
>>>
>>> To start to look such up, with all patches involved, per user, who
>>> likely does not know himself on what he exactly is, find the last
>>> building kernel for him then, guess on pending pull requests that time,
>>> and so on, is not making any sense for me.
>>>
>>> Should we not state, that is nothing against Douglas at all or Hans with
>>> his build reports, please be on latest .rc and git to test anything we
>>> have around?
>>>
>>> We are out of sync else.
>> Hermann,
>>
>> Sorry, but, sometimes, it is very hard to understand your English. I'm suspecting
>> that you're referring to the sync between hg and git.
>>
>> Short answer:
>> ============
>>
>>  - AFAIK, Douglas finished syncing the trees at the night of May, 12.
>>
>>  - Developers primary reference tree:
>> 	http://git.linuxtv.org/v4l-dvb.git
>>
>>  - Backport tree:
>> 	http://linuxtv.org/hg/v4l-dvb
>>
>>    As the backport is manual, some delay is expected at the backport tree. Also,
>> backports are made at the best efforts basis. So, nobody can warrant that the
>> drivers will behave correctly with an old kernel. Also, eventually, the backport tree
>> can break when compiled with an older kernel.
>>
>>    Developers are encouraged to use git for development, but patches and pull
>> requests against the backport tree are accepted.
>>
>> Long answer:
>> ===========
>>
>> As I have about 100 pending patches at Patchwork, plus 4 or 5 pull requests not
>> handled yet, mercurial tree will be soon out of sync. I'll try to merge most of the
>> pending stuff during this weekend.
>>
>> The main developers reference is -git. We merge all patches there. 
>> So, new stuff arrives there before being backported.
>>
>> That's said, we should be using git since 2.6.12, together with the kernel 
>> community. By not using it, our merge process became very complex
>> and it weren't scaling anymore. It is also impossible to merge the current
>> embedded patches with -hg, since we would need to keep several arch trees
>> inside hg, properly synchronized, which would make -hg tree very big
>> and full of hacks.
>>
>> Due to our late adoption of git on our development trees, we're still
>> needing to adjust the process. I'll likely need to do some improvements for
>> the next kernel cycle, since I'm still suffering some merge issues upstream,
>> that will likely affect developers if I don't adjust the procedures.
>>
>> The solution will likely be merging at git inside separate branches for separate
>> topics.
>>
>> I'm trying to keep one branch (currently, master) with the latest final kernel 
>> version. For example, if you use it right now, it is the vanilla 2.6.33 kernel, 
>> plus v4l-dvb new stuff. This allows not only developers to use, but also advanced
>> users that know how to compile a kernel (that's not that hard: in general,
>> "make oldconfig && make" is enough, if the distro kernel is not very old).
>>
>> Unfortunately, I don't have any time anymore to maintain the backport tree. We've
>> broke our record in terms of number of patches per release at -rc6: almost 
>> 800 patches for linux next, on a shorter kernel development cycle. So, we had about
>> 19 patches committed by day, 7 days by week, plus the ones that needed to be 
>> re-designed, due to some troubles, plus all architectural discussions we're having
>> about videobuf, events interface, mem2mem, etc.
>>
>> I suspect that part of growth on the number of patches is due to the usage of git, as
>> I'm seeing more upstream kernel hackers sending patches to drivers/media lately.
>>
>> So, Douglas assumed the maintainership of the hg tree. As all upstream patches
>> need to be backported, he's likely having a high demand bandwidth, because of the high 
>> number of patches.
>>
>> As far as I know (Douglas, please correct me if I'm wrong), he started by
>> applying patches, testing against a selected number of legacy kernels and publish
>> after the tests. Also, he needs to identify the origin of a patch before applying
>> on his tree, to avoid breaking developers tree based on mercurial to require rebasing
>> after his merge. Life would probably be easier for him if everybody would be generating
>> patches against git when submitting upstream.
>>
>> As people complained about the high delay, he decided just a few days ago 
>> to just sync the tree, and then adding backport patches with the help of the 
>> community. Of course, this means that the current -hg tree will compile only 
>> against 2.6.33, until someone backports the tree to the earlier kernels.
>>
>> I suspect that people will also complain about that. Not sure what strategy would
>> be the better.
>>
>> The fact is that, even with -hg, when we were close to the next merge window, the
>> number of patches tend to increase (as everybody tries to send their code for the
>> next merge window), and the need for backport increases, as other maintainers are
>> always improving the kernel ABI's. So, during a period of up to 4 weeks (one or 
>> two weeks before and the two weeks of the merge window), it would almost certain
>> that backport support would be broken.
>>
>> Anyway, it is up to Douglas to define what would be the better way to maintain the
>> backport tree, as he is the one that is feeling all the pain of backporting
>> stuff, of course listening to the community feedback. It would be nice if
>> people could also help him by sending backport patches were needed.
>>
> 
> Hi Mauro, Sander, Douglas,
> 
> I can see all that.
> 
> But the question was very simple.
> 
> What revision of v4l-dvb I should have suggested to Sander on the day of
> his request to work further on it?
> 
> I don't know, without very detailed input and a lot of looking up and
> broken build as next condition. So I do suggest to go to .rc and latest
> git. De facto it happened already.

The most updated version is at git:
	http://git.linuxtv.org/v4l-dvb.git

On most cases, running the latest -hg is equivalent, but, when some major
changes happen (that's the case of the new Remote Controller subsystem),
the sync delay may be higher.

> If this is within Sander's plans, not only Devin did list some
> shortcomings already for being on latest, I doubt. And a well maintained
> 2.6.18 seems to have still many fans :)
> 
> I also can see, on a first look, that Sander is not in sync with
> Michael's latest.

With a distributed development, sometimes temporary development trees
may contain some newer patches that are not ready for merge yet. For the
model to work, the rule "commit early, commit often" should be followed:
people shouldn't be sitting on their patches for a long time. 
 
> More patches still come in from older stuff. (Compro T750/T750F, we run
> into detection troubles again)

I'm not seeing any unusual number of conflicts when merging patches at -git
from Patchwork (e. g. the patches submitted to the mailing list).

So, or people are already using git when submitting patches, or hg and git are
close enough for the vast majority of people that submit us patches. I suspect
that both are true.

> Until Douglas should complain, I'll stay quiet, but I guess it will turn
> into some "stable" mercurial v4l-dvb release every few weeks and I doubt
> to be interested to dig around in such and compare.

Well, if the mercurial tree delay doesn't work for you, just use git. As I said
before, the primary development Kernel resource should be git.

My view is that the backport tree is very useful to have a broader number
of people testing V4L/DVB code, as it can be applied against legacy kernels.
Of course, for this to work, people should quickly fix broken backports
(that means that not only Douglas should work on it, but other developers
are welcomed to contribute with backport fixes).

> Gerd did hold the v4l backward compat on 2.4.x during the introduction
> of v4l2, xawtv and nvrec have been the only working v4l2 apps for long,
> tvtime followed then, somehow forced, and much later mplayer, with lots
> of cries in between.
> 
> Full v4l1 compat, it always had bugs like the mute ioctl on saa713x, is
> broken anyway since long on hybrid tuners, see fmtools on recent tuners.
> 
> I always was for it, to have the broadest possible testing base, but if
> there is no clear fall back anymore, I luckily can miss support for a
> few cards the OEMs never did care about.
> 
> Cheers,
> Hermann
>  


-- 

Cheers,
Mauro

Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

[hermann pitton]

Hi,

Am Donnerstag, den 13.05.2010, 09:32 -0300 schrieb Mauro Carvalho
Chehab:
> hermann pitton wrote:
> > Am Donnerstag, den 13.05.2010, 01:49 -0300 schrieb Mauro Carvalho
> > Chehab:
> >> hermann pitton wrote:
> >>> Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
> >>>> Sander Pientka wrote:
> >>>>> Hi Hermann,
> >>>>>
> >>>>> I am going to revive this old thread, I completely forgot about it and
> >>>>> I still want to solve this problem.
> >>>>>
> >>>>> Yes, with the IR transmitter not plugged in, the gpio is reported as
> >>>>> 00000 by dmesg.
> >>>>>
> >>>>> I am aware there is a picture of the backside missing on the wiki, I
> >>>>> will try to make one a.s.a.p.
> >>>>>
> >>>>> NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c.
> >>>>>
> >>>>> Besides, dmesg outputs a section of error messages I don't understand:
> >>>>>
> >>>>> [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
> >>>>> i2c_transfer returned: -5
> >>>>> [ 1585.548229] tda18271_toggle_output: error -5 on line 47
> >>>>> [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
> >>>>> i2c_transfer returned: -5
> >>>>> [ 1585.720129] tda18271_init: error -5 on line 826
> >>>>> [ 1585.720136] tda18271_tune: error -5 on line 904
> >>>>> [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
> >>>>> [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
> >>>>> i2c_transfer returned: -5
> >>>>> [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
> >>>>> i2c_transfer returned: -5
> >>>>> [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
> >>>>> i2c_transfer returned: -5
> >>>>> [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
> >>>>> [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
> >>>>>
> >>>>>
> >>>>> Do you have any idea about the origin of these errors? Do you think
> >>>>> they affect the IR functionality?
> >>>> The above errors won't change anything at IR side. For IR, the better approach
> >>>> is to start using raw_decode mode. I've enabled it only for Avermedia M135A, 
> >>>> since this is the board I'm using at the IR refactoring tests, but the same approach
> >>>> should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For GPIO18,
> >>>> all you need is to use something like:
> >>>>
> >>>>         case SAA7134_BOARD_AVERMEDIA_M135A:
> >>>>                 ir_codes     = RC_MAP_AVERMEDIA_M135A_RM_JX;
> >>>>                 mask_keydown = 0x0040000;
> >>>>                 mask_keyup   = 0x0040000;
> >>>>                 mask_keycode = 0xffff;
> >>>>                 raw_decode   = 1;
> >>>>                 break;
> >>>>
> >>>> (Of course, replacing the board name by your board name (SAA7134_BOARD_ZOLID_HYBRID_PCI?),
> >>>> and pointing to the proper ir_codes table. You'll likely need to write one table for
> >>>> the IR that were shipped with your board.
> >>>>
> >>>> To do that, you'll need to enable debug at ir_core (modprobe ir_core debug=1), and type every
> >>>> key on your keyboard, associating the scancode number with a key name. See http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of the most comon keycodes.
> >>>>
> >>>> For example, pressing the power button of an IR I have here (for Leadtek PVR3000), it
> >>>> gives this info at the dmesg log:
> >>>> ir_nec_decode: NEC scancode 0x0300
> >>>>
> >>>> All I need to do is to write a new keymap:
> >>>>
> >>>> add a new media/rc-map.h
> >>>>
> >>>>
> >>>>  as, for example:
> >>>> 	drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
> >>>> (copying one of the existing keymaps) and add:
> >>>>
> >>>> static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
> >>>> 	{ 0x300, KEY_POWER2 },
> >>>>
> >>>> for every key that it is there. Then, add the new file at drivers/media/IR/keymaps/Makefile.
> >>>>
> >>>> I've tried to summarize the above patches on a change I just did at the wiki page. Feel 
> >>>> free to improve it, if needed.
> >>>>
> >>>> Cheers,
> >>>> Mauro
> >>> Hi Mauro,
> >>>
> >>> what I did try to point to, with some sarcasm involved, is that I can't
> >>> advice any v4l-dvb as reference anymore.
> >>>
> >>> To start to look such up, with all patches involved, per user, who
> >>> likely does not know himself on what he exactly is, find the last
> >>> building kernel for him then, guess on pending pull requests that time,
> >>> and so on, is not making any sense for me.
> >>>
> >>> Should we not state, that is nothing against Douglas at all or Hans with
> >>> his build reports, please be on latest .rc and git to test anything we
> >>> have around?
> >>>
> >>> We are out of sync else.
> >> Hermann,
> >>
> >> Sorry, but, sometimes, it is very hard to understand your English. I'm suspecting
> >> that you're referring to the sync between hg and git.
> >>
> >> Short answer:
> >> ============
> >>
> >>  - AFAIK, Douglas finished syncing the trees at the night of May, 12.
> >>
> >>  - Developers primary reference tree:
> >> 	http://git.linuxtv.org/v4l-dvb.git
> >>
> >>  - Backport tree:
> >> 	http://linuxtv.org/hg/v4l-dvb
> >>
> >>    As the backport is manual, some delay is expected at the backport tree. Also,
> >> backports are made at the best efforts basis. So, nobody can warrant that the
> >> drivers will behave correctly with an old kernel. Also, eventually, the backport tree
> >> can break when compiled with an older kernel.
> >>
> >>    Developers are encouraged to use git for development, but patches and pull
> >> requests against the backport tree are accepted.
> >>
> >> Long answer:
> >> ===========
> >>
> >> As I have about 100 pending patches at Patchwork, plus 4 or 5 pull requests not
> >> handled yet, mercurial tree will be soon out of sync. I'll try to merge most of the
> >> pending stuff during this weekend.
> >>
> >> The main developers reference is -git. We merge all patches there. 
> >> So, new stuff arrives there before being backported.
> >>
> >> That's said, we should be using git since 2.6.12, together with the kernel 
> >> community. By not using it, our merge process became very complex
> >> and it weren't scaling anymore. It is also impossible to merge the current
> >> embedded patches with -hg, since we would need to keep several arch trees
> >> inside hg, properly synchronized, which would make -hg tree very big
> >> and full of hacks.
> >>
> >> Due to our late adoption of git on our development trees, we're still
> >> needing to adjust the process. I'll likely need to do some improvements for
> >> the next kernel cycle, since I'm still suffering some merge issues upstream,
> >> that will likely affect developers if I don't adjust the procedures.
> >>
> >> The solution will likely be merging at git inside separate branches for separate
> >> topics.
> >>
> >> I'm trying to keep one branch (currently, master) with the latest final kernel 
> >> version. For example, if you use it right now, it is the vanilla 2.6.33 kernel, 
> >> plus v4l-dvb new stuff. This allows not only developers to use, but also advanced
> >> users that know how to compile a kernel (that's not that hard: in general,
> >> "make oldconfig && make" is enough, if the distro kernel is not very old).
> >>
> >> Unfortunately, I don't have any time anymore to maintain the backport tree. We've
> >> broke our record in terms of number of patches per release at -rc6: almost 
> >> 800 patches for linux next, on a shorter kernel development cycle. So, we had about
> >> 19 patches committed by day, 7 days by week, plus the ones that needed to be 
> >> re-designed, due to some troubles, plus all architectural discussions we're having
> >> about videobuf, events interface, mem2mem, etc.
> >>
> >> I suspect that part of growth on the number of patches is due to the usage of git, as
> >> I'm seeing more upstream kernel hackers sending patches to drivers/media lately.
> >>
> >> So, Douglas assumed the maintainership of the hg tree. As all upstream patches
> >> need to be backported, he's likely having a high demand bandwidth, because of the high 
> >> number of patches.
> >>
> >> As far as I know (Douglas, please correct me if I'm wrong), he started by
> >> applying patches, testing against a selected number of legacy kernels and publish
> >> after the tests. Also, he needs to identify the origin of a patch before applying
> >> on his tree, to avoid breaking developers tree based on mercurial to require rebasing
> >> after his merge. Life would probably be easier for him if everybody would be generating
> >> patches against git when submitting upstream.
> >>
> >> As people complained about the high delay, he decided just a few days ago 
> >> to just sync the tree, and then adding backport patches with the help of the 
> >> community. Of course, this means that the current -hg tree will compile only 
> >> against 2.6.33, until someone backports the tree to the earlier kernels.
> >>
> >> I suspect that people will also complain about that. Not sure what strategy would
> >> be the better.
> >>
> >> The fact is that, even with -hg, when we were close to the next merge window, the
> >> number of patches tend to increase (as everybody tries to send their code for the
> >> next merge window), and the need for backport increases, as other maintainers are
> >> always improving the kernel ABI's. So, during a period of up to 4 weeks (one or 
> >> two weeks before and the two weeks of the merge window), it would almost certain
> >> that backport support would be broken.
> >>
> >> Anyway, it is up to Douglas to define what would be the better way to maintain the
> >> backport tree, as he is the one that is feeling all the pain of backporting
> >> stuff, of course listening to the community feedback. It would be nice if
> >> people could also help him by sending backport patches were needed.
> >>
> > 
> > Hi Mauro, Sander, Douglas,
> > 
> > I can see all that.
> > 
> > But the question was very simple.
> > 
> > What revision of v4l-dvb I should have suggested to Sander on the day of
> > his request to work further on it?
> > 
> > I don't know, without very detailed input and a lot of looking up and
> > broken build as next condition. So I do suggest to go to .rc and latest
> > git. De facto it happened already.
> 
> The most updated version is at git:
> 	http://git.linuxtv.org/v4l-dvb.git

Sander, you can try to work with that, but read Documentation/Changes to
make sure your distribution environment is qualified for it.

> On most cases, running the latest -hg is equivalent, but, when some major
> changes happen (that's the case of the new Remote Controller subsystem),
> the sync delay may be higher.
> 
> > If this is within Sander's plans, not only Devin did list some
> > shortcomings already for being on latest, I doubt. And a well maintained
> > 2.6.18 seems to have still many fans :)
> > 
> > I also can see, on a first look, that Sander is not in sync with
> > Michael's latest.
> 
> With a distributed development, sometimes temporary development trees
> may contain some newer patches that are not ready for merge yet. For the
> model to work, the rule "commit early, commit often" should be followed:
> people shouldn't be sitting on their patches for a long time. 

I assume he is on some older kernel and therefore should check on
something recent if the EIOs are still there.
 
> > More patches still come in from older stuff. (Compro T750/T750F, we run
> > into detection troubles again)
> 
> I'm not seeing any unusual number of conflicts when merging patches at -git
> from Patchwork (e. g. the patches submitted to the mailing list).
> 
> So, or people are already using git when submitting patches, or hg and git are
> close enough for the vast majority of people that submit us patches. I suspect
> that both are true.

OK, good enough.

> > Until Douglas should complain, I'll stay quiet, but I guess it will turn
> > into some "stable" mercurial v4l-dvb release every few weeks and I doubt
> > to be interested to dig around in such and compare.
> 
> Well, if the mercurial tree delay doesn't work for you, just use git. As I said
> before, the primary development Kernel resource should be git.
> 
> My view is that the backport tree is very useful to have a broader number
> of people testing V4L/DVB code, as it can be applied against legacy kernels.
> Of course, for this to work, people should quickly fix broken backports
> (that means that not only Douglas should work on it, but other developers
> are welcomed to contribute with backport fixes).

For now, if not using git, Sander needs a 2.6.33 with recent v4l-dvb
then to provide relevant debug output and eventually patches. He has to
check if his distribution has the minimal requirements for that one too.

This should be the correct advice for him at the moment.

Right?

Cheers,
Hermann

Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

[Mauro Carvalho Chehab]

hermann pitton wrote:

>> My view is that the backport tree is very useful to have a broader number
>> of people testing V4L/DVB code, as it can be applied against legacy kernels.
>> Of course, for this to work, people should quickly fix broken backports
>> (that means that not only Douglas should work on it, but other developers
>> are welcomed to contribute with backport fixes).
> 
> For now, if not using git, Sander needs a 2.6.33 with recent v4l-dvb
> then to provide relevant debug output and eventually patches.

Until Douglas or someone fix the breakages with older kernels, yes.

> He has to
> check if his distribution has the minimal requirements for that one too.

In thesis, yes, but, unless he is running a really old distribution 
(those that come with kernels lower than 2.6.16), it should be ok to 
run 2.6.33 on it, provided that properly compiled with the minimum
requirements needed by the distro. Generally, "make oldconfig" do a
good job of enabling the needed bits, but sometimes, manual adjustments
at compilation parameters might be needed.

Well, if the distro is older than 2.6.16, it won't be capable of running 
from -hg anyway (as the minimum supported kernel is 2.6.16). So, I don't 
think that this would be a problem, in practice.

-- 

Cheers,
Mauro

Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

[Mauro Carvalho Chehab]

Mauro Carvalho Chehab wrote:
> hermann pitton wrote:
> 
>>> My view is that the backport tree is very useful to have a broader number
>>> of people testing V4L/DVB code, as it can be applied against legacy kernels.
>>> Of course, for this to work, people should quickly fix broken backports
>>> (that means that not only Douglas should work on it, but other developers
>>> are welcomed to contribute with backport fixes).
>> For now, if not using git, Sander needs a 2.6.33 with recent v4l-dvb
>> then to provide relevant debug output and eventually patches.
> 
> Until Douglas or someone fix the breakages with older kernels, yes.

As the fix patch is really trivial, I found a couple of minutes to write a patch
for fixing this issue. I haven't test the patch, but, as it uses the same backport
logic as found at cx2355-ir, I don't expect much troubles on it.

-- 

Cheers,
Mauro

Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

[hermann pitton]

Hi,

Am Donnerstag, den 13.05.2010, 15:45 -0300 schrieb Mauro Carvalho
Chehab:
> Mauro Carvalho Chehab wrote:
> > hermann pitton wrote:
> > 
> >>> My view is that the backport tree is very useful to have a broader number
> >>> of people testing V4L/DVB code, as it can be applied against legacy kernels.
> >>> Of course, for this to work, people should quickly fix broken backports
> >>> (that means that not only Douglas should work on it, but other developers
> >>> are welcomed to contribute with backport fixes).
> >> For now, if not using git, Sander needs a 2.6.33 with recent v4l-dvb
> >> then to provide relevant debug output and eventually patches.
> > 
> > Until Douglas or someone fix the breakages with older kernels, yes.
> 
> As the fix patch is really trivial, I found a couple of minutes to write a patch
> for fixing this issue. I haven't test the patch, but, as it uses the same backport
> logic as found at cx2355-ir, I don't expect much troubles on it.

Mauro, fine, it is a start.

Compiles down to to 2.6.30, but has some __check_debug warnings for
three static bool insmod options there. (build cron job of today)

To replace them with some int seems ok, but since no such warnings on
higher kernels for bool, likely some compat issue.

IR oopses on 2.6.30 with Pinnacle 310i on a first try.

Thanks for all explanations of the current sync procedures, Douglas does
well and four weeks without in depth backward compat are hard to avoid
either way.

Did not try on 2.6.33.4 yet, but should be OK. The rest we can fix after
the merge window.

Cheers,
Hermann

saa7133[1]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[1]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 5-004b: chip found @ 0x96 (saa7133[1])
tda829x 5-004b: setting tuner address to 61
tda829x 5-004b: type set to tda8290+75a
saa7133[1]: registered device video1 [v4l2]
saa7133[1]: registered device vbi1
saa7133[1]: registered device radio1
saa7133[2]: setting pci latency timer to 64
saa7133[2]: found at 0000:02:09.0, rev: 208, irq: 19, latency: 64, mmio: 0xfdefd000
saa7133[2]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected]
saa7133[2]: board init: gpio is 600c000
IRQ 19/saa7133[2]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7133[2]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[2]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2c b0 22 ff ff
saa7133[2]: i2c eeprom 20: 01 2c 01 02 02 01 04 30 98 ff 00 a5 ff 21 00 c2
saa7133[2]: i2c eeprom 30: 96 10 03 32 15 20 ff ff 0c 22 17 88 03 44 31 f9
saa7133[2]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[2]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
tuner 6-004b: chip found @ 0x96 (saa7133[2])
tda829x 6-004b: setting tuner address to 61
tda829x 6-004b: type set to tda8290+75a
Registered IR keymap rc-pinnacle-color
input: i2c IR (Pinnacle PCTV) as /devices/virtual/input/input8
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffffa00e97c7>] __ir_input_register+0x26d/0x2fd [ir_core]
PGD 3ecbd067 PUD 2006b067 PMD 0 
Oops: 0000 [#1] SMP 
last sysfs file: /sys/module/saa7134/initstate
CPU 0 
Modules linked in: rc_pinnacle_color ir_kbd_i2c(+) tda827x tda8290 tuner saa7134(+) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core ir_common ir_core tveeprom sit tunnel4 fuse bridge stp llc bnep sco l2cap bluetooth sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath uinput snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer r8169 ppdev snd mii soundcore snd_page_alloc parport_pc shpchp k8temp parport hwmon joydev floppy serio_raw pcspkr i2c_nforce2 ata_generic pata_acpi pata_amd radeon drm i2c_algo_bit i2c_core [last unloaded: v4l1_compat]
Pid: 3399, comm: modprobe Not tainted 2.6.30.10-105.2.16.fc11.x86_64 #1  
RIP: 0010:[<ffffffffa00e97c7>]  [<ffffffffa00e97c7>] __ir_input_register+0x26d/0x2fd [ir_core]
RSP: 0018:ffff88003b459cb8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880025921400 RCX: ffff880036127000
RDX: ffffffff81621420 RSI: 0000000000000282 RDI: ffffffff816213f0
RBP: ffff88003b459d08 R08: 0000000000000000 R09: ffffffff81557ea4
R10: ffff88003e944500 R11: ffff88003b459b00 R12: ffff880036127000
R13: ffffffffa00ff3f0 R14: 000000000000002a R15: ffffffffa00f2dbd
FS:  00007f404f9f16f0(0000) GS:ffff88000100a000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000003c40d000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 3399, threadinfo ffff88003b458000, task ffff880025949700)
Stack:
 ffff880000000000 ffff880025921560 0000000000000286 ffff880025921588
 0000000000000286 ffff880024ce0300 0000000080000000 ffffffffa00ff3f0
 ffff880036127000 ffff88003daaf800 ffff88003b459d68 ffffffffa00f298c
Call Trace:
 [<ffffffffa00f298c>] ir_probe+0x3e7/0x4b3 [ir_kbd_i2c]
 [<ffffffffa00f25a5>] ? ir_probe+0x0/0x4b3 [ir_kbd_i2c]
 [<ffffffffa0000387>] i2c_device_probe+0xc0/0x101 [i2c_core]
 [<ffffffff81272da1>] driver_probe_device+0xdb/0x1fb
 [<ffffffff81272f1e>] __driver_attach+0x5d/0x81
 [<ffffffff81272ec1>] ? __driver_attach+0x0/0x81
 [<ffffffff81272264>] bus_for_each_dev+0x53/0x88
 [<ffffffff81272b40>] driver_attach+0x1e/0x20
 [<ffffffff81272822>] bus_add_driver+0xf7/0x259
 [<ffffffff81273208>] driver_register+0x9d/0x10e
 [<ffffffffa00f8000>] ? ir_init+0x0/0x19 [ir_kbd_i2c]
 [<ffffffffa0001ee2>] i2c_register_driver+0x91/0x116 [i2c_core]
 [<ffffffffa00f8000>] ? ir_init+0x0/0x19 [ir_kbd_i2c]
 [<ffffffffa00f8017>] ir_init+0x17/0x19 [ir_kbd_i2c]
 [<ffffffff8100a069>] do_one_initcall+0x5e/0x162
 [<ffffffff8107028d>] sys_init_module+0xaa/0x1d5
 [<ffffffff81010cc2>] system_call_fastpath+0x16/0x1b
Code: 48 8b 7d c8 89 55 b0 e8 0a 1c 2f e1 8b 55 b0 b8 f4 ff ff ff 85 d2 75 5b 4c 89 e7 e8 72 e1 1f e1 85 c0 78 4f 48 8b 83 98 01 00 00 <83> 38 01 75 0c 4c 89 e7 e8 50 07 00 00 85 c0 78 29 31 c0 83 3d 
RIP  [<ffffffffa00e97c7>] __ir_input_register+0x26d/0x2fd [ir_core]
 RSP <ffff88003b459cb8>
CR2: 0000000000000000
---[ end trace 2cb06ca615ef014b ]---
saa7133[2]: registered device video2 [v4l2]
saa7133[2]: registered device vbi2
saa7133[2]: registered device radio2
saa7133[3]: setting pci latency timer to 64
saa7133[3]: found at 0000:02:0a.0, rev: 209, irq: 17, latency: 64, mmio: 0xfdefc000
saa7133[3]: subsystem: 16be:0007, board: Medion Md8800 Quadro [card=96,autodetected]
saa7133[3]: board init: gpio is 0

Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

[hermann pitton]

Hi,

[snip]
> 
> Did not try on 2.6.33.4 yet, but should be OK. The rest we can fix after
> the merge window.

The saa7134 card=2 gpio remote is OK on 2.6.33.4 with current v4l-dvb.

Sander, let's know about further questions.

Cheers,
Hermann

Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner

[Douglas Schilling Landgraf]

Hi,

On Thu, May 13, 2010 at 1:49 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> hermann pitton wrote:
>> Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
>>> Sander Pientka wrote:
>>>> Hi Hermann,
>>>>
>>>> I am going to revive this old thread, I completely forgot about it and
>>>> I still want to solve this problem.
>>>>
>>>> Yes, with the IR transmitter not plugged in, the gpio is reported as
>>>> 00000 by dmesg.
>>>>
>>>> I am aware there is a picture of the backside missing on the wiki, I
>>>> will try to make one a.s.a.p.
>>>>
>>>> NEC IR support seems to be built-in already: drivers/media/IR/ir-nec-decoder.c.
>>>>
>>>> Besides, dmesg outputs a section of error messages I don't understand:
>>>>
>>>> [ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
>>>> i2c_transfer returned: -5
>>>> [ 1585.548229] tda18271_toggle_output: error -5 on line 47
>>>> [ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
>>>> i2c_transfer returned: -5
>>>> [ 1585.720129] tda18271_init: error -5 on line 826
>>>> [ 1585.720136] tda18271_tune: error -5 on line 904
>>>> [ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
>>>> [ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
>>>> i2c_transfer returned: -5
>>>> [ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
>>>> i2c_transfer returned: -5
>>>> [ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
>>>> i2c_transfer returned: -5
>>>> [ 1586.629458] tda18271_channel_configuration: error -5 on line 160
>>>> [ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
>>>>
>>>>
>>>> Do you have any idea about the origin of these errors? Do you think
>>>> they affect the IR functionality?
>>> The above errors won't change anything at IR side. For IR, the better approach
>>> is to start using raw_decode mode. I've enabled it only for Avermedia M135A,
>>> since this is the board I'm using at the IR refactoring tests, but the same approach
>>> should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For GPIO18,
>>> all you need is to use something like:
>>>
>>>         case SAA7134_BOARD_AVERMEDIA_M135A:
>>>                 ir_codes     = RC_MAP_AVERMEDIA_M135A_RM_JX;
>>>                 mask_keydown = 0x0040000;
>>>                 mask_keyup   = 0x0040000;
>>>                 mask_keycode = 0xffff;
>>>                 raw_decode   = 1;
>>>                 break;
>>>
>>> (Of course, replacing the board name by your board name (SAA7134_BOARD_ZOLID_HYBRID_PCI?),
>>> and pointing to the proper ir_codes table. You'll likely need to write one table for
>>> the IR that were shipped with your board.
>>>
>>> To do that, you'll need to enable debug at ir_core (modprobe ir_core debug=1), and type every
>>> key on your keyboard, associating the scancode number with a key name. See http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of the most comon keycodes.
>>>
>>> For example, pressing the power button of an IR I have here (for Leadtek PVR3000), it
>>> gives this info at the dmesg log:
>>> ir_nec_decode: NEC scancode 0x0300
>>>
>>> All I need to do is to write a new keymap:
>>>
>>> add a new media/rc-map.h
>>>
>>>
>>>  as, for example:
>>>      drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
>>> (copying one of the existing keymaps) and add:
>>>
>>> static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
>>>      { 0x300, KEY_POWER2 },
>>>
>>> for every key that it is there. Then, add the new file at drivers/media/IR/keymaps/Makefile.
>>>
>>> I've tried to summarize the above patches on a change I just did at the wiki page. Feel
>>> free to improve it, if needed.
>>>
>>> Cheers,
>>> Mauro
>>
>> Hi Mauro,
>>
>> what I did try to point to, with some sarcasm involved, is that I can't
>> advice any v4l-dvb as reference anymore.

Well, any help to fix v4l-dvb trees are welcome.

>> To start to look such up, with all patches involved, per user, who
>> likely does not know himself on what he exactly is, find the last
>> building kernel for him then, guess on pending pull requests that time,
>> and so on, is not making any sense for me.
>>
>> Should we not state, that is nothing against Douglas at all or Hans with
>> his build reports, please be on latest .rc and git to test anything we
>> have around?
>>
>> We are out of sync else.
>
> Hermann,
>
> Sorry, but, sometimes, it is very hard to understand your English. I'm suspecting
> that you're referring to the sync between hg and git.
>
> Short answer:
> ============
>
>  - AFAIK, Douglas finished syncing the trees at the night of May, 12.

Exactly.

>  - Developers primary reference tree:
>        http://git.linuxtv.org/v4l-dvb.git
>
>  - Backport tree:
>        http://linuxtv.org/hg/v4l-dvb

Agreed.

>   As the backport is manual, some delay is expected at the backport tree. Also,
> backports are made at the best efforts basis. So, nobody can warrant that the
> drivers will behave correctly with an old kernel. Also, eventually, the backport tree
> can break when compiled with an older kernel.

As Mauro pointed, the backport job is done by 99% of time taking every single
patch available in git tree and apply it manually and fixing
eventually problems.
So, it's can take some time.

>   Developers are encouraged to use git for development, but patches and pull
> requests against the backport tree are accepted.

Agreed,

> Long answer:
> ===========
>
> As I have about 100 pending patches at Patchwork, plus 4 or 5 pull requests not
> handled yet, mercurial tree will be soon out of sync. I'll try to merge most of the
> pending stuff during this weekend.
>
> The main developers reference is -git. We merge all patches there.
> So, new stuff arrives there before being backported.
>
> That's said, we should be using git since 2.6.12, together with the kernel
> community. By not using it, our merge process became very complex
> and it weren't scaling anymore. It is also impossible to merge the current
> embedded patches with -hg, since we would need to keep several arch trees
> inside hg, properly synchronized, which would make -hg tree very big
> and full of hacks.
>
> Due to our late adoption of git on our development trees, we're still
> needing to adjust the process. I'll likely need to do some improvements for
> the next kernel cycle, since I'm still suffering some merge issues upstream,
> that will likely affect developers if I don't adjust the procedures.
>
> The solution will likely be merging at git inside separate branches for separate
> topics.
>
> I'm trying to keep one branch (currently, master) with the latest final kernel
> version. For example, if you use it right now, it is the vanilla 2.6.33 kernel,
> plus v4l-dvb new stuff. This allows not only developers to use, but also advanced
> users that know how to compile a kernel (that's not that hard: in general,
> "make oldconfig && make" is enough, if the distro kernel is not very old).
>
> Unfortunately, I don't have any time anymore to maintain the backport tree. We've
> broke our record in terms of number of patches per release at -rc6: almost
> 800 patches for linux next, on a shorter kernel development cycle. So, we had about
> 19 patches committed by day, 7 days by week, plus the ones that needed to be
> re-designed, due to some troubles, plus all architectural discussions we're having
> about videobuf, events interface, mem2mem, etc.
>
> I suspect that part of growth on the number of patches is due to the usage of git, as
> I'm seeing more upstream kernel hackers sending patches to drivers/media lately.
>
> So, Douglas assumed the maintainership of the hg tree. As all upstream patches
> need to be backported, he's likely having a high demand bandwidth, because of the high
> number of patches.
>
> As far as I know (Douglas, please correct me if I'm wrong), he started by
> applying patches, testing against a selected number of legacy kernels and publish
> after the tests. Also, he needs to identify the origin of a patch before applying
> on his tree, to avoid breaking developers tree based on mercurial to require rebasing
> after his merge. Life would probably be easier for him if everybody would be generating
> patches against git when submitting upstream.
>
> As people complained about the high delay, he decided just a few days ago
> to just sync the tree, and then adding backport patches with the help of the
> community. Of course, this means that the current -hg tree will compile only
> against 2.6.33, until someone backports the tree to the earlier kernels.
>
> I suspect that people will also complain about that. Not sure what strategy would
> be the better.

Exactly Mauro, there is no solution which 100% of people will agree.
As you said,
with my first approach which was first fix any broken patch before
commit I received
private emails asking when 'x' patch will be synced with hg tree. Now,
with this new
approach which is sync hg and git tree ASAP, we can have hg and git
synced at most of
time and other people helping in possible broken patches while I am
syncing the trees since
it's opensource code.

> The fact is that, even with -hg, when we were close to the next merge window, the
> number of patches tend to increase (as everybody tries to send their code for the
> next merge window), and the need for backport increases, as other maintainers are
> always improving the kernel ABI's. So, during a period of up to 4 weeks (one or
> two weeks before and the two weeks of the merge window), it would almost certain
> that backport support would be broken.
>
> Anyway, it is up to Douglas to define what would be the better way to maintain the
> backport tree, as he is the one that is feeling all the pain of backporting
> stuff, of course listening to the community feedback. It would be nice if
> people could also help him by sending backport patches were needed.

Of course, we are a team I am open for new ideas and suggestions. If
you guys prefer,
we can talk about it in Linux Plumbers too. I intend to be there. If I
am not wrong, several
people from the list will attend this conference right?

Thanks,
Douglas