Skip to content
Snippets Groups Projects
  1. Jan 29, 2014
  2. Jan 15, 2014
  3. Dec 23, 2013
  4. Dec 18, 2013
  5. Dec 17, 2013
    • Sergey Udaltsov's avatar
    • Stefan Dirsch's avatar
      Fix Russian phonetic layout · 09989fd4
      Stefan Dirsch authored and Sergey Udaltsov's avatar Sergey Udaltsov committed
      According to
       https://bugzilla.novell.com/show_bug.cgi?id=498304
      the mapping of the Russian phonetic layout doesn't match what
      is shown in:
       http://en.wikipedia.org/wiki/Keyboard_layout#Russian
      
      
      
      Signed-off-by: default avatarEgbert Eich <eich@freedesktop.org>
      09989fd4
    • Egbert Eich's avatar
      Separate evdev and base rule specific parts · a343f226
      Egbert Eich authored and Sergey Udaltsov's avatar Sergey Udaltsov committed
      This prevents those rule files from being cluttered up
      by definitions irrelevant for the respective rule set.
      a343f226
    • Egbert Eich's avatar
      Fix henkan key on jp106 keyboard with inet media keys · bd9d0ced
      Egbert Eich authored and Sergey Udaltsov's avatar Sergey Udaltsov committed
      When support for inet keys was added to the keyboard driver
      back in the early 2000 none of the developers thought of
      Japanese 106 key keybards which have two extra keys generating
      the scan codes 0x79 and 0x7d.
      So for keys prefixed with the scan code 0x60 which were not
      remapped to anything else the line:
       *scanCode += 0x78;
      was added.
      Thus keys generating the scan codes 0xe0 0x01 and 0xe0 0x03
      will overlap with the Henkan and Muhenkan keys on Japanese
      keyboards. Those keys will geneate the keycode 129 (0x81)
      - symbols: XFER and I01 - and 131 (0x83) - symbols NFER and
      I03 - in X.
      The former keycode however maps to the XF86AudioMedia
      keysym on inet keyboards.
      From the rules the keysyms are aggregated such that the
      mapping of the Henkan key on jp106 keyboards (from the jp
      symbol file) gets overwritten by the XF86AudioMedia mapping.
      This makes Japanese users loose a key which is rather important
      for Japanse input methods only to gain a multimedia key which
      is rather irrelevant to people doing serious typing.
      This commit adds a huge kludge to fix this: it adds a rule
      which in turn adds a statement to the symbol string that
      restores the original mapping of this key on Japanse keyboard
      layouts. This way Japanse users will still use the XF86AudioMedia
      key.
      This of course only affects users of the legacy keyboard driver,
      evdev doesn't suffer from this problem.
      The better solution would probably be to change the keyboard
      driver in X to remap the key sequence 0xe0 0x01 to one of the
      still unused keycodes in the range above 250.
      Then the keyboard mappings can be changed to reflect this.
      WIth this change users using an unmatched combination of
      xf86-input-keyboard and this package would loose their
      XF86AudioMedia key.
      bd9d0ced
    • Peter Hutterer's avatar
      rules: add option grab:debug · f26d143c
      Peter Hutterer authored and Sergey Udaltsov's avatar Sergey Udaltsov committed
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      f26d143c
    • Carlos Garnacho's avatar
      symbols/inet: Fix mapping of KEY_DIRECTION/CYCLEWINDOWS for evdev · ec875f6f
      Carlos Garnacho authored and Sergey Udaltsov's avatar Sergey Udaltsov committed
      
      From checking the usage of KEY_CYCLEWINDOWS in the linux sources, it
      seems to be meant for task switching, rather than rotating the screen
      as XF86RotateWindows traditionally does. In turn, KEY_DIRECTION is what
      some kernel platform modules already use for the "rotate display" key
      in certain tablet models.
      
      So in order to make things consistent, it makes more sense to map
      KEY_DIRECTION to XF86RotateWindows, and KEY_CYCLEWINDOWS to XF86TaskPane
      as it's the closest offered behavior.
      
      Signed-off-by: default avatarCarlos Garnacho <carlosg@gnome.org>
      ec875f6f
  6. Nov 25, 2013
  7. Nov 17, 2013
    • Tilman Sauerbeck's avatar
      Added the Norman variant of the us layout. · 51ab5c95
      Tilman Sauerbeck authored and Sergey Udaltsov's avatar Sergey Udaltsov committed
      51ab5c95
    • Michal Nazarewicz's avatar
      Add more unicode to us(dvp) layout. · bf39904d
      Michal Nazarewicz authored and Sergey Udaltsov's avatar Sergey Udaltsov committed
      This commit adds the following definitions to the alternative group of
      the us(dvp) layout:
      
        Shift+AC11  is en dash      mnemonic: <EC11> is -
        Shift+AD02  is ...          was: dead caron  mnemonic: <AD02> is ,
        Shift+AE11  is reverse interrobang  mnemonic: <AE11> is !
        Shift+AD11  is interrobang  mnemonic: Shift+<AD11> is ?
      
        Shift+AB07  is micro        mnemonic: <AB07> is m
      
      Note about ellipsis which replace existing dead caron:
      
        The us(dvp) inherited some definitions from us(dvorak) simply because
        it omitted definition of all 4 levels for given key:
      
          key <AD02> { [ comma,           less,           guillemotleft               ] };
      
        which specifies only two levels so the third and fourth happens to be
        inherited from us(dvorak)'s definitions:
      
          key <AD02> { [	comma,	less,   dead_cedilla, dead_caron	] };
      
        I'm assuming that this was actually not intentional behaviour
        especially since the overwritten key is available in us(dvp) under
        another key (which make more sense):
      
          key <AD12> { [ at,              asciicircum,    dead_circumflex, dead_caron ] };
      
        Because of that, I've decided to go ahead and break that behaviour in
        favour of adding a new key.
      bf39904d
  8. Oct 29, 2013
Loading