build: use AC_CONFIG_MACRO_DIR as per libtoolize warning

libtoolize: Consider adding "AC_CONFIG_MACRO_DIR([m4])" to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding "-I m4" to ACLOCAL_AMFLAGS in Makefile.am.

Signed-off-by: Jan Engelhardt <jengelh@medozas.de>

Link with -no-undefined

Use -no-undefined to assure libtool that the libxkbcommon library has
no unresolved symbols at link time, so that libtool will build a shared
library on platforms require that all symbols are resolved when the
library is linked.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>

Don't check for xlib, we don't need it

Update xkb->ctrls->num_groups when copying the keysyms

This used to be set when we read an XKM file.

Restore compatible action structs

This unbreaks the X server code to serialize an xkb_desc, but loses the
32 bit vmod fields.  Needs some work...

Use flex for generating the scanner, add support for parsing from strings

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>

Add struct xkb_state

Don't return a static buffer in public API

Pull in XKB_COMMON_* version of modifier masks

This way we can use libxkbcommon without having to include X.h.

Dead code removal and static markup

Signed-off-by: Adam Jackson <ajax@redhat.com>

Remove libxkbfile dependency for real this time

Use const char * in struct xkb_rule_names

Pull in a few #defines from libxkbfile and lower kbproto requirement

Drop Bool type

It's a nightmare trying to avoid double definitions.

Get rid of a few unused #defines in public header

Rename XkbRMLVOSet to struct xkb_rule_names

Move private structs and defines to private headers

Rename public entry points to lowercase and underscore

Compile with -fvisibility=hidden when possible

Pull in enough structs and defines from XKBstr.h to only need XKB.h

We want to move away from sharing implementation structs and let libX11
and libxkbcommon use each their own set of structs.

Drop Xmd.h include now that we're using uint32_t

Fix warning from CARD32 -> uint32_t conversion

Constify XkbcAtomText()

Atoms aren't mutable and this lets us put tbGetBuffer() back in the box.

Make XkbcInitAtoms() call optional

Drop more malloc/free wrappers

Use the right action structs

We were casting the union members to the wrong action structs (from kbproto).

Copy over missing action structs from kbproto

Rename Xkbc*Action to struct xkb_*_action

Drop malloc wrappers

Drop CARD32 and Opaque types

Copy and duplicate XkbModsRec and XkbKTMapEntryRec

Copy these types in so we can extend the vmod size.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

fix mod size confusion

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Add really rudimentary rules caching support

Keep the parsed form of the last-used rules file around, and reuse that
if we get asked for the same ruleset.  If not, bin it and cache the
other one.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Use CARD32 instead of Atom, move geom headers in

Use CARD32 instead of Atom/KeySym/et al to avoid type size confusion
between server and non-server code; relatedly, move the geometry headers
in from kbproto, so every non-simple type (i.e. structs containing
nothing more than basic types) is now copied into xkbcommon.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Interp: More lazy keysym resolution

Resolve the keysyms when we create an InterpDef, rather than directly
in the parser.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Allow external atom databases

