| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 5544c51447f551dfc6df64438873a7ce64743976.
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 e8c2a3d7c996cb41c4c44ba67acae5ff9438fc06.
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>
|
|
And some cosmetic changes to use stuff->change consistently.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
|
|
TODO: static indices can be made just an int; some indices
can be combined.
|
|
And make sure os.h is included in files that use it.
|
|
|
|
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.
|
|
|
|
Really not necessary, we can just walk the list and spare us the special
treatment of the VCK.
|
|
|
|
Core events don't happen until later in the DIX, so pump device events down
instead. This makes modifiers work again when SlowKeys is enabled.
|
|
|
|
|
|
|
|
|
|
Again, hasn't worked since at least 7.0.
|
|
Remove a whole bunch of code that was never built, be it entire files or
just dead ifdefs.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
Could lead to some invalid pointers in the second server generation.
|
|
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.
|
|
Conflicts:
Xext/EVI.c
Xext/appgroup.c
Xext/cup.c
Xext/mitmisc.c
Xext/sampleEVI.c
dix/window.c
|
|
X.Org Bug 15614 <http://bugs.freedesktop.org/show_bug.cgi?id=15614>
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
|
|
|
|
- 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.
|
