Re: drop lircd!

[Gerd K. <kr...@by...>]

> >Wrong.  That is _one_ way to handle it.  Another is -- as noted in the
> >mail -- send the userspace-decoded IR events back to the kernel's input
> >layer, let the input layer do the event dispatching and to split the
> >"does everything" lircd monster into smaller parts (one for decoding,
> >one for networking, ...).
> >
> 1. That one "for decoding", would you call it lircd  ? :))

Probably not to avoid confusion.

> 2. Instead of 1 daemon to configure (and second "lirccd" is coming) , I 
> will have <how many> ?

Depends on what you are doing.  If *all* IR events go through the input
layer and liblirc_client reads from /dev/input/event<x> you need just
the decoding one for usb + serial devices and no daemon at all for the
TV card case.

If you want to send IR input over the network two more daemons (one for
each end of the network connection) would be needed.  If they are build
on top of the kernel input layer that would be something very generic.
It wouldn't work for IR only, it would also be possible to forward
keyboard/mouse/whatever input events over the network.

> 3. You brought no reason why all this is better from application point 
> of view.

Wrong.  I did.  You have the option to control applications which know
nothing about lirc with the IR remote.  Works nicely for teletext
browsers.

For applications which use lirc_client lib today basically nothing would
change.

Mixing the two (lirc and non-lirc apps) likely doesn't work that good
through.

> >The kernel modules can live in the standard kernel through, which will
> >IMHO make life much easier for both maintainers and users.  And it isn't
> >needed to split drivers into multiple parts just because one of the
> >required subsystems (of v4l + lirc) doesn't live in the standard kernel.
> 
> Put all lirc drivers into standard kernel ? Yes, that would be nice, but 
> will it happen ?

I don't expect major problems to put anything based on the input layer
into the kernel.

/dev/lirc-based stuff wouldn't go in until you have a official major
number for the device.  And probably a number of drivers will need
some cleanups before they will be accepted.  lirc_gpio.c for example
uses global variables for per-device informations, which is a _very_
bad idea.  I also think merging lirc_gpio.c into the bttv driver would
simplify the code alot.

> >Read my mail again please.
> >
> You must be able to distiguish between events. Those from remote must
> go to lirc-enabled applications, those from keyboard - to X.

I don't think this is a major problem.  Need to be discussed with the
input layer maintainer how to solve that puzzle through.  There are a
number of different ways I can think of ...

> Once again: you can do it (technically speaking) but unless your box
> is controlled from remote you don't want to.

How about letting the users decide whenever they want or not?

  Gerd

-- 
sigfault