lkml.org 
[lkml]   [2009]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
    On 11/30/09 13:34, Mauro Carvalho Chehab wrote:
    > Christoph Bartelmus wrote:
    >> Hi Mauro,
    >>
    >> I just don't want to change a working interface just because it could be
    >> also implemented in a different way, but having no other visible advantage
    >> than using more recent kernel features.
    >
    > I agree. The main reasons to review the interface is:
    > 1) to avoid any overlaps (if are there any) with the evdev interface;

    Use lirc for raw samples.
    Use evdev for decoded data.

    Hardware/drivers which can handle both can support both interfaces.

    IMHO it makes no sense at all to squeeze raw samples through the input
    layer. It looks more like a serial line than a input device. In fact
    you can homebrew a receiver and connect it to the serial port, which was
    quite common in pre-usb-ir-receiver times.

    > 2) to have it stable enough to be used, without changes, for a long
    > time.

    It isn't like lirc is a new interface. It has been used in practice for
    years. I don't think API stability is a problem here.

    > True, but even if we want to merge lirc drivers "as-is", the drivers will
    > still need changes, due to kernel CodingStyle, due to the usage of some API's
    > that may be deprecated, due to some breakage with non-Intel architectures, due
    > to some bugs that kernel hackers may discover, etc.

    I assumed this did happen in already in preparation of this submission?

    cheers,
    Gerd



    \
     
     \ /
      Last update: 2009-12-01 10:55    [W:3.041 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site