[lkml]   [2009]   [Nov]   [27]   [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?
    Jon Smirl wrote:
    > 3) No special tools - use mkdir, echo, cat, shell scripts to build maps

    From the POV of a distributor, there is always a special tool required.
    Whether it is implemented in bash, Python, or C doesn't make a
    difference to him.

    For an enduser whose distributor doesn't package that tool, it also
    doesn't matter whether it is bash or Python. (C is awkward because it
    needs to be run through gcc first.) A Pyton tool can operate the
    existing EVIOCSKEYCODE interface just as well as a C tool.

    Your mkdir/ echo/ cat programs would still just this: Programs. Sure,
    these programs would be interpreted by an interpreter which is installed
    everywhere, and the data they operate on is in a clear text format. The
    downside is that these programs do not exist yet.

    > 5) Direct multi-app support - no daemon

    Think of lircd (when it feeds into uinput) as of a userspace driver
    rather than a daemon. The huge benefit of a userspace driver is that it
    can load configuration files.

    Multi-app support is provided by evdev of course.

    > What are other goals for this subsystem?

    - Minimal development cost; reduced maintenance cost relative
    the to status quo.

    - No regressions would be best.
    Stefan Richter
    -=====-==--= =-== ==-==

     \ /
      Last update: 2009-11-27 22:53    [W:0.025 / U:135.132 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site