Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Jon Smirl wrote:
>> So now that I'm more or less done with porting the imon driver, I
>> think I'm ready to start tackling the mceusb driver. But I'm debating
>> on what approach to take with respect to lirc support. It sort of
>> feels like we should have lirc_dev ported as an ir "decoder"
>> driver/plugin before starting to port mceusb to ir-core, so that we
>> can maintain lirc compat and transmit support. Alternatively, I could
>> port mceusb without lirc support for now, leaving it to only use
>> in-kernel decoding and have no transmit support for the moment, then
>> re-add lirc support. I'm thinking that porting lirc_dev as, say,
>> ir-lirc-decoder first is probably the way to go though. Anyone else
>> want to share their thoughts on this?
> 
> I'd take whatever you think is the simplest path. It is more likely
> that initial testers will want to work with the new in-kernel system
> than the compatibility layer to LIRC. Existing users that are happy
> with the current LIRC should just keep on using it.

Agreed. You may start by adding either lirc "decoder" or mce. Both ways
will end on having the same result ;)

>> (Actually, while sharing thoughts... Should drivers/media/IR become
>> drivers/media/RC, ir-core.h become rc-core.h, ir-keytable.c become
>> rc-keytable.c and so on?)
> 
> Why aren't these files going into drivers/input/rc? My embedded system
> has a remote control and it has nothing to do with media.

Historical reasons. It were simpler to start from drivers/media, as we've
started with some already existing code there.

My intention is to write one or two big patches at the end, moving everything
to drivers/rc or drivers/input/rc and renaming the structures. The point is
that a patch like that will force people that are working on the code to rebase
to the newer names, so I prefer to postpone it to happen after we finish with
the big changes. A change like that won't affect just the new RC code, but also
several V4L/DVB drivers.

Maybe the right moment would be during the next merge window, as all pending 
work for 2.6.35 will be already finished, and people likely didn't start 
working for 2.6.36. So, my intention is to write such patch during the merge
week, just after sending the pending stuff.

-- 

Cheers,
Mauro