Subject: Re: [RFC PATCH 0/4] V3 - Implementation of IR support using the
 input subsystem
From: Jarod Wilson <jarod@wilsonet.com>
To: Pavel Machek <pavel@suse.cz>
Cc: Jon Smirl <jonsmirl@gmail.com>, lirc-list@lists.sourceforge.net,
       linux-kernel@vger.kernel.org
In-Reply-To: <20081009120333.GA1623@ucw.cz>
References: <20081006194032.15992.8393.stgit@terra>
	 <20081009120333.GA1623@ucw.cz>
Content-Type: text/plain
Date: Fri, 10 Oct 2008 00:11:39 -0400
Message-Id: <1223611899.13345.86.camel@xavier.wilsonet.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1310
Lines: 35

On Thu, 2008-10-09 at 14:03 +0200, Pavel Machek wrote:
> Hi!
> 
> >  What should the IR API look like?  How are IR events mapped into
> > keyboard events? Should they be mapped? Map them in the kernel or in
> > user space? The maps are tiny, less than 1K per remote.  Sysfs can
> > be used to load maps into the kernel driver. Make maps only for the
> > common buttons and don't map unusual ones?
> 
> Map them in kernel, in analogy with normal keyboards.

My thought was to basically follow what the ati_remote{,2} driver does.

> > How should multiple remotes be handled? Split them out into
> > individual input devices, or group them onto a single IR device? I
> > can implement either.
> 
> Individual input devices, I'd say... so that app can only listen for
> 'its' remote.

I don't quite get it. How can we tell there are multiple remotes to set
up multiple input devices when the system comes up? All we can know
about at driver init time is the receiver(s), no? Or would this be keyed
off a config file? Or ______ ?


-- 
Jarod Wilson
jarod@wilsonet.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/