Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753561AbZKWRjr (ORCPT ); Mon, 23 Nov 2009 12:39:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753381AbZKWRjq (ORCPT ); Mon, 23 Nov 2009 12:39:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40882 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752287AbZKWRjp (ORCPT ); Mon, 23 Nov 2009 12:39:45 -0500 Message-ID: <4B0AC8C9.6080504@redhat.com> Date: Mon, 23 Nov 2009 15:39:21 -0200 From: Mauro Carvalho Chehab User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Stefan Richter CC: Krzysztof Halasa , Jarod Wilson , Dmitry Torokhov , linux-kernel@vger.kernel.org, Mario Limonciello , linux-input@vger.kernel.org, linux-media@vger.kernel.org, Janne Grunau , Christoph Bartelmus Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure References: <200910200956.33391.jarod@redhat.com> <200910200958.50574.jarod@redhat.com> <4B0A765F.7010204@redhat.com> <4B0A81BF.4090203@redhat.com> <4B0AB60B.2030006@s5r6.in-berlin.de> In-Reply-To: <4B0AB60B.2030006@s5r6.in-berlin.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2159 Lines: 48 Stefan Richter wrote: > Krzysztof Halasa wrote: >> Mauro Carvalho Chehab writes: >> >>> Event input has the advantage that the keystrokes will provide an unique >>> representation that is independent of the device. >> This can hardly work as the only means, the remotes have different keys, >> the user almost always has to provide customized key<>function mapping. > > Modern input drivers in the mainline kernel have a scancode-to-keycode > translation table (or equivalent) which can be overwritten by userspace. > The mechanism to do that is the EVIOCSKEYCODE ioctl. This mechanism is already used by all V4L drivers and several DVB drivers. > (This is no recommendation for lirc. I have no idea whether a > pulse/space -> scancode -> keycode translation would be practical there.) pulse/space -> scancode translation is already done by several existing drivers. For example, there are several bttv and saa7134 devices that polls (or receive IRQ interrupts) to detect pulses (and the absense of them) in order to create a pulse/space code. The conversion from pulse/space to scancode is done inside the driver, with the help of some generic routines and based on the protocol specifications. The conversion from the scancode to a keycode is done based on in-kernel keycode tables that can be changed from userspace with EVIOCSKEYCODE ioctl. I can't see any technical reason why not doing the same for the lirc drivers, except for one issue: Those devices where the decoding is done by software can support any IR protocols. So, it is possible to buy a device with a NEC IR, and use a RC5 IR to control it. However, currently, there's no way to inform the kernel to use a different algorithm to translate the kernel. This can be solved by adding a few ioctls to enumerate the supported protocols and to select the one(s) that will be handled by the kernel driver. Cheers, Mauro -- 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/