Changes MakeAtom to take a const char * and NameForAtom to return them,
since many callers pass pointers to constant strings stored in read-only
ELF sections. Updates in-tree callers as necessary to clear const
mismatch warnings introduced by this change.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of always keeping two copies of the keymap, only generate the
core keymap from the XKB keymap when we really need to, and use the XKB
keymap as the canonical keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Keyboard map notifications are always generated from within XKB code,
which also takes care of copying the keysyms, etc. If you need to
mangle the keymap yourself, generate a new core keymap/modmap, and pass
it to XkbApplyMappingChange.
SendMappingNotify is renamed to SendPointerMappingNotify (and ditto its
Device variants), which still only _sends_ the notifications, as opposed
to also doing the copying a la XkbApplyMappingChange.
Also have the modmap change code traverse the device hierachy, rather
than just going off the core keyboard.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Turn two unsigned chars into one unsigned int for both vmods and the
vmod mask. As a bonus, remove broken unused accessor macro for setting
the vmods.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Turn four unsigned chars into one unsigned long.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Turn vmods from two unsigned chars into one int.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than requiring a one-to-one correspondence between XKM and struct
formats in action data, explicitly fill the action data, so we can break
API.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't use them, as they're not up to the task. We'll get a better
solution someday, promise.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When we find something weird in the rules, don't stash it as an extra
freeform component, just state that the rules file is likely broken and
move on with our lives.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We support every XKB operation on Xi devices, so always report that we
support everything, and that nothing is ever unsupported.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have modmap (in the exact same format!) in XKB, so just use
that all the time, instead of duplicating the information.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since modifierKeyMap is generated from modifierMap, just remove it, and
only generate it when we need to send the modifier map to the client.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Modifiers get cleared by the XKB code when we drop down into core input
processing, so just delete the dead code path to simplify things a bit.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have state fully stored within XKB, so instead of duplicating it,
just generate the values to send to clients when required.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
XkbInitKeyboardDeviceStruct is now the only valid keyboard
initialisation: all the details are hidden behind here. This now makes
it impossible to supply a core keymap at startup.
If dev->key is valid, dev->key->xkbInfo->desc is also valid.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No more #ifdef XKB, because you can't disable the build, and no more
noXkbExtension either.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For some reason, XKB allows clients to set a global (!) flag that simply
turns lock keys into state no-ops. Ignore this flag.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Humour the user if they run XkbCopyKeymap(foo, foo).
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Core events aren't run through these functions, so don't bother testing
for them.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The device-walking code is still depressing, though.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of hardcoding base/pc105/us, allow users to change the defaults at
./configure time. Change the default model to be evdev on Linux.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
After copying the master event, flip the detail field to the mapped button of
the SD, not the physical button. This way if the SD has a mapping 1:3 and the
MD has a mapping of 3:4, a press on button 1 on the SD results in a core event
on button 4.
X.Org Bug 19282 <http://bugs.freedesktop.org/show_bug.cgi?id=19282>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When updating the XKB keymap, make sure the keyboard feedback is also
copied, to preserve autorepeat settings etc.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Single-group keys may get replicated amongst all groups. Check explicitly for
this case and squash it down to one group.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
A single-group key on a multi-group keyboard has to be replicated across all
three groups (see Section 12.4 of the XKB protocol spec). Ensure that there's
enough symbols available to actually do that.
e.g. a key ABCD on a 3 group keyboard needs to be replicated as ABABCDCDABCD,
hence requiring space for 12 symbols, even if maxSymsPerKey is less than that.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
A grep on xorg/* revealed there's no consumer of this define.
Quote Alan Coopersmith:
"The consumer was in past versions of the headers now located
in proto/x11proto - for instance, in X11R6.0's xc/include/Xproto.h,
all the event definitions were only available if NEED_EVENTS were
defined, and all the reply definitions required NEED_REPLIES.
Looks like Xproto.h dropped them by X11R6.3, which didn't have
the #ifdef's anymore, so these are truly ancient now."
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Alloc an EventList once and then re-use instead of allocing a new event each
time we need a master event.
There's a trick included: because all the event processing handlers only take
an xEvent, init a size 1 EventList and squash the events into this one.
Events that have count > 1 must be squished into an xEvent array anyway before
passing into the event handlers, so we don't lose anything here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
We'd like to do soft repeat in the server for all keys. Remove obscure check, that'd
prevent the server from autorepeating when delay is set to exactly 660ms and rate is
set to exactly 25 (interval=40).
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Save in a few special cases, _X_EXPORT should not be used in C source
files. Instead, it should be used in headers, and the proper C source
include that header. Some special cases are symbols that need to be
shared between modules, but not expected to be used by external drivers,
and symbols that are accessible via LoaderSymbol/dlopen.
This patch also adds conditionally some new sdk header files, depending
on extensions enabled. These files were added to match pattern for
other extensions/modules, that is, have the headers "deciding" symbol
visibility in the sdk. These headers are:
o Xext/panoramiXsrv.h, Xext/panoramiX.h
o fbpict.h (unconditionally)
o vidmodeproc.h
o mioverlay.h (unconditionally, used only by xaa)
o xfixes.h (unconditionally, symbols required by dri2)
LoaderSymbol and similar functions now don't have different prototypes,
in loaderProcs.h and xf86Module.h, so that both headers can be included,
without the need of defining IN_LOADER.
xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
not exported (and with a comment about it).
If no rules file is given, simply re-use the previous one. If no RF is given
the first time this function is called, use the built-in default.
This includes fixing the built-in default to something that actually exists.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
The device's button down state array was changed to use DOWN_LENGTH and thus
bitflags for each button in cfcb3da7.
Update the DBSN events to copy this bit-wise state.
Update xkb and Xi to check for the bit flag instead of the array value.
Reported by ajax.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
The warnings corrected were only the ones that should correct
real problems. The most common one is 64 bit integers as
"printf %l" arguments.
Note that there is a patch related to this at:
http://bugs.freedesktop.org/show_bug.cgi?id=18204
