Eric Lee / smarc-fsl-linux-kernel

22 Sep, 2016

1 commit

  • 2ceeca049   [media] rc: split nec protocol into its three variants ... Browse Code »

    Currently we do not know what variant (bit length) of the nec protocol
    is used, other than from guessing from the length of the scancode. Now
    nec will be handled the same way as the sony protocol or the rc6 protocol;
    one variant per bit length.

    In the future we might want to expose the rc protocol type to userspace
    and we don't want to be introducing this world of pain into userspace
    too.

    Signed-off-by: Sean Young
    Signed-off-by: Mauro Carvalho Chehab

    Sean Young
     

09 Sep, 2016

2 commits

23 Jul, 2016

1 commit

  • c278256d0   Merge branch 'patchwork' into topic/docs-next ... Browse Code »

    * patchwork: (1492 commits)
    [media] cec: always check all_device_types and features
    [media] cec: poll should check if there is room in the tx queue
    [media] vivid: support monitor all mode
    [media] cec: fix test for unconfigured adapter in main message loop
    [media] cec: limit the size of the transmit queue
    [media] cec: zero unused msg part after msg->len
    [media] cec: don't set fh to NULL in CEC_TRANSMIT
    [media] cec: clear all status fields before transmit and always fill in sequence
    [media] cec: CEC_RECEIVE overwrote the timeout field
    [media] cxd2841er: Reading SNR for DVB-C added
    [media] cxd2841er: Reading BER and UCB for DVB-C added
    [media] cxd2841er: fix switch-case for DVB-C
    [media] cxd2841er: fix signal strength scale for ISDB-T
    [media] cxd2841er: adjust the dB scale for DVB-C
    [media] cxd2841er: provide signal strength for DVB-C
    [media] cxd2841er: fix BER report via DVBv5 stats API
    [media] mb86a20s: apply mask to val after checking for read failure
    [media] airspy: fix error logic during device register
    [media] s5p-cec/TODO: add TODO item
    [media] cec/TODO: drop comment about sphinx documentation
    ...

    Signed-off-by: Mauro Carvalho Chehab

    Mauro Carvalho Chehab
     

18 Jul, 2016

1 commit

09 Jul, 2016

1 commit

  • a4d020e97   [media] Convert Wideview WT220 DVB USB driver to rc-core ... Browse Code »

    Converts the dtt200u DVB USB driver over to the rc-core
    infrastructure for its handling of IR remotes. This device can receive
    generic NEC / NEC Extended signals and the switch to the newer core
    enables the easy use of tools such as ir-keytable to modify the active
    key map.

    Signed-off-by: Jonathan McDowell
    Signed-off-by: Mauro Carvalho Chehab

    Jonathan McDowell
     

22 Jun, 2016

1 commit

19 Nov, 2015

1 commit

06 Jul, 2015

1 commit

  • 275ddb40b   [media] rc-core: remove the LIRC "protocol" ... Browse Code »

    The LIRC protocol was always a bad fit and if we're ever going to expose
    protocol numbers in a user-space API, it'd be better to get rid of the
    LIRC "protocol" first.

    The sysfs API is kept backwards compatible by always listing the lirc
    protocol as present and enabled.

    Signed-off-by: David Härdeman
    Signed-off-by: Mauro Carvalho Chehab

    David Härdeman
     

10 Jun, 2015

4 commits

24 Sep, 2014

1 commit

27 Jul, 2014

1 commit

24 Jul, 2014

1 commit

07 Feb, 2014

1 commit

04 Feb, 2014

1 commit

11 Dec, 2013

1 commit

21 May, 2013

1 commit

  • 3020bea57   [media] rc: Add rc-delock-61959 ... Browse Code »

    This adds the keytable for the remote that comes with the Delock 61959.
    NEC protocol with address 0x866b.

    Signed-off-by: Jakob Haufe
    Reviewed-by: Antti Palosaari
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab

    Jakob Haufe
     

15 Apr, 2013

1 commit

  • 52f5ad6c5   [media] rc: add rc-reddo ... Browse Code »

    It is very similar than rc-msi-digivox-iii but new keytable is needed
    as there is one existing scancode mapped to different button. Also that
    one has less buttons.
    NEC extended protocol with address 0x61d6.

    Signed-off-by: Antti Palosaari
    Signed-off-by: Mauro Carvalho Chehab

    Antti Palosaari
     

24 Dec, 2012

1 commit

27 Oct, 2012

1 commit

  • c003ab1be   [media] rc-core: add separate defines for protocol bitmaps and numbers ... Browse Code »

    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
    Cc: Andy Walls
    Cc: Maxim Levitsky
    Cc: Antti Palosaari
    Cc: Mike Isely
    Signed-off-by: Mauro Carvalho Chehab

    David Härdeman
     

21 May, 2012

1 commit

20 May, 2012

1 commit

  • 5085c99ee   [media] ati_remote: add keymap for Medion X10 OR2x remotes ... Browse Code »

    Add another Medion X10 remote keymap. This is for the Medion OR2x
    remotes with the Windows MCE button.

    The receiver shipped with this remote has the same USB ID as the other
    Medion receivers, but the name is different and is therefore used to
    detect this variant.

    Signed-off-by: Anssi Hannula
    Signed-off-by: Mauro Carvalho Chehab

    Anssi Hannula
     

11 Apr, 2012

