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
dependent.
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.
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
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.