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...
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.
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.
