lkml.org 
[lkml]   [2009]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
    Date
    Mauro Carvalho Chehab <mchehab@redhat.com> writes:

    >> I do not believe you are being realistic. Sometimes we just need to say
    >> that the device is a POS and is just not worth it. Remember, there is
    >> still "lirc hole" for the hard core people still using solder to produce
    >> something out of the spare electronic components that may be made to
    >> work

    Which device? It was about a remote controller, not the receiver. The IR
    receivers are frequently coupled with a DVB etc. receiver. There is
    absolutely no problem supporting almost any remote if the hardware is
    compatible with the receiver (i.e. IR to IR, the carrier frequency is
    not 36 vs 56 kHz, the receiver supports the protocol etc).

    I don't say we need to support in-kernel decoding for arbitrary
    protocols.

    >> (never mind that it causes the CPU constantly poll the device, not
    >> letting it sleep and wasting electricity as a result - just hypotetical
    >> example here).

    Very hypotetical, indeed :-)

    Most (all?) home-made receivers don't need polling, they use IRQs
    instead ("the" home-made receiver is based on serial port and uses IRQ).
    They are hardly the "obscure hardware" that nobody has.

    The "more advanced" receivers using shift registers may use polling.

    > Fully agreed. The costs (our time) to add and keep supporting an in-kernel
    > driver for an IR that just one person is still using is higher than
    > asking the user to get a new IR. This time would be better spent adding a new
    > driver for other devices.

    Agreed, I think nobody argues we should support such things in the
    kernel.


    Once again: how about agreement about the LIRC interface
    (kernel-userspace) and merging the actual LIRC code first? In-kernel
    decoding can wait a bit, it doesn't change any kernel-user interface.
    --
    Krzysztof Halasa


    \
     
     \ /
      Last update: 2009-12-06 18:51    [W:8.002 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site