Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
From: Christoph Bartelmus <hidden>
Date: 2009-11-26 22:06:13
Also in:
linux-media, lkml
Possibly related (same subject, not in this thread)
- 2009-12-13 · Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure · <hidden>
- 2009-12-09 · Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure · Mauro Carvalho Chehab <hidden>
- 2009-12-09 · Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure · Mauro Carvalho Chehab <hidden>
- 2009-12-09 · Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure · Mauro Carvalho Chehab <hidden>
- 2009-12-08 · Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure · Krzysztof Halasa <khc@pm.waw.pl>
Hi Mauro, on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote:
Christoph Bartelmus wrote:
[...]
quoted
quoted
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. Christoph