Re: [RFC] What are the goals for the architecture of an in-kernelIR system?

[Mauro Carvalho Chehab]

Dmitry Torokhov wrote:
> On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
>>> How related lirc-core to the current lirc code? If it is not the same
>>> maybe we should not call it lirc to avoid confusion.
>> Just for better illustrate what I'm seeing, I broke the IR generic
>> code into two components:
>>
>> 	lirc core - the module that receives raw pulse/space and creates
>> 		    a device to receive raw API pulse/space events;
>>
>> 	IR core - the module that receives scancodes, convert them into
>> 		  keycodes and send via evdev interface.
>>
>> We may change latter the nomenclature, but I'm seeing the core as two different
>> modules, since there are cases where lirc core won't be used (those
>> devices were there's no way to get pulse/space events).
>>
> 
> OK, I think we are close but not exactly close. I believe that what you
> call lirc core will be used always - it is the code that create3s class
> devices, connectes decorers with the data streams, etc. I believe it
> will be utilized even in case of devices using hardware decoders. That
> is why we should probably stop calling it "lirc core" just tso we don't
> confuse it with original lirc.
> 
> Then we have decoders and lirc_dev - which implements original lirc
> interface (or maybe its modified version) and allows lircd to continue
> working.
> 
> Lastly we have what you call IR core which is IR-to-input bridge of
> sorts.

It seems to be just nomenclacure ;)

what I called "IR core" you called "lirc core"
what I called "lirc core" you called "lirc_dev"

What I called IR core is the one that will be used by every IR driver, handling
sysfs, evdev's, calling decoders, etc.

I opted to use the nomenclature Lirc to the part of the IR subsystem that
will create the Lirc interface.

Currently, I almost finished the evdev part of the "IR core", using the current
API to control the dynamic keycode allocation. It is already working fine with
V4L drivers.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/