Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> 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. > (what's worse is that it is defined as "int" instead of "u32" - so the number > of bits is different on 32 and on 64 systems) Most (all?) 64-bit systems use 32-bit ints (and 64-bit longs). u32 and similar are for sure better. >> We signal both and hope it isn't self-destruct button. >> We can't fix it no matter how hard we try. > > We can fix. Just let the userspace select what protocol(s) is(are) enabled. Sure, I meant the situation when both protocols (and scan codes) where enabled and configured. If we don't use RCx in the mapping table, we don't pass anything to RCx routine. If we have RCx but don't have the scan code in question, we don't find the key in the table and thus we ignore it again. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
