summaryrefslogtreecommitdiff
path: root/keycodes
Commit message (Collapse)AuthorAgeFilesLines
* keycodes: rename <MDSW> to <LVL5>, to show what its intended function isBenno Schulenberg2022-06-082-2/+4
| | | | | | Keep <MDSW> as an alias, for private user layouts that possibly use it. Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
* Add new keysyms from kernel v5.17Peter Hutterer2022-04-111-0/+1
| | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* keycodes: remove three commented-out codenames -- they serve no purposeBenno Schulenberg2022-04-101-4/+1
| | | | And move a comment to the relevant line, while correcting a typo.
* keycodes: sort the codenames for the bottom row into their physical orderBenno Schulenberg2022-04-101-6/+4
| | | | | Also drop an unneeded comment -- once LWIN and RWIN were extra keys, nowadays they are standard.
* keycodes: move two codenames into their normal physical orderBenno Schulenberg2022-04-101-4/+2
| | | | | Most other codenames are listed in the order in which they appear on a standard keyboard, so do this for these two too.
* keycodes: remove an obsolete and thus puzzling commentBenno Schulenberg2022-04-101-2/+2
| | | | | | | | | | | | 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>
* Always generate same symbols for Lang1 and Lang2Akihiko Odaki2022-03-202-18/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change came up after discussions in: https://github.com/google/mozc/issues/552 This change is not complex, but it has somewhat complex background. The following discussion describes it extensively. 1. Six keys somewhat related or unrelated This change involves six keys: ImeOn, ImeOff, Hangul Latin toggle, Hangul to Hanja conversion, Eisu toggle / Caps Lock and Katakana / Hiragana / Romaji. ImeOn is the name used by Microsoft. Apple calls it "Kana switch". ImeOff is the name used by Microsoft. Apple calls it "alphanumeric". Hangul Latin toggle is the name used in keycodes directory. Apple calls it "Hangul/English toggle". Hangul to Hanja conversion is the name used in keycodes directory. Apple calls it "Hanja conversion". ImeOn and Hangul Latin toggle are mapped to Lang1 in USB HID usage and physically located right to space key. ImeOff and Hangul to Hanja conversion are mapped to Lang2 in USB HID usage and physically located left to space key. Eisu toggle / Caps Lock and Katakana / Hiragana / Romaji has key top prints somewhat similar to ImeOff (which says "Eisu") and ImeOn (which says "Kana"), but they have different semantics for Japanese IMEs like macOS Japanese Input Method, Microsoft Japanese IME, and Mozc have two distinct states: IME ON/OFF state and input character type. Eisu_toggle and Hiragana_Katakana are used to toggle the input character type where ImeOn and ImeOff keys are used to IME ON/OFF state. Their physical positions are also different. Eisu toggle / Caps Lock are located where Caps Lock usually sits on a conventional IBM PC keyboard. The position of Hiragana / Katakana / Romaji are described in Microsoft's documentation shown later. The following pages describe the keys listed above: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/keyboard-japan-ime https://developer.apple.com/documentation/uikit/uikeyboardhidusage/uikeyboardhidusagekeyboardlang1 https://developer.apple.com/documentation/uikit/uikeyboardhidusage/uikeyboardhidusagekeyboardlang2 2. Messy situation before this change The following key codes were defined for xfree86: <EISU> = 210; <KANA> = 209; alias <HNGL> = <FK16>; alias <HJCV> = <FK17>; They used to represent ImeOff, ImeOn, Hangul Latin toggle, and Hangul to Hanja conversion, respectively. However, apparently HNGL and HJCV were incorrect. The following commits of xf86-input-keyboard suggest they are actually mapped to 209 and 210: 425c1280439fe37497a33c47b5a8432e59cbfb76 ccf63a61f39e1f107a67c33d6a7ad24ea4c76b7e evdev only has HNGL and HJCV, and they also represent ImeOn and ImeOff, respectively. EISU, KANA, HNGL, HNGL, and HJCV were then used to generate the following symbols respectively: Eisu_toggle, Hiragana_Katakana, Hangul, and Hangul_Hanja. Generating Eisu_toggle for ImeOff and Hiragana_Katakana for ImeOn were semantically incorrect as they rather provide the functionality of Eisu toggle / Caps Lock and Hiragana / Katakana / Romaji. 3. Solution This change solves the situation by always defining HNGL and HJCV key codes and generating Hangul for Lang1 keys and Hangul_Hanja for Lang2 keys. In this way, Japanese and Korean IMEs can know keys they need to toggle IME states. Japanese IMEs can also distinguish ImeOn and ImeOff from Eisu toggle / Caps Lock and Hiragana Katakana / Romaji. This change lets Hangul and Hangul_Hanja symbols overload semantics of Japanese and Korean IMEs. This is based on the following rationales: * evdev always emitted Hangul and Hangul_Hanja symbols before this change and therefore it would be least disruptive. * The key pairs are physically located in the same positions so users would expect them to perform interchangeably when switching Japanese and Korean IMEs. * Distinguishing from key codes is not possible anyway because the underlying hardware complies USB HID Usage Table, which do not distinguish those keys.
* keycodes: add KEY_EMOJI_PICKER from kernel v5.13Peter Hutterer2022-01-171-0/+1
| | | | | | Missing from 011b71a6f4b306db5c97953cb339b86cd089835f Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Drop autotoolsPeter Hutterer2021-12-171-25/+0
| | | | | | Even the xserver is now meson only and building a desktop stack without meson is not possible anymore. So let's drop autotools for meson, which is much easier to maintain.
* Move the evdev.in and inet.in template file to the gitlab-ci directoryPeter Hutterer2021-04-121-217/+0
| | | | | | | | 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>
* gitlab CI: generate the evdev keycodes (v2)Peter Hutterer2021-02-162-103/+597
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* keycodes: alias some used-by-default evdev keysPeter Hutterer2021-01-211-1/+4
| | | | | | | | | | | | | | | OUTP has been mapped to XF86Display in symbols/pc for about 13 years now, but no evdev keycode is mapped to this alias. Instead, we have I235 mapped to XF86Display in symbols/inet. Alias I235 to OUTP and remove the separate mapping, the keymap stays the same. Fixes xkbcomp warning Warning: Key <OUTP> not found in evdev+aliases(qwerty) keycodes Symbols ignored The same goes for KITG/KIDN/KIUP, all of which are mapped in symbols/pc. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Revert "gitlab CI: generate the evdev keycodes"Peter Hutterer2021-01-212-492/+2
| | | | | | | | | | | | | | | 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>
* gitlab CI: generate the evdev keycodesPeter Hutterer2021-01-182-2/+492
| | | | | | | | | | | | | | | | | | | 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>
* keycodes: fix some space vs tab issuesPeter Hutterer2021-01-181-8/+8
| | | | | | Make the line format for keycodes consistent for all <I123> codes. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Map `KEY_DOLLAR` and `KEY_EURO` to `dollar` and `EuroSign`Paul Menzel2020-06-231-0/+2
| | | | | | | | | | | | | | | | | The keyboard of the Acer TravelMate 5735Z has dedicated currency keys close to the arrow keys. Currently, these are not working. `libinput debug-events` reports the events below. event0 KEYBOARD_KEY +7.161s KEY_EURO (435) pressed event0 KEYBOARD_KEY +7.305s KEY_EURO (435) released event0 KEYBOARD_KEY +7.708s KEY_DOLLAR (434) pressed event0 KEYBOARD_KEY +7.852s KEY_DOLLAR (434) released So, add the corresponding mappings. With these changes, pressing these keys results in € and $ being displayed by GNOME Shell 3.36.3. Closes: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/213
* Sort evdev keycodesPaul Menzel2020-06-091-1/+1
| | | | Fixes: commit 28bb029b ("Map evdev keycode KEY_FULL_SCREEN to XF86XFullScreen")
* keycodes: merge the digital_vndr and sgi_vndr subdirs into the main dirPeter Hutterer2020-06-023-10/+6
| | | | | | They're just straight installs. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Indent the various dist_foo_DATA for better visual alignmentsPeter Hutterer2020-06-021-16/+16
| | | | | | No functional changes Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Use dist_foo_DATA to remove the need for EXTRA_DISTPeter Hutterer2020-06-021-3/+1
| | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Merge branch 'swick/xkeyboard-config-inet-fullscreen'Sergey Udaltsov2020-01-231-0/+1
|\
| * Map evdev keycode KEY_FULL_SCREEN to XF86XFullScreenSebastian Wick2019-10-311-0/+1
| | | | | | | | | | | | | | | | | | Add XF86XFullScreen, to be used as mapping for evdev's KEY_FULL_SCREEN. The patch for adding the FullScreen keysym to xproto is here: https://gitlab.freedesktop.org/xorg/proto/xorgproto/merge_requests/11 Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
* | keycodes: drop the PC98 custom model handlingPeter Hutterer2019-11-141-5/+0
|/ | | | | | This is obsolete, it's just evdev now Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Map evdev keycode KEY_ROTATE_LOCK_TOGGLE to XF86RotationLockToggleHans de Goede2019-03-161-0/+1
| | | | | | | | | | | | | | | Add XF86RotationLockToggle, to be used as mapping for evdev's KEY_ROTATE_LOCK_TOGGLE. I've a Point of View P1006W-232 Windows tablet which actually has a rotate-lock toggle-button. The latest kernel correctly generates KEY_ROTATE_LOCK_TOGGLE events for this. So now I'm hooking up support for it through all the higher layers. The patch for adding the RotationLockToggle keysym to xproto is here: https://patchwork.freedesktop.org/patch/279365/ Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* evdev/inet: Fix KEY_KEYBOARD mappingHans de Goede2019-03-161-1/+1
| | | | | | | | | | | | | | | | KEY_KEYBOARD has an evdev-keycode value of 374 not 366. It seems that with the original addition of the mapping the evdev-keycode value was mistaken for the X scancode which is 8 higher then the evdev-keycode since the X scancodes start at 8. What seems to have happened is that the evdev-keycode was used instead of the X scancode and then 8 was subtracted for the wrong "// #define KEY_KEYBOARD 366" comment. This commit corrects the comment to say 374 and corrects the X scancode being mapped to 382. Cc: Christian Kellner <christian@kellner.me> Reviewed-by: Christian Kellner <christian@kellner.me> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Map evdev keycode KEY_KEYBOARD to XF86KeyboardChristian Kellner2018-05-141-0/+1
| | | | | | | | | | NB: XF86Keyboard is a relatively new keysym and therefore needs recent protocol headers. Also KEY_KEYBOARD's keysym is > 255 and therefore needs a recent xkbcomp (as the new KEY_FAVORITES). https://bugs.freedesktop.org/show_bug.cgi?id=101521 Signed-off-by: Christian Kellner <christian@kellner.me>
* Map evdev keycode KEY_FAVORITES to XF86FavoritesChristian Kellner2018-05-141-0/+2
| | | | | | | | | | | NB: The value of KEY_FAVORITES is 0x16c (364) and thus beyond 255, which is not supported by X11. It might also need a recent xkbcomp that is patched so it does not throw fatal errors for those. See https://lists.x.org/archives/xorg-devel/2017-April/053389.html https://bugs.freedesktop.org/show_bug.cgi?id=100709 Signed-off-by: Christian Kellner <christian@kellner.me>
* Map evdev keycodes KEY_RFKILL and KEY_WWAN to XF86RFKill and XF86WWANBenjamin Berg2018-02-011-0/+2
| | | | | | | In particular KEY_RFKILL is required for properly handling airplane mode in userspace. https://bugs.freedesktop.org/show_bug.cgi?id=100970
* Added sbj keymap for Jolla phoneAndres Gomez2016-01-142-0/+11
| | | | | | | | | This extended keymap includes keycodes beyond the 255 which are not handled by X11 so it is only suitable for the use with libraries that support extended keycodes, like libxkbcommon. https://bugs.freedesktop.org/show_bug.cgi?id=92238
* Fix overlap of inet keys with jp Henkan and Muhenkan keysEgbert Eich2014-02-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The keyboard driver (for legacy keyboards) reports the same keycodes for some inet keys as for the extra keys (Henkan and Muhenkan) on Japanese 106 keyboards. So on these keyboards Japanese users either loose their extra keys or some multimedia keys. In: commit bd9d0ced6154de583c96573585f428618017fca3 Fix henkan key on jp106 keyboard with inet media keys the Henkan/Muhenkan keys were reintroduced. A better fix will map one of the two sets to different and still unused keycodes. A patch for the xf86-input-keyboard driver moves the two inet keys into the range above 0xfb. This patch contains the corresponding changes to xkeyboard-config. Both the legacy keyboard driver and xkeyboard-config will have to be updated simultaniously otherwise users will loose the two affected multmedia keys. Signed-off-by: Egbert Eich <eich@freedesktop.org>
* Fix AE00 alias in olpcm keycodesDaniel Drake2013-05-141-0/+1
| | | | | | The olpcm symbols refer to AE00 but that is not defined anywhere. https://bugs.freedesktop.org/show_bug.cgi?id=34738
* add support for the OLPC mechanical non-membrane keyboardWalter Bender2013-04-202-0/+24
| | | | | | | | | | | Patch updated against current tree. > From: Paul Fox <pgf@laptop.org> > Date: Tue, 20 Jul 2010 16:22:40 -0400 > Subject: [PATCH] add support for the OLPC "mechanical" (non-membrane) keyboard > model(s). to aid in this, add keycodes/olpc with aliases to avoid needing to > use BKSL and TLDE, which don't appear anywhere near their "traditional" > position on the olpcm mechanical keyboards.
* Update keycodes and geometry for Sun Keyboardsjavier2013-01-151-741/+37
| | | | | | Remove support for old Sun Type_4/5 keyboards and update data for Sun Type_6/7 Keyboards as described in Bug 57450 - XKB data specific for Sun Keyboards is outdated.
* Remove *.dir generationDaniel Stone2012-08-291-4/+2
| | | | | | | | | | It's only used by the X server's ListComponents call, which I intend to stub out shortly. (For bonus points, that call will fork xkbcomp to generate the necessary listings itself if it can't find the *.dir files.) Signed-off-by: Daniel Stone <daniel@fooishbar.org>
* Move fake key MDSW to a different keycode value in xfree86 table.Stefan Dirsch2011-05-251-1/+4
| | | | | | | | | According to symbols/inet this keycode is used by two keyboard models: logitech_g15 and apple. Thus it should not be used for a fake keycode that gets assigned to a virtual modifier. Signed-off-by: Egbert Eich <eich@freedesktop.org>
* Remove RCS tagsAlexandr Shadchin2011-02-1916-42/+0
| | | | Signed-off-by: Alexandr Shadchin <Alexandr.Shadchin@gmail.com>
* Add keycode definitions required for Apples Expose & Dashboard keys (F3/F4)Bryce Harrington2011-02-181-0/+2
| | | | | | | | | | | | | | Apple's Expose and Dashboard keys (F3 and F4) have correct keycodes reported by evdev, but are not mapped. This adds the required keycodes and symbols, using the symbols XF86LaunchA and XF86LaunchB, which allows the keys to be used in compiz configuration. (This patch has been included in Ubuntu since 2010.) Bug: #34351 Ref.: https://bugs.launchpad.net/ubuntu/+bug/520519 Signed-off-by: Bryce Harrington <bryce@canonical.com>
* removed dupesSergey V. Udaltsov2011-01-101-4/+0
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=32975
* xkeyboard-config: Keycodes for Apple Aluminium KeyboardsDamien Ciabrini2010-03-271-0/+24
| | | | | | | Aliases for base rules to match geometry definition JIS keyboard aliases necessary for evdev rules Signed-off-by: Damien Ciabrini <damien.ciabrini@gmail.com>
* Try #1 to create an "empty" rule.Jeremy Huddleston2010-02-202-0/+9
| | | | Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
* Update Sun license notices to current X.Org standard formAlan Coopersmith2010-01-171-23/+17
| | | | Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
* fixed Sun Type 6 modelSergey V. Udaltsov2009-09-151-1/+1
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=3952
* Remove unused .cvsignore file #23776Gaetan Nadon2009-09-083-7/+0
| | | | | | CVS is no longer used for X.Org modules Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* keycodes: restore I56-I59 by using aliases for OUTP and friends.Peter Hutterer2009-04-221-4/+8
| | | | | | | | | | 65fba6dfe3435f changed I56 to I59 to OUTP, KITG, KIDN, KIUP and removed the I56 keycodes from the xfree86 map. Some inet models rely on this key for special functionality - they don't work anymore now. Instead of replacing them completely, alias OUTP to I56, etc. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Dropping national-specific models abnt2, jp106, kr106. The corresponding ↵Sergey V. Udaltsov2009-02-262-18/+7
| | | | geometries are left in the codebase, for some while
* make keycode AC12 alias for BKSLSergey V. Udaltsov2009-02-192-2/+2
|
* merged xfree86(jp106) keycodes into xfree86, dropped the unnecesssary ruleSergey V. Udaltsov2009-02-192-11/+2
|
* dropped goodmap and badmap for apple macbooks, needed only for old broken ↵Sergey V. Udaltsov2008-12-181-10/+0
| | | | kernels, b.fd.o#9095
* Set keycode ranges 8-255, universally, b.fd.o#12538Sergey V. Udaltsov2008-11-268-25/+25
|
* fixed abnt2 keycodes, b.fd.o#18712Sergey V. Udaltsov2008-11-261-0/+1
|
View Lorry Controller Status