| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
(cherry picked from commit d954f9c80348de294602d931d387e5cd1ef4b9a5)
|
|
Previously, we'd just keep num_sections at 0, which would break the
geometry and lead us to leak sections. Don't do that.
(cherry picked from commit 0137b0394a248f694448a7d97c9a1a3efcf24e81)
|
|
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.
(cherry picked from commit 320abd7d1d906807448fa01ad3377daf707f46cc)
|
|
Make sure we send the correct event for the type of device when we're
sending key repeat events, which stops repeats being sent to incorrect
windows.
|
|
(cherry picked from commit 55888552769ce6361174285b09dfb78ee22c170d)
|
|
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.
(cherry picked from commit e717cf08e99746761d74289c426bbd84176f4435)
|
|
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.
(cherry picked from commit 9db8846fa53d91193bbfe541b244e2326440011d)
|
|
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 8f9bf927e1beecf9b9ec8877131ec12c765e4d84)
(cherry picked from commit ee3aa948eb8ed181d037294ed87df6ceec81684e)
|
|
This is hopefully better than hardcodey calling CoreProcessPointerEvent.
(cherry picked from commit 32d0440c7f6e604807cb14dd32349df6f22c903b)
(cherry picked from commit d3588a0aee33fbd233082f881c0d37152c6d4d8b)
|
|
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 6334d4e7be18de5f237c12a6dc20f75aa23477d0 with some
additional compile fixes and non-MPX adaptations)
(cherry picked from commit 99e826e867c1c5520153c539ba07a884aec88d0c)
|
|
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 4d5df14f2c4a3108a8c8adfcf4766c0d1a9daad2)
(cherry picked from commit 91077bfc50d54be37c217e377c55b6bf886a2fab)
|
|
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 bfe6b4d2d9952a80f8dbc63eec974ef894e5c226)
(cherry picked from commit 8b9481a113b56078191e2298bf590905978f6289)
|
|
XkbCopyKeymap reallocates the destination keymap when it is not large enough
to hold the source data. When reallocating the map->types data, it needs to
zero out the new entries. The computation for where to start bzero'ing was
accounting for the size of the data type twice, once implicitly in the
pointer arithmetic, and once explicitly with '* sizeof (XkbKeyTypeRec)'.
This would often lead to random memory corruption when the destination
keymap had existing map->types data.
|
|
|
|
This has never worked in any modular server release, and as far as I know
was never tested in 6.7 through 6.9.
|
|
Apparently it needed to be nSyms*15/10, not *12/10; make it match the
other allocation code.
|
|
Make sure size_types will _always_ be 0 if we don't have any types.
|
|
The former <X11/extensions/XKBsrv.h> has been pulled into the server now as
include/xkbsrv.h, and the world updated to look for it in the new place,
since it made no sense to define server API in an extension header. Any
further work along this line will need to do similar things with XKBgeom.h
and friends.
|
|
When we reallocated modmap, we accidentally clobbered syms with the
result, leaving syms definitely too small, and modmap also potentially too
small (as well as not actually allocated anymore).
|
|
Make sure we're not copying sym_interpret across from an empty source.
|
|
If we don't have map or preserve in the source map, make sure the
destination is initialised to NULL, and freed if it's a valid type.
|
|
|
|
Don't iterate invalid destination types (>= num_types) when coping key
types.
Don't free key_aliases if it's NULL (theoretical, but sure).
Make sure dst's label_font gets allocated if it's NULL.
(Thanks, Chris Lee.)
|
|
Fix uninitialised warning with memset(); we never actually use it
uninitialised, but gcc doesn't know that.
|
|
We now allow maps to be set (etc) on different keyboards, so stop putting
XkbXI_KeyboardsMask in unsupported.
|
|
Take various extra precautions with copying levels across (thanks Chris
Lee for a gdb session), including allocating when we don't already have a
coherent map.
Only free type components if they're present.
Allocate geometry and compat components if we don't already have them in
the dest map.
|
|
Remember to increment the source and destination shapes when copying,
instead of just endlessly copying the first one.
|
|
Compute virtual modmap size bounded by nVModMapKeys-1, rather than
nVModMapKeys.
This is sort of a best guess. The other way seems a little more
logical, but also leads to segfaults pretty quickly if you hammer
GetMap hard enough. So let's try this one.
|
|
Copy server->vmods, and all the atoms in names.
|
|
Forgot that all XKB requests took a device spec: the comparison of
'if working on the core keyboard, does this device send core events; or,
is this device the core keyboard?' was broken. Instead, what we want is
'if working on the core keyboard, does this device send core events; or,
is this device the one we're working on?'.
|
|
XKB.h specifies that XkbDfltXIId should be used where the client doesn't
care about the device identifier. We take this to mean core devices,
where practical.
|
|
Add a first cut at geometry support, which seems to generally work.
|
|
|
|
Add FIXME comments above request handlers which need to act on all core-sending
devices if called on the core keyboard.
|
|
|
|
|
|
|
|
Apply the settings to all devices sending core events, if we're working on the
core keyboard.
|
|
Update the keymaps of all keyboards which send core events on
GetKeyboardByName; still a few other procedures which need this treatment.
|
|
Certain versions of LynxOS needed to sleep up to five seconds for closing a
pipe to actually, y'know, be useful.
|
|
git+ssh://git.freedesktop.org/git/xorg/xserver into input-hotplug
|
|
Use XkbCharToInt as that's what we're doing.
|
|
git+ssh://git.freedesktop.org/git/xorg/xserver into input-hotplug
|
|
input-hotplug
|
|
|
|
|
|
Unconditionally free geometry when copying the keymap (so we have none on
core, oh well), add a couple of heartening comments.
|
|
Make sure we don't stomp preserve if it doesn't already exist, and fix a
couple of range-related thinkos in level name copying.
|
|
Fix a bunch of range issues caused by incorrect assumptions (e.g. that the
design was at least halfway sensible), and copy types by hand, instead of
just blindly memcpy()ing the lot, since it itself cleverly contains a ton
of allocated pointers.
|
|
We haven't copied {min,max}_key_code by the time the notifies run, so use
src instead of dst to determine number of keys, et al.
|
