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>