[lkml]   [2009]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
    On Fri, Dec 4, 2009 at 9:12 AM, Mauro Carvalho Chehab
    <> wrote:
    >> In-kernel decoding:

    [IR physical device] => [IR receiver driver] => [LIRC core] =>
    [decoder] => [IR core] => [input core] => [evdev]
    => [Lirc API device]>>
    >> Hardware decoder:
    >> [IR physical device] => [IR receiver driver] => [IR core]
    >>                                            => [input core] => [evdev]

    My hope is that 90% of users can achieve "just works" via these two
    models. There will need to be several default device/keymaps installed
    to avoid the need to configure. For example, have udev install a
    default map from Motorola DVR IR to Linux keycodes. Installing that
    map creates a new evdev device. Myth can then look for that device by
    default and listen to it. Now the user just needs to set their
    programmable remote to send Motorola DVR and everything should "just
    work". Pick similar default maps/evdev device for music players and
    home automation. Sophisticated users can change these default maps by
    editing the udev scripts.

    Long term the goal is to get IR profiles for Linux DVR, music player,
    home automation, etc in to the IR database. Then we won't have to
    override the profile for another company's device.

    I believe it is a requirement to send the decoded IR events up to user
    space (EV_IR). That would handle the case of the air conditioner
    remote. It also allows construction of an app that automatically
    searches the IR database for mapping tables. Normal apps would just
    ignore these events.

    Installing a map is what triggers the creation of another evdev
    device. There should be one evdev device per map installed. The
    current input API design does not provide for a way to do this.

    The only solution I see to automatic device creation is to monitor
    unmapped EV_IR events and search for them in the IR database. When a
    match is found, install the map from the database - which then
    triggers the creation of a new evdev device and the EV_IR event won't
    be unmapped any more. Searching is not a simple process since the same
    IR code often appears in more than one map. Some human intervention
    will probably be required.

    [IR physical device] => [IR receiver driver] => [LIRC core] =>
    [decoder] => [IR core] => [input core] => [evdev]
    => [Lirc API
    device] ==> [EV_IR

    The EV_IR events also allow a user space protocol decoder to inject
    those events back into the input subsystem where they will flow
    through the mapping tables.

    The in-kernel protocol decoders should be designed as a set of modules
    with the pulse data being simultaneously supplied to all modules. That
    will make it easy to work on the protocol converters - just
    insmod/rmmod as you make changes. These engines can be extracted from
    the LIRC code and turned into modules.

    Where are IR repeat bits going to be handled?

    Jon Smirl
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-12-04 16:45    [W:0.032 / U:15.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site