lkml.org 
[lkml]   [2010]   [Mar]   [26]   [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 Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
    > David Härdeman wrote:
    > > On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
    > >>> 10) extend keycode table replacement to support big/variable
    > >>> sized scancodes;
    > >> Pending.
    > >>
    > >> The current limit here is the scancode ioctl's are defined as:
    > >>
    > >> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /* get keycode */
    > >> #define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /* set keycode */
    > >>
    > >> As int size is 32 bits, and we must pass both 64 (or even bigger) scancodes, associated
    > >> with a keycode, there's not enough bits there for IR.
    > >>
    > >> The better approach seems to create an struct with an arbitrary long size, like:
    > >>
    > >> struct keycode_table_entry {
    > >> unsigned keycode;
    > >> char scancode[32]; /* 32 is just an arbitrary long array - maybe shorter */
    > >> int len;
    > >> }
    > >>
    > >> and re-define the ioctls. For example we might be doing:
    > >>
    > >> #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)
    > >> #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct keycode_table_entry)
    > >> #define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, void)
    > >>
    > >> Provided that the size for struct keycode_table_entry is different, _IO will generate
    > >> a different magic number for those.
    > >>
    > >> Or, instead of using 0x04, just use another sequential number at the 'E' namespace.
    > >>
    > >> An specific function to clear the table is needed with big scancode space,
    > >> as already discussed.
    > >>
    > >
    > > I'd suggest:
    > >
    > > struct keycode_table_entry {
    > > unsigned keycode;
    > > unsigned index;
    > > unsigned len;
    > > char scancode[];
    > > };
    > >
    > > Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
    > > ignored), that way no special function to clear the table is necessary,
    > > instead you do a loop with:
    > >
    > > EVIOCGKEYCODEBIG (with index 0)
    > > EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
    > > keycode = KEY_RESERVED)
    > >
    > > until EVIOCGKEYCODEBIG returns an error.
    >
    > Makes sense.

    Yes, I think so too. Just need a nice way to handle transition, I'd
    like in the end to have drivers implement only the improved methods and
    map legacy methods in evdev.

    >
    > > This also allows you to get all the current mappings from the kernel
    > > without having to blindly search through an arbitrarily large keyspace.
    > >
    > > Also, EVIOCLEARKEYCODEBIG should be:
    > >
    > > #define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)
    > >
    > > That way a user space application can simply call EVIOCLEARKEYCODEBIG,
    > > ask the user for an appropriate keycode, fill in the keycode member of
    > > the struct returned from EVIOCLEARKEYCODEBIG and call EVIOCSKEYCODEBIG.
    >
    > By using the index concept, I don't think we need another ioctl. Also,
    > there's no way for kernel to handle it, as it will be using the same
    > magic number of EVIOCGKEYCODEBIG.
    >
    > > On a related note, I really think the interface would benefit from
    > > allowing more than one keytable per irrcv device with an input device
    > > created per keytable. That way you can have one input device per remote
    > > control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an
    > > evdev IOCTL since there's an N-1 mapping between input devices and irrcv
    > > devices.
    >
    > I don't think that an ioctl over one /dev/input/event should be the proper way
    > to ask kernel to create another filtered /dev/input/event. As it were commented
    > that the multimedia keys on some keyboards could benefit on having a filter
    > capability, maybe we may have a sysfs node at class input that would allow
    > the creation/removal of the filtered event interface.

    No, if you want separate event devices just create a new instance of
    input device for every keymap and have driver/irrcv class route events
    to proper input device.

    Thanks.

    --
    Dmitry
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-03-26 17:05    [W:0.050 / U:0.036 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site