lkml.org 
[lkml]   [2009]   [Dec]   [4]   [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 Sat, Dec 05, 2009 at 12:01:00AM +0100, Christoph Bartelmus wrote:
    > Hi Dmitry,
    >
    > on 04 Dec 09 at 14:07, Dmitry Torokhov wrote:
    > > On Fri, Dec 04, 2009 at 10:46:00PM +0100, Christoph Bartelmus wrote:
    > >> Hi Mauro,
    > >>
    > >> on 04 Dec 09 at 12:33, Mauro Carvalho Chehab wrote:
    > >>> Christoph Bartelmus wrote:
    > >>>>>> Consider passing the decoded data through lirc_dev.
    > >> [...]
    > >>>> Consider cases like this:
    > >>>> http://lirc.sourceforge.net/remotes/lg/6711A20015N
    > >>>>
    > >>>> This is an air-conditioner remote.
    > >>>> The entries that you see in this config file are not really separate
    > >>>> buttons. Instead the remote just sends the current settings for e.g.
    > >>>> temperature encoded in the protocol when you press some up/down key. You
    > >>>> really don't want to map all possible temperature settings to KEY_*
    > >>>> events. For such cases it would be nice to have access at the raw scan
    > >>>> codes from user space to do interpretation of the data.
    > >>>> The default would still be to pass the data to the input layer, but it
    > >>>> won't hurt to have the possibility to access the raw data somehow.
    > >>
    > >>> Interesting. IMHO, the better would be to add an evdev ioctl to return the
    > >>> scancode for such cases, instead of returning the keycode.
    > >>
    > >> That means you would have to set up a pseudo keymap, so that you can get
    > >> the key event which you could than react on with a ioctl. Or are you
    > >> generating KEY_UNKNOWN for every scancode that is not mapped?
    > >> What if different scan codes are mapped to the same key event? How do you
    > >> retrieve the scan code for the key event?
    > >> I don't think it can work this way.
    > >>
    >
    > > EV_MSC/MSC_SCAN.
    >
    > How would I get the 64 bit scan codes that the iMON devices generate?
    > How would I know that the scan code is 64 bit?
    > input_event.value is __s32.
    >

    I suppose we could add MSC_SCAN_END event so that we can transmit
    "scancodes" of arbitrary length. You'd get several MSC_SCAN followed by
    MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32
    bit.

    FWIW there is MSC_RAW as well.

    --
    Dmitry


    \
     
     \ /
      Last update: 2009-12-05 00:17    [W:0.026 / U:31.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site