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>
'capability' seems to be the common terminology for this, and it sounds
better - so use it.
We also move the enum definition to the header, because otherwise the
'capabilities' field there doesn't make sense.
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>
Even though I really like the high repeat-rates, it might not be the best
default option. Hence, change it to some sane default.
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>
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 made xkbcommon mandatory some time ago and there is no reason to keep
this plain backend around anymore. It isn't tested at all and provides no
real advantage over xkb.
Even for debugging it is easier to use XKB.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
If multiple handlers are called on the same input-event, we must notify
handlers whether the event was already handled by a previous callback. We
push this decision to the handlers by allowing them to modify the
"handled" flag for an input event.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We really need xkbcommon. There is so much stuff (including parsing of
keyboard shortcuts in conf.c) that depends on it. Therefore, we make it
mandatory now which allows us to use xkbcommon functions all over the
place.
Note that xkbcommon itself has no runtime dependencies so it is a small
self-contained library. The only reason I didn't do this ealier is that
xkbcommon has not seen a public release, yet. However, that should be done
in the near future.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
When enabling the printf() logic for the logging subsystem, several
warnings were produced about missing or wrong specifiers. This fixes all
those occurrences.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Sorry for the big commit, but I was working on the wlterm application and
then thought I can rework the whole configure-logic again. This mainly
renames all build-defines to BUILD_DEFINE_* and BUILD_HAVE_* and allows
specifying which applications to build via --enable-kmscon/--enable-wlterm
and similar.
wlterm is a new application which is a native wayland client with no
external dependencies. It serves several purposes:
* It uses TSM (not yet implemented, but will come soon) to create a
console independent from kmscon. This shows how TSM can easily be used
to create independent terminal emulators.
* It is a native wayland application (probably the first independent
wayland app so far?) and is used to test how well the wayland API
works. As wayland is still under heavy development, we need more
application-writers who report back whether the wayland-API makes
sense to them and whether it works correctly.
* A proper terminal-emulator for wayland! There is currently no proper
emulator so we really need something that we can work with.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This is the last static helper that is moved so as a next step we should
get rid of the "static" library entirely.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This moves the timers to SHL and removes the old static_misc header and
source. They are no longer needed.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Shl (Static helper library) is the new name of all static helpers in
kmscon that might be shared between different applications.
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>
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>
Instead of using a boolean state we now have an integer and a device needs
to be put asleep as often as it was woken up to be put asleep, and vice
versa.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
The uterm library does not need and must not depend on main.h. Remove the
unneeded inclusion.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Instead of accessing the kmscon configuration from the uterm code, we
should pass it in on creation. Otherwise, uterm depends on main.c which
would be really ugly.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
The main configuration is now limited to kmscon and thus should not use
the conf_* prefix. Move all code to use the new name and introduce the new
main.h header mainly for kmscon.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
There is no much gain from having an internal kbd_desc_keysym_to_string()
function if we cannot get access to the kbd_desc object. Therefore, add a
forward helper to uterm_input() which forwards the call to its internal
kbd_desc object. This allows outside access to the keysym_to_string()
function.
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>
Small stuff that is not worth putting into a separate library is no moved
into the "static" library which is statically linked into all our
subsystems.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We need to correctly increase the refcnt. We currently increase it only
when it was 0 before due to a very subtle bug as we missed the "return".
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This is a rewrite of the input layer but integrated into uterm. It has the
same functionality but is tightly bound to the concepts behind uterm and
will soon supercede the old implementation.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
