linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

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]

Date:	Fri, 09 Apr 2010 20:32:53 -0300
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Andy Walls <awalls@...ix.net>
CC:	Devin Heitmueller <dheitmueller@...nellabs.com>,
	James Hogan <james@...anarts.com>,
	Jon Smirl <jonsmirl@...il.com>, Pavel Machek <pavel@....cz>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	hermann pitton <hermann-pitton@...or.de>,
	Christoph Bartelmus <lirc@...telmus.de>, j@...nau.net,
	jarod@...hat.com, jarod@...sonet.com, kraxel@...hat.com,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

Andy Walls wrote:
> On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote:
>> On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
>> <mchehab@...hat.com> wrote:
>>> [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by
>>> associating some scancode to KEY_POWER via ir-core, the driver can program the hardware
>>> to wake up the machine with the corresponding scancode. I can't see a need for a change at
>>> ir-core to implement such behavior. Of course, some attributes at sysfs can be added
>>> to enable or disable this feature, and to control the associated logic, but we first
>>> need to implement the wakeup feature at the hardware driver, and then adding some logic
>>> at ir-core to add the non-hardware specific code there.
>> Really?  Have you actually seen any hardware where a particular scan
>> code can be used to wake up the hardware?  The only hardware I have
>> seen has the ability to unsuspend on arrival of IR traffic, but you
>> didn't have the granularity to dictate that it only wake up on
>> particular scancodes.
> 
> The CX23888 and CX23102 can do it.  Basically any IR pulse pattern your
> heart desires; within reason.  And any carrier freq you want too; within
> reason.
> 
> But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere
> near properly supporing suspend/resume for their main video and DMA
> functions, AFAIK.

AFAIK, only saa7134 have a good suspend/resume code [1]. You may be watching TV,
do a suspend and waking the hardware again, and you'll keep seeing the same
channel (I tested it some time ago, when the proper suspend code were added,
on analog mode, with alsa enabled). Other drivers can suspend/resume, but
they won't properly restore the video registers, so, you'll see artifacts when
it returns.

So, yes, you're right: before any suspend/resume code on those drivers, we
first need to add some code to properly handle kernel threads and work queues
during suspend, and to restore all the registers to a sane state at resume,
before implementing IR wakeup on them.

In the case of mceusb, as there is already an userspace code for it on lirc,
it would probably not be that hard to make this feature to work with ir-core.

[1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software
decoder, the IR IRQ might be used to wake, but this means that everything,
even a glitch, would wake the hardware, so this won't work neither.

-- 

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/