[lkml]   [2009]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev
    On Thu, Nov 26, 2009 at 10:34:55PM -0500, Jon Smirl wrote:
    > On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson <> wrote:
    > > This part... Not so wild about. The common thought I'm seeing from people is
    > > that we should be using setkeycode to load keymaps. I mean, sure, I suppose
    > > this could be abstracted away so the user never sees it, but it seems to be
    > > reinventing a way to set up key mapping when setkeycode already exists, and
    > > is used by a number of existing IR devices in the v4l/dvb subsystem (as well
    > > as misc things like the ati rf remotes, iirc). Is there some distinct
    > > advantage to going this route vs. setkeycode that I'm missing?
    > The configfs scheme and keymaps offer the same abilities. One is an
    > ancient binary protocol and the other one uses Unix standard commands
    > like mkdir and echo to build the map. You need special commands -
    > setkeycodes, getkeycodes, showkey, loadkeys, xmodmap, dump-keys to use
    > a keymap. I've been using Linux forever and I can't remember how
    > these commands work.

    Nor you really should - it all is mostly being used transparently for
    the end-user. I mean udev loading your laptop-specific keymap is not
    using loadkeys but specially written utility that issues EVIOCSKEYCODE

    > Keymaps are a binary protocol written by Risto Kankkunen in 1993.
    > Configfs was added by Oracle about two years ago but it has not been
    > used for mapping purposes.

    Nor it is even enabled by default... Do we want to make in mandatory on
    all consumer systems out there?

    > It's another discussion, but if IR goes the configfs route I'd
    > consider writing a patch to switch keymaps/keycodes onto the configfs
    > model. It is a huge advantage to get rid of these pointless special
    > purpose commands that nobody knows how to use. I'd keep the legacy
    > IOCTLs working and redirect the data structure to a configfs one
    > instead of the existing structure.

    What is the memory footprint for configfs solution though? I would hate
    to see the cost of user-modifiable keymap explode tenfold so that we can
    rely less (not even get rid of, since it is published userspace API/ABI)
    on setkeycodes and related ioctls.

    > The same idea is behind getting rid of IOCTLs and using sysfs. Normal
    > Unix commands can manipulate sysfs. IOCTLs have problems with strace,
    > endianess and the size of int (32/64b).

    The size of long you mean, right? Besides, now that we know better we
    should simply use explicitely-sized fields in ioctl structures.


     \ /
      Last update: 2009-11-29 08:23    [W:0.022 / U:6.912 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site