From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756023Ab0C3Mnz (ORCPT ); Tue, 30 Mar 2010 08:43:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50290 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755477Ab0C3Mnx (ORCPT ); Tue, 30 Mar 2010 08:43:53 -0400 Message-ID: <4BB1F1E5.9000703@redhat.com> Date: Tue, 30 Mar 2010 09:43:17 -0300 From: Mauro Carvalho Chehab User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Mauro Carvalho Chehab , Dmitry Torokhov , Jon Smirl , Pavel Machek , Krzysztof Halasa , hermann pitton , Christoph Bartelmus , awalls@radix.net, j@jannau.net, jarod@redhat.com, jarod@wilsonet.com, kraxel@redhat.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, superm1@ubuntu.com Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? References: <20091215201933.GK24406@elf.ucw.cz> <9e4733910912151229o371ee017tf3640d8f85728011@mail.gmail.com> <20091215203300.GL24406@elf.ucw.cz> <9e4733910912151245ne442a5dlcfee92609e364f70@mail.gmail.com> <9e4733910912151338n62b30af5i35f8d0963e6591c@mail.gmail.com> <4BAB7659.1040408@redhat.com> <20100326112755.GB5387@hardeman.nu> <4BACC769.6020906@redhat.com> <20100326160150.GA28804@core.coreip.homeip.net> <4BAFE4B7.2030204@redhat.com> <20100330110957.GB6164@hardeman.nu> In-Reply-To: <20100330110957.GB6164@hardeman.nu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Härdeman wrote: > On Sun, Mar 28, 2010 at 08:22:31PM -0300, Mauro Carvalho Chehab wrote: >> I also noticed another problem: kernel should have some way to report >> the expected >> size of the scancode to userspace, especially if we want to have the compatibility >> code (since, with compat, a scancode maximum size need to be 32 bits, otherwise >> the code won't work). >> >> I'll likely adding another control that returns the size of the scancode. > > And perhaps the interface should explicitly define that for the case > where userspace sends an undersized scancode, the real scancode will be > generated by zero-extending the undersized scancode into its expected > size. > > That way the interface will be binary-forwards-compatible even if > scancode sizes are increased at some later date. Makes sense. Padding an undersized scancode is endian-dependent. So, we'll likely need to add some padding functions. The better seems to add the logic at include/linux/byteorder/generic.h. -- Cheers, Mauro