Instead of letting xkbcommon write to stderr, we now forward these
messages via the llog handler.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
We should use library-logging in uterm to avoid cluttering stderr for
applications. Hence, use llog instead of log directly.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
This adds a small US-keymap to the uterm library which is loaded if we
cannot find a suitable system default keymap. This allows using the keymap
if no XKB keymaps are installed.
Thanks to Ran Benita for the minimal US keymap.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
This adds an --xkb-keymap <FILE> option to kmscon. When given, kmscon
will try to compile the keymap from the file before trying the other
options (like the XkbKeymap option in xorg.conf).
This is useful for users who have a customized XKB keymap, which is
usually kept in a single file. Example, in X:
xkbcomp $DISPLAY my_keymap.xkb
Customize my_keymap.xkb to your liking, and then in .xinitrc, or
xorg.conf:
xkbcomp my_keymap.xkb $DISPLAY
Now you can also do this in kmscon.conf.
Additionally, lacking such an option, kmscon is quite difficult to use
without an installed xkeyboard-config package, which provides the
infrastructure for the "rules" configuration mechanism. We might even
want to distribute some plain xkb file as a last ditch, for
robustness, if even the default RMLVO fails... without a keyboard a
terminal is not very useful.
(changed Ran's patch to use *_from_string() instead of *_from_file())
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
We want to avoid any static files that are shared between multiple
programs but are not part of SHL. These make the build-process just more
complex.
Move log.[ch] to SHL so we have a known context.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
We will split the public uterm header soon to avoid big headers. Hence,
rename internal headers to *_internal.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
If we cannot write LED states to an input device, we should print proper
warnings instead of ignoring it.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Fix the problems caused by the keyboard state getting out-of-sync with
the xkb_state while the device is asleep (instead of the current hack).
The problem is described in a comment and in the removed FIXME.
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We set the model to a system-default, which means, we are hosed if the
system-default is not what the user expects. Therefore, allow setting the
model via internal APIs.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Upon device wakeup or led state changes, we update the keyboard LEDs to
match the new xkb state.
This means that every kmscon instance retains its own LED state, in the
users eyes. In other words, if you had Num Lock set on one kmscon, switched
to an X VT where it's off, and come back, then Num Lock will be set as
when you left. This is what X server, linux VT, etc. do.
Note that since we need to write the LED events to the evdev devices, we
need to open them RDWR. But since we don't really care what happens to
that write(), that's fine.
Also note that this means NumLock is off by default, which might be
annoying. We need to think how to get some 'setleds' or 'numlockx'
equivalent functionality.
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Before we transitioned to xkbcommon, we had some code that, upon
returning from a VT-switch, looked at the evdev led state and updated
the keyboard modifier state accordingly. So if we returned and NumLock
was on, we adjusted ourselves to that. That was pretty cute.
xkbcommon however doesn't support updating the state by LEDs like that.
Normally, the state of the LEDs is derived from the modifiers; going the
other way is tricky, error-prone and not used much. What we should be
doing is updating the LEDs according to *our* state.
This commit does the part of removing the unused dead code.
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
libxkbcommon has a configure option to set the default values for the
RMLVO's (if they are passed as NULL or "" - we use "" so it'd be safe to
print). If they are not specified there, it's just "us" like we currently
do have. But if they are specified, we should most likely defer to it.
We do the same for the model field, instead of hardcoding "evdev". The
rules field remains hardcoded to "evdev", because we rely on it when
doing the evdev scancode-to-keycode +8 mapping.
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Now that libxkbcommon had a release, that has some API breakage (in
particular to xkb_keysym_from_name), we should update our code against
it and advise users to just use the xkbcommon release.
This should not happen anymore, for the foreseeable future at least.
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We currently do not reset the key-repeat-delay when key-presses are
changed fast enough to fall into the repeat-rate range. Therefore, we
might get spurios key-repeats, even though the key itself wasn't held for
repeat-delay milliseconds.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We currently do not handle modifier-changes during key-repeats. This is
odd as pressing shift should change a repeating key.
To avoid duplicating a lot of code, this patch puts most of the
key-handling into helper functions and cleans it up. We now handle all
kinds of key-repeat specialties and everything should work fine.
Reported-by: Ran Benity <ran234@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
A key-repeat is about keycodes, not keysyms. We repeat the keycode and the
events that are generated by it, so we must also stop repeating if the
given keycode is released.
This fixes a bug where a key would still be repeated if we press:
<a-down> - <Shift-down> - <a-up> - <Shift-up>
Reported-by: Ran Benita <ran234@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We need to pass the +8 shifted codes instead of the real hardware codes as
XKB needs these for X11 legacy reasons.
Reported-by: Ran Benita <ran234@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
To allow users to specify key-repeat rates/delays, we now implement
software key-repeat. This is mostly copied from wlt_toolkit.c which
already does this.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
If a user has multiple active XKB layouts but only one of them has ASCII
keysyms on the base level, then ctrl+<XY> might actually never work,
because these keys aren't available in the current layout. This patch
tries to find a layout of the user that actually _has_ ascii keysyms on
the base level and passes this information along with the normal keysym
information.
The TSM layer can now use this ascii keysym instead of the normal unicode
keysym to handle ctrl+<XY> shortcuts. This is the same way xterm et. al.
handle this, so it seems to be a good idea to do this in TSM, too.
Reported (and mainly written) by Ran Benita.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
xkbcommon supports reporting multiple keysyms per key-event. There is no
keymap which uses this, yet. However, this feature is not meant to enhance
performance by reducing the number of calls into xkb, but instead multiple
keysyms are to be handled as one big keysym.
But there are no examples, yet, so we cannot actually perform any
conversions on them. But we can add the infrastructure for it.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This changes the uterm-input infrastructure to use XKB directly instead of
using a modularized infrastructure. There is no need to use something else
anymore.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We really need to clean this up and allow parsing of grabs in conf.c
again. xkbcommon is now mandatory so we can fix all the input layers to
use it.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
uterm_internal.h contains only input related content so we can rename it
and remove all the inclusions where it is not needed.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Damnit, already pushed and not noticed this bug. Anyway, this fixes the
obvious typo in uxkb module.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This new helper can be used to convert a string description of a keysym
into a real keysym. This is required to allow users to configure keyboard
shortcuts and more.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We currently have a very subtle bug when modifiers are pressed while
leaving a terminal but released while entering. The internal state will
not be updated and as xkbcommon does not fix this up, we need to recreate
the state when re-entering the terminal.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This is a rewrite of the input system. The backends itself are not
modified. However, it is now possible to have multiple backends and change
them on runtime.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
