Use dummy config functions to replace those from config/config.c, and
therefore do not link Xprt with $CONFIG_LIB.
Works around an endlessly spinning loop in dix/dispatch.c::Dispatch()
(WaitForSomething() not waiting) when built with dbus, which was
causing Xprt to use 95% cpu.
The HAL spec says that input.xkb.{rmlv}* can be sent, but if the user
specifies a X-specific {rmlv}, then this is overridden through the use of
input.x11_options.Xkb{RMLV}.
However, the way how the server parses options--by ignoring capitalisation,
underscores and spaces--the HAL and the x11_options would override each other.
So we simply filter the options, letting Xkb{RMLV} override xkb_{rmlv} and
only actually add them to the device after parsing _all_ options.
* rmlv ... rules, model, layout, variant
See Bug 13037 <http://bugs.freedesktop.org/show_bug.cgi?id=13037>
(cherry picked from commit fc35d1e3be)
The HAL spec says that input.xkb.{rmlv}* can be sent, but if the user
specifies a X-specific {rmlv}, then this is overridden through the use of
input.x11_options.Xkb{RMLV}.
However, the way how the server parses options--by ignoring capitalisation,
underscores and spaces--the HAL and the x11_options would override each other.
So we simply filter the options, letting Xkb{RMLV} override xkb_{rmlv} and
only actually add them to the device after parsing _all_ options.
* rmlv ... rules, model, layout, variant
See Bug 13037 <http://bugs.freedesktop.org/show_bug.cgi?id=13037>
daniels:
"Hrm, I'd prefer to have input.xkb.{m,l,v,o} be the primary keys, and
have input.x11_options be a backup for that, rather than the former
being deprecated, for the reasons I listed earlier ..."
see http://bugs.freedesktop.org/show_bug.cgi?id=13037#c51
This reverts commit 26188875de.
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.
GLX, there's more to the world than just you. If you fail to load the
software renderer, don't bring the entire server down.
The error path probably needs better testing on this one, but it seems
mostly okay to me.
These options are still sent by some HAL implementations (e.g. HAL on FC8),
and may overwrite the options set in the x11-input.fdi file.
For a more detailed description of why see Bug #13037, comment 42.
X.Org Bug 13037 <http://bugs.freedesktop.org/show_bug.cgi?id=13037#c42>
Since glyphs are stored in pixmaps now, they can make their way into VRAM,
which invalidates a bunch of fast-path assumptions in the XAA code. Thus
you end up doing color-expands or WriteBitmap from la-la land and your
aliased glyphs go all funny.
Since XAA isn't ever growing the ability to do sane glyph accel, just force
glyph pixmaps into host memory by catching them at CreatePixmap time.
We need a manual call to SetCursor when we switch from SW to HW rendering and
the other way round. This way we display the new cursor after removing the old
one.
In addition, we only update the internal state for the VCP's sprite. This way,
when we switch back to HW rendering the state is up-to-date and wasn't
overwritten with the other sprite's state.
The second part is a hack. It would be better to keep a state for each sprite,
but then again we don't have hardware that can render multiple cursors so we
might as well do with the hack.
Switches back to HW cursors when sprites other than the VCP are removed.
The current state requires the cursor to change shape once before it updates
to SW / HW rendering (whatever is appropriate), e.g. by moving into a
different window. Until this is done, the cursor is invisible.
The composite overlay window code had several misunderstandings of the
workings of the X server, in particular error handling paths would often
double-free objects. Clean all of this up by using resource destruction as
the sole mechanism for freeing resource-based objects.
Thanks to Owen Taylor for root-causing this one.
If a TreatAsTransparent window has any area in the borderClip, that will be
added to the totalClip region for use by other windows. That's wrong.
Instead, simply empty the borderClip for TreatAsTransparent windows right up
front.
This patch only creates a Files section if required, so if no entries are
added, an empty Files section will not be created.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
XQuartz was crashing because the Appkit thread was trying to GetXXXEvents while the Xserver thread was exiting.
This adds some more sanity checks and avoids that crash
(cherry picked from commit 34ec4bd6ac)
When a new device is added, calculate the event size needed if a DCCE event is
sent and set the EQ's event size to this minimum. This avoids reallocs when a
event is sent (which may happen during a SIGIO).
