1. 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
      * 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>
  2. 29 Apr, 2016 1 commit
  3. 15 Apr, 2016 1 commit
  4. 30 Nov, 2015 1 commit
  5. 24 Nov, 2015 3 commits
  6. 29 Sep, 2015 2 commits
  7. 21 Apr, 2015 1 commit
  8. 10 Feb, 2015 2 commits
  9. 12 Nov, 2014 1 commit
  10. 28 Oct, 2014 1 commit
  11. 29 Jul, 2014 1 commit
  12. 18 Apr, 2014 1 commit
  13. 03 Apr, 2014 1 commit
  14. 24 Mar, 2014 1 commit
  15. 18 Mar, 2014 1 commit
  16. 17 Mar, 2014 4 commits
  17. 12 Mar, 2014 2 commits
  18. 11 Mar, 2014 3 commits
  19. 04 Feb, 2014 1 commit
  20. 12 Jan, 2014 3 commits
  21. 02 Jul, 2013 1 commit
  22. 10 May, 2013 2 commits
  23. 06 May, 2013 1 commit
    • Peter Hutterer's avatar
      xkb: free XkbRulesUsed and XkbRulesDflt on extension cleanup · 6f44d672
      Peter Hutterer authored
      ==2547== 1 bytes in 1 blocks are still reachable in loss record 1 of 111
      ==2547==    at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
      ==2547==    by 0x64D1551: strdup (strdup.c:43)
      ==2547==    by 0x4802FB: Xstrdup (utils.c:1113)
      ==2547==    by 0x585B6C: XkbSetRulesUsed (xkbInit.c:219)
      ==2547==    by 0x58700F: InitKeyboardDeviceStruct (xkbInit.c:595)
      ==2547==    by 0x419FA3: vfbKeybdProc (InitInput.c:74)
      ==2547==    by 0x425A3D: ActivateDevice (devices.c:540)
      ==2547==    by 0x425F65: InitAndStartDevices (devices.c:713)
      ==2547==    by 0x5ACA57: main (main.c:259)
      and a few more of the above.
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
  24. 06 Mar, 2013 1 commit
    • Andreas Wettstein's avatar
      xkb: Fixes to LatchMods/LatchGroup · 0f537da7
      Andreas Wettstein authored
      The main problem this patch addresses is that if a latch is put on
      multi-level key with a Latch/Lock/Set, it is possible that after all
      keys are released, still base modifiers are set, which typically will
      make the keyboard unusable.  To see how it happens (without the patch),
      assume that key AltGr sets Mod5 when pressed by itself, and latches Mod3
      when pressed together with Shift.  Now press Shift, then AltGr and
      release both keys in reverse order.  Mod3 is now latched, and the
      LatchMods filter remains active as the second filter.  Now press AltGr;
      Mod5 base modifier gets set, and the SetMods filter will become active
      as the first filter.  Release AltGr: First, the SetMods filter will set
      clearMods to Mod5, then the LatchMods filter will overwrite clearMods
      with Mod3.  Result: the Mod5 base modifier will remain set.  This
      example becomes practically relevant for the revised German standard
      layout (DIN 2137-1:2012-06).
      Other changes implement the latch behaviour more accurately according to
      the specification.  For example, releasing a modifier latching key can
      at the same time clear a locked modifier, promote another modifier that
      is latched to locked, and latch a third modifier.  Overall, what the
      code does should be straightforward to compare what the XKB protocol
      specification demands, see the table in section 6.3.
      Finally, releasing a key no longer cancels a latch that has not become
      pending yet.  In my opinion, the specification is not clear; it speaks
      of "operating" a key, which the patch effectivly interprets as "press"
      rather than "press or release".  From my experience, using the latter
      interpretation makes latches on higher levels practically unusable.  In
      the example given above, one would have to release AltGr always before
      Shift to get the Mod3-Latch.  The practical relevance of latches on
      higher levels is once more given by the revised German standard layout.
      Signed-off-by: 's avatarAndreas Wettstein <wettstein509@solnet.ch>
      Reviewed-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
  25. 21 Feb, 2013 1 commit
  26. 15 Feb, 2013 1 commit
  27. 08 Feb, 2013 1 commit