Revision tags: v4.10-rc6, v4.10-rc5, v4.10-rc4, v4.10-rc3, v4.10-rc2, v4.10-rc1, v4.9, v4.9-rc8, v4.9-rc7, v4.9-rc6, v4.9-rc5, v4.9-rc4, v4.9-rc3, v4.9-rc2, v4.9-rc1, v4.8, v4.8-rc8, v4.8-rc7, v4.8-rc6, v4.8-rc5, v4.8-rc4, v4.8-rc3, v4.8-rc2, v4.8-rc1, v4.7, v4.7-rc7, v4.7-rc6, v4.7-rc5, v4.7-rc4, v4.7-rc3, v4.7-rc2, v4.7-rc1, v4.6, v4.6-rc7, v4.6-rc6, v4.6-rc5, v4.6-rc4, v4.6-rc3, v4.6-rc2, v4.6-rc1, v4.5, v4.5-rc7, v4.5-rc6, v4.5-rc5, v4.5-rc4, v4.5-rc3, v4.5-rc2, v4.5-rc1, v4.4, v4.4-rc8, v4.4-rc7, v4.4-rc6, v4.4-rc5, v4.4-rc4, v4.4-rc3, v4.4-rc2 |
|
#
d80ca8bd |
| 16-Nov-2015 |
Heiner Kallweit <hkallweit1@gmail.com> |
[media] media: rc: move check whether a protocol is enabled to the core
Checking whether a protocol is enabled and calling the related decoder functions should be done by the rc core, not the protoc
[media] media: rc: move check whether a protocol is enabled to the core
Checking whether a protocol is enabled and calling the related decoder functions should be done by the rc core, not the protocol handlers.
Properly handle lirc considering that no protocol bit is set for lirc.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
show more ...
|
Revision tags: v4.4-rc1, v4.3, v4.3-rc7, v4.3-rc6, v4.3-rc5, v4.3-rc4, v4.3-rc3, v4.3-rc2, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1 |
|
#
c5540fbb |
| 03-Apr-2014 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: remove protocol arrays
The basic API of rc-core used to be:
dev = rc_allocate_device(); dev->x = a; dev->y = b; dev->z = c; rc_register_device();
which is a pretty common pat
[media] rc-core: remove protocol arrays
The basic API of rc-core used to be:
dev = rc_allocate_device(); dev->x = a; dev->y = b; dev->z = c; rc_register_device();
which is a pretty common pattern in the kernel, after the introduction of protocol arrays the API looks something like:
dev = rc_allocate_device(); dev->x = a; rc_set_allowed_protocols(dev, RC_BIT_X); dev->z = c; rc_register_device();
There's no real need for the protocols to be an array, so change it back to be consistent (and in preparation for the following patches).
[m.chehab@samsung.com: added missing changes at some files] Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
show more ...
|
Revision tags: v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5 |
|
#
1a1934fa |
| 28-Feb-2014 |
James Hogan <james.hogan@imgtec.com> |
[media] rc: abstract access to allowed/enabled protocols
The allowed and enabled protocol masks need to be expanded to be per filter type in order to support wakeup filter protocol selection. To eas
[media] rc: abstract access to allowed/enabled protocols
The allowed and enabled protocol masks need to be expanded to be per filter type in order to support wakeup filter protocol selection. To ease that process abstract access to the rc_dev::allowed_protos and rc_dev::enabled_protocols members with inline functions.
Signed-off-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
show more ...
|
Revision tags: v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11, v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1, v3.10, v3.10-rc7, v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2, v3.10-rc1, v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5, v3.9-rc4, v3.9-rc3, v3.9-rc2 |
|
#
9719afae |
| 06-Mar-2013 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: don't treat dev->rc_map.rc_type as a bitmap
store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for two reasons. First of all, it is pretty bogus to change the p
[media] rc-core: don't treat dev->rc_map.rc_type as a bitmap
store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for two reasons. First of all, it is pretty bogus to change the protocol type of the keymap just because the hardware has been asked to decode a different protocol. Second, dev->rc_map.rc_type is an enum (i.e. a single protocol) as pointed out by James Hogan <james.hogan@imgtec.com>. Fix both issues by introducing a separate enabled_protocols member to struct rc_dev.
Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
show more ...
|
Revision tags: v3.9-rc1, v3.8, v3.8-rc7, v3.8-rc6, v3.8-rc5, v3.8-rc4, v3.8-rc3, v3.8-rc2, v3.8-rc1, v3.7, v3.7-rc8, v3.7-rc7, v3.7-rc6, v3.7-rc5, v3.7-rc4, v3.7-rc3, v3.7-rc2, v3.7-rc1 |
|
#
c003ab1b |
| 11-Oct-2012 |
David Härdeman <david@hardeman.nu> |
[media] rc-core: add separate defines for protocol bitmaps and numbers
The RC_TYPE_* defines are currently used both where a single protocol is expected and where a bitmap of protocols is expected.
[media] rc-core: add separate defines for protocol bitmaps and numbers
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: David 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: Mauro Carvalho Chehab <mchehab@redhat.com>
show more ...
|
Revision tags: v3.6, v3.6-rc7, v3.6-rc6, v3.6-rc5, v3.6-rc4, v3.6-rc3, v3.6-rc2, v3.6-rc1, v3.5, v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4, v3.5-rc3, v3.5-rc2, v3.5-rc1, v3.4, v3.4-rc7, v3.4-rc6, v3.4-rc5, v3.4-rc4, v3.4-rc3, v3.4-rc2, v3.4-rc1, v3.3, v3.3-rc7, v3.3-rc6, v3.3-rc5, v3.3-rc4, v3.3-rc3, v3.3-rc2, v3.3-rc1, v3.2, v3.2-rc7, v3.2-rc6, v3.2-rc5, v3.2-rc4, v3.2-rc3, v3.2-rc2, v3.2-rc1, v3.1, v3.1-rc10, v3.1-rc9, v3.1-rc8, v3.1-rc7, v3.1-rc6, v3.1-rc5, v3.1-rc4, v3.1-rc3, v3.1-rc2, v3.1-rc1 |
|
#
ee2ce3a0 |
| 29-Jul-2011 |
Stephen Rothwell <sfr@canb.auug.org.au> |
[media] ir-mce_kbd-decoder: include module.h for its facilities
drivers/media/rc/ir-mce_kbd-decoder.c:446:16: error: expected declaration specifiers or '...' before string constant drivers/media/rc/
[media] ir-mce_kbd-decoder: include module.h for its facilities
drivers/media/rc/ir-mce_kbd-decoder.c:446:16: error: expected declaration specifiers or '...' before string constant drivers/media/rc/ir-mce_kbd-decoder.c:446:1: warning: data definition has no type or storage class drivers/media/rc/ir-mce_kbd-decoder.c:446:1: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE' drivers/media/rc/ir-mce_kbd-decoder.c:446:16: warning: function declaration isn't a prototype drivers/media/rc/ir-mce_kbd-decoder.c:447:15: error: expected declaration specifiers or '...' before string constant drivers/media/rc/ir-mce_kbd-decoder.c:447:1: warning: data definition has no type or storage class drivers/media/rc/ir-mce_kbd-decoder.c:447:1: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR' drivers/media/rc/ir-mce_kbd-decoder.c:447:15: warning: function declaration isn't a prototype drivers/media/rc/ir-mce_kbd-decoder.c:448:20: error: expected declaration specifiers or '...' before string constant drivers/media/rc/ir-mce_kbd-decoder.c:448:1: warning: data definition has no type or storage class drivers/media/rc/ir-mce_kbd-decoder.c:448:1: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION' drivers/media/rc/ir-mce_kbd-decoder.c:448:20: warning: function declaration isn't a prototype
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
show more ...
|
Revision tags: v3.0 |
|
#
f5f2cc64 |
| 13-Jul-2011 |
Jarod Wilson <jarod@redhat.com> |
[media] rc-core support for Microsoft IR keyboard/mouse
This is a custom IR protocol decoder, for the RC-6-ish protocol used by the Microsoft Remote Keyboard, apparently developed internally at Micr
[media] rc-core support for Microsoft IR keyboard/mouse
This is a custom IR protocol decoder, for the RC-6-ish protocol used by the Microsoft Remote Keyboard, apparently developed internally at Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and transceiver requirements and specifications document, which also touches on this IR keyboard/mouse device.
Its a standard keyboard with embedded thumb stick mouse pointer and mouse buttons, along with a number of media keys. The media keys are standard RC-6, identical to the signals from the stock MCE remotes, and will be handled as such. The keyboard and mouse signals will be decoded and delivered to the system by an input device registered specifically by this driver.
Successfully tested with multiple mceusb-driven transceivers, as well as with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware with enough sampling resolution should be able to use this decoder, nothing about it is at all receiver-hardware-specific.
This work is inspired by lirc_mod_mce:
The documentation there and code aided in understanding and decoding the protocol, but the bulk of the code is actually borrowed more from the existing in-kernel decoders than anything. I did recycle the keyboard keycode table, a few defines, and some of the keyboard and mouse data parsing bits from lirc_mod_mce though.
Special thanks to James Meyer for providing the hardware, and being patient with me as I took forever to get around to writing this.
callback routine to ensure we don't get any stuck keys, and used symbolic names for the keytable. Also cc'ing Florian this time, who I believe is the original mod-mce author...
CC: Florian Demski <fdemski@users.sourceforge.net> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
show more ...
|