ChangeLog | 246 ++++++++++++++++++++++++++++++++++++
configure.ac | 4
debian/changelog | 8 +
glamor/glamor_render.c | 16 +-
hw/xfree86/common/xf86Bus.c | 3
hw/xfree86/common/xf86platformBus.c | 24 ++-
hw/xfree86/common/xf86platformBus.h | 1
hw/xquartz/xpr/xprScreen.c | 23 ++-
mi/mieq.c | 2
os/connection.c | 7 -
os/utils.c | 2
present/present_event.c | 2
12 files changed, 308 insertions(+), 30 deletions(-)
New commits:
commit 27797ffbac79b4cba369ee56ff0c7e82cc48b32b
Author: Julien Cristau <jcris...@debian.org>
Date: Mon Sep 15 23:59:34 2014 +0200
Document cherry-pick
diff --git a/debian/changelog b/debian/changelog
index f43c942..0e4bc3e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ xorg-server (2:1.16.0.901-1) UNRELEASED; urgency=medium
* New upstream release
+ glx/present: Only send GLX_BufferSwapComplete for
PresentCompleteKindPixmap (closes: #761393)
+ * glx: Disable indirect GLX contexts by default (cherry-pick from master)
-- Julien Cristau <jcris...@debian.org> Mon, 15 Sep 2014 23:56:51 +0200
commit ba0c6a7c7cc7079a84398ab288e6ef775038a3a6
Author: Eric Anholt <e...@anholt.net>
Date: Thu Sep 4 10:59:40 2014 -0700
glx: Disable indirect GLX contexts by default.
Almost every situation of someone running indirect GLX is a mistake
that results in X Server crashes. Indirect GLX is the cause of
regular security vulnerabilities, and rarely provides any capability
to the user. Just disable it unless someone wants to enable it for
their special use case (using +iglx on the command line).
Signed-off-by: Eric Anholt <e...@anholt.net>
Acked-by: Keith Packard <kei...@keithp.com>
Signed-off-by: Keith Packard <kei...@keithp.com>
(cherry picked from commit d0da0e9c3bb8fe0cd4879ecb24d21715bfaa209b)
diff --git a/os/utils.c b/os/utils.c
index ed7581e..b63913c 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -194,7 +194,7 @@ Bool noGEExtension = FALSE;
Bool CoreDump;
-Bool enableIndirectGLX = TRUE;
+Bool enableIndirectGLX = FALSE;
#ifdef PANORAMIX
Bool PanoramiXExtensionDisabledHack = FALSE;
commit 1de97960145123eedaa2449245827b5f0afdc920
Author: Julien Cristau <jcris...@debian.org>
Date: Mon Sep 15 23:57:56 2014 +0200
Bump changelogs
diff --git a/ChangeLog b/ChangeLog
index 1da7a9b..d0f83c9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,249 @@
+commit 3ce47886c58b0640697f243a5df7060109c8346f
+Author: Julien Cristau <jcris...@debian.org>
+Date: Mon Sep 15 22:55:16 2014 +0200
+
+ Bump to 1.16.0.901
+
+ Signed-off-by: Julien Cristau <jcris...@debian.org>
+
+commit c48d07cf0e6edfc92dcb97de66c2484a8ddba452
+Author: Keith Packard <kei...@keithp.com>
+Date: Thu Sep 4 08:36:07 2014 -0700
+
+ glx/present: Only send GLX_BufferSwapComplete for PresentCompleteKindPixmap
+
+ Present didn't provide the 'kind' argument to the
+ present_complete_notify hook that GLX uses to construct
+ GLX_BufferSwapComplete events, so GLX was reporting events for
+ PresentCompleteKindMSC notifications, which resulted in duplicate
+ GLX_BufferSwapComplete events and crashes in clutter.
+
+ See the gnome bug: https://bugzilla.gnome.org/show_bug.cgi?id=733282
+
+ Signed-off-by: Keith Packard <kei...@keithp.com>
+ Reviewed-by: Eric Anholt <e...@anholt.net>
+ (cherry picked from commit bf338efc678258d2d366dff2ed873752f98f0bfc)
+ [backport to 1.16: check 'kind' in the caller to avoid ABI change]
+ Signed-off-by: Julien Cristau <jcris...@debian.org>
+
+commit fbe977941abb0a6db19b345652b6106d849899c1
+Author: Thierry Reding <tred...@nvidia.com>
+Date: Thu Feb 13 13:36:12 2014 +0100
+
+ xfree86: Allow non-PCI devices as primary
+
+ On platforms that don't support PCI or have no GPU attached to the PCI
+ bus, there can still be a primary device on a non-PCI bus.
+
+ Signed-off-by: Thierry Reding <tred...@nvidia.com>
+ Reviewed-by: Rob Clark <robdcl...@gmail.com>
+ Tested-by: Rob Clark <robdcl...@gmail.com>
+ Signed-off-by: Keith Packard <kei...@keithp.com>
+ (cherry picked from commit 5d133276de9c50146e80ffc69edd429c2afe98e6)
+ Signed-off-by: Hans de Goede <hdego...@redhat.com>
+ Signed-off-by: Julien Cristau <jcris...@debian.org>
+
+commit 484b881ecd7fbf5e1aabacfa96acb6f53475e32d
+Author: Thierry Reding <tred...@nvidia.com>
+Date: Thu Feb 13 13:31:31 2014 +0100
+
+ xfree86: Fallback to first platform device as primary
+
+ When neither of the various bus implementations was able to find a
+ primary bus and device, fallback to using the platform bus as primary
+ bus and the first platform device as primary device.
+
+ Signed-off-by: Thierry Reding <tred...@nvidia.com>
+ Reviewed-by: Rob Clark <robdcl...@gmail.com>
+ Tested-by: Rob Clark <robdcl...@gmail.com>
+ Signed-off-by: Keith Packard <kei...@keithp.com>
+ (cherry picked from commit 2f0183222b4279266e6ef60b923738ff55f0afba)
+ [hdegoede: backport to 1.16 which doesn't have syspath directly in
OdevAttributes]
+ Signed-off-by: Hans de Goede <hdego...@redhat.com>
+ Signed-off-by: Julien Cristau <jcris...@debian.org>
+
+commit af2e9e3bb173885106f041f89b9f39b57fe3550a
+Author: Jeremy Huddleston Sequoia <jerem...@apple.com>
+Date: Mon Aug 11 13:15:24 2014 -0700
+
+ XQuartz: Better support turning off "Displays have separate Spaces" on OS
X Mavericks
+
+ http://xquartz.macosforge.org/trac/ticket/1876
+
+ Follow-up to: 1c10b37380d228b35db8a8616a6312ac54f5e59b
+
+ Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
+ (cherry picked from commit ab32ee35890be51137b56525826ffe219b63eb88)
+
+commit b7a24467f738bfd9437e8de02ed5e44409054185
+Author: Jeremy Huddleston Sequoia <jerem...@apple.com>
+Date: Wed Jul 23 11:53:33 2014 -0700
+
+ ListenOnOpenFD: Remove Resets since this is intended to be for hotplugging
connections
+
+ pharris says that the resets should not be done in the hotplugging case.
+
+ This may fix a crash reported against XQuartz:
+ http://xquartz.macosforge.org/trac/ticket/869
+
+ Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
+ Reviewed-by: Peter Harris <phar...@opentext.com>
+ (cherry picked from commit dfbc6a1a78ff3192baae6f7f2af98b6e51422f75)
+
+commit a793483e38bfb8af19877f69e873c1776de18d1f
+Author: Jeremy Huddleston Sequoia <jerem...@apple.com>
+Date: Sat Jul 19 17:08:09 2014 -0700
+
+ mieq: Fix a crash regression in mieqProcessDeviceEvent
+
+ (lldb) bt
+ * thread #6: tid = 0x92d4eb, 0x00000001001dee94
X11.bin`mieqProcessDeviceEvent(dev=0x0000000000000000, event=0x0000000100298bb0,
+ screen=0x0000000000000000) + 36 at mieq.c:519, stop reason =
EXC_BAD_ACCESS (code=1, address=0x44)
+ * frame #0: 0x00000001001dee94
X11.bin`mieqProcessDeviceEvent(dev=0x0000000000000000,
event=0x0000000100298bb0, screen=0x0000000000000000) + 36 at
+ mieq.c:519
+ frame #1: 0x00000001001df3eb X11.bin`mieqProcessInputEvents + 555 at
mieq.c:631
+ frame #2: 0x0000000100017674 X11.bin`ProcessInputEvents + 20 at
darwinEvents.c:422
+ frame #3: 0x0000000100175eaa X11.bin`Dispatch + 154 at dispatch.c:357
+ frame #4: 0x0000000100181b4a X11.bin`dix_main(argc=4,
argv=0x00007fff5fbff750, envp=0x00007fff5fbff650) + 1594 at main.c:296
+ frame #5: 0x000000010001ba80
X11.bin`server_thread(arg=0x0000000101208220) + 64 at quartzStartup.c:66
+ frame #6: 0x00007fff89bb9899 libsystem_pthread.dylib`_pthread_body +
138
+ frame #7: 0x00007fff89bb972a libsystem_pthread.dylib`_pthread_start +
137
+ frame #8: 0x00007fff89bbdfc9 libsystem_pthread.dylib`thread_start + 13
+
+ Regression from: 9fb08310b51b46736f3ca8dbc04efdf502420403
+
+ Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
+ Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
+ (cherry picked from commit 1faa76670572e3478965fd2cd9ab60ab2d865e3a)
+
+commit 3c0431b8911241552a15a43e4279c50658b50a18
+Author: Keith Packard <kei...@keithp.com>
+Date: Wed Jul 16 16:03:23 2014 -0700
+
+ glamor: Fix temp picture coordinates in glamor_composite_clipped_region
+
+ To understand this patch, let's start at the protocol interface where
+ the relationship between the coordinate spaces is documented:
+
+ static Bool
+ _glamor_composite(CARD8 op,
+ PicturePtr source,
+ PicturePtr mask,
+ PicturePtr dest,
+ INT16 x_source,
+ INT16 y_source,
+ INT16 x_mask,
+ INT16 y_mask,
+ INT16 x_dest, INT16 y_dest,
+ CARD16 width, CARD16 height, Bool fallback)
+
+ The coordinates are passed to this function directly off the wire and
+ are all relative to their respective drawables. For Windows, this means
+ that they are relative to the upper left corner of the window, in
+ whatever pixmap that window is getting drawn to.
+
+ _glamor_composite calls miComputeCompositeRegion to construct a clipped
+ region to actually render to. In reality, miComputeCompositeRegion clips
+ only to the destination these days; source clip region based clipping
+ would have to respect the transform, which isn't really possible. The
+ returned region is relative to the screen in which dest lives; offset by
+ dest->drawable.x and dest->drawable.y.
+
+ What is important to realize here is that, because of clipping, the
+ composite region may not have the same position within the destination
+ drawable as x_dest, y_dest. The protocol coordinates now exist solely to
+ 'pin' the three objects together.
+
+ extents->x1,y1 Screen origin of clipped operation
+ width,height Extents of the clipped operation
+ x_dest,y_dest Unclipped destination-relative
operation coordinate
+ x_source,y_source Unclipped source-relative operation coordinate
+ x_mask,y_mask Unclipped mask-relative operation
coordinate
+
+ One thing we want to know is what the offset is from the original
+ operation origin to the clipped origin
+
+ Destination drawable relative coordinates of the clipped operation:
+
+ x_dest_clipped = extents->x1 - dest->drawable.x
+ y_dest_clipped = extents->y1 - dest->drawable.y
+
+ Offset from the original operation origin:
+
+ x_off_clipped = x_dest_clipped - x_dest
+ y_off_clipped = y_dest_clipped - y_dest
+
+ Source drawable relative coordinates of the clipped operation:
+
+ x_source_clipped = x_source + x_off_clipped;
+ y_source_clipped = y_source + y_off_clipped;
+
+ Mask drawable relative coordinates of the clipped operation:
+
+ x_mask_clipped = x_source + x_off_clipped;
+ y_mask_clipped = y_source + y_off_clipped;
+
+ This is where the original code fails -- it doesn't subtract the
+ destination drawable location when computing the distance that the
+ operation has been moved by clipping. Here's what it does when
+ constructing a temporary source picture:
+
+ temp_src =
+ glamor_convert_gradient_picture(screen, source,
+ extent->x1 + x_source - x_dest,
+ extent->y1 + y_source - y_dest,
+ width, height);
+ ...
+ x_temp_src = -extent->x1 + x_dest;
+ y_temp_src = -extent->y1 + y_dest;
+
+ glamor_convert_gradient_picture needs source drawable relative
+ coordinates, but that is not what it's getting; it's getting
+ screen-relative coordinates for the destination, adjusted by the
+ distance between the provided source and destination operation
+ coordinates. We want x_source_clipped and y_source_clipped:
+
+ x_source_clipped = x_source + x_off_clipped
+ = x_source + x_dest_clipped - x_dest
+ = x_source + extents->x1 - dest->drawable.x -
x_dest
+
+ x_temp_src/y_temp_src are supposed to be the coordinates of the original
+ operation translated to the temporary picture:
+
+ x_temp_src = x_source - x_source_clipped;
+ y_temp_src = y_source - y_source_clipped;
+
+ Note that x_source_clipped/y_source_clipped will never be less than
+ x_source/y_source because all we're doing is clipping. This means that
+ x_temp_src/y_temp_src will always be non-positive; the original source
+ coordinate can never be strictly *inside* the temporary image or we
+ could have made the temporary image smaller.
+
+ x_temp_src = x_source - x_source_clipped
+ = x_source - (x_source + x_off_clipped)
+ = -x_off_clipped
+ = x_dest - x_dest_clipped
+ = x_dest - (extents->x1 - dest->drawable.x)
+
+ Again, this is off by the destination origin within the screen
+ coordinate space.
+
+ The code should look like:
+
+ temp_src =
+ glamor_convert_gradient_picture(screen, source,
+ extent->x1 + x_source - x_dest
- dest->pDrawable->x,
+ extent->y1 + y_source - y_dest
- dest->pDrawable->y,
+ width, height);
+
+ x_temp_src = -extent->x1 + x_dest + dest->pDrawable->x;
+ y_temp_src = -extent->y1 + y_dest + dest->pDrawable->y;
+
+ Signed-off-by: Keith Packard <kei...@keithp.com>
+ Reviewed-by: Markus Wick <mar...@selfnet.de>
+ (cherry picked from commit 55f5bfb578e934319d1308cbb56c900c5ac7cfa7)
+ Signed-off-by: Julien Cristau <jcris...@debian.org>
+
commit 8b36e1ec8dd9f53e9f4e10422c2100844e9e549c
Author: Keith Packard <kei...@keithp.com>
Date: Thu Jul 17 00:03:33 2014 -0700
diff --git a/debian/changelog b/debian/changelog
index b832d41..f43c942 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+xorg-server (2:1.16.0.901-1) UNRELEASED; urgency=medium
+
+ * New upstream release
+ + glx/present: Only send GLX_BufferSwapComplete for
PresentCompleteKindPixmap (closes: #761393)
+
+ -- Julien Cristau <jcris...@debian.org> Mon, 15 Sep 2014 23:56:51 +0200
+
xorg-server (2:1.16.0-2) unstable; urgency=medium
* xserver-xorg-dev: /usr/share/xserver-xorg/configure_flags.mk
commit 3ce47886c58b0640697f243a5df7060109c8346f
Author: Julien Cristau <jcris...@debian.org>
Date: Mon Sep 15 22:55:16 2014 +0200
Bump to 1.16.0.901
Signed-off-by: Julien Cristau <jcris...@debian.org>
diff --git a/configure.ac b/configure.ac
index 1c327fd..d93eb21 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,8 +26,8 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ(2.60)
-AC_INIT([xorg-server], 1.16.0,
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], xorg-server)
-RELEASE_DATE="2014-07-16"
+AC_INIT([xorg-server], 1.16.0.901,
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], xorg-server)
+RELEASE_DATE="2014-09-15"
RELEASE_NAME="Marionberry Pie"
AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_MACRO_DIR([m4])
commit c48d07cf0e6edfc92dcb97de66c2484a8ddba452
Author: Keith Packard <kei...@keithp.com>
Date: Thu Sep 4 08:36:07 2014 -0700
glx/present: Only send GLX_BufferSwapComplete for PresentCompleteKindPixmap
Present didn't provide the 'kind' argument to the
present_complete_notify hook that GLX uses to construct
GLX_BufferSwapComplete events, so GLX was reporting events for
PresentCompleteKindMSC notifications, which resulted in duplicate
GLX_BufferSwapComplete events and crashes in clutter.
See the gnome bug: https://bugzilla.gnome.org/show_bug.cgi?id=733282
Signed-off-by: Keith Packard <kei...@keithp.com>
Reviewed-by: Eric Anholt <e...@anholt.net>
(cherry picked from commit bf338efc678258d2d366dff2ed873752f98f0bfc)
[backport to 1.16: check 'kind' in the caller to avoid ABI change]
Signed-off-by: Julien Cristau <jcris...@debian.org>
diff --git a/present/present_event.c b/present/present_event.c
index ff57eba..e9b8276 100644
--- a/present/present_event.c
+++ b/present/present_event.c
@@ -173,7 +173,7 @@ present_send_complete_notify(WindowPtr window, CARD8 kind,
CARD8 mode, CARD32 se
}
}
}
- if (complete_notify)
+ if (complete_notify && kind == PresentCompleteKindPixmap)
(*complete_notify)(window, mode, serial, ust, msc);
}
commit fbe977941abb0a6db19b345652b6106d849899c1
Author: Thierry Reding <tred...@nvidia.com>
Date: Thu Feb 13 13:36:12 2014 +0100
xfree86: Allow non-PCI devices as primary
On platforms that don't support PCI or have no GPU attached to the PCI
bus, there can still be a primary device on a non-PCI bus.
Signed-off-by: Thierry Reding <tred...@nvidia.com>
Reviewed-by: Rob Clark <robdcl...@gmail.com>
Tested-by: Rob Clark <robdcl...@gmail.com>
Signed-off-by: Keith Packard <kei...@keithp.com>
(cherry picked from commit 5d133276de9c50146e80ffc69edd429c2afe98e6)
Signed-off-by: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Julien Cristau <jcris...@debian.org>
diff --git a/hw/xfree86/common/xf86platformBus.c
b/hw/xfree86/common/xf86platformBus.c
index 1890494..c541788 100644
--- a/hw/xfree86/common/xf86platformBus.c
+++ b/hw/xfree86/common/xf86platformBus.c
@@ -476,10 +476,9 @@ xf86platformProbeDev(DriverPtr drvp)
/* for non-seat0 servers assume first device is the master */
if (ServerIsNotSeat0())
break;
- if (xf86_platform_devices[j].pdev) {
- if (xf86IsPrimaryPlatform(&xf86_platform_devices[j]))
- break;
- }
+
+ if (xf86IsPrimaryPlatform(&xf86_platform_devices[j]))
+ break;
}
}
commit 484b881ecd7fbf5e1aabacfa96acb6f53475e32d
Author: Thierry Reding <tred...@nvidia.com>
Date: Thu Feb 13 13:31:31 2014 +0100
xfree86: Fallback to first platform device as primary
When neither of the various bus implementations was able to find a
primary bus and device, fallback to using the platform bus as primary
bus and the first platform device as primary device.
Signed-off-by: Thierry Reding <tred...@nvidia.com>
Reviewed-by: Rob Clark <robdcl...@gmail.com>
Tested-by: Rob Clark <robdcl...@gmail.com>
Signed-off-by: Keith Packard <kei...@keithp.com>
(cherry picked from commit 2f0183222b4279266e6ef60b923738ff55f0afba)
[hdegoede: backport to 1.16 which doesn't have syspath directly in
OdevAttributes]
Signed-off-by: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Julien Cristau <jcris...@debian.org>
diff --git a/hw/xfree86/common/xf86Bus.c b/hw/xfree86/common/xf86Bus.c
index b3b3f8c..bd3e4e3 100644
--- a/hw/xfree86/common/xf86Bus.c
+++ b/hw/xfree86/common/xf86Bus.c
@@ -210,6 +210,9 @@ xf86BusProbe(void)
#if (defined(__sparc__) || defined(__sparc)) && !defined(__OpenBSD__)
xf86SbusProbe();
#endif
+#ifdef XSERVER_PLATFORM_BUS
+ xf86platformPrimary();
+#endif
}
/*
diff --git a/hw/xfree86/common/xf86platformBus.c
b/hw/xfree86/common/xf86platformBus.c
index eb1a3fb..1890494 100644
--- a/hw/xfree86/common/xf86platformBus.c
+++ b/hw/xfree86/common/xf86platformBus.c
@@ -635,4 +635,21 @@ void xf86platformVTProbe(void)
xf86PlatformReprobeDevice(i, xf86_platform_devices[i].attribs);
}
}
+
+void xf86platformPrimary(void)
+{
+ /* use the first platform device as a fallback */
+ if (primaryBus.type == BUS_NONE) {
+ xf86Msg(X_INFO, "no primary bus or device found\n");
+
+ if (xf86_num_platform_devices > 0) {
+ char *syspath = xf86_get_platform_attrib(0, ODEV_ATTRIB_SYSPATH);
+
+ primaryBus.id.plat = &xf86_platform_devices[0];
+ primaryBus.type = BUS_PLATFORM;
+
+ xf86Msg(X_NONE, "\tfalling back to %s\n", syspath);
+ }
+ }
+}
#endif
diff --git a/hw/xfree86/common/xf86platformBus.h
b/hw/xfree86/common/xf86platformBus.h
index 5dee4e0..dec1956 100644
--- a/hw/xfree86/common/xf86platformBus.h
+++ b/hw/xfree86/common/xf86platformBus.h
@@ -77,6 +77,7 @@ extern _X_EXPORT int
xf86PlatformMatchDriver(char *matches[], int nmatches);
extern void xf86platformVTProbe(void);
+extern void xf86platformPrimary(void);
#endif
#endif
commit af2e9e3bb173885106f041f89b9f39b57fe3550a
Author: Jeremy Huddleston Sequoia <jerem...@apple.com>
Date: Mon Aug 11 13:15:24 2014 -0700
XQuartz: Better support turning off "Displays have separate Spaces" on OS X
Mavericks
http://xquartz.macosforge.org/trac/ticket/1876
Follow-up to: 1c10b37380d228b35db8a8616a6312ac54f5e59b
Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
(cherry picked from commit ab32ee35890be51137b56525826ffe219b63eb88)
diff --git a/hw/xquartz/xpr/xprScreen.c b/hw/xquartz/xpr/xprScreen.c
index 7aa1ae1..d0a525f 100644
--- a/hw/xquartz/xpr/xprScreen.c
+++ b/hw/xquartz/xpr/xprScreen.c
@@ -169,14 +169,25 @@ displayScreenBounds(CGDirectDisplayID id)
(int)frame.size.width, (int)frame.size.height,
(int)frame.origin.x, (int)frame.origin.y);
- /* Remove menubar to help standard X11 window managers.
- * On Mavericks and later, the menu bar is on all displays.
- */
- if (XQuartzIsRootless
+ Boolean spacePerDisplay = false;
#if MAC_OS_X_VERSION_MIN_REQUIRED < 1090
- && (NSAppKitVersionNumber >= 1265 || (frame.origin.x == 0 &&
frame.origin.y == 0))
+ if (NSAppKitVersionNumber >= 1265)
#endif
- ) {
+ {
+ Boolean ok;
+ (void)CFPreferencesAppSynchronize(CFSTR("com.apple.spaces"));
+ spacePerDisplay = !
CFPreferencesGetAppBooleanValue(CFSTR("spans-displays"),
+
CFSTR("com.apple.spaces"),
+ &ok);
+ if (!ok)
+ spacePerDisplay = true;
+ }
+
+ /* Remove menubar to help standard X11 window managers.
+ * On Mavericks and later, the menu bar is on all displays when
spans-displays is false or unset.
+ */
+ if (XQuartzIsRootless &&
+ (spacePerDisplay || (frame.origin.x == 0 && frame.origin.y == 0))) {
frame.origin.y += aquaMenuBarHeight;
frame.size.height -= aquaMenuBarHeight;
}
commit b7a24467f738bfd9437e8de02ed5e44409054185
Author: Jeremy Huddleston Sequoia <jerem...@apple.com>
Date: Wed Jul 23 11:53:33 2014 -0700
ListenOnOpenFD: Remove Resets since this is intended to be for hotplugging
connections
pharris says that the resets should not be done in the hotplugging case.
This may fix a crash reported against XQuartz:
http://xquartz.macosforge.org/trac/ticket/869
Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
Reviewed-by: Peter Harris <phar...@opentext.com>
(cherry picked from commit dfbc6a1a78ff3192baae6f7f2af98b6e51422f75)
diff --git a/os/connection.c b/os/connection.c
index 40d9ff3..f915e12 100644
--- a/os/connection.c
+++ b/os/connection.c
@@ -1307,13 +1307,6 @@ ListenOnOpenFD(int fd, int noxauth)
/* Increment the count */
ListenTransCount++;
-
- /* This *might* not be needed... /shrug */
- ResetAuthorization();
- ResetHosts(display);
-#ifdef XDMCP
- XdmcpReset();
-#endif
}
/* based on TRANS(SocketUNIXAccept) (XtransConnInfo ciptr, int *status) */
commit a793483e38bfb8af19877f69e873c1776de18d1f
Author: Jeremy Huddleston Sequoia <jerem...@apple.com>
Date: Sat Jul 19 17:08:09 2014 -0700
mieq: Fix a crash regression in mieqProcessDeviceEvent
(lldb) bt
* thread #6: tid = 0x92d4eb, 0x00000001001dee94
X11.bin`mieqProcessDeviceEvent(dev=0x0000000000000000, event=0x0000000100298bb0,
screen=0x0000000000000000) + 36 at mieq.c:519, stop reason = EXC_BAD_ACCESS
(code=1, address=0x44)
* frame #0: 0x00000001001dee94
X11.bin`mieqProcessDeviceEvent(dev=0x0000000000000000,
event=0x0000000100298bb0, screen=0x0000000000000000) + 36 at
mieq.c:519
frame #1: 0x00000001001df3eb X11.bin`mieqProcessInputEvents + 555 at
mieq.c:631
frame #2: 0x0000000100017674 X11.bin`ProcessInputEvents + 20 at
darwinEvents.c:422
frame #3: 0x0000000100175eaa X11.bin`Dispatch + 154 at dispatch.c:357
frame #4: 0x0000000100181b4a X11.bin`dix_main(argc=4,
argv=0x00007fff5fbff750, envp=0x00007fff5fbff650) + 1594 at main.c:296
frame #5: 0x000000010001ba80
X11.bin`server_thread(arg=0x0000000101208220) + 64 at quartzStartup.c:66
frame #6: 0x00007fff89bb9899 libsystem_pthread.dylib`_pthread_body + 138
frame #7: 0x00007fff89bb972a libsystem_pthread.dylib`_pthread_start +
137
frame #8: 0x00007fff89bbdfc9 libsystem_pthread.dylib`thread_start + 13
Regression from: 9fb08310b51b46736f3ca8dbc04efdf502420403
Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
(cherry picked from commit 1faa76670572e3478965fd2cd9ab60ab2d865e3a)
diff --git a/mi/mieq.c b/mi/mieq.c
index 872ff93..8907a6e 100644
--- a/mi/mieq.c
+++ b/mi/mieq.c
@@ -516,7 +516,7 @@ mieqProcessDeviceEvent(DeviceIntPtr dev, InternalEvent
*event, ScreenPtr screen)
verify_internal_event(event);
/* refuse events from disabled devices */
- if (!dev->enabled)
+ if (dev && !dev->enabled)
return;
/* Custom event handler */
commit 3c0431b8911241552a15a43e4279c50658b50a18
Author: Keith Packard <kei...@keithp.com>
Date: Wed Jul 16 16:03:23 2014 -0700
glamor: Fix temp picture coordinates in glamor_composite_clipped_region
To understand this patch, let's start at the protocol interface where
the relationship between the coordinate spaces is documented:
static Bool
_glamor_composite(CARD8 op,
PicturePtr source,
PicturePtr mask,
PicturePtr dest,
INT16 x_source,
INT16 y_source,
INT16 x_mask,
INT16 y_mask,
INT16 x_dest, INT16 y_dest,
CARD16 width, CARD16 height, Bool fallback)
The coordinates are passed to this function directly off the wire and
are all relative to their respective drawables. For Windows, this means
that they are relative to the upper left corner of the window, in
whatever pixmap that window is getting drawn to.
_glamor_composite calls miComputeCompositeRegion to construct a clipped
region to actually render to. In reality, miComputeCompositeRegion clips
only to the destination these days; source clip region based clipping
would have to respect the transform, which isn't really possible. The
returned region is relative to the screen in which dest lives; offset by
dest->drawable.x and dest->drawable.y.
What is important to realize here is that, because of clipping, the
composite region may not have the same position within the destination
drawable as x_dest, y_dest. The protocol coordinates now exist solely to
'pin' the three objects together.
extents->x1,y1 Screen origin of clipped operation
width,height Extents of the clipped operation
x_dest,y_dest Unclipped destination-relative
operation coordinate
x_source,y_source Unclipped source-relative operation coordinate
x_mask,y_mask Unclipped mask-relative operation
coordinate
One thing we want to know is what the offset is from the original
operation origin to the clipped origin
Destination drawable relative coordinates of the clipped operation:
x_dest_clipped = extents->x1 - dest->drawable.x
y_dest_clipped = extents->y1 - dest->drawable.y
Offset from the original operation origin:
x_off_clipped = x_dest_clipped - x_dest
y_off_clipped = y_dest_clipped - y_dest
Source drawable relative coordinates of the clipped operation:
x_source_clipped = x_source + x_off_clipped;
y_source_clipped = y_source + y_off_clipped;
Mask drawable relative coordinates of the clipped operation:
x_mask_clipped = x_source + x_off_clipped;
y_mask_clipped = y_source + y_off_clipped;
This is where the original code fails -- it doesn't subtract the
destination drawable location when computing the distance that the
operation has been moved by clipping. Here's what it does when
constructing a temporary source picture:
temp_src =
glamor_convert_gradient_picture(screen, source,
extent->x1 + x_source - x_dest,
extent->y1 + y_source - y_dest,
width, height);
...
x_temp_src = -extent->x1 + x_dest;
y_temp_src = -extent->y1 + y_dest;
glamor_convert_gradient_picture needs source drawable relative
coordinates, but that is not what it's getting; it's getting
screen-relative coordinates for the destination, adjusted by the
distance between the provided source and destination operation
coordinates. We want x_source_clipped and y_source_clipped:
x_source_clipped = x_source + x_off_clipped
= x_source + x_dest_clipped - x_dest
= x_source + extents->x1 - dest->drawable.x -
x_dest
x_temp_src/y_temp_src are supposed to be the coordinates of the original
operation translated to the temporary picture:
x_temp_src = x_source - x_source_clipped;
y_temp_src = y_source - y_source_clipped;
Note that x_source_clipped/y_source_clipped will never be less than
x_source/y_source because all we're doing is clipping. This means that
x_temp_src/y_temp_src will always be non-positive; the original source
coordinate can never be strictly *inside* the temporary image or we
could have made the temporary image smaller.
x_temp_src = x_source - x_source_clipped
= x_source - (x_source + x_off_clipped)
= -x_off_clipped
= x_dest - x_dest_clipped
= x_dest - (extents->x1 - dest->drawable.x)
Again, this is off by the destination origin within the screen
coordinate space.
The code should look like:
temp_src =
glamor_convert_gradient_picture(screen, source,
extent->x1 + x_source - x_dest
- dest->pDrawable->x,
extent->y1 + y_source - y_dest
- dest->pDrawable->y,
width, height);
x_temp_src = -extent->x1 + x_dest + dest->pDrawable->x;
y_temp_src = -extent->y1 + y_dest + dest->pDrawable->y;
Signed-off-by: Keith Packard <kei...@keithp.com>
Reviewed-by: Markus Wick <mar...@selfnet.de>
(cherry picked from commit 55f5bfb578e934319d1308cbb56c900c5ac7cfa7)
Signed-off-by: Julien Cristau <jcris...@debian.org>
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 14ab738..e5d5d2c 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -1450,8 +1450,8 @@ glamor_composite_clipped_region(CARD8 op,
|| source_pixmap->drawable.height != height)))) {
temp_src =
glamor_convert_gradient_picture(screen, source,
- extent->x1 + x_source - x_dest,
- extent->y1 + y_source - y_dest,
+ extent->x1 + x_source - x_dest -
dest->pDrawable->x,
+ extent->y1 + y_source - y_dest -
dest->pDrawable->y,
width, height);
if (!temp_src) {
temp_src = source;
@@ -1459,8 +1459,8 @@ glamor_composite_clipped_region(CARD8 op,
}
temp_src_priv =
glamor_get_pixmap_private((PixmapPtr) (temp_src->pDrawable));
- x_temp_src = -extent->x1 + x_dest;
- y_temp_src = -extent->y1 + y_dest;
+ x_temp_src = -extent->x1 + x_dest + dest->pDrawable->x;
+ y_temp_src = -extent->y1 + y_dest + dest->pDrawable->y;
}
if (mask
@@ -1474,8 +1474,8 @@ glamor_composite_clipped_region(CARD8 op,
* to do reduce one convertion. */
temp_mask =
glamor_convert_gradient_picture(screen, mask,
- extent->x1 + x_mask - x_dest,
- extent->y1 + y_mask - y_dest,
+ extent->x1 + x_mask - x_dest -
dest->pDrawable->x,
+ extent->y1 + y_mask - y_dest -
dest->pDrawable->y,
width, height);
if (!temp_mask) {
temp_mask = mask;
@@ -1483,8 +1483,8 @@ glamor_composite_clipped_region(CARD8 op,
}
temp_mask_priv =
glamor_get_pixmap_private((PixmapPtr) (temp_mask->pDrawable));
- x_temp_mask = -extent->x1 + x_dest;
- y_temp_mask = -extent->y1 + y_dest;
+ x_temp_mask = -extent->x1 + x_dest + dest->pDrawable->x;
+ y_temp_mask = -extent->y1 + y_dest + dest->pDrawable->y;
}
/* Do two-pass PictOpOver componentAlpha, until we enable
* dual source color blending.
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xten6-0000zy...@moszumanska.debian.org
