|
d92a248c
|
2020-02-05T17:42:06
|
|
API to query modifier set required to type a keysym
The new API is useful to implement features like auto-type and
desktop automation. Since the inputs for these features is usually
specified in terms of the symbols that need to be typed, the
implementation needs to be able to invert the keycode->keysym
transformation and produce a sequence of keycodes that can be used
to type the requested character(s).
|
|
40aab05e
|
2019-12-27T13:03:20
|
|
build: include config.h manually
Previously we included it with an `-include` compiler directive. But
that's not portable. And it's better to be explicit anyway.
Every .c file should have `include "config.h"` first thing.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
9d58bbd4
|
2019-06-04T14:01:02
|
|
Use bitwise test instead of popcount to check if one bit is set
We don't need to determine the total number of bits set to determine if
exactly one is set.
Additionally, on x86_64 without any -march=* flag, __builtin_popcount
will get compiled to a function call to the compiler runtime (on gcc),
or a long sequence of bit operations (on clang).
Signed-off-by: Michael Forney <mforney@mforney.org>
|
|
767fa86d
|
2017-12-21T14:18:07
|
|
Convert http:// -> https:// where possible
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
6b57344c
|
2017-04-27T20:06:21
|
|
state: cure boolean blindness in the filter functions' result
Makes it a little easier to understand the filters.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
927fd8f8
|
2017-04-27T19:17:53
|
|
state: remove unneeded NULL check
xkb_filter_new() cannot return NULL.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
d44c3ab2
|
2017-04-27T19:14:56
|
|
state: reorder new() functions before the set() functions in the code
So that they may be read more naturally in chronological order.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
327364d2
|
2016-11-14T17:37:35
|
|
utils: rename popcount to avoid conflict in NetBSD
Resolves https://github.com/xkbcommon/libxkbcommon/issues/41
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
babc9e0c
|
2016-02-27T22:31:16
|
|
state: add GTK consumed modifiers mode
This is more or less what is implemented here:
https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkkeys-x11.c?h=3.19.10#n1131
The implementation here is more technically correct but should provide
the same results.
Try it out with ./test/interactive-evdev -g (modifiers prefixed with "-"
are consumed).
https://bugzilla.gnome.org/show_bug.cgi?id=754110
https://github.com/xkbcommon/libxkbcommon/issues/17
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a0a41332
|
2016-02-27T19:06:14
|
|
state: allow different modes for calculating consumed modifiers
The current functions dealing with consumed modifiers use the
traditional XKB definition of consumed modifiers (see description in the
added documentation). However, for several users of the library (e.g.
GTK) this definition is unsuitable or too eager. This is exacerbated by
some less-than-ideal xkeyboard-config type definitions (CTRL+ALT seems
to cause most grief...).
So, because we
- want to enable alternative interpretations, but
- don't want to expose too much internal details, and
- want to keep things simple for all library users,
we add a high-level "mode" parameter which selects the desired
interpretation. New ones can be added as long as they make some sense.
All of the old consumed-modifiers functions keep using the traditional
("XKB") mode. I mark xkb_state_mod_mask_remove_consumed() and as
deprecated without adding a *2 variant because I don't it is very useful
(or used) in practice.
Alternative modes are added in subsequent commits (this commit only adds
a mode for the existing behavior).
https://github.com/xkbcommon/libxkbcommon/issues/17
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
c8e6996f
|
2016-06-09T15:30:21
|
|
src/state: match_mod_masks can return bool instead of int
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
c8a25645
|
2016-02-28T00:02:05
|
|
state: factor out get_entry_for_mods()
Will be useful later.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9f5139b5
|
2016-02-27T19:43:07
|
|
state: factor out entry_is_active() check
Makes the code slightly cleaner and I plan to use the function in
another place.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
13d23259
|
2015-09-07T14:45:09
|
|
state: reduce scope of fake action
Also rename to "dummy" as I think it is a nicer name.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
c03834a1
|
2014-10-23T21:00:20
|
|
Reduce variable scopes
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
30e7445d
|
2014-10-17T00:41:05
|
|
state: correctly infer inactive type entries
The current test is incorrect, since 'map[None]' is entirely valid. In
most cases this doesn't cause any problems, since the default fallback
is Level1, and it's almost always 'map[None] = Level1' anyway. But in
one case in xkeyboard-config it isn't, in types/numpad(mac):
type "KEYPAD" {
modifiers = None;
map[None] = Level2;
level_name[Level2] = "Number";
};
So before checking if no modifiers were mapped, make sure there *were*
any modifiers at all.
https://bugs.freedesktop.org/show_bug.cgi?id=85092
Reported-by: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a1f0595a
|
2014-08-18T20:27:07
|
|
state: make sure the mods are fully resolved after xkb_state_update_mask()
Virtual modifiers can have "mappings" to real modifiers, e.g. NumLock
may also set Mod2. In a normal turn of events, the various components
(depressed, latched, locked, and consequently effective) include the
mapped mods, because the masks are pre-resolved everywhere. However,
xkb_state_update_mask() accepts arbitrary mod masks, which may not be
resolved (if it comes from somewhere other than
xkb_state_serialize_mods()). So let's always resolve them ourselves.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
99184f16
|
2012-11-24T13:29:54
|
|
Make the effective mod mask calculation available to other files
We will want to use that function in state.c as well.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
80ae8e61
|
2014-08-18T20:08:25
|
|
state: no need for loop in xkb_state_update_mask()
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9014cf8c
|
2014-04-22T13:15:21
|
|
keymap, keycodes, compat: don't use darray for LEDs
Use a static array of size XKB_MAX_LEDS instead, as in xkb_mod_set.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
3d7aff5f
|
2014-04-19T16:15:05
|
|
keymap: rename wrap_group_into_range -> XkbWrapGroupIntoRange
It better fits with the naming convention in keymap.h.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
54174409
|
2014-03-27T17:42:20
|
|
state: fix consumed modifier calculation
The current calculation is in short:
entry ? (entry->mask & ~entry->preserve) : 0
This changes it be
type->mask & ~(entry ? entry->preserve : 0)
This is what Xlib does. While less intuitive, it is actually more
correct, if you follow this deduction:
- The key group's type->mask defines which modifiers the key even cares
about. The others are completely irrelevant (and in fact they are
masked out from all sided in the level calculation). Example: NumLock
for an alphabetic key.
- The type->mask, the mods which are not masked out, are *all* relevant
(and in fact in the level calculation they must match *exactly* to the
state). These mods affect which level is chosen for the key, whether
they are active or not.
- Because the type->mask mods are all relevant, they must be considered
as consumed by the calculation *even if they are not active*.
Therefore we use type->mask instead of entry->mask.
The second change is what happens when no entry is found: return 0 or
just take preserve to be 0? Let's consider an example, the basic type
type "ALPHABETIC" {
modifiers = Shift+Lock;
map[Shift] = Level2;
map[Lock] = Level2;
level_name[Level1] = "Base";
level_name[Level2] = "Caps";
};
Suppose Shift+Lock is active - it doesn't match any entry, thus it gets
to level 0. The first interpretation would take them both to be
unconsumed, the second (new one) would take them both to be consumed.
This seems much better: Caps is active, and Shift disables it, they both
do something.
This change also fixes a pretty lousy bug (since 0.3.2), where Shift
appears to apparently *not* disable Caps. What actually happens is that
Caps is not consumed (see above) but active, thus the implicit
capitalization in get_one_sym() kicks in and capitalizes it anyway.
Reported-by: Davinder Pal Singh Bhamra
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
3cfa7fda
|
2014-03-21T23:00:37
|
|
state: apply control transformation on utf8/utf32 keysym strings
This is required by the specification:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Control_Modifier
and clients expect this to happen.
https://bugs.freedesktop.org/show_bug.cgi?id=75892
Reported-by: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
b973d71e
|
2014-03-21T23:00:17
|
|
state: add xkb_state_key_get_{utf8,utf32}() API functions
These functions generally have the same effect as
xkb_state_key_get_syms() + xkb_keysym_to_utf{8,32}().
So why add them?
- They provide a slightly nicer interface, especially if the string is
the only interest.
- It makes the handling of multiple-keysyms-to-utf8 transparent. For the
designated use-case of multiple-keysyms (unicode combining
characters), this is a must. We also validate the UTF-8, which the
user might not otherwise do.
- We will need to apply some transformation on the resulting string
which depend on the xkb_state. This is not possible with the
xkb_keysym_* functions.
With these functions, the existing xkb_keysym_to_utf{8,32}() are not
expected to be used by a typical user; they are "raw" functions.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
4fb7b06b
|
2014-02-21T18:09:00
|
|
state: Add xkb_state_key_get_consumed_mods
This retrieves the mask of consumed modifiers for a given key and state,
which is helpful for toolkits without having them to do it one modifier
at a time, or pass in 0xFFFFFFFF to xkb_state_remove_consumed_mods to
"reverse-engineer" the consumed mods.
|
|
e89516e9
|
2014-02-09T13:51:38
|
|
state: check wrap_group_into_range() return value
It returns XKB_LAYOUT_INVALID in case num_groups == 0. So we shouldn't
just save it in the state.
Note, though, that this condition is generally impossible.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
04bacf87
|
2014-02-08T15:53:50
|
|
state: optimize xkb_state_led_update_all()
Before:
ran@ran:~/src/libxkbcommon$ ./test/bench-key-proc
ran 20000000 iterations in 6.623018074s
After:
ran@ran:~/src/libxkbcommon$ ./test/bench-key-proc
ran 20000000 iterations in 4.762291091s
Not that anyone needs to process millions of keys per second...
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
769b91c5
|
2014-02-08T15:30:05
|
|
Use (1u << idx) instead of (1 << idx) where appropriate
It doesn't matter (I think), since the implicit conversion doesn't have
any effect (e.g. sign-extension). But it's better to be aware of the
type.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
623b10f8
|
2014-02-08T00:27:54
|
|
Fix sign-compare warnings
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
2abff2a0
|
2014-02-07T17:29:34
|
|
state: use the XKB_MOD_MASK constant
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
31430670
|
2014-01-11T16:40:42
|
|
Fix some cppcheck warnings
Someone was nice enough to run this for us:
ftp://ftp.sunet.se/pub/Linux/distributions/Debian/debian/pool/main/libx/libxkbcommon/libxkbcommon_0.3.1.orig.tar.gz
[libxkbcommon-0.3.1/src/keymap.c:86]: (style) The scope of the variable 'j' can be reduced.
[libxkbcommon-0.3.1/src/keymap.c:87]: (style) The scope of the variable 'key' can be reduced.
[libxkbcommon-0.3.1/src/keysym-utf.c:843]: (style) The scope of the variable 'mid' can be reduced.
[libxkbcommon-0.3.1/src/state.c:992]: (style) The scope of the variable 'str' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/action.c:467]: (style) The scope of the variable 'absolute' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:468]: (style) The scope of the variable 'consumed' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:862]: (style) The scope of the variable 'mlvo' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:863]: (style) The scope of the variable 'kccgst' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:865]: (style) The scope of the variable 'match_type' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/symbols.c:753]: (style) The scope of the variable 'toAct' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/symbols.c:1573]: (style) The scope of the variable 'key' can be reduced.
[libxkbcommon-0.3.1/test/common.c:80]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'.
[libxkbcommon-0.3.1/test/interactive.c:358]: (style) The scope of the variable 'nevs' can be reduced.
[libxkbcommon-0.3.1/test/interactive.c:236]: (style) Checking if unsigned variable 'nsyms' is less than zero.
[libxkbcommon-0.3.1/test/interactive.c:226]: (style) Unused variable: unicode
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
2a2a8d7d
|
2013-08-13T18:57:43
|
|
state: apply capitalization transformation on keysyms
The xkbproto spec says:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Lock_Modifier
If the Lock modifier is not consumed by the symbol lookup process,
routines that determine the symbol and string that correspond to
an event should capitalize the result.
This was not an issue until now, because most xkeyboard-config keymaps
do not utilize this "feature", and specify the keysyms for the Lock
modifier explicitly instead. However, some keymaps do depend on it, e.g.
ch(fr) for eacute and others.
The spec goes on to describe two options for doing this transformation:
locale-sensitive and locale-insensitive. We opt for the latter; it is
less desirable but we don't want *that* headache.
Also, only xkb_state_key_get_one_sym() is changed;
xkb_state_key_get_syms() is left as-is, and always reports the
untransformed keysyms. This is for the following reasons:
- The API doesn't allow it, since we return a const pointer directly to
the keymap keysyms table and we can't transform that.
- The transformation doesn't make sense for multiple-keysyms.
- It can be useful for an application to get the "raw" keysyms if it
wants to (e.g. maybe it wants to do the transformation itself).
Finally, note that xkb_state_mod_index_is_consumed() does *not*
report Lock as consumed even if it was used in the transformation. This
is what Xlib does.
This definitely doesn't fall under the "hard to misuse" API rule but
it's the best we can do.
https://bugs.freedesktop.org/show_bug.cgi?id=67167
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
be38862b
|
2013-07-26T00:50:26
|
|
keymap: remove struct xkb_key_redirect_action
The file src/xkbcomp/action.c already doesn't handle this action type
and fails if it encounters it. So lets not pretend to do something with
it, and ignore it rather than failing.
If we/someone wants this we can consider implementing it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9f75e0ab
|
2013-03-07T01:15:21
|
|
state: use stdbool in filters
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
57bfde3a
|
2013-03-04T18:41:13
|
|
keymap: rename xkb_kt_map_entry to xkb_key_type_entry
That's a better name and fits more nicely.
Also change type->map to type->entries.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
cd6a71fc
|
2013-03-04T02:12:00
|
|
state: small style fix
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
8cee7490
|
2013-02-17T22:18:57
|
|
Change 'indicator' to 'led' everywhere possible
The code currently uses the two names interchangeably.
Settle on 'led', because it is shorter, more recognizable, and what we
use in our API (though of course the parser still uses 'indicator').
In camel case we make it 'Led'.
We change 'xkb_indicator_map' to just 'xkb_led' and the variables of
this type are 'led'. This mimics 'xkb_key' and 'key'.
IndicatorNameInfo and LEDInfo are changed to 'LedNameInfo' and
'LedInfo', and the variables are 'ledi' (like 'keyi' etc.). This is
instead of 'ii' and 'im'.
This might make a few places a bit confusing, but less than before I
think. It's also shorter.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
089c3a18
|
2013-02-17T14:59:50
|
|
state: fix unbound virtual modifier bug
Recent xkeyboard-config introduced the following line in symbols/level3:
vmods = LevelThree,
However, the XKM format which xkbcomp produces for the X server can't
handle explicit virtual modifiers such as this:
https://bugs.freedesktop.org/show_bug.cgi?id=4927
So by doing the following, for example:
setxkbmap -layout de (or another 3-level layouts)
xkbcomp $DISPLAY out.xkb
xkbcomp out.xkb $DISPLAY
The modifier is lost and can't be used for switching to Level3 (see the
included test).
We, however, are affected worse by this bug when we load the out.xkb
keymap. First, the FOUR_LEVEL_ALPHABETIC key type has these entries:
map[None] = Level1;
map[Shift] = Level2;
map[Lock] = Level2;
map[LevelThree] = Level3;
[...]
Now, because the LevelThree virtual modifier is not bound to anything,
the effective mask of the "map[LevelThree]" entry is just 0. So when
the modifier state is empty (initial state), this entry is chosen, and
we get Level3, instead of failing to match any entry and getting the
default Level1.
The difference in behavior from the xserver stems from this commit:
acdad6058d52dc8a3e724dc95448300850d474f2
Which removed the entry->active field. Without bugs, this would be
correct; however, it seems in this case we should just follow the
server's behavior.
The server sets the entry->active field like so in XKBMisc.c:
/* entry is active if vmods are bound */
entry->active = (mask != 0);
The xkblib spec explains this field, but does not specify how to
initialize it. This commit does the same as above but more directly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
f1598469
|
2012-11-11T16:14:30
|
|
state: rename state->cur to state->components
'cur' doesn't make sense anymore. 'components' is a bit long for this,
but not too bad, and nothing better comes to mind.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
7372c9f1
|
2012-11-11T16:06:54
|
|
state: don't keep the previous state components in xkb_state
There is really no need to keep this in the struct, we can just allocate
it on the stack when we need to.
Don't know why I did it this way.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
60bd9202
|
2012-11-11T00:22:46
|
|
keymap: wrap the layout parameter if it is out of range for the key
The functions num_levels_for_key() and get_syms_by_level() have a
'layout' parameter. Currently it is expected that this value is always
legal for the key, as determined by num_layouts_for_key(). However,
there are legitimate use cases for passing an out-of-range layout there,
most probably passing the effective layout, and expecting to get the
keysyms/levels for just this layout. So we wrap it just as we do in the
xkb_state_* functions.
This is also useful for stuff like this:
http://developer.gnome.org/gdk/stable/gdk-Keyboard-Handling.html#gdk-keymap-lookup-key
If this behavior is not desired, the user has the option to check
against num_layouts_for_key herself.
https://bugs.freedesktop.org/show_bug.cgi?id=56866
Reported-by: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
7261f404
|
2012-10-29T01:00:27
|
|
state, context: allow passing NULL to *_unref()
For error handling code, it's nice to be able to pass NULL to these
function without worrying about segfaults ensuing. free() sets the
precedent here.
Also document this fact.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a51ee704
|
2012-10-26T16:24:11
|
|
state: don't use xkb_keymap_num_layouts internally
Clearer and more greppable this way.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
ee6f3f28
|
2012-10-26T16:12:28
|
|
state: don't use xkb_state_serialize_* internally
The code in these cases is clearer when done directly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
6f093ad5
|
2012-10-24T23:09:26
|
|
state: fix possible index-out-of-bounds in action dispatch table
The current code assumes that action->type always falls in the range of
the xkb_action_type enum. But keymaps can also have Private actions,
which are allowed to set their own type number.
So with a default xkeyboard-config keymap, keycode 86 at level 4, which
triggers such an action, causes us to crash.
Fix it by always checking the bounds.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
867992cd
|
2012-10-23T17:17:18
|
|
state: fix typo in state component copying
Gladly no-one should have been fast enough to hit this.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
4b81c9f3
|
2012-10-22T21:00:57
|
|
Report which components of the state have changed
We add a return value to the xkb_state_update_key and
xkb_state_update_mask, which reports to the caller which of the state
components have changed as a result.
This restores the XKB functionality of the XkbStateNotify and
XkbIndicatorsStateNotify events. See:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Events
It is quite useful in some situations. For example, it allows an
application to avoid doing some work if nothing of relevance in the
state has changed. Say, a keyboard layout applet. Also useful for
debugging.
The deltas themselves are not provided, because I can't see a use case.
If needed, it should be possible to add some API for that.
In xkbcommon, keymaps are immutable, so all of the other *Notify events
from XKB are irrelevant.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
550cb24d
|
2012-10-22T19:19:43
|
|
state: add struct state_components
This holds all of the state component fields in the state in one struct.
We will later want to keep the previous state components after updates,
so this will allow us to do it without duplicating the fields.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
6a94b122
|
2012-10-22T20:49:44
|
|
Split the mods, layout, leds parts of xkb_state_components
Note first:
This commits breaks the ABI somewhat. If an application is run against
this commit without recompiling against the updated header, these break:
- xkb_state_layout_*_is_active always retuns false.
- xkb_state_serialize_mods always returns 0.
So it might break layout switching in some applications. However,
xkbcommon-compat.h provides the necessary fixes, so recompiling should
work (though updating the application is even better).
Split the enum to its individual components, which enables us to refer
to them individually. We will use that later for reporting which
components of the state have changed after update.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
f43b33c0
|
2012-10-13T13:13:55
|
|
state: make mod_index_is_consumed() return -1 on invalid input
Like all the other functions.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9197eb0f
|
2012-10-10T19:08:01
|
|
Remove the XKB_NUM_INDICATORS limit
Use a darray instead of a static array of size 32.
We still enforce XKB_MAX_LEDS because of the size of xkb_led_mask_t.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
2f4db8a9
|
2012-10-10T09:47:31
|
|
keymap, state: don't assume led index < xkb_keymap_num_leds
xkb_keymap_num_leds() returns the number of leds that have any
possibility of being set. Even if a led is defined but can not be set in
any way, it is not counted.
In a few places currently we assume that led indexes are smaller than
this number, which is wrong both for the above reason and for the fact
that the xkb format actually allows explicitly setting the indicator
index, which means that the indexes might be non-consecutive.
We don't really have good API to iterate on leds, now, because
xkb_keymap_num_leds is pretty useless. To work around that we use
sizeof(xkb_led_mask_t) * 8.
This makes the "Group 2" led work (try switching to a layout other than
the first in test/interactive).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
b65980cc
|
2012-10-05T15:10:41
|
|
state: don't needlessly fetch the xkb_key
It's a leftover.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
8016c6f4
|
2012-10-03T20:21:05
|
|
state: simplify xkb_state_mod_index_is_active
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
e5b6055b
|
2012-10-03T20:16:09
|
|
state: don't ignore type argument in xkb_state_mod_*_are_active
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
1a6b1e07
|
2012-10-03T19:41:22
|
|
state: fix bad EFFECTIVE check in *_is_active()
This is a regression introduced in ed78fbcb30888cbfc6cd00.
XKB_STATE_EFFECTIVE is just a OR of the other states, so using & here is
completely wrong. So test/state shows for example:
dumping state for LCtrl down:
group English (US) (0): effective depressed latched locked
mod Control (2): depressed latched locked
dumping state for LCtrl + RAlt down:
group English (US) (0): effective depressed latched locked
mod Control (2): depressed latched locked
mod Mod1 (3): depressed latched locked
dumping state for RAlt down:
group English (US) (0): effective depressed latched locked
mod Mod1 (3): depressed latched locked
dumping state for Caps Lock:
group English (US) (0): effective depressed latched locked
mod Lock (1): depressed latched locked
led Caps Lock (0): active
dumping state for Alt-Shift-+
group English (US) (0): effective depressed latched locked
mod Shift (0): depressed latched locked
mod Mod1 (3): depressed latched locked
which is bogus.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
fe1faa14
|
2012-10-03T20:08:13
|
|
Use our types instead of int/uint32_t in a few places
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
11df0632
|
2012-09-27T21:11:11
|
|
state: add missing const in get_one_sym
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
5aaf65b7
|
2012-09-27T23:27:49
|
|
Add xkb_state_key_get_one_sym
The trivial wrapper around xkb_state_key_get_syms that every user to
date has implemented.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
5d265926
|
2012-09-24T14:57:30
|
|
keymap: remove some more unneeded macros
It clearer to just access the needed data directly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
c955f8e2
|
2012-09-24T14:41:09
|
|
keymap: store a pointer to the type in xkb_group instead of index
Gets rid of some more unneeded indirection, including the XkbKeyType
macro.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
01b00d75
|
2012-09-24T12:11:31
|
|
keymap, symbols: improve xkb_key memory layout
Add struct xkb_group and xkb_level for use in xkb_key, to mirror how
it's done in KeyInfo, GroupInfo, LevelInfo in symbols.c. This
corresponds more nicely to the logical data layout (i.e. a key has
groups which have levels), and also removes a lot of copying and ugly
code due to the index indirections and separate arrays which were used
before.
This uses more memory in some places (e.g. we alloc an action for every
level even if the key doesn't have any) but less in other places (e.g.
we no longer have to pad each group to ->width levels). The numbers say
we use less overall.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
419a4975
|
2012-09-21T21:16:20
|
|
state: missing XKB_EXPORT on xkb_state_key_get_level
And some error handling.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
67b03cea
|
2012-09-21T16:30:01
|
|
state: correctly wrap state->locked_group and ->group
These values weren't wrapped before, which caused group_index_is_active
to stop working after a few group switches.
Also, the current group-wrapping function didn't take into consideration
actions such as LockGroup=-1, which need to wrap around, etc.
xkb_layout_index_t is unsigned, but it was used to hold possibly
negative values (e.g. locked_group is 0 and gets a -1 action).
This group wrapping function should now act like the XkbAdjustGroup
function from xserver, and at least ./test/interactive doesn't bring up
any problems with group switching any more.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
7d1db12d
|
2012-09-21T15:39:32
|
|
state: separate group wrapping/clamping to a function
We'll need this function for wrapping our global effective group as
well.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
ed78fbcb
|
2012-09-21T12:45:58
|
|
state: special case effective group in layout_is_active
Currently, xkb_state_layout_{index,name}_is_active may report multiple
groups as effective, because at looks at base,latched,locked separately.
But there can only be one effective group, which is computed from the
other three. So if XKB_STATE_EFFECTIVE is requested, just compare to the
effective group we have computed.
We also modify mod_{index,name}_is_active similarly, just for symmetry
(there the effective mask is just an OR of the other three so the
current test is correct).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
bbaa11c6
|
2012-09-21T14:58:31
|
|
Rename map.{c,h} to keymap.{c,h}
Seeing as we don't like "map" anymore.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
7dca986e
|
2012-09-21T14:55:46
|
|
state, map: check XkbKey != NULL where missing
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
debd62b5
|
2012-09-21T13:30:42
|
|
Move xkb_state functions from map.c to state.c
Seems more appropriate.
Only change is to turn some xkb_state_get_map functions to direct
state->keymap.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
fcd20290
|
2012-09-21T14:44:17
|
|
Don't use xkbcommon-compat names in internal code
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
bf194080
|
2012-09-19T16:19:57
|
|
Promote keymap enumeration API to public
Rename the functions to get keysyms by key/layout/level to fit with the
recent public API renames, and expose them.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
6b66afc4
|
2012-09-19T15:56:07
|
|
state: handle ACTION_LOCK_NO_{UN,}LOCK for mods
xkblib spec says:
XkbSA_LockNoLock If set, and the action type is XkbSA_LockMods,
the server only unlocks the action modifiers.
XkbSA_LockNoUnlock If set, and the action is XkbSA_LockMods,
the server only locks the action modifiers.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
b2110705
|
2012-09-16T14:45:32
|
|
Organize src/ and test/ headers
- Add context.h and move context-related functions from xkb-priv.h to
it.
- Move xkb_context definition back to context.c.
- Add keysym.h and move keysym upper/lower/keypad from xkb-priv.h to it.
- Rename xkb-priv.h to map.h since it only contains keymap-related
definitions and declarations now.
- Remove unnecessary includes and some and some other small cleanups.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9a27ac72
|
2012-09-14T16:10:47
|
|
state: use filter->priv instead of modifying the action
in xkb_filter_group_set_new.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
8098daa0
|
2012-09-14T16:01:11
|
|
state: move filter initialization to the dispatcher
This removes all of the boilerplate from the *_new functions, and leaves
them just as simple functions which perform the effect of the action on state.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
2c19c938
|
2012-09-14T15:33:54
|
|
state: call xkb_filter_new from the dispatcher
Pass the new filter as a parameter instead of getting a new one in each
action function, and introducing a failure condition there.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
16425ffa
|
2012-09-14T11:26:36
|
|
state: don't keep the xkb_state in the filters
Just pass it as a parameter: to make state.c a bit less stateful.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
c2570d51
|
2012-09-14T11:17:30
|
|
state, map: constify references to xkb_key
Makes it clear that we treat the keys as immutible values in these
files.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
04f1b3be
|
2012-09-14T15:29:12
|
|
state: dispatch actions from a table
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
841f3223
|
2012-09-14T11:02:12
|
|
state, map: use keycodes only for the API functions
The policy is now consistent: every API functions which recieves a
keycode should resolve it to an xkb_key first thing, and all the
internal functions use that instead of the keycode.
To facilitate it a bit, we move the KeycodeInRange check to XkbKey
itself, which returns NULL if the keycode is illegal.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
886b0ca5
|
2012-09-10T23:24:19
|
|
state: remove unused next field from xkb_filter
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
b4b40d73
|
2012-09-12T16:54:07
|
|
Copyright updates
With Dan Nicholson's permission (via email), update his copyright and
license statements to the standard X.Org boilerplate MIT license, as
both myself and Ran have been using.
Clean up my copyright declarations (in some cases to correct ownership),
and add copyright/license statements from myself and/or Ran where
appropriate.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
70c775f6
|
2012-09-10T20:38:46
|
|
kbproto unentanglement: action flags
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
830fe671
|
2012-09-10T20:07:54
|
|
kbproto unentanglement: XkbIM_*
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
0b2506db
|
2012-09-10T19:23:16
|
|
kbproto unentanglement: action types
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
74ec4c1c
|
2012-08-21T12:47:28
|
|
kbproto unentanglement: XkbNumIndicators
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
82491d5f
|
2012-08-30T12:14:29
|
|
map, state: check for KeycodeInRange only in API functions
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
06d7803a
|
2012-08-30T12:13:37
|
|
state: fix mod_names_are_active
This function was always returning -1.
Adding a test, we see that test/state.c treat the is_active functions as
returning booleans, which would treat -1 as success, so we test for > 0
instead (most users would probably get this wrong as well...).
Also update the documentation for the are_active functions, and add a
ATTR_NULL_SENTINEL for gcc __attribute__((sentinel)).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
9f0c0160
|
2012-08-30T11:21:03
|
|
state: fix type confusion within xkb_state_update_mask
idx should be xkb_mod_index_t, while mod is the mask.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
ae576e85
|
2012-08-30T17:15:39
|
|
state: remove unneeded optimization
The code that follows does exactly that.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
a45b7d75
|
2012-08-27T11:51:37
|
|
state: light indicator when either condition is satisfied
For the indicator to be set, it is sufficient for at least one of the
group, modifier, or control state to match; this is in line with the
xkblib spec, section 8.2 and ComputeAutoState() in xserver/xkb/xkbLEDs.c
(though the xserver implementation differs from the spec on some
points...).
This also adds a tiny optimization to skip the entire check if the mask
is empty.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
d1b476a3
|
2012-08-27T11:25:23
|
|
state: fix led_update_all group mask calculation
The one above uses which_mods, this one should use which_groups.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
87dff888
|
2012-08-10T18:14:35
|
|
Store actions inside struct xkb_key
Cuts out a lot of useless redirection and space.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
75853ed6
|
2012-08-10T10:11:49
|
|
Use XKB_{GROUP,LEVEL}_INVALID instead of -1 for errors
The group/level types are unsigned, so it's odd to return -1 for them.
Instead use their invalid values (which happen to be == -1).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
6d61e39d
|
2012-08-10T10:08:20
|
|
state: use global static const for fake action
Requires constifying some arguments.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
07b18bde
|
2012-08-09T02:33:51
|
|
Modernize struct xkb_mods
Currently xkb_mods has the following members:
- uint8_t real_mods - 8 X11 core mods
- xkb_mod_mask_t vmods - 16 virtual mods, zero-based index
- xkb_mod_mask_t mask - the computed effective *real* modifier mask,
basically a cache for the first two which is:
real_mods | real mods computed from vmods
Our API acts on masks which combine the real_mods and vmods into a
single value, which is:
8 first bits real mods | 16 next bits virtual mods
(XkbNumModifiers = 8, XkbNumVirtualMods = 16). This is also the format
which ResolveVModMask uses (which is where all the modifier masks really
"come from", e.g. "Shift+Lock+Level5" -> xkb_mod_mask_t).
What the code does now after getting the mask from ResolveVModMask, is
to break it into real part and virtual part and store them seperately,
and then join them back together when the effective mask is calculated.
This is all pretty useless work. We change xkb_mods to the following:
- xkb_mod_mask_t mods - usually what ResolveVModMask returns
- xkb_mod_mask_t mask - the computed mask cache
And try to consistently use the word "mods" for the original,
non-effective mods and mask for the effective mods (which can only
contain real mods for now, because things break otherwise).
The separation is also made clearer. The effective masks are computed by
UpdateModifiersFromCompat after all the sections have been compiled;
before this the mask field is never touched; after this (i.e. map.c and
state.c) the original mods field is never touched. This single execption
to this rule is keymap-dump.c: it needs to print out only the original
modifiers, not computed ones. This is also the reason why we actually
keep two fields instead keeping one and modifying it in place.
The next logical step is probably to turn the real mods into vmods
themselves, and get rid of the distinction entirely (in a compatible
way).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
59d947c9
|
2012-08-05T19:24:44
|
|
Add and use xkb_level_index_t
Several types are used over the code for shift levels; better to use
just one.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
58f8d2c1
|
2012-07-20T17:09:49
|
|
utils: remove Xfuncproto.h and use our own macros
Add XKB_EXPORT to replace _X_EXPORT, and copy the definitions of
_X_ATTRIBUTE_FOO as ATTR_FOO.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
50b25a12
|
2012-07-17T11:03:43
|
|
Use xkb_group_index_t for group variables throughout
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
d0097f4e
|
2012-07-15T15:55:34
|
|
Pass around xkb_key's instead of keycodes
This way we don't need to look up the key every time. We now only deal
with keycodes in the public API and in keycodes.c.
Also adds an xkb_foreach_key macro, which is used a lot.
Signed-off-by: Ran Benita <ran234@gmail.com>
|