1 commit

  • 9d454d48e   [media] ati_remote: add support for Medion X10 Digitainer remote ... Browse Code »

    Add support for another Medion X10 remote. This was apparently
    originally used with the Medion Digitainer box, but is now sold
    separately without any Digitainer labeling.

    A peculiarity of this remote is a scrollwheel in place of up/down
    buttons. Each direction is mapped to 8 different scancodes, each
    corresponding to 1..8 notches, allowing multiple notches to the same
    direction to be transmitted in a single scancode. The driver transforms
    the multi-notch scancodes to multiple events of the single-notch
    scancode.
    (0x70..0x77 = 1..8 notches down, 0x78..0x7f = 1..8 notches up)

    Since the scrollwheel scancodes are the same that are used for mouse on
    some other X10 (ati_remote) remotes, the driver will now check whether
    the active keymap has a keycode defined for the single-notch scancode
    when a mouse/scrollwheel scancode (0x70..0x7f) is received. If set,
    scrollwheel is assumed, otherwise mouse is assumed.

    This remote ships with a different receiver than the already supported
    Medion X10 remote, but they share the same USB ID. The only difference
    in the USB descriptors is that the Digitainer receiver has the Remote
    Wakeup bit set in bmAttributes of the Configuration Descriptor.
    Therefore that is used to select the default keymap.

    Thanks to Stephan Raue from OpenELEC (www.openelec.tv) for providing me
    both a Medion X10 Digitainer remote+receiver and an already supported
    Medion X10 remote+receiver. Thanks to Martin Beyss for providing some
    useful information about the remote (including the "Digitainer" name).
    This patch has been tested by both of them and myself.

    Signed-off-by: Anssi Hannula
    Tested-by: Stephan Raue
    Tested-by: Martin Beyss
    Signed-off-by: Mauro Carvalho Chehab

    Anssi Hannula
     

08 Mar, 2012

1 commit

15 Feb, 2012

1 commit

11 Jan, 2012

1 commit

  • 0963119fc   [media] rc-videomate-m1f.c Rename to match remote controler name ... Browse Code »

    This remote was added with support for card Compro VideoMate M1F.

    This remote is shipped with various Compro cards, not this one only.

    Furthermore this remote can be bought separately under name Compro
    VideoMate K100.
    http://compro.com.tw/en/product/k100/k100.html

    So give it a proper name.

    [mchehab@redhat.com: Fix the Makefile]
    Signed-off-by: Samuel Rakitničan
    Signed-off-by: Mauro Carvalho Chehab

    Samuel Rakitnican
     

24 Nov, 2011

1 commit

22 Sep, 2011

3 commits

28 Jul, 2011

1 commit

  • f5f2cc646   [media] rc-core support for Microsoft IR keyboard/mouse ... Browse Code »

    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
    Signed-off-by: Jarod Wilson
    Signed-off-by: Mauro Carvalho Chehab

    Jarod Wilson
     

20 May, 2011

1 commit

23 Mar, 2011

1 commit

  • 15195d3a8   [media] rc/keymaps: Rename Hauppauge table as rc-hauppauge ... Browse Code »

    There are two "hauppauge-new" keymaps, one with protocol
    unknown, and the other with the protocol marked accordingly.
    However, both tables are miss-named.

    Also, the old rc-hauppauge-new is broken, as it mixes
    three different controllers as if they were just one.

    This patch solves half of the problem by renaming the
    correct keycode table as just rc-hauppauge. This table
    contains the codes for the four different types of
    remote controllers found on Hauppauge cards, properly
    mapped with their different addresses.

    create mode 100644 drivers/media/rc/keymaps/rc-hauppauge.c
    delete mode 100644 drivers/media/rc/keymaps/rc-rc5-hauppauge-new.c
    [Jarod: fix up RC_MAP_HAUPPAUGE defines]

    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Jarod Wilson

    Mauro Carvalho Chehab
     

22 Mar, 2011

2 commits

  • 638b53f80   [media] add TerraTec remote ... Browse Code »

    Remote used for TerraTec Cinergy T Stick RC.
    Keytable from Martin Groszhauser

    Signed-off-by: Antti Palosaari
    Cc: Martin Groszhauser
    Cc: TerraTux
    Signed-off-by: Mauro Carvalho Chehab

    Antti Palosaari
     
  • 739ff04f6   [media] technisat-usb2: added driver for Technisat's USB2.0 DVB-S/S2 receiver ... Browse Code »

    This patch is adding support for Technisat's new USB2.0 DVB-S/S2 receiver
    device. The development was sponsored by Technisat.

    The Green led is toggle depending on the frontend-state. The Red LED is turned
    on all the time.

    The MAC address reading from the EEPROM along with the
    LRC-method to check whether its valid.

    Support for the IR-receiver of the Technisat USB2 box. The keys of
    small, black remote-control are built-in, repeated key behaviour are
    simulated.

    The i2c-mutex of the dvb-usb-structure is used as a general mutex for
    USB requests, as there are 3 threads racing for atomic requests
    consisting of multiple usb-requests.

    A module option is there which disables the toggling of LEDs by the
    driver on certain triggers. Useful when being used in a "dark"
    environment.

    [mchehab@redhat.com: Fix merge conflicts with RC renaming patches]
    Signed-off-by: Martin Wilks
    Signed-off-by: Patrick Boettcher
    Signed-off-by: Mauro Carvalho Chehab

    Patrick Boettcher
     

29 Dec, 2010

2 commits