GitLab

Add some commentary about future directions needed for the GLX drawable
creation and destruction code.

Match xalloc with xfree.

I made some minor formatting improvements.
(cherry picked from commit b772d64f)

In attach() check for pDraw being NULL, and also print an ErrorF message,
because we eventually want to track down why this is occuring.

It's unclear how this occurs, but as I noted in the 1.4 branch, I believe that
the DrawablePtr/struct _Drawable -> id is the member being accessed that causes
KERN_PROTECTION_FAILURE at 0x0000000000000004

This passes my tests using: env LIBGL_ALWAYS_INDIRECT=1 ./sometest.

I fixed a warning: caused by initializing the screen->base.visuals with the
configs.  It is a ** not a *.  It seems that some other part of GLX will
initialize this for us.
(cherry picked from commit 17f6a261)

This has been replaced by in-kernel support for USB mices several
years ago and hasn't been enabled in build since X.Org 6.8.

The new replacement is __GLXconfig.
(cherry picked from commit 3bed9b65)

Also trailing white space removal to clear git warnings.

(cherry picked from commit e62107e5)

(cherry picked from commit 0ad91c59)

(cherry picked from commit 56c469a6)

(cherry picked from commit 0947aa79)

(cherry picked from commit 80350907)

(cherry picked from commit a61a8d90)

and just have the AppKit thread wake it up.
(cherry picked from commit 799715b8)

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.

Without this, commit ace38faf is useless
when HAL support is disabled.
Signed-off-by: Julien Cristau <jcristau@debian.org>

XXX check amd64 pci init

Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>

Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>

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>

Signed-off-by: Julien Cristau <jcristau@debian.org>

(cherry picked from commit 477c6968)

it got accidently added and isn't used.
(cherry picked from commit cb6ffce6)

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>

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>

Depends on commit 70e18a3b to get
definition of xf86InitVidMem on Solaris.

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>

This does a precursor check to make sure the copies are required before
entering the prepare/done code.

Simple fix for now, I'm sure damage shouldn't be calling us with nbox = 0.

(cherry picked from commit be8ac84c)

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 42944936)