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...
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.
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.
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.
using a hardcoded ProcessKeyboardEvent. Otherwise we lose the ability to
process DeviceKeyEvents after the first key press.
This should be the correct fix now.
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.
otherwise a Xi grab may overwrite or release a core grab.
Replace grab and associates with coreGrab and deviceGrab structures,
adjust rest of dix/Xi/etc to compile.
xfree86: Don't check for core devices, we'll have the virtual ones anyway.
If we check, the first mouse device is duplicated and sends
double events.
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).
bugfix: uninitialized pPointer in miPointerGetPosition ifndef MPX
adding DeviceIntPtr parameter to ScreenRec's cursor functions.
cleanup of miPointer code to use same scheme in each function
dix: MPHasCursor() function determines checking whether to invoke
cursor rendering.
animcur: adding DeviceIntPtr parameter to cursor functions but animcur relies
on the core pointer right now.
xfixes: adding DeviceIntPtr parameter to cursor functions but xfixes relies on
the core pointer right now.
rac: adding DeviceIntPtr parameter to cursor functions but RAC relies on
the core pointer right now.
ramdac: adding DeviceIntPtr parameter to cursor functions but ramdac relies on
the core pointer right now.
added SpriteRecs for MPX devices
changed sprite dependency and added MPX functionality to parts
of events.c (ConfineToShape, PostNewCursor, XineramaCheckMotion,
CheckMotion, XineramaChangeToCursor, ChangeToCursor, CheckPhysLimits,
PointerConfinedToScreen)
added DeviceIntRec param to GetSpritePosition(). This required some
minor changes in ddx, xtest, xkb and xfixes.
mi: changed miPointer to pointer instead of static struct.
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.
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.
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.
