1. 05 Apr, 2018 1 commit
    • Adam Jackson's avatar
      xkb: Silence some compiler warnings · 83913de2
      Adam Jackson authored
      Of the form:
      
      ../xkb/XKBGAlloc.c: In function ‘SrvXkbAddGeomKeyAlias’:
      ../xkb/XKBGAlloc.c:591:13: warning: ‘strncpy’ specified bound 4 equals destination size [-Wstringop-truncation]
                   strncpy(alias->real, realStr, XkbKeyNameLength);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      This is intentional; the code that reads from these fields never reads
      more than 4 bytes anyway. Rephrase things in terms of memcpy so that's
      clear. Obviously this is awful but in XKB awful is par.
      Signed-off-by: 's avatarAdam Jackson <ajax@redhat.com>
      Acked-by: 's avatarKeith Packard <keithp@keithp.com>
      83913de2
  2. 05 Mar, 2018 1 commit
  3. 13 Dec, 2017 2 commits
  4. 06 Nov, 2017 1 commit
  5. 01 Nov, 2017 1 commit
  6. 30 Oct, 2017 1 commit
  7. 24 Oct, 2017 1 commit
  8. 04 Oct, 2017 4 commits
  9. 26 Apr, 2017 1 commit
    • Eric Anholt's avatar
      Add a Meson build system alongside autotools. · 1549e303
      Eric Anholt authored
      This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
      and Xdmx so far.  The outline of Xquartz/Xwin support is in tree, but
      hasn't been built yet.  The unit tests are also not done.
      
      The intent is to build this as a complete replacement for the
      autotools system, then eventually replace autotools.  meson is faster
      to generate the build, faster to run the bulid, shorter to write the
      build files in, and less error-prone than autotools.
      
      v2: Fix indentation nits, move version declaration to project(), use
          existing meson_options for version-config.h's vendor name/web.
      Signed-off-by: 's avatarEric Anholt <eric@anholt.net>
      Acked-by: 's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      1549e303
  10. 25 Apr, 2017 1 commit
  11. 27 Mar, 2017 1 commit
  12. 23 Mar, 2017 1 commit
  13. 01 Mar, 2017 1 commit
  14. 04 Jan, 2017 1 commit
    • Mihail Konev's avatar
      xkb: Match key releases with an overlaid press · 9d32b71c
      Mihail Konev authored
      Testcase:
      
      In ~/.xbindkeysrc:
        "xterm &"
             XF86LaunchA
      
      In ~/ov.xkb:
        xkb_keymap {
            xkb_keycodes { include "evdev" };
            xkb_types    { include "complete" };
            xkb_compat   { include "complete"
                interpret Overlay1_Enable+AnyOfOrNone(all) {
                    action= SetControls(controls=Overlay1);
                };
            };
            xkb_symbols  { include "pc+inet(evdev)+us"
                key <INS> { [ Overlay1_Enable ] };
                key <AE01> { overlay1 = <AE02> }; // Insert+1 => 2
                key <TLDE> { overlay1 = <I128> }; // Insert+~ => XF86LaunchA
            };
            xkb_geometry { include "pc(pc104)" };
        };
      
      Apply this layout: 'xkbcomp ~/ov.xkb $DISPLAY'.
      Run "xbindkeys -n -v"
      In the exact order:
      - press Insert
      - press Tilde
      - release Insert
      - wait
      - release Tilde
      Keyboard input in the new terminal window(s) would be locked
      until another Insert+Tilde .
      Reported-by: 's avatarMariusz Mazur <mariusz.g.mazur@gmail.com>
      Signed-off-by: 's avatarMihail Konev <k.mvc@ya.ru>
      Reviewed-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      9d32b71c
  15. 21 Sep, 2016 1 commit
  16. 07 Sep, 2016 1 commit
  17. 06 Jul, 2016 1 commit
  18. 29 Jun, 2016 1 commit
  19. 21 Jun, 2016 1 commit
    • Peter Hutterer's avatar
      xkb: after changing the keymap, force an indicator update · cc7c0b0e
      Peter Hutterer authored
      When NumLock is on and a new keymap is applied, the next modifier state
      change will turn off that LED (but leave the state enabled). The cause
      for this is a bit convoluted:
      
      * the SLI explicitState is copied from the current state in
        ProcXkbGetKbdByName. Thus, if NumLock is on, that state is 0x2.
      * on the next modifier key press (e.g. Shift), XkbApplyState() calls into
        XkbUpdateIndicators() -> XkbUpdateLedAutoState() to update SLIs (if any)
        for the currently changed modifier. But it does so with a mask only for
        the changed modifier (i.e. for Shift).
      * XkbUpdateLedAutoState() calculates the state based on this mask and
        ends up with 0 because we don't have a Shift LED and we masked out the
        others.
      * XkbUpdateLedAutoState() compares that state with the previous state
        (which is still 0x2) and then proceeds to turn the LED off
      
      This doesn't happen in the normal case because either the mask
      encompasses all modifiers or the state matches of the masked-out
      modifiers matches the old state.
      
      Avoid this issue by forcing an SLI update after changing the keymap.
      This updates the sli->effectiveState and thus restores everything to
      happy working order.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1047151Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: 's avatarDaniel Stone <daniels@collabora.com>
      (cherry picked from commit ac164e58)
      cc7c0b0e
  20. 20 Jun, 2016 1 commit
  21. 03 Jun, 2016 1 commit
    • Olivier Fourdan's avatar
      xkb: add hook to allow/deny AccessX key repeat · fda5675f
      Olivier Fourdan authored
      The xserver generates the key repeat by itself.
      
      But when used with another server processing inputs first (e.g. a
      Wayland compositor), the other server may be busy dealing with some
      other things and not queue up key release events in time.
      
      Add a vfunc in XkbSrvInfo to possibly add a check before re-emitting a
      keypress event in the AccessX timer handler, so that the key repeat has
      a chance to be denied if the server processing the input is not ready.
      Signed-off-by: 's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      fda5675f
  22. 26 May, 2016 2 commits
  23. 04 May, 2016 1 commit
    • Peter Hutterer's avatar
      xkb: after changing the keymap, force an indicator update · ac164e58
      Peter Hutterer authored
      When NumLock is on and a new keymap is applied, the next modifier state
      change will turn off that LED (but leave the state enabled). The cause
      for this is a bit convoluted:
      
      * the SLI explicitState is copied from the current state in
        ProcXkbGetKbdByName. Thus, if NumLock is on, that state is 0x2.
      * on the next modifier key press (e.g. Shift), XkbApplyState() calls into
        XkbUpdateIndicators() -> XkbUpdateLedAutoState() to update SLIs (if any)
        for the currently changed modifier. But it does so with a mask only for
        the changed modifier (i.e. for Shift).
      * XkbUpdateLedAutoState() calculates the state based on this mask and
        ends up with 0 because we don't have a Shift LED and we masked out the
        others.
      * XkbUpdateLedAutoState() compares that state with the previous state
        (which is still 0x2) and then proceeds to turn the LED off
      
      This doesn't happen in the normal case because either the mask
      encompasses all modifiers or the state matches of the masked-out
      modifiers matches the old state.
      
      Avoid this issue by forcing an SLI update after changing the keymap.
      This updates the sli->effectiveState and thus restores everything to
      happy working order.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1047151Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: 's avatarDaniel Stone <daniels@collabora.com>
      ac164e58
  24. 29 Apr, 2016 1 commit
  25. 15 Apr, 2016 1 commit
  26. 30 Nov, 2015 1 commit
  27. 24 Nov, 2015 3 commits
  28. 29 Sep, 2015 2 commits
  29. 21 Apr, 2015 1 commit
  30. 10 Feb, 2015 3 commits