Allow people to plug in an external atom database (e.g. the X server's),
so we don't have to migrate our own atoms over later.  We are a bit
over-keen on atoms at the moment, so it does pollute the atom database a
bit though.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Copy in XkbCompatMapRec and XkbSymInterpretRec

These contain actions, so transition them ahead to XkbcAction and move
them into XKBcommon.h.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Use CARD32 instead of Atom, drag in XkbClientMapRec

On 64-bit architectures, XID varies in size between the server (always
32 bits), and non-server (always unsigned long) for some inexplicable
reason.  Use CARD32 instead to avoid this horrible trap.

This involves dragging in XkbClientMapRec so we don't get stuck in the
KeySym trap.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Regroup actions into current vs. deprecated, resize vmod

Use Xkbc* for all our actions that we intend to keep around, and Xkb*
for deprecated ones we can hopefully get rid of, at least internally.

While we're at it, make vmods be a uint32_t.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: Don't malloc() and free() most scanned tokens

Use a constant buffer instead.  Sigh.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Fix compilation with DEBUG

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: Use fread() instead of getc()

So, it turns out that if you're parsing a fairly large amount of data,
using getc() to get all the input rather than, say, read(), is some kind
of remarkably daft and unperformant idea.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: Lazy keysym parsing (avoid XStringToKeysym)

Instead of calling XStringToKeysym on every keysym we parse, store it as
a string until we need to store it in an actual keymap.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Atoms: Avoid allocations in XkbAtomText()

XkbAtomGetString() returns a freshly-allocated string, whereas
XkbAtomText() returns the same in a temporary buffer.  XkbAtomText used
to call XkbAtomGetString() and then free the result, which seems quite
spectacularly pointless when you think about it.  Shuffle the atom code
around so we don't have to allocate for XkbAtomText().

This changes semantics slightly wrt non-printable characters, but I
haven't been able to see any effect so far.  And it may well be ever so
slightly quicker.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

configure.ac: Enable automake silent rules by default

This allows us to spot warnings much more easily.  Also, drop the
now-deprecated AM_MAINTAINER_MODE.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Expose tbGetBuffer to the rest of libxkbcommon

This will let us implement XkbAtomGetString on top of XkbAtomText,
instead of having the latter get a duplicated string, dump it into a
temporary buffer, and subsequently free it (sigh).

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: keycodes: Silence gcc warnings

It was right to warn us: some of these were actually bogus.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: geometry: Plug numerous atom text & expr leaks

This code is absolute misery.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: Atom text and expr leak fixes part #973

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: Don't leak atom text and string exprs, again

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: expr: Use XkbcAtomText instead of GetString

This returns us a temporary string, rather than leaking the atom.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: Don't leak atom text and string exprs

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: vmod: Don't get and immediately intern atoms

XkbcInternAtom(XkbcAtomGetString(atom)) has to be the most spectacularly
broken antipattern I've yet seen.  Just compare the atoms directly.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

xkbcomp: Replace open-coded strdup

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Add testcase for XkbcCanonicaliseComponents

Should be reasonably thorough; the shell part is, however, quite
unpleasant.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Add XkbcCanonicaliseComponents

Canonicalises two sets of components (new and old), e.g.:
new: +bar
old: foo
result: foo+bar

This is required as part of the spec, so clients can reuse part of the
device's old keymap.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

XKBcommon.h: Make header self-contained

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Keysym: Add apallingly bad API documentation for keysym <-> string

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Make keysym <-> string conversion public API

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

XKB: Text: Use keysym <-> string conversion from keysym.c

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Test: Keysym: Add tests for new keysym <-> string conversions

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

Keysym: Fix conversion for Unicode and bare numbers

Ensure that Unicode string representations are accepted and turned into
numbers, as well as hexadecimal numbers in 0xabcd1234 form; unknown
keysyms are output as 0xabcd1234 in string form.

This also ensures that strings are never returned malloc()ed.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

KeySym: Actually handle NoSymbol

Add NoSymbol into the keysym table, so keysym <-> string conversion works for
that, too; also eliminate special-casing of VoidSymbol.

This will require special-casing in libX11 to preserve its API.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

test: Fix srcdir != objdir build and test failures

filecomp would fail because it couldn't find the input files, after
compilation failed due to missing includes.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>

listing: Drop unused deviceSpec argument

The server might care about this, but ListComponents is just reading xkb
files.

xkbcomp: Another fairly major rewrite of the listing mode

The listing code in xkbcomp had been setup to allocate a set of buffers
with file paths and then later parse through them to find which maps were
needed.

All the allocation (with the additional allocation for the components
list) was making it really slow, so this patch makes everything simpler
by just generating the components list as we walk the directory tree.

Rewrite listing code to generate XkbComponentListPtr

In xkbcomp, the listing code printed out the xkb files to stdout and the
caller would parse the output. Here, we can just generate a
XkbComponentListPtr and pass it back.

This should be a series of smaller commits, but there was no clean way to
do it since it's basically a complete rewrite except for the core map
matching logic.

A lot of code used for special printing modes in xkbcomp has been
shedded. Callers can massage the output as they please.

xkbcomp: Kill unused listing code and make functions static

Much of this was only called from xkbcomp and not used to generate
listings for the server.

Scale back global variables

Some of the global variables were either not used anymore or only used
in the listing code.

Add XkbNameMatchesPattern implementation from xkbfile

The xkbcomp listing code matches a glob type pattern against installed
xkb files. This adds a Xkbc implementation of the pattern matching code.

xkbcomp: Fix use of removed macros

Revert "xkbcomp: Remove listing sources"

This reverts commit c4c9e36fbf4019d802323d9053f54cbfa6d3d5e5. It turns
out that the listing code is used to support the X_kbListComponents
request (via XkbListComponents).

This will have to be refactored into some reasonable interface instead
of the current usage where the server reads xkbcomp stdout. Gross.

misc: Coding-style cleanup

Use xkbpath API for locating rules

Instead of hardcoding the XKB base directory when searching for rules in
the xkbcomp code, we can extend the xkbpath API to cover rules and reuse
it. That will make it more convenient if it's ever exposed so people can
set their XKB search paths in a reasonable way.

Program and files for testing CompileKeymapFromFile

A few simple test cases for verifying the operation of parsing a keymap
file and compiling a keyboard description from it.

Add interface to compile keyboard description from keymap files

We need to support generating a keyboard description from a keymap file
because there are just some cases where RMLVO or ktcsg is not enough.

The map choosing logic has been refactored into its own function and now
supports choosing a named or default keymap.

test: Remove extraneous includes

These programs don't actually use the internal API.

Make XkbcInitAtoms externally accessible

Applications (like the server) need to initialize the atoms system
before using the rest of the library. Maybe it should just init itself
implicitly.

Constify public API

There's no reason the arguments can't be const.

Change CompileKeymapFromRules to take XkbRMLVOSet

Let's use a nice interface now that it's available from XKBrulescommon.h.

Remove all non-public API from XKBcommon.h header

The noble intention was to expose all the new API and new generic types
in the split out kbproto headers through XKBcommon.h. It turns out that
would be a massive amount of work in the server. Someday, but first just
wedging in XkbCompileKeymap* would be good.

Most of the API is in new internal xkb*.h headers. In order to allow the
XKBcommon.h header to be used from the server, we can't pull in other
headers from kbproto since the server has its own copies. However, types
that are different (XkbDescRec, XkbAction) still have Xkbc equivalents
here, and I think they should be used in the server.

Remove KS macros available in XKBfilecommon.h now

A couple of the XkbcKS* macros become redundant with XKBfilecommon.h
split out in kbproto.

Require strdup and remove utils wrapper

This kills a couple warnings from using the uStringDup wrapper. If you
don't have strdup on your platform, you have bigger issues.

Add action datatypes as defined in the server

Some of the XkbAction types are defined differently in the server, so we
add those to XKBcommon.h and use them here like XkbcDescPtr. We'll have
to deal with the impedance mismatch on the client side later.

Coding style cleanup on key allocation functions

test: Exercise compiling from components

This could probably use a lot more real world test cases, but it does
the job for now.

xkbcomp: Don't say we're exiting when we're not

xkbcomp: Give keymap file empty name if none supplied

Ensure that the keymap file topName is not NULL since it gets blindly
dereferenced later.

xkbcomp: Ensure at least keycodes supplied in components

It seems that at least a non-empty keycodes component is required to
compile a XkbcDescPtr.

xkbcomp: Don't dereference NULL VarDefsPtr

xkbcomp: Refactor keymap file generator

test: Minor refactor to allow $EXEEXT in program names

test: Add logging and some intentionally failing cases

We want to log the output of the tests rather than letting them go to
stderr. This allows tests we expect to fail to be run.

xkbcomp: Generating components requires rules _and_ layout

This came from trial and error, but it seems that you can generate a
valid keymap with only rules and layout.

xkbcomp: Fail when converting rules to components returns an error

XkbcRF_GetComponents was returning an error but leaving the generated
components alone. This ensures that the broken XkbComponentNamesPtr is
freed and the error is passed up to the caller.

xkbcomp: Cleanup error messages

xkbcomp: Ensure user has supplied a rules name

rulescomp: Remove unneeded API

Refactor xkbpath so that it implicitly initializes

Instead of requiring the user to call XkbInitIncludePath() and
XkbAddDefaultDirectoriesToPath(), all the path entry points now implicitly
initialize the path. When initializing, the default directories are added
so it's useful.

This provides normal operation without exposing the xkbpath API. That
might happen later to allow apps to edit the XKB search path.

Remove trailing spaces in source files