| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Additionally, report successful tests count.
|
|
Fourteen years ago, commit b69a8bdff0 added a rule for redefining the
<NMLK> key for IBM Spacesaver keyboards in order to have `Num_Lock` on
both levels. This was needed to overwrite `Pointer_EnableKeys` that
was on the second level by default, which interfered with how the
Spacesaver NumLock key worked (https://bugs.freedesktop.org/16767).
Two years later, commit 1bc01a5eaa removed the default assignment of
`Pointer_EnableKeys` to the second level of <NMLK>, thus making the
special rule for IBM Spacesavers redundant.
(There are still a few vendor files that assign `Pointer_EnableKeys`.
These assignments should probably be removed too.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
Keep <MDSW> as an alias, for private user layouts that possibly use it.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
Having them in symbols/pc instead of in symbols/inet(evdev) means that
any assignments that a custom layout makes to these keys will not get
overridden by the standard +inet(evdev) rule.
This fixes issue #50.
Reported-by: Alex-Daniel Jakimenko
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
|
|
|
|
Commit 710752e4be from fourteen years ago repurposed keycode 97
(until then used for "Romaji") for AB11, freeing up keycode 211
for <I211>, but forgot to remove this comment.
(Also add a space, to line up the Japanese codes consistently.)
Also, adjust the generation script to not recreate the comment.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
|
|
libxkbcommon (commit 1cae25005211) now provides the output of the layout
tester format in YAML, with successful compilations on stdout and failed ones
on stderr. This makes it easy to collect the results, extract and print the
failures with yq but also parse the yaml file and leave a JUnit XML in place
that will then show up as result on a MR page.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
It causes the CI job to fail because diff now finds something that changed.
See d1a7abd34f79cb0ad27c4861afd98d5b92723be0
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
These don't need to sit in the main source tree where we need exceptions for
them in the build system. They are only called from special jobs in the CI
pipelines, so let's move this to the CI directory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
xorgproto 2021.2 and later has a recognizable pattern for adding new keysyms
to XF86keysym.h based on the Linux kernel input-event-codes.h. Use this to
detect any keysyms that are present in the header file but not yet in
symbols/inet.
This is merely a gitlab CI job as we only have to do an actual update once
every few months or so. A git diff is sufficient here too, it contains all the
information we will need to understand what is missing from the updated file.
We check xorgproto master because that gives us some heads-up on what will
come. There is a minor chance that we are mapping keycodes that change before
the release but it's minor and fixable anyway.
Requires: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/23
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
While I'm not a huge fan of the code style it enforces, at least it's
consistent this way.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The various <I123> keycodes in keycodes/evdev simply match the kernel
defines + offset 8. There is no need to maintain these manually, let's
generate them instead.
Keycodes update rarely and irregularly (on average maybe every second kernel
release) so there's no need to integrate this into the build itself, let's add
it to our CI instead.
The script here uses python-libevdev which has a list of the various key
codes and their names (compile-time built-in in libevdev itself so it's
advisable that a recent libevdev is used). The script is hooked up to a custom
job that will fail if there are key codes with a #define in the kernel that
are not listed in our evdev file. We allow that job to fail, it's not that
urgent to block any merge requests.
Changes to v1, see commit 5dc9b48c and its revert 8fa3b314:
- Parse the template for existing defines and alias those keys. e.g.
alias <I121> = <MUTE>;
- Kernel v5.10 keycodes are now included in the file
- The script defaults to the correct template/keycode file, no commandline
arguments needed for the default run.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Some of the generated keys overwrote existing keys, causing warnings
and nonfunctional keys. For example:
xkbcommon: WARNING: Multiple names for keycode 121; Using <I121>, ignoring <MUTE>
Revert this commit, we're too close to a release and it's better to wait until
the next one to give this approach more time to settle.
Fixes #247
This reverts commit 5dc9b48c9b31de9f9780887a79ded3b1e52591d9.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The various <I123> keycodes in keycodes/evdev simply match the kernel
defines + offset 8. There is no need to maintain these manually, let's
generate them instead.
Keycodes update rarely and irregularly (on average maybe every second kernel
release) so there's no need to integrate this into the build itself, let's add
it to our CI instead.
The script here uses python-libevdev which has a list of the various key
codes and their names (compile-time built-in in libevdev itself so it's
advisable that a recent libevdev is used). The script is hooked up to a custom
job that will fail if there are key codes with a #define in the kernel that
are not listed in our evdev file. We allow that job to fail, it's not that
urgent to prevent any other pipelines.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
