linux-kernel - Re: [RFC v2] Another approach to IR

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <9e4733910912011019n798c7552i6f9b16f9e8e90c58@mail.gmail.com>
Date:	Tue, 1 Dec 2009 13:19:02 -0500
From:	Jon Smirl <jonsmirl@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Maxim Levitsky <maximlevitsky@...il.com>, awalls@...ix.net,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	jarod@...sonet.com, khc@...waw.pl, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	lirc-list@...ts.sourceforge.net, superm1@...ntu.com,
	Christoph Bartelmus <lirc@...telmus.de>
Subject: Re: [RFC v2] Another approach to IR

On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
<mchehab@...hat.com> wrote:
> Hi Jon,
> So, what we can do is to have a "default" keycode table mapping several
> different IR's there to be used by drivers that are shipped with an IR
> that can be fully mapped by the default table. However, for devices
> with scancodes that overlaps with the default table, we'll need a separate
> table.

The goal is to try and design a set of zero config defaults that can
work for 90% of users.

LIRC merges two different things, basic IR driver support and
application scripting for non-IR aware apps. Application scripting for
unaware apps is always going to happen in user space and it will
always need to be manually configured.  But scripting should be
optional.

I'm looking at the driver half and I'd like to explore how zero config
support can be built for IR aware apps. Of course we don't have any IR
aware apps today because no kernel IR event types have been defined
yet. It is better to simply make the apps IR aware and have them
process IR events from evdev (in other words forget about the configs
code it was a poor man's scripting scheme).

For mouse/keyboard support something parallel to USB HID is needed. A
couple of common device profiles would be mapped to keyboard/mouse
events by default. That should support 90% of users. The other 10% can
use a set keys IOCTL to change the mappings.

A couple of use cases:
  insert MSMCE IR device
  kernel automatically loads all drivers
  IR events appear in evdev as vendor/device/command triplets

  apt-get mythtv
  set universal remote to xmit DVR commands
  everything just works

  set universal remote to xmit device A commands
  device A commands mapped to keyboard/mouse movements
  everything just works

For these default cases you just have to read enough docs to know what
device to set your universal remote to.

The scenario I'd like to achieve
   install TV app
   install audio app
   install home automation app
   use multi-function remote to control in parallel with zero config
other than setting three devices into the remote.

-- 
Jon Smirl
jonsmirl@...il.com
--
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/