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.
When MouseKeys are activated, keyboard devices may generate fake mouse button
events through XKB. Let's get then running through the appropriate paths, i.e.
as XI events on the correct device.
To make matters more fun, ProcessOtherEvents drops events if the DIX device
state cannot be updated accordingly, i.e. all button events from keyboard
devices.
Hence we need to get the paired MD for the device in XkbDDXFakeDeviceButton,
and post the event through the paired MD (usually the VCP).
Removes now-unused ddxFakeBtn.c.
Note: this patch only half-arsedly fixed button events, motion events are a
more complicated matter.
A couple of coding style cleanups, a warning fix via removing a
now-unused label, and also put an else so we don't spuriously trip a
condition that should admittedly never occur anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
newTypes is a local variable which always has an address. newTypesIn,
on the other hand, might be sus.
See also 5544c51447.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Was doing only dry-runs, which kinda explains why changing the compat map
didn't really have any effect.
Fallout from e8c2a3d7c9.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
If we update key types from core, and groups 2 - n have a canonical type but
the same symbols as the explicit type of group 1, assume that it was a core
sym duplication according to Section 12.4 of the XKB Protocol Spec.
Ignore the canonical types and pretend there's only one group for the key -
with the explicit key type.
The protocol spec does not cover this case, so we have to guess here.
According to Section 12.4 of the XKB Protocol Spec, if a key only has a single
group but the keyboard has multiple groups defined, the core description of
the key is a duplication of the single group across all symbols. i.e.
G1L1 G1L2 G1L1 G1L2 G1L3 G1L4 G1L3 G1L4
The previous code generated G1L1 G1L2 G1L3 G1L4 G1L3 G1L4, leading to
"invented" groups when the process is reversed.
Note that this creates wrong key types on reconstruction from core to xkb,
i.e. any single-group key with a key type that is not one of the canonical
four (Sec 12.2.3), will get the assigned type on group 1, and a canonical type
for the other gruops.
X.Org Bug 14373 <http://bugs.freedesktop.org/show_bug.cgi?id=14373>
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
If called with XkbUseCoreKbd, run through all attached SDs and replicate the
call. This way, we keep the SDs in sync with the MD as long as core clients
control the MDs.
device->button->down used to be a 32-byte bitmask with one bit for each
button. This has changed into a 256-byte array, with one byte assigned for
each button. Some of the callers were still using this array as a bitmask
however, this is fixed with this patch.
Thanks to Keith Packard for pointing this out. See also:
http://lists.freedesktop.org/archives/xorg/2008-June/036202.html
We only have one set of default rules options in xkb. When the second keyboard
is brought up with Xkb options specified, these new options overwrite the old.
In future server generations, the rules used for the VCK are a mixture of the
default ones and ones previously specified for other keyboards. Simply
resetting the xkb default rules to NULL avoids this issue.
Reproducable by setting XkbLayout "de" and XkbVariant "nodeadkeys". In the
second server generation, the VCK has "us(nodeadkeys)". This again produces a
SIGABRT when the first key is hit.
I could not figure out why the SIGABRT happens. This patch is avoiding the
issue rather than fixing it.
Conflicts:
Xext/xprint.c (removed in master)
config/hal.c
dix/main.c
hw/kdrive/ati/ati_cursor.c (removed in master)
hw/kdrive/i810/i810_cursor.c (removed in master)
hw/xprint/ddxInit.c (removed in master)
xkb/ddxLoad.c
When something went wrong building a keymap, try to explain to the user
what it actually was, instead of the dreaded 'Failed to load XKB keymap'
catch-all.
- map can be NULL in some cases, so don't try to dereference it.
- don't default to inputInfo.keyboard
This is firefighting, I presume something in the class copy may have gone
wrong to get a NULL map in the first instance?
XkbFinishDeviceInit is called once when the device is initialised, but also
when a class copy causes the key class of a device to change. In this case, overwriting the CtrlProc of the KeybdFeedbackClass with XkbDDXKeybdCtrlProc sets up a nice recursive loop of XkbDDXKeybdCtrlProc calling itself until the cows come home.
If input processing is frozen, only wrap realInputProc: don't smash
processInputProc as well. When input processing is thawed, pIP will be
rewrapped correctly.
This supersedes the previous workaround in 50e80c9.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
An astute observer will note that the entirety of XkbCopyKeymap is indented
with spaces, and no tabs whatsoever, and not commit changes which break the
otherwise consistent indentation.
A non-astute observer will note the breakage when the commit mail comes
through with clearly broken indentation.
A polite, non-astute, observer will then fix it.
C'est la vie.
Due to an unwitting sense inversion when eliminating XkbFileInfo, we were
setting the complete wrong keymap on startup (non-XKB map if we had an XKB
map available, or the XKB map if we didn't have any available). Invert the
sense properly, and add two small bits that also went missing in that commit.
Sorry about the megacommit, but this touches on a lot of stuff.
Get rid of XkbFileInfo, which was pretty seriously redundant, and move the
only useful thing it had (defined) into XkbDescRec. defined will be removed
pretty soon anyway. Is the compat map pointer non-NULL? Then you have a
compat map, congratulations! Anyhow, I digress.
All functions that took an XkbFileInfoPtr now take an XkbDescPtr, _except_
XkmReadFile, which returns an XkbDescPtr *, because people want to deal in
XkbDescPtrs, not XkbDescRecs.
We were forgetting to set the sizes for sections and rows and a couple of
other misc bits in XkbCopyKeymap's geometry. Sort that out, and add a
couple of clarifying comments along the way.
We need to start breaking the XKB API to enforce sanity, so drag whichever
headers we need to do so into the server tree, as the client API is set in
stone, being part of Xlib.
It actually does help if a pointer is NULL rather than pointing to nirvana
when you're trying to free it lateron. Who would have thought?
(cherry picked from commit 7a97ca667405a42d008265c3a870210cc1da97dd)
In some weird cases we call this function when there is no SrvLedInfo on the
device. And it turns out null-pointer dereferences are bad.
X.Org Bug 13961 <http://bugs.freedesktop.org/show_bug.cgi?id=13961>
Don't run VT switches, terminations, or anything, on the core keyboard: only
run actions which affect the keyboard state. If we get an action such as VT
switch, just swallow the event.
If a slave device is attached to a master device, then we need to send a
mapping notify to the client.
Mapping notify needs to be sent if
- different slave device but on same master
- different master
This gives you funny behaviour with the ClientPointer. When a
MappingNotify is sent to the client, the client usually responds with a
GetKeyboardMapping. This will retrieve the ClientPointer's keyboard mapping,
regardless of which keyboard sent the last mapping notify request. So
depending on the CP setting, your keyboard may change layout in each app...
Haven't quite figured out yet how to make these repeats work. Because we share
the class between devices, the key state is already set when we process the
master device's event, causing a repeat on each event.
Cope with Xi and pointer events in the (now increasingly misnamed)
XkbProcessKeyboardEvent. If it's the wrong type, call through the wrapping
chain to get out; else, process it.
Don't get XkbUpdateIndicators to update the indicators on all our devices: we
already deal with that ourselves.
Add exevents.h include to get more (proto)types.
Instead of hardcoding CoreProcessPointerEvent, actually try to unwrap properly
and then call the unwrapped processInputProc. Seems to be a better idea,
especially since it makes stuff actually work...
(cherry picked from commit 8f9bf927e1)
XI events can now take the same processing paths as core events, and should do
the correct state changes etc.
There's some cases where XKB will use KeyPress as type for an event to be
delivered to the client. Stuck warnings in, not sure what the correct solution
is yet.
(cherry picked from commit 6334d4e7be with some
additional compile fixes and non-MPX adaptations)
using a hardcoded ProcessKeyboardEvent. Otherwise we lose the ability to
process DeviceKeyEvents after the first key press.
This should be the correct fix now.
(cherry picked from commit 4d5df14f2c)
Using a global array for action filters is bad. If two keyboard hit a modifier
at the same time, releaseing the first one will deactivate the filter and
thus the second keyboard can never release the modifier again.
(cherry picked from commit bfe6b4d2d9)
Removes "LookupKeyboardDevice" and "LookupPointerDevice" in favor of
inputInfo.keyboard and inputInfo.pointer, respectively; all use cases
are non-XI compliant anyway.
Instead of hardcoding CoreProcessPointerEvent, actually try to unwrap properly
and then call the unwrapped processInputProc. Seems to be a better idea,
especially since it makes stuff actually work...
Mikhail Gusarov
Dirk Wallenstein
Tiago Vignatti
Peter Hutterer
Jeremy Huddleston
Horst Wente
Alan Coopersmith
Tomas Carnecky
Eamon Walsh
Nirbheek Chauhan
Daniel Stone
Tomas Janousek
Colin Harrison
Maarten Maathuis
Jason Vas Dias
Dan Nicholson
Peter Åstrand
Adam Jackson
Pierre Willenbrock
Julien Cristau
Peter Hutterer
Sascha Hlusiak
Paulo Cesar Pereira de Andrade
James Cloos
Kim Woelders
Matthieu Herrb
Mathieu Bérard
Peter Hutterer
Egbert Eich
Peter Hutterer
Thomas Jaeger
Keith Packard
David Nolden