lkml.org 
[lkml]   [2009]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2009-11-26 23:17    [W:0.227 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site