| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Alloc an EventList once and then re-use instead of allocing a new event each
time we need a master event.
There's a trick included: because all the event processing handlers only take
an xEvent, init a size 1 EventList and squash the events into this one.
Events that have count > 1 must be squished into an xEvent array anyway before
passing into the event handlers, so we don't lose anything here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
(cherry picked from commit d281866b74f7067f2704c278fe9720eafc0ee5ef)
|
|
If no rules file is given, simply re-use the previous one. If no RF is given
the first time this function is called, use the built-in default.
This includes fixing the built-in default to something that actually exists.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
(cherry picked from commit 463e02e7de5da3e582a3a049110a476713c7210e)
|
|
We'd like to do soft repeat in the server for all keys. Remove obscure check, that'd
prevent the server from autorepeating when delay is set to exactly 660ms and rate is
set to exactly 25 (interval=40).
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
(cherry picked from commit bbf811514d3cdf84790bad5b852942a4e636902b)
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Reported by Magnus Kessler.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
|
|
|
|
|
|
|
|
Previously each server starting ran xkbcomp with the output set to
<keymapname>.xkm, read it, then deleted it - which led to races if
two servers were starting at the same time with the same keymap.
Sun bug #6773816 Xorg uses the same xkm output file for compiled keymap file
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6773816>
|
|
Remove several doubled statement-terminal semicolons.
Reported by Fernando Carrijo.
|
|
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.
|
|
|
|
|
