lkml.org 
[lkml]   [2009]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
    From
    On Fri, Dec 4, 2009 at 8:48 PM, Andy Walls <awalls@radix.net> wrote:
    > On Fri, 2009-12-04 at 19:28 -0500, Jon Smirl wrote:
    >> On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
    >> > BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
    >> > codes. Anyone here has docs on the XMP protocol?
    >>
    >> Assuming a general purpose receiver (not one with fixed hardware
    >> decoding), is it important for Linux to receive IR signals from all
    >> possible remotes no matter how old or obscure?
    >
    > Importance of any particular requirement is relative/subjective.  As is
    > usefulness of any existing functionality.
    >
    > Personally, I just think it's cool to pick up a random remote and use
    > Linux to figure out its protocol and its codes and get it working.

    You are a technical user.

    >
    >
    >
    >>  Or is it acceptable to
    >> tell the user to throw away their dedicated remote and buy a universal
    >> multi-function one?
    >
    > Nope.  That other OS provider forces device obsolescence or arbitrary
    > constraints on users quite often and I don't like it myself.  That's why
    > I use Linux.
    >
    >
    >>   Universal multi-function remotes are $12 in my
    >> grocery store - I don't even have to go to an electronics store.
    >
    > The old remote in my possession costs $0, and I don't even have to leave
    > the house.
    >
    >
    >> I've been working off the premise of getting rid of obscure remotes
    >> and replacing them with a universal one. The universal one can be set
    >> to send a common protocol like JVC or Sony. That implies that we only
    >> need one or two protocol decoders in-kernel which greatly reduces the
    >> surface area of the problem.
    >
    > The design should serve the users, the users should not serve the
    > design.  If the reduction of requirements scope starts forcing users to
    > buy new hardware, are we really serving the users or just asking them to
    > pay to compensate for our shortcomings?

    Use of arbitrary remotes is a complex process. It almost certainly can
    not be done in a transparent "just works" manner.

    Let me rephrase, is it ok to tell people to buy a new remote if they
    want to avoid a complex, technical configuration process that isn't
    even guaranteed to work (they might have a 56K remote and a 38K
    receiver or a Sony remote and a fixed RC-5 receiver).

    I'm not proposing that we prevent arbitrary remotes from working,
    you're just going to need to expend more effort to make them work.
    For example, you have to have a fair amount of IR knowledge to figure
    out why those two cases above don't work. You might have to install
    LIRC and futz with irrecord and build your own config files and
    mapping tables, etc...

    It doesn't have to only be a universal remote, we can pre-install
    mapping tables for the remotes commonly shipped with the v4l hardware.
    When the v4l drivers load they could even poke the default map for
    their bundled remotes directly into the input system if they wanted
    to. Doing that might save a lot of config issues.

    How this for new goals?
    Specific IR drivers autoload maps for their bundled remotes by
    poking them into the input subsystem during module load
    IR always has default map for a universal remote - it provides five
    devices and uses a common protocol like JVC (may not work for fixed
    hardware, you have to set these five common devices into the universal
    remote)
    All of these maps can be overriden with user space commands (which
    lets you configure funky remotes)

    --
    Jon Smirl
    jonsmirl@gmail.com
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-12-05 04:49    [W:4.208 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site