We already deal with the button mapping in GetPointerEvents, so don't
do the remapping again in ProcessOtherEvent.
(cherry picked from commit 7ff002fe3e229330216d7f2ff16cdabe63014bcd)
Fix the botched previous key_is_down test, which would give false positives.
Also move key_autorepeats to a separate inline function.
(cherry picked from commit 242f56f722)
xf86RandR12ScreenSetSize must protect calls to EnableDisableFBAccess with
suitable vtSema checks to avoid invoking driver code while the X server is
inactive.
(cherry picked from commit 265a633cf1)
The code in connect_hook incorrectly checks for dbus_bus_request_name failure.
The dbus_bus_request_name error indicator is -1, not 0. This leads
to subsequent assertion failure in libdbus.
(cherry picked from commit ddce48ede0)
XkbRemoveResourceClient wants to access xkbInfo if it exists, so make
sure we NULL it after freeing it. It doesn't make much sense to move
the RemoveResourceClient call first, as there's not much point in
notifying clients while we're shutting the server down anyway.
(cherry picked from commit 23023af1c5a33546a2027cad23a946a2882e9893)
Make sure errno is saved and restored from the SIGIO handler, so errors
from system calls in input handlers don't break the interrupted code.
(cherry picked from commit 41c3069f7c)
When we change the mapping on a core device, make sure we propagate this
through to XKB for all extended devices as well.
(cherry picked from commit 27ad5d74c2)
Call ProcessOtherEvents first, then for all keyboard devices let them be
wrapped by XKB. This way all XI events will go through XKB.
Note that the VCK is still not wrapped, so core events will bypass XKB.
(cherry picked from commit d627061b48)
(cherry picked from commit 8ead41388e)
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.
(cherry picked from commit e717cf08e9)
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.
(cherry picked from commit 9db8846fa5)
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)
(cherry picked from commit ee3aa948eb)
FixKeyState needs to be able to handle XI events, otherwise we get "impossible
keyboard events" on server zaps and other special key combos.
(cherry picked from commit 5ee409794e)
(cherry picked from commit 8d3d027062)
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)
(cherry picked from commit 99e826e867)
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)
(cherry picked from commit 91077bfc50)
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)
(cherry picked from commit 8b9481a113)
Add the device private index, given we use that in a macro here, and also the
prototype for xkbUnwrapProc, since that's also useful.
(cherry picked from commit a3d48de5f2)
Don't build XF86Misc or XF86Vidmode in hw/xfree86/dixmod when it's been
explicitly disabled in configure, or we don't have the proto modules
installed.
(cherry picked from commit df57ae1639)
If message iterator cannot be created, the caller didn't supply any
parameters. Return BadValue, instead of dying a horrible death while being
stuck in an endless loop.
(cherry picked from commit 0fcde83d94)
Add keyc->postdown, which represents the key state as of the last mieqEnqueue
call, and use it when we need to know the posted state, instead of the
processed state (keyc->down). Add small functions to getevents.c to query and
modify key state in postdown and use them all through, eliminating previously
broken uses.
(cherry picked from commit 81c28ffd2b)
In commit 41bb9fce47, the event delivery loop
for Xinput enabled keyboards was changed and accidentally used the wrong
index variable, causing random events to be delivered when returning from VT
switch.
In addition, in commit aeba855b07,
SIGIO was blocked during delivery of these events, but not for the entire
period the xf86Events array was being used. Block SIGIO for the whole loop
to avoid other event delivery from trashing the key release events.
(cherry picked from commit aa7ed1f5f3)
(cherry picked from commit accd71bda6)
Previously, the server version reported by xdpyinfo and Xorg -version would
bear some vague resemblance to a X.Org katamari version, but in the presence
of modularization (and client-server relationships with different katamari
versions on each side) those numbers don't really make sense. Instead, just
report the package version.
When branching a stable branch, master's version should be immediately updated
to the endpoint of the stable branch plus a snapshot of 1 (for example,
1.4.0.1 after server-1.4-branch). The stable branch should then be changed to
RC0 at that time (1.3.99.0, for example).
This scheme was partially attempted for server 1.3, but lacked the appropriate
master updates, thus why it had to be revisited now. While here, we can also
remove a lot of versioning complexity since everything is based on the package
version.
(cherry picked from commit 47300ed2be)
compNewPixmap copies bits from the parent window to the redirected child
pixmap to populate the pixmap with reasonable data. It cannot always use
CopyArea as that only works across matching depths. Use Composite when
the depths do not match.
(cherry picked from commit f98dfec79d)
Clients expect any Xinerama-enabled screen to report at least one
monitor, but with RandR, there may not be any enabled crtcs. In this case,
tell the client that Xinerama is not active.
(cherry picked from commit 1afdf8b0a9)
The timestamp transferred in the X protocol is a 32-bit number of
milliseconds.
The timestamp stored in the server is a structure that contains two fields:
months (!) and milliseconds.
When the server passes the config timestamp to the client, it discards the
months part and sends only the milliseconds part.
When the server receives the config timestamp from the client, it tries to
guess the "months" part by looking at the current time and then maybe adding
or
subtracting one. The guess is wrong after the server has been running long
enough (several hours).
I have added two ErrorF calls around the 'if' statement that returns
RRSetConfigInvalidConfigTimestamp in randr/randr.c and my Xorg.0.log has
this:
randr request got good config time: 0:-2103495671
for the first few successful xrandr calls, and
randr request failed with RRSetConfigInvalidConfigTime: client passed
1:-2103495671, server has 0:-2103495671
when it fails. The server has been running for 8 and a half hours.
The obvious fix would be to ignore the months field and only compare the
milliseconds.
(cherry picked from commit 0dc2bb6101)
MAXBUFSIZE appears to be a leftover of some previous time. Instead, just
use maxBigRequestSize when bigreqs are available (limiting buffers to ~16MB).
When bigreqs are not available, needed won't be larger than the maximum
size of a non-bigreqs request (256kB).
(cherry picked from commit ca82d4bddf)