[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100330110957.GB6164@hardeman.nu>
Date: Tue, 30 Mar 2010 13:09:57 +0200
From: David Härdeman <david@...deman.nu>
To: Mauro Carvalho Chehab <mchehab@...hat.com>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Jon Smirl <jonsmirl@...il.com>, Pavel Machek <pavel@....cz>,
Krzysztof Halasa <khc@...waw.pl>,
hermann pitton <hermann-pitton@...or.de>,
Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
j@...nau.net, jarod@...hat.com, jarod@...sonet.com,
kraxel@...hat.com, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
IR system?
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.
--
David Härdeman
--
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/
Powered by blists - more mailing lists