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.
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.
over to new system.
Need to update documentation and address some remaining vestiges of
old system such as CursorRec structure, fb "offman" structure, and
FontRec privates.
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.