xserver-xorg-video-vmware: Changes to 'debian-unstable'
ChangeLog | 71 +++++++++++++++++++++++++++++++++++++++++++++++
configure.ac | 2 -
debian/README.source | 73 ++++++++++++++++++++++++++++++++++++++++++++++++
debian/changelog | 7 ++++
debian/control | 2 -
debian/xsfbs/xsfbs.sh | 12 --------
src/vmware.c | 75 +++++++++++++++++++++++++++++++++++++++++++-------
src/vmware.h | 9 ++++++
src/vmwarectrl.c | 50 ++++++++++++++++++++++++++++++++-
9 files changed, 276 insertions(+), 25 deletions(-)
New commits:
commit 20043de576caed60782f641a957eb747cefe60bb
Author: Brice Goglin <bgoglin@debian.org>
Date: Thu Jul 30 00:52:40 2009 +0200
Prepare changelog for upload
diff --git a/debian/changelog b/debian/changelog
index 293963d..e3b5a1e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,9 @@
-xserver-xorg-video-vmware (1:10.16.7-1) UNRELEASED; urgency=low
+xserver-xorg-video-vmware (1:10.16.7-1) unstable; urgency=low
* New upstream release.
* Add README.source, bump Standards-Version to 3.8.2.
- -- Brice Goglin <bgoglin@debian.org> Thu, 30 Jul 2009 00:51:03 +0200
+ -- Brice Goglin <bgoglin@debian.org> Thu, 30 Jul 2009 00:52:36 +0200
xserver-xorg-video-vmware (1:10.16.6-1) unstable; urgency=low
commit 3dbfcf4ed06eeb8cffc3131f84492f2910201509
Author: Brice Goglin <bgoglin@debian.org>
Date: Thu Jul 30 00:51:30 2009 +0200
New upstream release
diff --git a/ChangeLog b/ChangeLog
index 262108a..b609632 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,74 @@
+commit 382c25f53870da0db0ee74f343c20c312e6b03af
+Author: Philip Langdale <philipl@fido2.homeip.net>
+Date: Mon Jul 20 18:03:47 2009 -0700
+
+ Bump for 10.16.7 Release.
+
+commit c2d9678431a40f6a15dc7f50690507cdda8d11e2
+Author: Micah Dowty <micah@vmware.com>
+Date: Mon Jun 1 10:47:51 2009 -0700
+
+ An imperfect fix for Xinerama state changes without a mode change
+
+ This patch improves behaviour for Xinerama state changes (via the
+ VMWARE_CTRL) extension that don't have an accompanying mode change.
+ This will be the case if a new Xinerama monitor layout has a bounding
+ box with an identical size to that of the previous layout.
+
+ Prior to this patch, the behaviour was pretty bad. If you sent two
+ Xinerama states with the same bounding box, the second state would
+ be set as pending but no actual mode change would occur, because
+ the X server would already be in the right video mode. This means
+ that the pending mode stays pending.
+
+ If another Xinerama state comes in after this, we would hit our
+ "Aborting due to existing pending state" error, and the new state
+ would be discarded. This means we'd drop the mode switch on the
+ floor, plus we'd lie to the client and say it worked.
+
+ One example of the user-visible symptoms from this: The user has
+ four monitors of the same size. We'll call them A through D.
+ The VM goes into full-screen mode, and they set it to use screens
+ ABC. Now they switch to BCD. These have the same bounding box size,
+ so no mode change occurs and a topology is still pending. Now they
+ switch to monitors BC. This mode switch is dropped, so the guest
+ is still in the ABC topology and the mode is too wide for BC.
+
+ This patch is an incomplete fix. If we're setting a new topology
+ with the same bounding box, we'll flush the Xinerama state
+ immediately since we know the mode switch will never occur. This
+ means we don't get stuck with xineramaNextState set when it
+ shouldn't be, and we don't have the problem with dropping
+ subsequent mode changes. We also do set the new Xinerama state,
+ so apps that query it will see the updated state immediately.
+
+ But the fix isn't perfect- as far as I can tell, there's no way
+ to notify applications that the monitor layout changed without
+ a mode switch. So even though we've set the new topology, most
+ apps won't notice. There are ways we could hack around this,
+ but none of them are pretty.
+
+commit d10841493c4707f23f928d7580bc5bddb51d22a6
+Author: Bob Long <blong@vmware.com>
+Date: Fri May 22 15:48:55 2009 -0700
+
+ Fix black screen after resume from hibernate.
+
+ The root cause for the black screen and system lock up is
+ caused by not recovering the SVGA ID register after hibernation.
+ Incorrect ID register value will invalidate the FIFO memory start
+ register, and driver will not retrieve correct FIFO memory start
+ address and the busy read of svga FIFO sync register will lock up
+ the whole system.
+
+ Currently SVGA Xorg driver does not have a kernel module to handle
+ the power management event, but Xorg will call driver provided
+ LeaveVT before shutting down system and call EnterVT after resuming
+ system from hibernation, so these two callback functions are good
+ entry points to save and restore the ID register value. This patch
+ saves the ID register value in LeaveVT and restores the value to
+ SVGA ID register in EnterVT.
+
commit b4ea3052f843c2d1c285252cbf1bed2f4857f96c
Author: Philip Langdale <philipl@fido2.homeip.net>
Date: Tue May 12 16:48:43 2009 -0700
diff --git a/debian/changelog b/debian/changelog
index 06f52a7..293963d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,9 @@
-xserver-xorg-video-vmware (1:10.16.6-2) UNRELEASED; urgency=low
+xserver-xorg-video-vmware (1:10.16.7-1) UNRELEASED; urgency=low
+ * New upstream release.
* Add README.source, bump Standards-Version to 3.8.2.
- -- Brice Goglin <bgoglin@debian.org> Thu, 30 Jul 2009 00:49:27 +0200
+ -- Brice Goglin <bgoglin@debian.org> Thu, 30 Jul 2009 00:51:03 +0200
xserver-xorg-video-vmware (1:10.16.6-1) unstable; urgency=low
commit 542f5777ce89c68bb39fe3bab3f828003dec2692
Author: Brice Goglin <bgoglin@debian.org>
Date: Thu Jul 30 00:50:42 2009 +0200
Bump Standards-Version to 3.8.2 now that we have README.source
diff --git a/debian/changelog b/debian/changelog
index 77bb04f..06f52a7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+xserver-xorg-video-vmware (1:10.16.6-2) UNRELEASED; urgency=low
+
+ * Add README.source, bump Standards-Version to 3.8.2.
+
+ -- Brice Goglin <bgoglin@debian.org> Thu, 30 Jul 2009 00:49:27 +0200
+
xserver-xorg-video-vmware (1:10.16.6-1) unstable; urgency=low
* New upstream release.
diff --git a/debian/control b/debian/control
index ef83d71..4ca0923 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,7 @@ Build-Depends:
automake,
libtool,
xutils-dev
-Standards-Version: 3.7.3
+Standards-Version: 3.8.2
Vcs-Git: git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-vmware
Vcs-Browser: http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-vmware.git
commit 382c25f53870da0db0ee74f343c20c312e6b03af
Author: Philip Langdale <philipl@fido2.homeip.net>
Date: Mon Jul 20 18:03:47 2009 -0700
Bump for 10.16.7 Release.
diff --git a/configure.ac b/configure.ac
index 6afb1fb..eb5142e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@
AC_PREREQ(2.57)
AC_INIT([xf86-video-vmware],
- 10.16.6,
+ 10.16.7,
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
xf86-video-vmware)
diff --git a/src/vmware.c b/src/vmware.c
index 5275441..2d1eabd 100644
--- a/src/vmware.c
+++ b/src/vmware.c
@@ -83,7 +83,7 @@ char rcsId_vmware[] =
#define VMWARE_DRIVER_NAME "vmware"
#define VMWARE_MAJOR_VERSION 10
#define VMWARE_MINOR_VERSION 16
-#define VMWARE_PATCHLEVEL 6
+#define VMWARE_PATCHLEVEL 7
#define VMWARE_DRIVER_VERSION \
(VMWARE_MAJOR_VERSION * 65536 + VMWARE_MINOR_VERSION * 256 + VMWARE_PATCHLEVEL)
#define VMWARE_DRIVER_VERSION_STRING \
commit 8f72294ada477f003888b6776883c1dd98289f3f
Author: Julien Cristau <jcristau@debian.org>
Date: Wed Jun 3 03:37:37 2009 +0200
Kill custom readlink function
This was needed for very, very old versions of debianutils.
Closes: #498890
diff --git a/debian/xsfbs/xsfbs.sh b/debian/xsfbs/xsfbs.sh
index 197eb74..781826f 100644
--- a/debian/xsfbs/xsfbs.sh
+++ b/debian/xsfbs/xsfbs.sh
@@ -303,16 +303,6 @@ EOF
fi
}
-# we require a readlink command or shell function
-if ! which readlink > /dev/null 2>&1; then
- message "The readlink command was not found. Please install version" \
- "1.13.1 or later of the debianutils package."
- readlink () {
- # returns what symlink in $1 actually points to
- perl -e '$l = shift; exit 1 unless -l $l; $r = readlink $l; exit 1 unless $r; print "$r\n"' "$1"
- }
-fi
-
check_symlink () {
# syntax: check_symlink symlink
#
commit c2d9678431a40f6a15dc7f50690507cdda8d11e2
Author: Micah Dowty <micah@vmware.com>
Date: Mon Jun 1 10:47:51 2009 -0700
An imperfect fix for Xinerama state changes without a mode change
This patch improves behaviour for Xinerama state changes (via the
VMWARE_CTRL) extension that don't have an accompanying mode change.
This will be the case if a new Xinerama monitor layout has a bounding
box with an identical size to that of the previous layout.
Prior to this patch, the behaviour was pretty bad. If you sent two
Xinerama states with the same bounding box, the second state would
be set as pending but no actual mode change would occur, because
the X server would already be in the right video mode. This means
that the pending mode stays pending.
If another Xinerama state comes in after this, we would hit our
"Aborting due to existing pending state" error, and the new state
would be discarded. This means we'd drop the mode switch on the
floor, plus we'd lie to the client and say it worked.
One example of the user-visible symptoms from this: The user has
four monitors of the same size. We'll call them A through D.
The VM goes into full-screen mode, and they set it to use screens
ABC. Now they switch to BCD. These have the same bounding box size,
so no mode change occurs and a topology is still pending. Now they
switch to monitors BC. This mode switch is dropped, so the guest
is still in the ABC topology and the mode is too wide for BC.
This patch is an incomplete fix. If we're setting a new topology
with the same bounding box, we'll flush the Xinerama state
immediately since we know the mode switch will never occur. This
means we don't get stuck with xineramaNextState set when it
shouldn't be, and we don't have the problem with dropping
subsequent mode changes. We also do set the new Xinerama state,
so apps that query it will see the updated state immediately.
But the fix isn't perfect- as far as I can tell, there's no way
to notify applications that the monitor layout changed without
a mode switch. So even though we've set the new topology, most
apps won't notice. There are ways we could hack around this,
but none of them are pretty.
diff --git a/src/vmware.c b/src/vmware.c
index 069cf2c..5275441 100644
--- a/src/vmware.c
+++ b/src/vmware.c
@@ -306,7 +306,7 @@ vmwareSendSVGACmdUpdate(VMWAREPtr pVMWARE, BoxPtr pBB)
vmwareWriteWordToFIFO(pVMWARE, pBB->y2 - pBB->y1);
}
-static void
+void
vmwareSendSVGACmdUpdateFullScreen(VMWAREPtr pVMWARE)
{
BoxRec BB;
@@ -1163,8 +1163,40 @@ VMWAREModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode, Bool rebuildPixmap)
vgaHWProtect(pScrn, FALSE);
/*
- * XXX -- If we want to check that we got the mode we asked for, this
- * would be a good place.
+ * Push the new Xinerama state to X clients and the hardware,
+ * synchronously with the mode change. Note that this must happen
+ * AFTER we write the new width and height to the hardware
+ * registers, since updating the WIDTH and HEIGHT registers will
+ * reset the device's multimon topology.
+ */
+ vmwareNextXineramaState(pVMWARE);
+
+ return TRUE;
+}
+
+void
+vmwareNextXineramaState(VMWAREPtr pVMWARE)
+{
+ VMWARERegPtr vmwareReg = &pVMWARE->ModeReg;
+
+ /*
+ * Switch to the next Xinerama state (from pVMWARE->xineramaNextState).
+ *
+ * This new state will be available to X clients via the Xinerama
+ * extension, and we push the new state to the virtual hardware,
+ * in order to configure a number of virtual monitors within the
+ * device's framebuffer.
+ *
+ * This function can be called at any time, but it should usually be
+ * called just after a mode switch. This is for two reasons:
+ *
+ * 1) We don't want X clients to see a Xinerama topology and a video
+ * mode that are inconsistent with each other, so we'd like to switch
+ * both at the same time.
+ *
+ * 2) We must set the host's display topology registers after setting
+ * the new video mode, since writes to WIDTH/HEIGHT will reset the
+ * hardware display topology.
*/
/*
@@ -1178,7 +1210,14 @@ VMWAREModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode, Bool rebuildPixmap)
pVMWARE->xineramaNextState = NULL;
pVMWARE->xineramaNextNumOutputs = 0;
+
} else {
+ /*
+ * There is no next state pending. Switch back to
+ * single-monitor mode. This is necessary for resetting the
+ * Xinerama state if we get a mode change which doesn't
+ * follow a VMwareCtrlDoSetTopology call.
+ */
VMWAREXineramaPtr basicState =
(VMWAREXineramaPtr)xcalloc(1, sizeof (VMWAREXineramaRec));
if (basicState) {
@@ -1195,7 +1234,8 @@ VMWAREModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode, Bool rebuildPixmap)
}
/*
- * Update host's view of guest topology.
+ * Update host's view of guest topology. This tells the device
+ * how we're carving up its framebuffer into virtual screens.
*/
if (pVMWARE->vmwareCapability & SVGA_CAP_DISPLAY_TOPOLOGY) {
if (pVMWARE->xinerama) {
@@ -1223,14 +1263,13 @@ VMWAREModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode, Bool rebuildPixmap)
vmwareWriteReg(pVMWARE, SVGA_REG_DISPLAY_IS_PRIMARY, TRUE);
vmwareWriteReg(pVMWARE, SVGA_REG_DISPLAY_POSITION_X, 0);
vmwareWriteReg(pVMWARE, SVGA_REG_DISPLAY_POSITION_Y, 0);
- vmwareWriteReg(pVMWARE, SVGA_REG_DISPLAY_WIDTH, mode->HDisplay);
- vmwareWriteReg(pVMWARE, SVGA_REG_DISPLAY_HEIGHT, mode->VDisplay);
+ vmwareWriteReg(pVMWARE, SVGA_REG_DISPLAY_WIDTH, vmwareReg->svga_reg_width);
+ vmwareWriteReg(pVMWARE, SVGA_REG_DISPLAY_HEIGHT, vmwareReg->svga_reg_height);
}
+ /* Done. */
vmwareWriteReg(pVMWARE, SVGA_REG_DISPLAY_ID, SVGA_INVALID_DISPLAY_ID);
}
-
- return TRUE;
}
static void
@@ -1436,6 +1475,7 @@ VMWAREAddDisplayMode(ScrnInfoPtr pScrn,
DisplayModeRec *mode;
mode = xalloc(sizeof(DisplayModeRec));
+ memset(mode, 0, sizeof *mode);
mode->name = xalloc(strlen(name) + 1);
strcpy(mode->name, name);
diff --git a/src/vmware.h b/src/vmware.h
index b906ff2..a3502dd 100644
--- a/src/vmware.h
+++ b/src/vmware.h
@@ -245,6 +245,10 @@ void vmwareSendSVGACmdUpdate(
VMWAREPtr pVMWARE, BoxPtr pBB
);
+void vmwareSendSVGACmdUpdateFullScreen(
+ VMWAREPtr pVMWARE
+ );
+
DisplayModeRec *VMWAREAddDisplayMode(
ScrnInfoPtr pScrn,
const char *name,
@@ -257,6 +261,10 @@ Bool vmwareIsRegionEqual(
const RegionPtr reg2
);
+void vmwareNextXineramaState(
+ VMWAREPtr pVMWARE
+ );
+
/* vmwarecurs.c */
Bool vmwareCursorInit(
ScreenPtr pScr
diff --git a/src/vmwarectrl.c b/src/vmwarectrl.c
index 634b9ca..d9ceaa4 100644
--- a/src/vmwarectrl.c
+++ b/src/vmwarectrl.c
@@ -282,11 +282,59 @@ VMwareCtrlDoSetTopology(ScrnInfoPtr pScrn,
if (xineramaState) {
memcpy(xineramaState, extents, number * sizeof (VMWAREXineramaRec));
+ /*
+ * Make this the new pending Xinerama state. Normally we'll
+ * wait until the next mode switch in order to synchronously
+ * push this state out to X clients and the virtual hardware.
+ *
+ * However, if we're already in the right video mode, there
+ * will be no mode change. In this case, push it out
+ * immediately.
+ */
xfree(pVMWARE->xineramaNextState);
pVMWARE->xineramaNextState = xineramaState;
pVMWARE->xineramaNextNumOutputs = number;
- return VMwareCtrlDoSetRes(pScrn, maxX, maxY, FALSE);
+ if (maxX == pVMWARE->ModeReg.svga_reg_width &&
+ maxY == pVMWARE->ModeReg.svga_reg_height) {
+
+ /*
+ * XXX:
+ *
+ * There are problems with trying to set a Xinerama state
+ * without a mode switch. The biggest one is that
+ * applications typically won't notice a topology change
+ * that occurs without a mode switch. If you run "xdpyinfo
+ * -ext XINERAMA" after one such topology change, it will
+ * report the new data, but apps (like the GNOME Panel)
+ * will not notice until the next mode change.
+ *
+ * I don't think there's any good solution to this... as
+ * far as I know, even on a non-virtualized machine
+ * there's no way for an app to find out if the Xinerama
+ * opology changes without a resolution change also
+ * occurring. There might be some cheats we can take, like
+ * swithcing to a new mode with the same resolution and a
+ * different (fake) refresh rate, or temporarily switching
+ * to an intermediate mode. Ick.
+ *
+ * The other annoyance here is that when we reprogram the
+ * SVGA device's monitor topology registers, it may
+ * rearrange those monitors on the host's screen, but they
+ * will still have the old contents. This might be
+ * correct, but it isn't guaranteed to match what's on X's
+ * framebuffer at the moment. So we'll send a
+ * full-framebuffer update rect afterwards.
+ */
+
+ vmwareNextXineramaState(pVMWARE);
+ vmwareSendSVGACmdUpdateFullScreen(pVMWARE);
+
+ return TRUE;
+ } else {
+ return VMwareCtrlDoSetRes(pScrn, maxX, maxY, FALSE);
+ }
+
} else {
return FALSE;
}
commit 7deebf983f53c505bc25171ab77fdc408f250a6e
Author: Julien Cristau <jcristau@debian.org>
Date: Tue May 26 15:58:19 2009 +0200
xsfbs: don't run dpkg --print-installation-architecture
This is deprecated in new dpkg, and had no users anyway.
diff --git a/debian/xsfbs/xsfbs.sh b/debian/xsfbs/xsfbs.sh
index 8840ff9..197eb74 100644
--- a/debian/xsfbs/xsfbs.sh
+++ b/debian/xsfbs/xsfbs.sh
@@ -57,8 +57,6 @@ EOF
exit $SHELL_LIB_USAGE_ERROR
fi
-ARCHITECTURE="$(dpkg --print-installation-architecture)"
-
if [ "$1" = "reconfigure" ] || [ -n "$DEBCONF_RECONFIGURE" ]; then
RECONFIGURE="true"
else
commit 4178d948cd66a938222d0d7c6353ee8d60229e40
Author: David Nusinow <dnusinow@debian.org>
Date: Mon May 25 20:08:50 2009 -0400
Add README.source
diff --git a/debian/README.source b/debian/README.source
new file mode 100644
index 0000000..34ab4bf
--- /dev/null
+++ b/debian/README.source
@@ -0,0 +1,73 @@
+------------------------------------------------------
+Quick Guide To Patching This Package For The Impatient
+------------------------------------------------------
+
+1. Make sure you have quilt installed
+2. Unpack the package as usual with "dpkg-source -x"
+3. Run the "patch" target in debian/rules
+4. Create a new patch with "quilt new" (see quilt(1))
+5. Edit all the files you want to include in the patch with "quilt edit"
+ (see quilt(1)).
+6. Write the patch with "quilt refresh" (see quilt(1))
+7. Run the "clean" target in debian/rules
+
+Alternatively, instead of using quilt directly, you can drop the patch in to
+debian/patches and add the name of the patch to debian/patches/series.
+
+------------------------------------
+Guide To The X Strike Force Packages
+------------------------------------
+
+The X Strike Force team maintains X packages in git repositories on
+git.debian.org in the pkg-xorg subdirectory. Most upstream packages
+are actually maintained in git repositories as well, so they often
+just need to be pulled into git.debian.org in a "upstream-*" branch.
+Otherwise, the upstream sources are manually installed in the Debian
+git repository.
+
+The .orig.tar.gz upstream source file could be generated this
+"upstream-*" branch in the Debian git repository but it is actually
+copied from upstream tarballs directly.
+
+Due to X.org being highly modular, packaging all X.org applications
+as their own independent packages would have created too many Debian
+packages. For this reason, some X.org applications have been grouped
+into larger packages: xutils, xutils-dev, x11-apps, x11-session-utils,
+x11-utils, x11-xfs-utils, x11-xkb-utils, x11-xserver-utils.
+Most packages, including the X.org server itself and all libraries
+and drivers are, however maintained independently.
+
+The Debian packaging is added by creating the "debian-*" git branch
+which contains the aforementioned "upstream-*" branch plus the debian/
+repository files.
+When a patch has to be applied to the Debian package, two solutions
+are involved:
+* If the patch is available in one of the upstream branches, it
+ may be git'cherry-picked into the Debian repository. In this
+ case, it appears directly in the .diff.gz.
+* Otherwise, the patch is added to debian/patches/ which is managed
+ with quilt as documented in /usr/share/doc/quilt/README.source.
+
+quilt is actually invoked by the Debian X packaging through a larger
+set of scripts called XSFBS. XSFBS brings some other X specific
+features such as managing dependencies and conflicts due to the video
+and input driver ABIs.
+XSFBS itself is maintained in a separate repository at
+ git://git.debian.org/pkg-xorg/xsfbs.git
+and it is pulled inside the other Debian X repositories when needed.
+
+The XSFBS patching system requires a build dependency on quilt. Also
+a dependency on $(STAMP_DIR)/patch has to be added to debian/rules
+so that the XSFBS patching occurs before the actual build. So the
+very first target of the build (likely the one running autoreconf)
+should depend on $(STAMP_DIR)/patch. It should also not depend on
+anything so that parallel builds are correctly supported (nothing
+should probably run while patching is being done). And finally, the
+clean target should depend on the xsfclean target so that patches
+are unapplied on clean.
+
+When the upstream sources contain some DFSG-nonfree files, they are
+listed in text files in debian/prune/ in the "debian-*" branch of
+the Debian repository. XSFBS' scripts then take care of removing
+these listed files during the build so as to generate a modified
+DFSG-free .orig.tar.gz tarball.
commit d10841493c4707f23f928d7580bc5bddb51d22a6
Author: Bob Long <blong@vmware.com>
Date: Fri May 22 15:48:55 2009 -0700
Fix black screen after resume from hibernate.
The root cause for the black screen and system lock up is
caused by not recovering the SVGA ID register after hibernation.
Incorrect ID register value will invalidate the FIFO memory start
register, and driver will not retrieve correct FIFO memory start
address and the busy read of svga FIFO sync register will lock up
the whole system.
Currently SVGA Xorg driver does not have a kernel module to handle
the power management event, but Xorg will call driver provided
LeaveVT before shutting down system and call EnterVT after resuming
system from hibernation, so these two callback functions are good
entry points to save and restore the ID register value. This patch
saves the ID register value in LeaveVT and restores the value to
SVGA ID register in EnterVT.
diff --git a/src/vmware.c b/src/vmware.c
index ef2dedb..069cf2c 100644
--- a/src/vmware.c
+++ b/src/vmware.c
@@ -652,6 +652,7 @@ VMWAREPreInit(ScrnInfoPtr pScrn, int flags)
"No supported VMware SVGA found (read ID 0x%08x).\n", id);
return FALSE;
}
+ pVMWARE->suspensionSavedRegId = id;
#if !XSERVER_LIBPCIACCESS
pVMWARE->PciTag = pciTag(pVMWARE->PciInfo->bus, pVMWARE->PciInfo->device,
@@ -1820,7 +1821,13 @@ VMWAREEnterVT(int scrnIndex, int flags)
ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
VMWAREPtr pVMWARE = VMWAREPTR(pScrn);
- if (!pVMWARE->SavedReg.svga_fifo_enabled) {
+ /*
+ * After system resumes from hiberation, EnterVT will be called and this
+ * is a good place to restore the SVGA ID register.
+ */
+ vmwareWriteReg(pVMWARE, SVGA_REG_ID, pVMWARE->suspensionSavedRegId);
+
+ if (!pVMWARE->SavedReg.svga_fifo_enabled) {
VMWAREInitFIFO(pScrn);
}
@@ -1831,6 +1838,14 @@ static void
VMWARELeaveVT(int scrnIndex, int flags)
{
ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
+ VMWAREPtr pVMWARE = VMWAREPTR(pScrn);
+
+ /*
+ * Before shutting down system for hibneration, LeaveVT will be called,
+ * we save the ID register value here and later restore it in EnterVT.
+ */
+ pVMWARE->suspensionSavedRegId = vmwareReadReg(pVMWARE, SVGA_REG_ID);
+
VMWARERestore(pScrn);
}
diff --git a/src/vmware.h b/src/vmware.h
index 57872b2..b906ff2 100644
--- a/src/vmware.h
+++ b/src/vmware.h
@@ -102,6 +102,7 @@ typedef struct {
VMWARERegRec SavedReg;
VMWARERegRec ModeReg;
+ CARD32 suspensionSavedRegId;
DisplayModePtr dynModes[NUM_DYN_MODES];
Reply to: