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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
