lkml.org 
[lkml]   [2009]   [Dec]   [7]   [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?
    Krzysztof Halasa wrote:
    > Mauro Carvalho Chehab <mchehab@redhat.com> writes:
    >

    >> struct input_keytable_entry {
    >> u16 index;
    >> u64 scancode;
    >> u32 keycode;
    >> } __attribute__ ((packed));
    >>
    >> (the attribute packed avoids needing a compat for 64 bits)
    >
    > Maybe { u64 scancode; u32 keycode; u16 index; u16 reserved } would be a
    > bit better, no alignment problems and we could eventually change
    > "reserved" into something useful.
    >
    > But I think, if we are going to redesign it, we better use scancodes of
    > arbitrary length (e.g. protocol-dependent length). It should be opaque
    > except for the protocol handler.

    Yes, an opaque type for scancode at the userspace API can be better, but
    passing a pointer to kernel will require some compat32 logic (as pointer
    size is different on 32 and 64 bits).

    We may use something like an u8[] with an arbitrary large number of bytes.
    In this case, we need to take some care to avoid LSB/MSB troubles.

    Cheers,
    Mauro.


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