xorg-server: Changes to 'upstream-unstable'
Xext/shm.c | 15 +++++++--------
configure.ac | 4 ++--
dix/devices.c | 2 +-
fb/fbwindow.c | 2 +-
present/present.c | 6 +++---
5 files changed, 14 insertions(+), 15 deletions(-)
New commits:
commit 151ec89574c0d1b4566137d0f2d965ef48f04ec5
Author: Julien Cristau <jcristau@debian.org>
Date: Sun Nov 2 11:21:33 2014 +0100
Bump to 1.16.1.901
diff --git a/configure.ac b/configure.ac
index c556721..3a9a961 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.1, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], xorg-server)
-RELEASE_DATE="2014-09-21"
+AC_INIT([xorg-server], 1.16.1.901, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], xorg-server)
+RELEASE_DATE="2014-11-02"
RELEASE_NAME="Marionberry Pie"
AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_MACRO_DIR([m4])
commit a4d9637504ea4c97ca22d86c9f2e275f5253470d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Oct 16 14:09:08 2014 +0100
Xext/shm: Detach SHM segment after Pixmap is released
The GPU may still have a reference to the SHM segment which would only
be finally released when the Pixmap is destroy. So we can only detach
the SHM segment (and thereby making the memory unaccessible) after the
backend has had a chance to flush any remaining references.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85058
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: gedgon@gmail.com
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 9b29fa957a397664463c7c78fbcc2f34d1993271)
Signed-off-by: Julien Cristau <jcristau@debian.org>
diff --git a/Xext/shm.c b/Xext/shm.c
index 4dad8b6..b787918 100644
--- a/Xext/shm.c
+++ b/Xext/shm.c
@@ -248,21 +248,20 @@ ShmDestroyPixmap(PixmapPtr pPixmap)
{
ScreenPtr pScreen = pPixmap->drawable.pScreen;
ShmScrPrivateRec *screen_priv = ShmGetScreenPriv(pScreen);
+ void *shmdesc = NULL;
Bool ret;
- if (pPixmap->refcnt == 1) {
- ShmDescPtr shmdesc;
-
- shmdesc = (ShmDescPtr) dixLookupPrivate(&pPixmap->devPrivates,
- shmPixmapPrivateKey);
- if (shmdesc)
- ShmDetachSegment((void *) shmdesc, pPixmap->drawable.id);
- }
+ if (pPixmap->refcnt == 1)
+ shmdesc = dixLookupPrivate(&pPixmap->devPrivates, shmPixmapPrivateKey);
pScreen->DestroyPixmap = screen_priv->destroyPixmap;
ret = (*pScreen->DestroyPixmap) (pPixmap);
screen_priv->destroyPixmap = pScreen->DestroyPixmap;
pScreen->DestroyPixmap = ShmDestroyPixmap;
+
+ if (shmdesc)
+ ShmDetachSegment(shmdesc, pPixmap->drawable.id);
+
return ret;
}
commit a7c207cc8e713092c51401baddbb3a30de398a34
Author: Axel Davy <axel.davy@ens.fr>
Date: Wed Oct 29 13:31:42 2014 +0100
Fix present_notify to return right away when querying current or past msc.
When the target msc is past or is the current one, we want to get immediate
feedback. This patch fixes this behaviour.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 882f2d10d99a04a96afc0ce0c8937e16bec3afb5)
Signed-off-by: Julien Cristau <jcristau@debian.org>
diff --git a/present/present.c b/present/present.c
index 4596c4a..cf283f4 100644
--- a/present/present.c
+++ b/present/present.c
@@ -858,7 +858,7 @@ present_pixmap(WindowPtr window,
xorg_list_add(&vblank->event_queue, &present_exec_queue);
vblank->queued = TRUE;
- if (target_msc >= crtc_msc) {
+ if ((pixmap && target_msc >= crtc_msc) || (!pixmap && target_msc > crtc_msc)) {
ret = present_queue_vblank(screen, target_crtc, vblank->event_id, target_msc);
if (ret != Success) {
xorg_list_del(&vblank->event_queue);
@@ -921,7 +921,7 @@ present_notify_msc(WindowPtr window,
0, 0,
NULL,
NULL, NULL,
- 0,
+ PresentOptionAsync,
target_msc, divisor, remainder, NULL, 0);
}
commit 27600a6b2056b8cf6af8b6b0f078164ef36c0767
Author: Axel Davy <axel.davy@ens.fr>
Date: Sat Sep 27 23:17:13 2014 +0200
Fix present_pixmap when using present_notify_msc
Calling present_notify_msc could cancel a pending pixmap presentation.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 9bc01dfc7070a40f5948588895b3a11dd1636d0e)
Signed-off-by: Julien Cristau <jcristau@debian.org>
diff --git a/present/present.c b/present/present.c
index 3aea0d7..4596c4a 100644
--- a/present/present.c
+++ b/present/present.c
@@ -762,7 +762,7 @@ present_pixmap(WindowPtr window,
* in the same frame
*/
- if (!update) {
+ if (!update && pixmap) {
xorg_list_for_each_entry_safe(vblank, tmp, &window_priv->vblank, window_list) {
if (!vblank->pixmap)
commit 0e62f275aa02c5694fd714f3bbd5271836142755
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Mon Aug 4 10:47:03 2014 +1000
xkb: ignore floating slave devices when updating from master (#81885)
Introduced in 45fb3a934dc0db51584aba37c2f9d73deff9191d. When a device is
enabled, the master's locked state is pushed to the slave. If the device is
floating, no master exists and we triggered a NULL-pointer dereference
in XkbPushLockedStateToSlaves.
X.Org Bug 81885 <http://bugs.freedesktop.org/show_bug.cgi?id=81885>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 1e30fc1b99bda040038e4fd56d1b27c686b44c75)
Signed-off-by: Julien Cristau <jcristau@debian.org>
diff --git a/dix/devices.c b/dix/devices.c
index 7f079ff..9e1c546 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -416,7 +416,7 @@ EnableDevice(DeviceIntPtr dev, BOOL sendevent)
XISendDeviceHierarchyEvent(flags);
}
- if (!IsMaster(dev))
+ if (!IsMaster(dev) && !IsFloating(dev))
XkbPushLockedStateToSlaves(GetMaster(dev, MASTER_KEYBOARD), 0, 0);
RecalculateMasterButtons(dev);
commit f7ca20cacfd4e0304d01f29491ae8363fd482279
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Aug 19 15:57:22 2014 -0500
fb: Fix invalid bpp for 24bit depth window
We have a hack in fb layer for a 24bpp screen to use 32bpp images, and
fbCreateWindow() replaces its drawable.bitsPerPixel field
appropriately. But, the problem is that it always replaces when 32bpp
is passed. If the depth is 32, this results in bpp < depth, which is
actually invalid.
Meanwhile, fbCreatePixmap() has a more check and it creates with 24bpp
only when the passed depth <= 24 for avoiding such a problem.
This oneliner patch just adds the similar check in fbCreateWindow().
This (hopefully) fixes the long-standing broken graphics mess of
cirrus KMS with 24bpp.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit fe5018e0564118a7a8198fa286186fdb9ed818c7)
Signed-off-by: Julien Cristau <jcristau@debian.org>
diff --git a/fb/fbwindow.c b/fb/fbwindow.c
index 368c4b8..c90175f 100644
--- a/fb/fbwindow.c
+++ b/fb/fbwindow.c
@@ -33,7 +33,7 @@ fbCreateWindow(WindowPtr pWin)
{
dixSetPrivate(&pWin->devPrivates, fbGetWinPrivateKey(pWin),
fbGetScreenPixmap(pWin->drawable.pScreen));
- if (pWin->drawable.bitsPerPixel == 32)
+ if (pWin->drawable.bitsPerPixel == 32 && pWin->drawable.depth <= 24)
pWin->drawable.bitsPerPixel =
fbGetScreenPrivate(pWin->drawable.pScreen)->win32bpp;
return TRUE;
Reply to: