Dmitry Torokhov wrote:

On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:

quoted

quoted

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.