Messages in this thread | | | Date | Thu, 26 Nov 2009 20:14:18 -0200 | From | Mauro Carvalho Chehab <> | Subject | Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure |
| |
Christoph Bartelmus wrote: > Hi Mauro, > > on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote: >> Christoph Bartelmus wrote: > [...] >>>> lircd supports input layer interface. Yet, patch 3/3 exports both devices >>>> that support only pulse/space raw mode and devices that generate scan >>>> codes via the raw mode interface. It does it by generating artificial >>>> pulse codes. >>> Nonsense! There's no generation of artificial pulse codes in the drivers. >>> The LIRC interface includes ways to pass decoded IR codes of arbitrary >>> length to userspace. > >> I might have got wrong then a comment in the middle of the >> imon_incoming_packet() of the SoundGraph iMON IR patch: > > Indeed, you got it wrong. > As I already explained before, this device samples the signal at a > constant rate and delivers the current level in a bit-array. This data is > then condensed to pulse/space data.
Ah, ok. It is now clear to me.
IMHO, it would be better to explain this at the source code, since the imon_incoming_packet() is a little complex.
It would help the review process if those big routines could be broken into a few functions. While this improves code readability, it shouldn't affect performance, as gcc will handle the static functions used only once as inline.
> Christoph
Cheers, Mauro.
| |