From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure Date: Thu, 26 Nov 2009 15:14:36 -0800 Message-ID: <20091126231436.GC6936@core.coreip.homeip.net> References: <4B0A81BF.4090203@redhat.com> <4B0AC65C.806@redhat.com> <4B0E765C.2080806@redhat.com> <4B0ED238.6060306@redhat.com> <4B0EED7D.90204@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pw0-f42.google.com ([209.85.160.42]:57974 "EHLO mail-pw0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750919AbZKZXOe (ORCPT ); Thu, 26 Nov 2009 18:14:34 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Krzysztof Halasa Cc: Mauro Carvalho Chehab , Jarod Wilson , linux-kernel@vger.kernel.org, Mario Limonciello , linux-input@vger.kernel.org, linux-media@vger.kernel.org, Janne Grunau , Christoph Bartelmus On Thu, Nov 26, 2009 at 10:27:08PM +0100, Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > > > No. All the other API functions there work with 32 bits for scancodes. > > We don't need them, do we? We need a new ioctl for changing key mappings > anyway (a single ioctl for setting the whole table I think), and we can > have arbitrary length of scan codes there. Unless we determine that we 100% need bigger size of scancode then the current ioctls are just fine. Why do we _need_ an ioctl to load the whole tabe? Are you concerned about speed with which the keymap is populated? I don't think it would be an issue. -- Dmitry