lkml.org 
[lkml]   [2005]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [rfc] keytables - the new keycode->keysym mapping
    On Wed, Feb 09, 2005 at 06:19:21PM +0100, Jirka Bohac wrote:

    > There are presently two ways around this, neither of them good enough
    > 1) assigning one of the other modifier keysyms to the CapsLock key
    > -- the LED will not work

    True.

    > But by adding two modifiers to almost every keyboard map, you would
    > increase the space occupied by the keymaps four times. ... erm ... eight
    > times, because there is also this "applkey" (application keypad) flag,
    > that will be needed as another modifier.

    But keymaps are allocated dynamically.
    Any number of new modifiers does not cost anything until
    one actually uses some particular modifier combination.

    New modifiers are not expensive at all.

    > - the proposed keyboard map file format is IMHO much much nicer

    Keymap files live in user space. The layout of a keymap file
    has no bearing on the kernel implementation of keymaps.

    We want a map (keystroke,current_modifiers) -> keycode.
    The present kernel code organizes things in maps, one for
    each modifier combination that people want to use.
    You want to organize things per keystroke.

    I see no great advantages. Many small arrays allocated
    by kmalloc() leads to more overhead - probably your version
    would lead to larger memory usage, but I have not checked.
    It looks like your code is larger.
    It also looks like your code is slower, with a loop instead of
    a table lookup.

    (Not that those things are very important, but I do not see
    significant advantages for your setup. Maybe you have numbers?)

    Of more interest are the added features.

    You come with a single big patch, but some parts are independent.

    For example, I see

    +struct kbdiacruc {
    + unsigned char diacr, base;
    + unsigned int result; /* UCS */
    +};

    Ten years ago we made the mistake of being too careful with memory.
    Today it is a very bad idea to introduce new ioctls that act on
    8-bit quantities. These must all be int's.

    An ioctl somewhat in this style has been proposed several times,
    and I have no serious objections. If you want it, separate it out
    and make it a patch on its own.

    Andries
    -
    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: 2005-03-22 14:10    [W:0.025 / U:0.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site