summaryrefslogtreecommitdiff
path: root/xkbcommon
AgeCommit message (Collapse)AuthorFilesLines
2013-05-09Add keycode min/max and iteration APIMatthias Clasen1-0/+40
Add three new pieces of API: - xkb_keymap_min_keycode does what it says on the tin - xkb_keymap_max_keycode likewise - xkb_keymap_key_for_each calls the provided function once for every valid key in the keymap Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2013-04-01keymap: add xkb_keymap_new_from_buffer()David Herrmann1-0/+14
The current API doesn't allow the caller to create keymaps from mmap()'ed files. The problem is, xkb_keymap_new_from_string() requires a terminating 0 byte. However, there is no way to guarantee that when using mmap() so a user currently has to copy the whole file just to get the terminating zero byte (assuming they cannot use xkb_keymap_new_from_file()). This adds a new entry xkb_keymap_new_from_buffer() which takes a memory location and the buffer size in bytes. Internally, we depend on yy_scan_{string,byte}() helpers. According to flex documentation these already copy the input string because they are wrappers around yy_scan_buffer(). yy_scan_buffer() on the other hand has some insane requirements. The buffer must be writeable and the last two bytes must be ASCII-NUL. But the buffer may contain other 0 bytes just fine. Because we don't want these constraints in our public API, xkb_keymap_new_from_buffer() needs to create a copy of the input memory. But it then calls yy_scan_buffer() directly. Hence, we have the same number of buffer-copies as with *_from_string() but without the terminating 0 requirement. The explicit yy_scan_buffer() call is preferred over yy_scan_byte() so the buffer-copy operation is not hidden somewhere in flex. Maybe some day we no longer depend on flex and can have a zero-copy API. A user could mmap() a file and it would get parsed right from this buffer. But until then, we shouldn't expose this limitation in the API but instead provide an API that some day can work with zero-copy. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> [ran: rebased on top of my branch] Conflicts: Makefile.am src/xkbcomp/xkbcomp.c
2013-03-19Allow NULL rmlvo for xkb_keymap_new_from_namesDaniel Stone1-1/+3
Previously we allowed you to pass a names struct with five NULL members, but not just pass NULL for the struct itself. This was pretty dumb. :( Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2013-03-19Add environment overrides for default RMLVODaniel Stone1-1/+3
You can now set default values in the environment, as well as a context option to ignore the environment, e.g. for tests. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2013-03-18doc: some improvementsRan Benita1-38/+50
Signed-off-by: Ran Benita <ran234@gmail.com>
2013-03-18More spelling errorsRan Benita1-11/+11
Signed-off-by: Ran Benita <ran234@gmail.com>
2013-03-18keysym: print unicode keysyms uppercase and 0-paddedRan Benita1-1/+1
Use the same format as XKeysymToString. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-11-11keymap: wrap the layout parameter if it is out of range for the keyRan Benita1-8/+10
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>
2012-11-07Don't use trailing enum comma in public headersRan Benita1-8/+8
Pretty annoying, but C89 doesn't support that (officially), and it might cause warning with -pedantic, etc. (though you need -Wsystem-headers to see them usually). Removing them is not a big deal. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-11-06doc: clarify that keysym_to_utf8 returns size including '\0'Ran Benita1-3/+3
Signed-off-by: Ran Benita <ran234@gmail.com>
2012-11-04Add some explanations on consumed modifiersRan Benita1-2/+43
This should hopefully clarify this somewhat subtle point to the uninitiated users. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-29state, context: allow passing NULL to *_unref()Ran Benita1-0/+6
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>
2012-10-26doc: fix wrong commentRan Benita1-1/+1
Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-23doc: various fixesRan Benita1-46/+49
Just moving around / fixing syntax / grammar. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-23doc: move include_path functions to a separate groupRan Benita1-25/+38
These are 'special intrest' function, like the logging functions, so it's nice to have them in their own logical group. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-22Change update_mask arguments to read 'depressed' instead of 'base'Ran Benita1-2/+2
Just to be consistent, as we use 'depressed' everywhere else in the API. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-22Report which components of the state have changedRan Benita1-39/+45
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>
2012-10-22Split the mods, layout, leds parts of xkb_state_componentsRan Benita2-23/+65
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>
2012-10-22doc: add note about X11 vs. extended keycodesRan Benita1-0/+20
Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-16Add xkb_keysym_from_name() flags argument for case-insensitive searchDavid Herrmann1-1/+17
This adds a flags argument to xkb_keysym_from_name() so we can perform a case-insensitive search. This should really be supported as many keysyms have really weird capitalization-rules. However, as this may produce conflicts, users must be warned to only use this for fallback paths or error-recovery. This is also the reason why the internal XKB parsers still use the case-sensitive search. This also adds some test-cases so the expected results are really produced. The binary-size does _not_ change with this patch. However, case-sensitive search may be slightly slower with this patch. But this is barely measurable. [ran: use bool instead of int for icase, add a recommendation to the doc, and test a couple "thorny" cases.] Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
2012-10-13Finish first round of API documentationRan Benita1-144/+519
There are a few @todo's, but nothing serious. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-13state: make mod_index_is_consumed() return -1 on invalid inputRan Benita1-2/+2
Like all the other functions. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-12Change log env vars to XKB_LOG_LEVEL/VERBOSITYRan Benita1-4/+4
A bit more consistent and descriptive. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-11doc: use JAVADOC_AUTOBRIEFRan Benita1-42/+42
Don't have to type @brief all the time. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-11Make xkb_keymap_num_leds return the index range instead of active countRan Benita1-0/+4
Currently xkb_keymap_num_leds() returns a count of valid (settable) leds. Because the indexes might be non-consecutive, and some leds might not be settable, it is incorrect to use this function for iterating over the leds in the keymap. But this is the main use case of this function, so instead of the current behavior we adapt the function to the use case by making it return the needed range of iteration. The caller needs to handle invalid intermittent indexes, though. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-27Add xkb_state_key_get_one_symDaniel Stone1-0/+7
The trivial wrapper around xkb_state_key_get_syms that every user to date has implemented. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-24Add format argument to xkb_keymap_get_as_stringRan Benita2-4/+13
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>
2012-09-24Add return value the xkb_keysym_get_nameRan Benita1-0/+6
This is useful to see whether the function was successful and whether truncation occurred. It just changes void -> int so shouldn't break API or ABI. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-24Improve API doxygen documentationRan Benita2-138/+305
To make it look better and a bit more structured and informative. Not all of the functions are converted to doxygen format, so this is not finished. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-24API: add _context prefix to log-related functionsRan Benita1-10/+11
This is to follow the general scheme set by all of the other API functions. Since no one is using these functions yet, we don't (actually better not) add the old names to xkbcommon-compat.h. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-24Promote keymap enumeration API to publicDaniel Stone1-0/+39
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>
2012-09-20API change: Rename xkb_map_* and group -> layoutDaniel Stone2-52/+105
Move xkb_map_* functions to xkb_keymap_*, xkb_key_* functions under either xkb_keymap or xkb_state, and rename groups to layout in all user-visible API. Backwards-compatible hooks are provided, such that old source will build, but silently mangled to the new names, and old binaries will also continue to work. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-20Add xkbcommon-compat.h and compat.cDaniel Stone2-0/+32
So we can start renaming stuff while retaining backwards source and binary compatibility. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-16Organize src/ and test/ headersRan Benita1-1/+0
- 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>
2012-09-12Copyright updatesDaniel Stone1-1/+2
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>
2012-09-11xkbcommon-keysyms: Add header protectionDavid Herrmann1-1/+10
As there is currently no stable release of xkbcommon, other projects might want to include a copy of the keysyms so they can be used even though libxkbcommon may not be available on the machine. However, if xkbcommon.h is still included, conflicts will occur. Hence, to avoid nasty hacks, simply include a header protection in xkbcommon upstream. [daniels: Added protection to Makefile.am's update-keysyms, as well as XKB_KEY_NoSymbol, and a comment noting that it shouldn't be updated directly.] Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-11xkbcommon.h build fix for missing stdarg.hPekka Paalanen1-0/+1
In file included from external/collabora/libxkbcommon/src/xkb-priv.h:87, from external/collabora/libxkbcommon/src/xkbcomp/xkbcomp.h:30, from external/collabora/libxkbcommon/src/xkbcomp/xkbcomp-priv.h:30, from external/collabora/libxkbcommon/src/xkbcomp/action.h:30, from external/collabora/libxkbcommon/src/xkbcomp/action.c:27: external/collabora/libxkbcommon/xkbcommon/xkbcommon.h:279: error: expected declaration specifiers or '...' before 'va_list' Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
2012-09-11kbproto unentanglement: XkbExplicit*MaskDaniel Stone1-0/+1
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-03log: replace "priority" by "level" everywhereRan Benita1-13/+14
Now that we don't use syslog, "level" does sound more commonplace. We should change it while there is still nobody using it. Also leave some space between the integers of the xkb_log_level enum values, if we ever need to shove more in between. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-02state: fix mod_names_are_activeRan Benita1-16/+16
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>
2012-08-08Add xkb_map_mod_mask_remove_consumedDaniel Stone1-0/+9
A fairly simple helper which, given an xkb_mod_mask_t, removes all modifiers which are consumed during processing of a particular key. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-08-08Add xkb_log_level enum rather than using syslogDaniel Stone1-6/+18
Instead of relying on people including syslog.h, add our own XKB_LOG_LEVEL_* defines. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-08-08Add API to query whether a modifier is consumedRan Benita1-0/+10
Currently the user has no way of knowing which of the active modifiers have been used in the translation of a keycode to its keysyms. The use case is described in the GTK docs: say there's a menu accelerator activated by "<Alt>+". Some layouts have "+" shifted, and some have it on the first level. So in keymaps where "+" is shifted, the Shift modifier is consumed and must be ignored when the user is testing for "<Alt>+". Otherwise, we may get "<Alt><Shift>+" and the accelerator should not actually fire. For this we also use the preserve[] information in the key types, which can forces us to report modifiers as unconsumed even if they were used in the translation. Until now we didn't do anything with this information. The API tries to match its surronding. It's not very efficient but this can be fixed. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-08-07log: allow to resore default log functionRan Benita1-2/+2
Signed-off-by: Ran Benita <ran234@gmail.com>
2012-08-07Use only one set of core mod name-to-index functionsRan Benita1-1/+1
These were repeated 5 times. Note that this changes the ABI slightly: XKB_MOD_NAME_CAPS is changed from "Caps Lock" to "Lock", which is the ordinary legacy mod name for it. Since its hidden behind a #define, it's best to stay compatible with the old names (as I think was intended, given that "Mod1", etc. are the same). Signed-off-by: Ran Benita <ran234@gmail.com>
2012-07-23Add logging APIRan Benita1-0/+71
Add new public API to provide the library users with some options to control and customize the logging output from the library. It is based upon the skeleton from the libabc demo libray: https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git which is public domain and works pretty well. This requires passing in the context object in every logging call, and thus the conversion is done file by file. We also remove the global warningLevel variable in favor of a verbosity level in the context, which can be set by the user and is silent by default. One issue is the ACTION calls, which, while nice, do not play very well with line- and priority-based logging, and would require some line continuation handling or keeping state or some other compromise. So instead remove these and just inline them with their respective warning/error. So instead of: ERROR("Memory allocation failed\n") ACTION("Removing all files on hardisk\n") its something like that: log_err("Memory allocation failed; Removing all files on harddisk\n") Signed-off-by: Ran Benita <ran234@gmail.com>
2012-07-23build: drop the include/ directoryRan Benita3-0/+3651
The include/ dir is somewhat redundant and makes it just a bit harder to handle the -I directives from out side of automake; without it the default $(top_buildir) just works. Here's also some further justifications I found: http://smcv.pseudorandom.co.uk/2008/09/pc-uninstalled/ Signed-off-by: Ran Benita <ran234@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-21 13:43:12 +0000