| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
Signed-off-by: Ran Benita <ran234@gmail.com>
|
| |
|
|
|
|
|
| |
Instead of using a static array of size XKB_NUM_GROUPS, because we want
to get rid of this limit.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
| |
|
|
|
|
| |
One unneeded XKB_NUM_GROUPS less.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function really needs a format argument, for symmetry with the
keymap creation functions. If we add new formats, we will almost
certainly want to add support for serializing it into a string. It would
also allow to convert from one format to another, etc.
The in the common case, the user would just want to use the format she
used to create the keymap; for that we add a special
XKB_KEYMAP_USE_ORIGINAL_FORMAT value, which will do that (it is defined
to -1 outside of the enum because I have a feeling we might want to use
0 for something else). To support this we need to keep the format inside
the keymap. While we're at it we also initialize keymap flags properly.
This changes the API, but the old xkb_map_get_as_string name works as
expected so this is the best time to do this.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
| |
|
|
|
|
| |
Because we keep the keycode inside the xkb_key now.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
Seeing as we don't like "map" anymore.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
