Make sure all of the private keys used by the test code are
initialized before being used.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Robert Hooker <sarvatt@ubuntu.com>
This patch has been generated by the following Coccinelle semantic patch:
@@
expression E;
@@
-if(E) { free(E); }
+free(E);
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Marcin Baczyński <marbacz@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Marcin Baczyński <marbacz@gmail.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
This patch only changes the API, not the implementation of the
devPrivates infrastructure. This will permit a new devPrivates
implementation to be layed into the server without requiring
simultaneous changes in every devPrivates user.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Classic strlen/strcpy mistake of
foo = malloc(strlen(bar));
strcpy(foo, bar);
Testcase: valgrind Xephyr :1
==8591== Invalid write of size 1
==8591== at 0x4A0638F: strcpy (mc_replace_strmem.c:311)
==8591== by 0x605593: _XkbCopyGeom (xkbUtils.c:1994)
==8591== by 0x605973: XkbCopyKeymap (xkbUtils.c:2118)
==8591== by 0x6122B3: InitKeyboardDeviceStruct (xkbInit.c:560)
==8591== by 0x4472E2: CoreKeyboardProc (devices.c:577)
==8591== by 0x447162: ActivateDevice (devices.c:530)
==8591== by 0x4475D6: InitCoreDevices (devices.c:672)
==8591== by 0x4449EE: main (main.c:254)
==8591== Address 0x6f96505 is 0 bytes after a block of size 53 alloc'd
==8591== at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==8591== by 0x6054B7: _XkbCopyGeom (xkbUtils.c:1980)
==8591== by 0x605973: XkbCopyKeymap (xkbUtils.c:2118)
==8591== by 0x6122B3: InitKeyboardDeviceStruct (xkbInit.c:560)
==8591== by 0x4472E2: CoreKeyboardProc (devices.c:577)
==8591== by 0x447162: ActivateDevice (devices.c:530)
==8591== by 0x4475D6: InitCoreDevices (devices.c:672)
==8591== by 0x4449EE: main (main.c:254)
Reported-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by-and-apologised-for: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Many references to the WindowTable array already had the corresponding
screen pointer handy, which meant they usually looked like
"WindowTable[pScreen->myNum]". Adding a field to ScreenRec instead of
keeping this information in a parallel array simplifies those
expressions, and eliminates a MAXSCREENS-sized array.
Since dix uses this data, a screen private entry isn't appropriate.
xf86-video-dummy currently uses WindowTable, so it needs to be updated
to reflect this change.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
TryClientEvents already did this; this commit just moves the assignment
one level down so that no event source has to worry about sequence
numbers.
...No event source, that is, except XKB, which inexplicably calls
WriteToClient directly for several events.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Just let Dispatch() check for a noClientException, rather than making
every single dispatch procedure take care of it.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The only remaining X-functions used in server are XNF*, the rest is converted to
plain alloc/calloc/realloc/free/strdup.
X* functions are still exported from server and x* macros are still defined in
header file, so both ABI and API are not affected by this change.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
_XkbCopyGeom did not copy all of the data from the source geometry. This
resulted in failures when trying to obtain the keymap from a server
where the default geometry has not been replaced by a custom
configuration.
Signed-off-by: Dirk Wallenstein <halsmit@t-online.de>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
move srv assignment to before it's being used. Also, check for xkb being nil.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The name XkbDDXFakeDeviceButton and XkbDDXFakeDeviceMotion is somewhat
misleading, there's no DDX involved in the game at all anymore.
This removes XkbFakeDeviceMotion and XkbFakeDeviceButton from the API where
it arguably shouldn't have been in the first place.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Section 4.6.1 of the XKB spec says that "the initial event always moves the
cursor the distance specified in the action [...]", so skip the
POINTER_ACCELERATE flag for GPE, it would cause double-acceleration.
Potential regression - GPE expects the coordinates to be either relative or
both. XKB in theory allows for x to be relative and y to be absolute (or
vice versa). Let's pretend that scenario has no users.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Simon Thum <simon.thum@gmx.de>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
In theory, an event coming in during GPE could reset our lastSlave, leading
to rather interesting events lateron.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Simon Thum <simon.thum@gmx.de>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Posting an event through a master device may cause pointer jumps once
lastSlave == master, caused by double scaling. To avoid this, post the fake
event generated by XKB through the XTEST device instead.
Fedora bug #560356 <https://bugzilla.redhat.com/560356>
Tested-by: Andrew McNabb
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
XkbEnableDisableControls set extra garbage bits on the xkbControlsNotify
changedControls mask because it was uninitialized on the stack.
Found by clang
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Video mode switching via keypad keys did not work
Signed-off-by: Horst Wente <horst.wente@acm.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
XKB really XKBdoes not XKBneed its own XKBdefines for XKBeverything.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Signed-off-by: Keith Packard <keithp@keithp.com>
Since it's typedef'd to XkbConvertCase anyway and the headers are now split
from the client headers, simply get rid of it altogether.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Bonus point - it's easier to understand what's actually being done with the
memory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Signed-off-by: Keith Packard <keithp@keithp.com>
Please no extension-specific macros for memory allocation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Convert all calls of CreateNewResourceType to pass name argument
Breaks DIX ABI.
ABI versions bumped:
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Calls RegisterResourceName to record the type name for
use by X-Resource, XACE/SELinux/XTsol, and DTrace.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Make sure to check return value before setting bitmask flags.
For most calls, just fails to init the extension. Since Xinput
already calls FatalError() on initialization failure, so does
failure to allocate Xinput's resource type.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
As the comment for the function states, led_return is undefined if map is
NULL. We might as well skip writing to it then.
Found by clang.
Reported-by: Tomas Carnecky <tom@dbservice.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Through some code paths it is possible that NULL is being passed in the
'ed' parameter to XkbFlushLedEvents(). Make sure we don't pass it along
to bzero().
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This avoids NULL from being passed to memcpy() later in the code. While
that wasn't an issue before - that value being NULL implied 'size == 0'
so memcpy() wouldn't try to dereference it - it made the code harder
to read and also confused clang.
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This request is used to get the current keyboard group and is called from
GTK. It does not return an actual keymap (aside from modifiers) so it
should be safe to relax the permission on it. However it does return
button state information which should be controlled through a separate
pointer Read check.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Checking just for root is insufficient since that does not guarantee write/read
permissions in XKM_OUTPUT_DIR (for example with sandbox).
Check if we can write a file, as well as read it later. Otherwise, invoke the
fallback to /tmp
Signed-off-by: Nirbheek Chauhan <nirbheek@gentoo.org>
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
include/protocol-versions.h specifies each extension version as supported by
the server and sent back on the wire to the client.
This fixes up several issues with the server potentially reporting a higher
version of the protocol if recompiled against a newer version of the
protocol.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Julien Cristau <jcristau@debian.org>
The event sequence for continuously pressed keys with the keyboard driver is
PRESS - PRESS - PRESS - ... - RELEASE.
The first press sets the repeatKey to the keycode and the matching timer.
The second press (on the same keycode) can be silently dropped instead of
overwriting the timer again.
X.Org Bug 23889 <http://bugs.freedesktop.org/show_bug.cgi?id=23889>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
If the layout is changed on a master's lastSlave, the master needs to change
layout immediately. Otherwise, the master stays on the same layout until the
lastSlave changes - which may not happen if only a single keyboard is
available.
X.Org Bug 21859 <http://bugs.freedesktop.org/show_bug.cgi?id=21859>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For core and XI1 events, store the key_repeat flag in the sequence number
until TryClientEvents. The sequenceNumber is unset until TryClientEvents.
[Also thrown in, some random indentation changes. Thanks]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ifdef'd out since the switch to internal events. PtrBtn actions now work
again. Instead of generating the event directly, GPE generates the event and
it is then posted through the usual event processing routines
(mieqProcessDeviceEvent).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
InternalEvents shouldn't be used anywhere outside the X server itself. Split
up into events.h for opaque typedefs for the events needed by various
headers and eventstr.h for the actual struct definitions.
eventstr.h must only be included by code that requires internal events and
is not part of the SDK.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reverts the following four patches:
feb757f384 "XKB: Sanitise vmods for redirected keys"
b5f49382fe "XKB: Sanitise ctrls action"
1bd7fd195d "XKB: Sanitise pointer actions"
61c508fa78 "XKB: Sanitise vmods in actions"
Strictly speaking, the structs used in the server are not part of the client
ABI. Practically, they are as we copy from the wire straight into the
structs. Changing the struct sizes breaks various wire/server conversions.
Even when the structs have the same size, some internal magic causes
conversions to fail. Visible by diffing the output files of:
setxkbmap -layout de; xkbcomp -xkb :0 busted.xkb
setxkbmap -layout de -print | xkbcomp -xkb - correct.xkb
Interestingly enough, busted.xkb is the working one although the output is
incorrect. Revert the four offending patches until the exact cause of this
breakage can be determined.
This patch restores functionality to Level3 modifiers.
X.Org Bug 19602 <http://bugs.freedesktop.org/show_bug.cgi?id=19602>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's devices (e.g. some barcode readers) that have axes but no buttons.
When such a device sends a motion event, the valuator and button class is
copied into the master pointer (i.e. removing the button class).
So we need a couple of extra sanity checks for the button class to exist.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
isMaster is not enough as long as we differ between master pointers and
keyboard. With flexible device classes, the usual checks for whether a
master device is a pointer (currently check for ->button, ->valuators or
->key) do not work as an SD may post an event through a master and mess this
check up.
Example, a device with valuators but no buttons would remove the button
class from the VCP and thus result in the
IsPointerDevice(inputInfo.pointer) == FALSE.
This will become worse in the future when new device classes are introduced
that aren't provided in the current system (e.g. a switch class).
This patch replaces isMaster with "type", one of SLAVE, MASTER_POINTER and
MASTER_KEYBOARD. All checks for dev->isMaster are replaced with an
IsMaster(dev).
In ProcXkbGetKbdByName, mrep.firstVModMapKey, .nVModMapKeys and
.totalVModMapKeys were not initialized, contained random values and caused
accesses to unallocated and later modified memory, causing
XkbSizeVirtualModMap and XkbWriteVirtualModMap to see different number of
nonzero values, resulting in writes past the end of an array in XkbSendMap.
This patch initializes those values sensibly and reverts commits 5c0a2088 and
6dd4fc46, which have been plain non-sense.
Signed-off-by: Tomas Janousek <tomi@nomi.cz>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This type is only used in XI to give a hint of what type this device may be.
Call it xinput_type for clarity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In ProcXkbGetKbdByName, mrep.firstVModMapKey, .nVModMapKeys and
.totalVModMapKeys were not initialized, contained random values and caused
accesses to unallocated and later modified memory, causing
XkbSizeVirtualModMap and XkbWriteVirtualModMap to see different number of
nonzero values, resulting in writes past the end of an array in XkbSendMap.
This patch initializes those values sensibly and reverts commits 5c0a2088 and
6dd4fc46, which have been plain non-sense.
Signed-off-by: Tomas Janousek <tomi@nomi.cz>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reproducible:
Configure a server that uses the keyboard driver with an invalid ruleset,
e.g. (Option "XkbRules" "foobar"). Ensure that Option "AllowEmptyInput" is
"off" in the ServerFlags or ServerLayout section. Start the server.
After failing to init the keymap, the server will try to clean up after the
device, double-freeing some xkb structs that have not been reset properly.
X.Org Bug 21278 <http://bugs.freedesktop.org/show_bug.cgi?id=21278>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reproducible:
Configure a server that uses the keyboard driver with an invalid ruleset,
e.g. (Option "XkbRules" "foobar"). Ensure that Option "AllowEmptyInput" is
"off" in the ServerFlags or ServerLayout section. Start the server.
After failing to init the keymap, the server will try to clean up after the
device, double-freeing some xkb structs that have not been reset properly.
X.Org Bug 21278 <http://bugs.freedesktop.org/show_bug.cgi?id=21278>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit shouldn't have been pushed, we're still sorting out the API we
want to use.
This reverts commit 876910a951.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I really don't know what the purpose of this variable is or was, aside from
potentially clobbering up our key state since there's a path where it may be
used uninitialised.
Also, this means that xkbi->prev_state is now accessible from the DIX with
meaningful data.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When ProcXkbSetNamedIndicator is called on a core device, and we
walk the slaves to set the LED's on each of them, ignore any slaves
that do not have either a KbdFeedbackCtrl or LedCtrl structure.
(This is much more critical in xserver-1.5-branch, where we walk
*all* devices, not just the slaves of the specified master, and
thus return failure when setting an LED on the Core Keyboard and
hit a xf86-input-mouse device with no LED's to set.)
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
We only have one root window and writing the rules used to the same property
for each device is quite pointless if you don't have the same RMLVO on all
devices. So let's be sensible and write the same property to the device too,
so at least we know which device got loaded with which RMLVO.
XkbGetRulesDftls may get a copy of what will later be freed when passed into
XkbSetRulesDftls.
On the second run of XkbGet/SetRulesDflts:
XkbGetRulesDflts(rmlvo)
rmlvo->rules = current-rules
XkbSetRulesDflts(rmlvo)
free(current-rules)
current-rules = strdup(rmlvo->rules)
Leaving us with garbage in current-rules.
This patch requires callers of XkbGetRulesDflts to free the associated memory.
See also
http://lists.freedesktop.org/archives/xorg-devel/2009-February/000305.html
Reported-by: Benjamin Close <Benjamin.Close@clearchain.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Close <Benjamin.Close@clearchain.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Virtually all callers use
XkbGetRulesDefault(&rmlvo);
InitKeyboardDeviceStruct(..., rmlvo);
Let's save them the trouble and accept NULL as a hint to take the
default RMLVO.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Close <Benjamin.Close@clearchain.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Don't pass xEvent* and count through to processing, pass a single
InternalEvent.
Custom handlers are disabled for the time being. And for extra fun,
XKB's pointer motion emulation is disabled. But stick an error in there so
that we get reminded should we forget about it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Note that this breaks DGA. Life is tough.
EnqueueEvent is a somewhat half-baked solution, we immediately drop back into
XI and store them. But it should in theory work.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't let the dcce be random data.
Before dropping down into the DIX, convert back into XI events. This is a
temporary solution only, until the DIX is capable of handling InternalEvents
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than compiling a new keymap every time InitKeyboardDeviceStruct
is called, cache the previous keymap and reuse it if the rules have not
changed.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
base_color and label_color need to reference the color in the destination, not
in the source.
X.Org Bug 20081 <http://bugs.freedesktop.org/show_bug.cgi?id=20081>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
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
This is the biggest "visibility" patch. Instead of doing a "export"
symbol on demand, export everything in the sdk, so that if some module
fails due to an unresolved symbol, it is because it is using a symbol
not in the sdk.
Most exported symbols shouldn't really be made visible, neither
advertised in the sdk, as they are only used by a single shared object.
Symbols in the sdk (or referenced in sdk macros), but not defined
anywhere include:
XkbBuildCoreState()
XkbInitialMap
XkbXIUnsupported
XkbCheckActionVMods()
XkbSendCompatNotify()
XkbDDXFakePointerButton()
XkbDDXApplyConfig()
_XkbStrCaseCmp()
_XkbErrMessages[]
_XkbErrCode
_XkbErrLocation
_XkbErrData
XkbAccessXDetailText()
XkbNKNDetailMaskText()
XkbLookupGroupAndLevel()
XkbInitAtoms()
XkbGetOrderedDrawables()
XkbFreeOrderedDrawables()
XkbConvertXkbComponents()
XkbWriteXKBSemantics()
XkbWriteXKBLayout()
XkbWriteXKBKeymap()
XkbWriteXKBFile()
XkbWriteCFile()
XkbWriteXKMFile()
XkbWriteToServer()
XkbMergeFile()
XkmFindTOCEntry()
XkmReadFileSection()
XkmReadFileSectionName()
InitExtInput()
xf86CheckButton()
xf86SwitchCoreDevice()
RamDacSetGamma()
RamDacRestoreDACValues()
xf86Bpp
xf86ConfigPix24
xf86MouseCflags[]
xf86SupportedMouseTypes[]
xf86NumMouseTypes
xf86ChangeBusIndex()
xf86EntityEnter()
xf86EntityLeave()
xf86WrapperInit()
xf86RingBell()
xf86findOptionBoolean()
xf86debugListOptions()
LoadSubModuleLocal()
LoaderSymbolLocal()
getInt10Rec()
xf86CurrentScreen
xf86ReallocatePciResources()
xf86NewSerialNumber()
xf86RandRSetInitialMode()
fbCompositeSolidMask_nx1xn
fbCompositeSolidMask_nx8888x0565C
fbCompositeSolidMask_nx8888x8888C
fbCompositeSolidMask_nx8x0565
fbCompositeSolidMask_nx8x0888
fbCompositeSolidMask_nx8x8888
fbCompositeSrc_0565x0565
fbCompositeSrc_8888x0565
fbCompositeSrc_8888x0888
fbCompositeSrc_8888x8888
fbCompositeSrcAdd_1000x1000
fbCompositeSrcAdd_8000x8000
fbCompositeSrcAdd_8888x8888
fbGeneration
fbIn
fbOver
fbOver24
fbOverlayGeneration
fbRasterizeEdges
fbRestoreAreas
fbSaveAreas
composeFunctions
VBEBuildVbeModeList()
VBECalcVbeModeIndex()
TIramdac3030CalculateMNPForClock()
shadowBufPtr
shadowFindBuf()
miRRGetScreenInfo()
RRSetScreenConfig()
RRModePruneUnused()
PixmanImageFromPicture()
extern int miPointerGetMotionEvents()
miClipPicture()
miRasterizeTriangle()
fbPush1toN()
fbInitializeBackingStore()
ddxBeforeReset()
SetupSprite()
InitSprite()
DGADeliverEvent()
SPECIAL CASES
o defined as _X_INTERNAL
xf86NewInputDevice()
o defined as static
fbGCPrivateKey
fbOverlayScreenPrivateKey
fbScreenPrivateKey
fbWinPrivateKey
o defined in libXfont.so, but declared in xorg/dixfont.h
GetGlyphs()
QueryGlyphExtents()
QueryTextExtents()
ParseGlyphCachingMode()
InitGlyphCaching()
SetGlyphCachingMode()
Previously each server starting ran xkbcomp with the output set to
<keymapname>.xkm, read it, then deleted it - which led to races if
two servers were starting at the same time with the same keymap.
Sun bug #6773816 Xorg uses the same xkm output file for compiled keymap file
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6773816>
If the event is an XI event, we need to work on the correct device, not on
the VCK.
Adds XIGetDevice(event) function to extract the device from an event.
