kc3-lang/libxkbcommon/test/data/keymaps/stringcomp.data
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
32c19f4b | 2012-09-27 21:30:29 | keymap-dump: make it look better with long key names Not worth messing around with too much, just make it legible. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4b69d6f7 | 2012-09-15 02:09:34 | keycodes: ignore explicit minimum/maximum statements These statements are pretty pointless for us; we don't restrict keycodes like X does, and if someone writes e.g. maximum = 255 but only has 100 keys, we currently happily alloc all those empty keys. xkbcomp already handles the case when these statements aren't given, and uses a computed min/max instead. We should just always use that. (Of course since keycodes/evdev currently uses almost all of the keycodes in the range it declares, including 255, this doesn't save any memory for the common user right now). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a9fa3739 | 2012-09-12 16:39:54 | keymap-dump: don't write spaces between multiple-syms-per-level This can get a bit unwieldy. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9de067aa | 2012-08-27 21:31:18 | compat: ignore "group" (compatibility) statements Group compatibility statements are like the following: group 3 = AltGr; This currently results in: keymap->groups[2].mask = <real mod mapped from AltGr vmod> And we don't do any thing with this value later. The reason it exists in XKB is to support non-XKB clients (i.e. XKB support disabled entirely in the server), which do not know the concept of "group", and use some modifier to distinguish between the first and second keyboard layouts (usually with the AltGr key). We don't care about all of that, so we can forget about it. One artifact of this removal is that xkb_map_num_groups no longer works, because it counted through keymap->groups (this wasn't entirely correct BTW). Instead we add a new num_groups member to the keymap, which just hold the maximum among the xkb_key's num_groups. This also means we don't have to compute anything just to get the number of groups. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
16f2de8b | 2012-08-14 16:26:30 | compat: ignore "locking" field in sym interprets This field is used in conjunction with key behaviors, which we don't support since c1ea23da5. This is also unused in xkeyboard-config. Signed-off-by: Ran Benita <ran234@gmail.com> | |
 |
93f6517c | 2012-08-03 04:07:33 | stringcomp: Make test more punishing Recreate the old test/dump scenario, where we test the following map: - rules: evdev - model: pc104 - layout #1: us - layout #2: ru - layout #3: ca(multix) - layout #4: de(neo) This is ever so slightly altered from the xkbcomp output; running the following: setxkbmap -rules evdev -model pc105 -layout us,ru,ca,de -variant ,,multix,neo -print | xkbcomp -xkb - - will give you a map with RCTL added to the modifier_map for both Control and Mod3. Running the output through xkbcomp -xkb - - again, will give you RCTL only added to Mod3. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
6701fb5f | 2012-08-03 03:54:44 | stringcomp: Remove unnecessary Level1 mappings As a map will implicitly go to level one unless explicitly mentioned otherwise, remove all explicit =Level1 mappings, except for those with preserve entries. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
39da9274 | 2012-08-03 03:38:46 | stringcomp: Update input file for output changes Bring the input file into line with recent changes to the dump output, so we're as close as we can get to a round trip. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
059c1842 | 2012-07-12 12:02:19 | Move test data files to test/data/keymaps Signed-off-by: Daniel Stone <daniel@fooishbar.org> |