lkml.org 
[lkml]   [2009]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC v2] Another approach to IR
    Date
    Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:

    > On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
    >> Ferenc Wagner wrote:
    >>> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
    >>
    >> We should not forget that simple IR's don't have any key to select the address,
    >> so the produced codes there will never have KEY_TV/KEY_DVD, etc.
    >
    > Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
    > media inputs in a device/application. My receiver accepts codes like
    > that.

    Sorry, my point wasn't the event names, I picked them for their
    superficial correspondence to the TV, DVD, SAT etc. buttons found on
    multifunction remotes. Obviously I picked wrong.

    I was also wrong to assume that remotes with such buttons are always
    multifunction remotes in the sense that they are meant to control
    separate devices. As Mauro pointed out, (some) bundled remotes with
    such buttons aren't; thus I wouldn't consider them multifunction at all.
    They simply have some extra buttons labelled TV, DVD etc, which probably
    shouldn't be mapped to KEY_TV, KEY_DVD etc. (since those events carry
    different semantics) but should be mapped to something else. Or not, if
    these buttons change some internal decoder state instead, modifying the
    mapping or destination input device of the other keys.

    It's just a different scenario, where the kernel could reasonably give
    rather different representations to simple applications aiming at
    plug&play: letting through the function change events untouched, or
    masking and using them internally.

    True multifunction devices don't send such events, the TV, DVD etc
    buttons on them change their internal state and the scan codes sent by
    the other keys, if I understand this correctly.

    I'd prefer if these two behaviours could be abstacted from, and the
    input layer interface would provide destination selection events +
    generic events, or (to be defined) device specific events only in either
    case. Is that possible or even reasonable?
    --
    Thanks,
    Feri.

    Ps: I'm writing this in the hope to clean up the landscape and possibly
    help in choosing the best design. I'm not at all familiar with IR, and
    the above distinction was pretty surprising for me. Also, I'm just
    lurking here, so don't take me too seriously. :)


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