• D
    [media] rc-core: add separate defines for protocol bitmaps and numbers · c003ab1b
    David Härdeman 提交于
    The RC_TYPE_* defines are currently used both where a single protocol is
    expected and where a bitmap of protocols is expected.
    
    Functions like rc_keydown() and functions which add/remove entries to the
    keytable want a single protocol. Future userspace APIs would also
    benefit from numeric protocols (rather than bitmap ones). Keytables are
    smaller if they can use a small(ish) integer rather than a bitmap.
    
    Other functions or struct members (e.g. allowed_protos,
    enabled_protocols, etc) accept multiple protocols and need a bitmap.
    
    Using different types reduces the risk of programmer error. Using a
    protocol enum whereever possible also makes for a more future-proof
    user-space API as we don't need to worry about a sufficient number of
    bits being available (e.g. in structs used for ioctl() calls).
    
    The use of both a number and a corresponding bit is dalso one in e.g.
    the input subsystem as well (see all the references to set/clear bit when
    changing keytables for example).
    
    This patch separate the different usages in preparation for
    upcoming patches.
    
    Where a single protocol is expected, enum rc_type is used; where one or more
    protocol(s) are expected, something like u64 is used.
    
    The patch has been rewritten so that the format of the sysfs "protocols"
    file is no longer altered (at the loss of some detail). The file itself
    should probably be deprecated in the future though.
    Signed-off-by: NDavid Härdeman <david@hardeman.nu>
    Cc: Andy Walls <awalls@md.metrocast.net>
    Cc: Maxim Levitsky <maximlevitsky@gmail.com>
    Cc: Antti Palosaari <crope@iki.fi>
    Cc: Mike Isely <isely@pobox.com>
    Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
    c003ab1b
gpio-ir-recv.c 4.9 KB