The builtin-fonts configure option was removed, as it at best should
have been a runtime option. Instead, now it always register all "font
path element" backends, and adds built-ins fonts at the end of the
default font path.
This should be a more reasonable solution, to "correct" the most
common Xorg FAQ (could not open default font 'fixed'), and also don't
break by default applications that use only the standard/historical
X Font rendering.
(cherry picked from commit 49b93df8a3)
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 69a2728891)
This was to account for cases where you had video and print screens in
the same server. Lunacy. Leave the slot in ScreenInfo, but rename it,
and stop looking at it.
(cherry picked from commit a82e6efb7b)
Added a configure option called --enable-standalone-xpbproxy which is useful for deveoping xpbproxy.
The 'active' switch in preferences just disables the in-server xpbproxy (not this standalone).
If input processing is frozen, only wrap realInputProc: don't smash
processInputProc as well. When input processing is thawed, pIP will be
rewrapped correctly.
This supersedes the previous workaround in 50e80c9.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
(cherry picked from commit 37b1258f0a)
In some cases (triggered by a key repeat during a sync grab) XKB unwrapping
can overwrite the device's realInputProc with the enqueueInputProc. When the
grab is released and the events are replayed, we end up in an infinite loop.
Each event is replayed and in replaying pushed to the end of the queue again.
This fix is a hack only. It ensures that the realInputProc is never
overwritten with the enqueueInputProc.
This fixes Bug #13511 (https://bugs.freedesktop.org/show_bug.cgi?id=13511)
(cherry picked from commit eace88989c)
(cherry picked from commit 50e80c3987)
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)
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)
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)
Add support for HAL-based hotplugging, in which we just get the list of
input devices and properties from HAL. Requires an FDI which is not yet
in mainline HAL.
Break up D-Bus into two components: a D-Bus core that can be used by any
part of the server (for the moment, just the D-Bus hotplug API, and the
forthcoming HAL hotplug API), and the old D-Bus hotplug API.
This patch changes the semantics of manual redirect windows so that they no
longer affect the clip list of their parent. Doing this means the parent can
draw to the area covered by the child without using IncludeInferiors. More
importantly, this also means that the parent receives expose events when
that region is damaged by other actions.
Before you complain, this code hasn't seen material change since at least
X11R6. It certainly does not build with any modern version of Kerberos.
Anybody wanting krb5 auth to their X server should probably be using
GSSAPI instead of internal krb5 API anyway.
