1. 19 Aug, 2016 1 commit
    • Martin Flöser's avatar
      Ensure modifier locks and latches don't trigger the mod only shortcut · ec98f498
      Martin Flöser authored
      If caps lock is on the shift key should not trigger. Similar pressing
      caps lock should neither on activation press nor on deactivation press
      trigger the shortcut. Related to that are latched modifiers aka sticky
      modifiers: if the modifier is still on after releasing the key the
      shortcut should not trigger. We must assume the user wanted to use the
      modifier to activate the modifier, not to activate the shortcut.
      This change ensures that we don't track for modifier only shortcuts if
      a modifier is active before press or after release.
      The added test case demonstrates for caps lock, latched modifiers is
      currently still untested. (Needs a way to mock it).
      Test Plan: See test case for caps lock.
      Reviewers: #kwin, #plasma
      Subscribers: kwin
      Tags: #kwin
      Differential Revision: https://phabricator.kde.org/D2467
  2. 26 Jun, 2016 1 commit
    • Martin Flöser's avatar
      Update Keyboard focus when the Surface of the active client changes · 7adf69de
      Martin Flöser authored
      For XWayland windows the window might be activated before the Wayland
      Surface is set for it. Thus the keyboard focus is not passed to the
      window. Only on the next activate after the window got created the
      window got keyboard focus.
      This change addresses this problem by emitting a signal from Toplevel
      when the surface changes. The KeyboardInput listens to this signal
      for the active client and updates keyboard focus again if the surface
      changes. Thus keyboard focus is properly passed to XWayland windows.
      Test Plan:
      Test case which creates an X11 window is adjusted to verify
      the condition.
      Reviewers: #plasma_on_wayland, #kwin
      Subscribers: plasma-devel, kwin
      Tags: #plasma_on_wayland, #kwin
      Differential Revision: https://phabricator.kde.org/D2009
  3. 30 May, 2016 1 commit
    • Martin Flöser's avatar
      Pass LibInput::Device* through the event handlers · 69cbb409
      Martin Flöser authored
      The signals emitted by LibInput::Connection carry the Device for which
      the input event was received. This Device is passed to the input handlers.
      Custom event classes are added which extend QMouseEvent, QKeyEvent and
      QWheelEvent respectively and expose the Device. The Device is only passed
      around as a forward declared pointer, so even if compiled without libinput
      support, it should still compile.
      Event handlers which need to get access to the Device can now just cast
      the event pointer to the custom class and access it. This can be used in
      future to handle device specific key codes, etc.
      As we don't have a proper event classes for touch events the event
      handlers do not yet have access to the Device. Here the internal API
      needs to be adjusted in future.
      Reviewers: #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D1667
  4. 22 Feb, 2016 1 commit
  5. 19 Feb, 2016 7 commits
    • Martin Flöser's avatar
      Notify org.kde.osdService about keyboard layout changes · bc7f33db
      Martin Flöser authored
      KWin starts to track which is the current layout and in case it changes
      notifies the org.kde.osdService about the change through DBus. KWin has
      a better knowledge about changes than the KeyboardDaemon could have, so
      it's better to do in KWin. E.g. KWin can also notice changes not
      triggered by the global shortcut, but by the keymap itself.
    • Martin Flöser's avatar
      Support switching keyboard layout shortcut · c79511b2
      Martin Flöser authored
      KWin registers/steals the shortcut of the "KDE Keyboard Layout Switcher"
      and binds it to a new method which actually switches the layout.
      The actual switcher from which the shortcut is stolen should only be a
      representation on Wayland. Though how to do this is a problem for the
      future. Only the active window is notified about layout changes and the
      plasmoid will never get the event in time. This is of course a minor
      problem compared to the fact that the KeyboardDaemon is absolutely X11
    • Martin Flöser's avatar
      Update keyboard modifier state on seat after each key event · 83a4fe54
      Martin Flöser authored
      The layout might have changed, thus we should notify the client about
      it. The server ensures that on no state change it's not sent to the
    • Martin Flöser's avatar
      Load xkb keymap information from kxkbrc config file · 2e36c4b7
      Martin Flöser authored
      This is the start for adding proper support for keyboard layouts. If
      we have a configuration in kxkbrc the keymap is generated from that
      information. This allows to have different layouts and also layout
      switching is working (though not yet passed to Wayland clients properly).
      Not yet working is the global shortcut for layout switching and
      reconfiguring the layouts.
    • Martin Flöser's avatar
      Ask Xkb before starting to repeat a key · 5caf3316
      Martin Flöser authored
      The keymap knows whether the key should repeat or not. E.g. no need to
      trigger repeat for modifier keys.
    • Martin Flöser's avatar
    • Martin Flöser's avatar
      Implement internal keyboard repeat · cb3c6a47
      Martin Flöser authored
      As a Wayland server KWin does not have to emit additional key repeat
      events (unlike X11). The clients are responsible for handling this based
      on the provided key repeat information.
      Internally KWin needs key repeat, though. E.g. the effects need key
      repeat (filtering in Present Windows), window moving by keyboard needs
      repeat, etc. etc.
      This change introduces the internal key repeat. For each key press a
      QTimer is started which gets canceled again on the key release. If the
      timer fires it invoked processKey with a new KeyboardKeyAutoRepeat state.
      This is handled just like a KeyPress, but states are not updated and
      the QKeyEvent has autorepeat set to true.
      The event filters check for the autorepeat state and filter the event
      out if they are not interested in it. E.g. the filters passing the event
      to the Wayland client need to filter it out.
      Currently auto-repeat is bound to using libinput. This needs to be
      modified. The only backend sending repeated events is X11, thus for
      other backends it should be enabled.
      Whether creating a timer on each key event is a good idea is something to
      evaluate in future.
      Reviewed-By: Bhushan Shah
  6. 15 Feb, 2016 1 commit
    • Martin Flöser's avatar
      Split keyboard related functionality from InputRedirection · 849d1751
      Martin Flöser authored
      Similar to the change regarding pointer and touch a
      KeyboardInputRedirection is created. The Xkb class is also moved to
      the new files keyboard_input.h and keyboard_input.cpp.
      Just like in the case of PointerInputRedirection no signals are added,
      but the existing signals in InputRedirection are directly invoked.