linux-kernel - Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B0EFDBA.8000905@redhat.com>
Date:	Thu, 26 Nov 2009 20:14:18 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Christoph Bartelmus <lirc@...telmus.de>
CC:	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	khc@...waw.pl, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	superm1@...ntu.com
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/