When the linux kernel sets the NX bit vm86 segfaults when it tries to execute
code in memory that is not marked EXEC. Such code gets called whenever
we return from a VBIOS call to signal the calling program that the call
is actually finished and that we are not trapping for other reasons (like
IO accesses).
Use mprotect(2) to set these memory ranges PROT_EXEC.
There's little chance that we'll get the input devices at runtime without HAL,
we might as well force the server to add mouse/kbd devices automatically -
just like in the olden days.
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>
This way we on't need to hold the mutex during the dixSaveScreens() call.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Tiago Vignatti <vignatti@c3sl.ufpr.br>
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
These values need not be constrained to integer values.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
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).
(cherry picked from commit 4294493632)
This prevents visuals with odd sizes. The machine I use didn't have
this problem, but it shows up on some others.
(cherry picked from commit ed181382dd)
Use the settings queried from the system in xprScreen.c, rather than those 2 calls.
The 2 calls increased the total number of visuals a great deal (when using GLXEXT),
and not all of the visuals were usable with GLX. Some of the visuals aren't usable
with GLX still, such as DirectColor, but that seems to be acceptable based on my
understanding of the manual that states "a subset of visuals are made available
for OpenGL rendering."
(cherry picked from commit 373b8a5f32)
It was returning inverted values in comparison to the 1.4 branch. This resulted in
the windows not drawing due to a deep path of: RootlessReorderWindow ->
SCREENREC(pScreen)->imp->DoReorderWindow(winRec) - > xprDoReorderWindow ->
AppleWMDoReorderWindow.
(cherry picked from commit d1d398db76)
We need them for each window, every time a window is allocated. Storing them
in a devPrivate is the wrong thing to do.
This also removes the unused ENTER_LEAVE_SEMAPHORE_ISSET macro.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
grab == devgrab anyway, this is a leftover from the time when we had two
different grabs per device (core and XI grab).
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Copy the EventRec's information into local variables before processing them,
this should make it safer for upcoming threading and also makes it easier to
read.
Simplify the event allocation code from the abyss it was before.
This also fixes a potential bug where a custom handler could scramble the
event before the same -now scrambled- event was then passed through the
master's custom event handler.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
As reported in http://bugs.freedesktop.org/show_bug.cgi?id=18438
the server suggests reconfiguring HAL if AllowEmptyInput is enabled
and no input devices are known.
Instead of that notice, if HAL is disabled at configure time,
AllowEmptyInput is enabled in the config and no input devices are
found report those facts and recommend disabling AllowEmptyInput.