Commit Graph

8 Commits (11df063265655f2c165c80bb1e6e30f443dffd68)

Author SHA1 Message Date
Ran Benita 4b69d6f71d 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>
2012-09-15 02:09:34 +03:00
Ran Benita a9fa37396f 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>
2012-09-13 15:57:10 +03:00
Ran Benita 9de067aad4 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>
2012-09-01 10:59:47 +03:00
Ran Benita 16f2de8bf0 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>
2012-09-01 10:59:46 +03:00
Daniel Stone 93f6517cd0 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>
2012-08-08 16:23:31 +02:00
Daniel Stone 6701fb5fe5 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>
2012-08-08 16:23:30 +02:00
Daniel Stone 39da9274a7 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>
2012-08-08 16:23:30 +02:00
Daniel Stone 059c1842ef Move test data files to test/data/keymaps
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-07-12 14:14:50 +01:00