xserver-xorg-video-vmware: Changes to 'debian-unstable'
ChangeLog | 92 +++++++
README | 553 ------------------------------------------------
configure.ac | 7
debian/changelog | 6
man/vmware.man | 2
src/Makefile.am | 3
src/vmware.c | 10
src/vmware.h | 20 +
src/vmwarectrl.c | 37 ++-
src/vmwarecurs.c | 1
src/vmwaremodes.c | 123 ++++++++++
vmwarectrl/vmwarectrl.c | 6
12 files changed, 286 insertions(+), 574 deletions(-)
New commits:
commit 1f4e1e3f6df64b3a94fb1141c3a4211947d24a99
Author: Brice Goglin <bgoglin@debian.org>
Date: Wed May 13 07:41:51 2009 +0200
Prepare changelog for upload
diff --git a/debian/changelog b/debian/changelog
index 076082c..77bb04f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,8 @@
-xserver-xorg-video-vmware (1:10.16.6-1) UNRELEASED; urgency=low
+xserver-xorg-video-vmware (1:10.16.6-1) unstable; urgency=low
* New upstream release.
- -- Brice Goglin <bgoglin@debian.org> Wed, 13 May 2009 07:41:29 +0200
+ -- Brice Goglin <bgoglin@debian.org> Wed, 13 May 2009 07:41:44 +0200
xserver-xorg-video-vmware (1:10.16.5-3) unstable; urgency=low
commit 2278d0f71c492b1a686842e54a2588db53e88c41
Author: Brice Goglin <bgoglin@debian.org>
Date: Wed May 13 07:41:42 2009 +0200
New upstream release
diff --git a/ChangeLog b/ChangeLog
index 013f5f8..262108a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,95 @@
+commit b4ea3052f843c2d1c285252cbf1bed2f4857f96c
+Author: Philip Langdale <philipl@fido2.homeip.net>
+Date: Tue May 12 16:48:43 2009 -0700
+
+ Bump for 10.16.6 release
+
+commit 8e15f6669ff2cb5bf4260ac87a481a4e38044b26
+Author: Micah Dowty <micah@vmware.com>
+Date: Tue May 12 16:46:39 2009 -0700
+
+ Better cursor size limit and explanation
+
+ Increase the cursor size limit to 64x64, and give a
+ better explanation of the host's cursor size limits.
+
+commit bfa3dfc27b05d4a2deff230f8241bd44f72fb7a0
+Author: Micah Dowty <micah@vmware.com>
+Date: Tue May 12 16:46:00 2009 -0700
+
+ Allow cursor updates while unhidden
+
+ This change just adds a flag to our hardware cursor,
+ telling Xorg that it doesn't need to hide the cursor
+ when updating its shape. This fixes the cursor flicker
+ in X11.
+
+commit dccc9376a4fb1cba9c35b7617989608497fca7be
+Author: Micah Dowty <micah@vmware.com>
+Date: Tue May 12 16:45:29 2009 -0700
+
+ Unbreak vmwarectrl setres
+
+ The vmwarectrl tool's "setres" command was unusable,
+ because it looks like someone added the settopology
+ test without updating the argument indices for setres.
+ This patch makes setres usable again.
+
+commit b7dbdd28764a8f3883833ab818a7b7314632b0b2
+Author: Micah Dowty <micah@vmware.com>
+Date: Tue May 12 16:44:42 2009 -0700
+
+ Fix dynamic mode edge cases
+
+ The VMware Xorg driver supports dynamic modelines that can be set from
+ userspace via an X extension. These are used to implement VM features
+ which need to automatically change the resolution of the guest OS.
+
+ This driver implements the feature using two modelines. The driver
+ would alternately update one mode then the other, so that in typical
+ usage one mode is current and the other is available for the next mode
+ switch.
+
+ This usually worked, but there were many edge cases that could cause
+ this alternating pattern to get 'out of sync', so we'd end up changing
+ the resolution of the current video mode. This could end up putting
+ the X server in a state where the screen resolution has been changed,
+ but the hardware was never reprogrammed for the new resolution.
+
+ This patch fixes the problem by explicitly searching for a dynamic
+ mode that isn't currently in use. We no longer rely on the alternating
+ pattern.
+
+commit cfe8793180ec633dd7a17d059ad882ef461ed1d9
+Author: Micah Dowty <micah@vmware.com>
+Date: Tue May 12 16:43:13 2009 -0700
+
+ Update README
+
+ Updates the copyright date, and replaces the rather out-of-date
+ 2D documentation with a link to the updated 2D and 3D docs on
+ Source Forge.
+
+commit e3769142d80953d6da484eb979f5274c8a3abeb3
+Author: Shelley Gong <shelleygong@vmware.com>
+Date: Thu Apr 16 13:28:47 2009 -0700
+
+ Automatically add modelines for the driver's built-in set of modes.
+
+ The driver has had a built-in set of modes for a while, but there
+ was nothing adding modelines to back them up, causing initial modes
+ to be rejected at startup with certain Xorg versions.
+
+ This change adds the actual modelines for sufficiently new versions
+ of the server (>= 1.2), as the necessary calls were only introduced
+ at that time.
+
+commit 3c223e8f7b03e2d7f8c31faeeeeb37030c461176
+Author: Alan Coopersmith <alan.coopersmith@sun.com>
+Date: Fri Jan 9 16:39:07 2009 -0800
+
+ Remove xorgconfig & xorgcfg from See Also list in man page
+
commit 1bbef3aa7ab15ee93cd4cd47c3d484ac91f0440d
Author: Philip Langdale <philipl@fido2.homeip.net>
Date: Tue Aug 19 11:23:44 2008 -0700
diff --git a/debian/changelog b/debian/changelog
index a250f0b..076082c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+xserver-xorg-video-vmware (1:10.16.6-1) UNRELEASED; urgency=low
+
+ * New upstream release.
+
+ -- Brice Goglin <bgoglin@debian.org> Wed, 13 May 2009 07:41:29 +0200
+
xserver-xorg-video-vmware (1:10.16.5-3) unstable; urgency=low
* Upload to unstable.
commit b4ea3052f843c2d1c285252cbf1bed2f4857f96c
Author: Philip Langdale <philipl@fido2.homeip.net>
Date: Tue May 12 16:48:43 2009 -0700
Bump for 10.16.6 release
diff --git a/configure.ac b/configure.ac
index da14e7b..6afb1fb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@
AC_PREREQ(2.57)
AC_INIT([xf86-video-vmware],
- 10.16.5,
+ 10.16.6,
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
xf86-video-vmware)
diff --git a/src/vmware.c b/src/vmware.c
index 5d29f72..ef2dedb 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 5
+#define VMWARE_PATCHLEVEL 6
#define VMWARE_DRIVER_VERSION \
(VMWARE_MAJOR_VERSION * 65536 + VMWARE_MINOR_VERSION * 256 + VMWARE_PATCHLEVEL)
#define VMWARE_DRIVER_VERSION_STRING \
commit 8e15f6669ff2cb5bf4260ac87a481a4e38044b26
Author: Micah Dowty <micah@vmware.com>
Date: Tue May 12 16:46:39 2009 -0700
Better cursor size limit and explanation
Increase the cursor size limit to 64x64, and give a
better explanation of the host's cursor size limits.
diff --git a/src/vmware.h b/src/vmware.h
index 80393e6..57872b2 100644
--- a/src/vmware.h
+++ b/src/vmware.h
@@ -43,8 +43,14 @@
#include "svga_reg.h"
#include "svga_struct.h"
-/* Arbitrarily choose max cursor dimensions. The emulation doesn't care. */
-#define MAX_CURS 32
+/*
+ * The virtual hardware's cursor limits are pretty big. Some VMware
+ * product versions limit to 1024x1024 pixels, others limit to 128
+ * kilobytes of cursor data. We just choose an arbitrary maximum
+ * cursor size. 64x64 is a common value for real hardware, so we'll go
+ * with that.
+ */
+#define MAX_CURS 64
#define NUM_DYN_MODES 2
commit bfa3dfc27b05d4a2deff230f8241bd44f72fb7a0
Author: Micah Dowty <micah@vmware.com>
Date: Tue May 12 16:46:00 2009 -0700
Allow cursor updates while unhidden
This change just adds a flag to our hardware cursor,
telling Xorg that it doesn't need to hide the cursor
when updating its shape. This fixes the cursor flicker
in X11.
diff --git a/src/vmwarecurs.c b/src/vmwarecurs.c
index ddd98bc..b7c61fa 100644
--- a/src/vmwarecurs.c
+++ b/src/vmwarecurs.c
@@ -290,6 +290,7 @@ vmwareCursorInit(ScreenPtr pScreen)
infoPtr->MaxWidth = MAX_CURS;
infoPtr->MaxHeight = MAX_CURS;
infoPtr->Flags = HARDWARE_CURSOR_BIT_ORDER_MSBFIRST |
+ HARDWARE_CURSOR_UPDATE_UNHIDDEN |
HARDWARE_CURSOR_SOURCE_MASK_NOT_INTERLEAVED;
infoPtr->SetCursorColors = vmwareSetCursorColors;
infoPtr->SetCursorPosition = vmwareSetCursorPosition;
commit dccc9376a4fb1cba9c35b7617989608497fca7be
Author: Micah Dowty <micah@vmware.com>
Date: Tue May 12 16:45:29 2009 -0700
Unbreak vmwarectrl setres
The vmwarectrl tool's "setres" command was unusable,
because it looks like someone added the settopology
test without updating the argument indices for setres.
This patch makes setres usable again.
diff --git a/vmwarectrl/vmwarectrl.c b/vmwarectrl/vmwarectrl.c
index 6c45095..38ded50 100644
--- a/vmwarectrl/vmwarectrl.c
+++ b/vmwarectrl/vmwarectrl.c
@@ -30,7 +30,7 @@ main (int argc, char **argv)
exit(EXIT_FAILURE);
}
- if (argc == 2) {
+ if (argc >= 2) {
if (strcmp(argv[1], "setres") == 0) {
int x, y;
if (argc < 4) {
@@ -38,8 +38,8 @@ main (int argc, char **argv)
exit(EXIT_FAILURE);
}
- x = atoi(argv[1]);
- y = atoi(argv[2]);
+ x = atoi(argv[2]);
+ y = atoi(argv[3]);
if (VMwareCtrl_SetRes(dpy, screen, x, y)) {
printf("Set Res was successful\n");
commit b7dbdd28764a8f3883833ab818a7b7314632b0b2
Author: Micah Dowty <micah@vmware.com>
Date: Tue May 12 16:44:42 2009 -0700
Fix dynamic mode edge cases
The VMware Xorg driver supports dynamic modelines that can be set from
userspace via an X extension. These are used to implement VM features
which need to automatically change the resolution of the guest OS.
This driver implements the feature using two modelines. The driver
would alternately update one mode then the other, so that in typical
usage one mode is current and the other is available for the next mode
switch.
This usually worked, but there were many edge cases that could cause
this alternating pattern to get 'out of sync', so we'd end up changing
the resolution of the current video mode. This could end up putting
the X server in a state where the screen resolution has been changed,
but the hardware was never reprogrammed for the new resolution.
This patch fixes the problem by explicitly searching for a dynamic
mode that isn't currently in use. We no longer rely on the alternating
pattern.
diff --git a/src/vmware.c b/src/vmware.c
index 60a3004..5d29f72 100644
--- a/src/vmware.c
+++ b/src/vmware.c
@@ -1784,8 +1784,7 @@ VMWAREScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
* We will lazily add the dynamic modes as the are needed when new
* modes are requested through the control extension.
*/
- pVMWARE->dynMode1 = NULL;
- pVMWARE->dynMode2 = NULL;
+ memset(&pVMWARE->dynModes, 0, sizeof pVMWARE->dynModes);
#if VMWARE_DRIVER_FUNC
pScrn->DriverFunc = VMWareDriverFunc;
diff --git a/src/vmware.h b/src/vmware.h
index 2b3c119..80393e6 100644
--- a/src/vmware.h
+++ b/src/vmware.h
@@ -46,6 +46,9 @@
/* Arbitrarily choose max cursor dimensions. The emulation doesn't care. */
#define MAX_CURS 32
+#define NUM_DYN_MODES 2
+
+
typedef struct {
CARD32 svga_reg_enable;
CARD32 svga_reg_width;
@@ -94,8 +97,7 @@ typedef struct {
VMWARERegRec SavedReg;
VMWARERegRec ModeReg;
- DisplayModePtr dynMode1;
- DisplayModePtr dynMode2;
+ DisplayModePtr dynModes[NUM_DYN_MODES];
Bool* pvtSema;
diff --git a/src/vmwarectrl.c b/src/vmwarectrl.c
index 24865d6..634b9ca 100644
--- a/src/vmwarectrl.c
+++ b/src/vmwarectrl.c
@@ -116,19 +116,20 @@ VMwareCtrlDoSetRes(ScrnInfoPtr pScrn,
CARD32 y,
Bool resetXinerama)
{
+ int modeIndex;
DisplayModePtr mode;
VMWAREPtr pVMWARE = VMWAREPTR(pScrn);
if (pScrn && pScrn->modes) {
VmwareLog(("DoSetRes: %d %d\n", x, y));
-
+
if (resetXinerama) {
xfree(pVMWARE->xineramaNextState);
pVMWARE->xineramaNextState = NULL;
pVMWARE->xineramaNextNumOutputs = 0;
}
- /*
+ /*
* Don't resize larger than possible but don't
* return an X Error either.
*/
@@ -138,20 +139,30 @@ VMwareCtrlDoSetRes(ScrnInfoPtr pScrn,
}
/*
- * Switch the dynamic modes so that we alternate
- * which one gets updated on each call.
+ * Find an dynamic mode which isn't current, and replace it with
+ * the requested mode. Normally this will cause us to alternate
+ * between two dynamic mode slots, but there are some important
+ * corner cases to consider. For example, adding the same mode
+ * multiple times, adding a mode that we never switch to, or
+ * adding a mode which is a duplicate of a built-in mode. The
+ * best way to handle all of these cases is to directly test the
+ * dynamic mode against the current mode pointer for this
+ * screen.
*/
- mode = pVMWARE->dynMode1;
- pVMWARE->dynMode1 = pVMWARE->dynMode2;
- pVMWARE->dynMode2 = mode;
- /*
- * Initialise the dynamic mode if it hasn't been used before.
- */
- if (!pVMWARE->dynMode1) {
- pVMWARE->dynMode1 = VMWAREAddDisplayMode(pScrn, "DynMode", 1, 1);
+ for (modeIndex = 0; modeIndex < NUM_DYN_MODES; modeIndex++) {
+ /*
+ * Initialise the dynamic mode if it hasn't been used before.
+ */
+ if (!pVMWARE->dynModes[modeIndex]) {
+ pVMWARE->dynModes[modeIndex] = VMWAREAddDisplayMode(pScrn, "DynMode", 1, 1);
+ }
+
+ mode = pVMWARE->dynModes[modeIndex];
+ if (mode != pScrn->currentMode) {
+ break;
+ }
}
- mode = pVMWARE->dynMode1;
mode->HDisplay = x;
mode->VDisplay = y;
commit cfe8793180ec633dd7a17d059ad882ef461ed1d9
Author: Micah Dowty <micah@vmware.com>
Date: Tue May 12 16:43:13 2009 -0700
Update README
Updates the copyright date, and replaces the rather out-of-date
2D documentation with a link to the updated 2D and 3D docs on
Source Forge.
diff --git a/README b/README
index 0ddbbac..fee6788 100644
--- a/README
+++ b/README
@@ -1,555 +1,12 @@
-
-Copyright (C) 1999-2002 VMware, Inc.
+Copyright (C) 1999-2009 VMware, Inc.
All Rights Reserved
The code here may be used/distributed under the terms of the standard
XFree86 license.
+Documentation on the VMware SVGA Device programming model
+has been updated and expanded, and it now lives at:
- VMware SVGA Device Interface and Programming Model
- --------------------------------------------------
-
-
-Include Files
--------------
-
-svga_reg.h
- SVGA register definitions, SVGA capabilities, and FIFO command definitions.
-
-svga_limits.h
- Included by svga_reg.h, defines maximum frame buffer and memory region
- sizes.
-
-svga_modes.h
- A list of default display modes that are built into the driver.
-
-svga_overlay.h
- A list of definitions required for Xv extension support. Included by vmwarevideo.c
-
-svga_escape.h
- A list of definitions for the SVGA Escape commands.
-
-guest_os.h
- Values for the GUEST_ID register.
-
-vm_basic_types.h
- Common type definitions.
-
-vm_device_version.h
- PCI vendor ID's and related information.
-
-vmwarectrl.h
-vmwarectrlproto.h
- The definitions of the VMWARECTRL protocol extension.
-
-Programming the VMware SVGA Device
-----------------------------------
-
-1. Reading/writing a register:
-
- The SVGA registers are addressed by an index/value pair of 32 bit
- registers in the IO address space.
-
- The 0710 VMware SVGA chipset (PCI device ID PCI_DEVICE_ID_VMWARE_SVGA) has
- its index and value ports hardcoded at:
-
- index: SVGA_LEGACY_BASE_PORT + 4 * SVGA_INDEX_PORT
- value: SVGA_LEGACY_BASE_PORT + 4 * SVGA_VALUE_PORT
-
- The 0405 VMware SVGA chipset (PCI device ID PCI_DEVICE_ID_VMWARE_SVGA2)
- determines its index and value ports as a function of the first base
- address register in its PCI configuration space as:
-
- index: <Base Address Register 0> + SVGA_INDEX_PORT
- value: <Base Address Register 0> + SVGA_VALUE_PORT
-
- To read a register:
- Set the index port to the index of the register, using a dword OUT
- Do a dword IN from the value port
-
- To write a register:
- Set the index port to the index of the register, using a dword OUT
- Do a dword OUT to the value port
-
- Example, setting the width to 1024:
-
- mov eax, SVGA_REG_WIDTH
- mov edx, <SVGA Address Port>
- out dx, eax
- mov eax, 1024
- mov edx, <SVGA Value Port>
- out dx, eax
-
-2. Initialization
- Check the version number
- loop:
- Write into SVGA_REG_ID the maximum SVGA_ID_* the driver supports.
- Read from SVGA_REG_ID.
- Check if it is the value you wrote.
- If yes, VMware SVGA device supports it
- If no, decrement SVGA_ID_* and goto loop
- This algorithm converges.
-
- Map the frame buffer and the command FIFO
- Read SVGA_REG_FB_START, SVGA_REG_FB_SIZE, SVGA_REG_MEM_START,
- SVGA_REG_MEM_SIZE.
- Map the frame buffer (FB) and the FIFO memory (MEM)
-
- Get the device capabilities and frame buffer dimensions
- Read SVGA_REG_CAPABILITIES, SVGA_REG_MAX_WIDTH, SVGA_REG_MAX_HEIGHT,
- and SVGA_REG_HOST_BITS_PER_PIXEL / SVGA_REG_BITS_PER_PIXEL.
-
- Note: The capabilities can and do change without the PCI device ID
- changing or the SVGA_REG_ID changing. A driver should always check
- the capabilities register when loading before expecting any
- capabilities-determined feature to be available. See below for a list
- of capabilities as of this writing.
-
- Note: If SVGA_CAP_8BIT_EMULATION is not set, then it is possible that
- SVGA_REG_HOST_BITS_PER_PIXEL does not exist and
- SVGA_REG_BITS_PER_PIXEL should be read instead.
-
- Report the Guest Operating System
- Write SVGA_REG_GUEST_ID with the appropriate value from <guest_os.h>.
- While not required in any way, this is useful information for the
- virtual machine to have available for reporting and sanity checking
- purposes.
-
- SetMode
- Set SVGA_REG_WIDTH, SVGA_REG_HEIGHT, SVGA_REG_BITS_PER_PIXEL
- Read SVGA_REG_FB_OFFSET
- (SVGA_REG_FB_OFFSET is the offset from SVGA_REG_FB_START of the
- visible portion of the frame buffer)
- Read SVGA_REG_BYTES_PER_LINE, SVGA_REG_DEPTH, SVGA_REG_PSEUDOCOLOR,
- SVGA_REG_RED_MASK, SVGA_REG_GREEN_MASK, SVGA_REG_BLUE_MASK
-
- Note: SVGA_REG_BITS_PER_PIXEL is readonly if
- SVGA_CAP_8BIT_EMULATION is not set in the capabilities register. Even
- if it is set, values other than 8 and SVGA_REG_HOST_BITS_PER_PIXEL
- will be ignored.
-
- Enable SVGA
- Set SVGA_REG_ENABLE to 1
- (to disable SVGA, set SVGA_REG_ENABLE to 0. Setting SVGA_REG_ENABLE
- to 0 also enables VGA.)
-
- Initialize the command FIFO
- The FIFO is exclusively dword (32-bit) aligned. The first four
- dwords define the portion of the MEM area that is used for the
- command FIFO. These are values are all in byte offsets from the
- start of the MEM area.
-
- A minimum sized FIFO would have these values:
- mem[SVGA_FIFO_MIN] = 16;
- mem[SVGA_FIFO_MAX] = 16 + (10 * 1024);
- mem[SVGA_FIFO_NEXT_CMD] = 16;
- mem[SVGA_FIFO_STOP] = 16;
-
- Set SVGA_REG_CONFIG_DONE to 1 after these values have been set.
-
- Note: Setting SVGA_REG_CONFIG_DONE to 0 will stop the device from
- reading the FIFO until it is reinitialized and SVGA_REG_CONFIG_DONE is
- set to 1 again.
-
-3. SVGA command FIFO protocol
- The FIFO is empty when SVGA_FIFO_NEXT_CMD == SVGA_FIFO_STOP. The
- driver writes commands to the FIFO starting at the offset specified
- by SVGA_FIFO_NEXT_CMD, and then increments SVGA_FIFO_NEXT_CMD.
-
- The FIFO is full when SVGA_FIFO_NEXT_CMD is one word before SVGA_FIFO_STOP.
-
- When the FIFO becomes full, the FIFO should be sync'd
-
- To sync the FIFO
- Write SVGA_REG_SYNC
- Read SVGA_REG_BUSY
- Wait for the value in SVGA_REG_BUSY to be 0
-
- The FIFO should be sync'd before the driver touches the frame buffer, to
- guarantee that any outstanding BLT's are completed.
-
-4. Cursor
- When SVGA_CAP_CURSOR is set, hardware cursor support is available. In
- practice, SVGA_CAP_CURSOR will only be set when SVGA_CAP_CURSOR_BYPASS is
- also set and drivers supporting a hardware cursor should only worry about
- SVGA_CAP_CURSOR_BYPASS and only use the FIFO to define the cursor. See
- below for more information.
-
-5. Pseudocolor
- When the read-only register SVGA_REG_PSEUDOCOLOR is 1, the device is in a
- colormapped mode whose index width and color width are both SVGA_REG_DEPTH.
- Thus far, 8 is the only depth at which pseudocolor is ever used.
-
- In pseudocolor, the colormap is programmed by writing to the SVGA palette
- registers. These start at SVGA_PALETTE_BASE and are interpreted as
- follows:
-
- SVGA_PALETTE_BASE + 3*n - The nth red component
- SVGA_PALETTE_BASE + 3*n + 1 - The nth green component
- SVGA_PALETTE_BASE + 3*n + 2 - The nth blue component
-
- And n ranges from 0 to ((1<<SVGA_REG_DEPTH) - 1).
-
-
-Drawing to the Screen
----------------------
-
-After initialization, the driver can write directly to the frame buffer. The
-updated frame buffer is not displayed immediately, but only when an update
-command is sent. The update command (SVGA_CMD_UPDATE) defines the rectangle
-in the frame buffer that has been modified by the driver, and causes that
-rectangle to be updated on the screen.
-
-A complete driver can be developed this way. For increased performance,
-additional commands are available to accelerate common operations. The two
-most useful are SVGA_CMD_RECT_FILL and SVGA_CMD_RECT_COPY.
-
-After issuing an accelerated command, the FIFO should be sync'd, as described
-above, before writing to the frame buffer.
-
-Addendum on 7/11/2000
----------------------
-
-SVGA_REG_FB_OFFSET and SVGA_REG_BYTES_PER_LINE may change after SVGA_REG_WIDTH
-or SVGA_REG_HEIGHT is set. Also the VGA registers must be written to after
-setting SVGA_REG_ENABLE to 0 to change the display to a VGA mode.
-
-Addendum on 11/29/2001
----------------------
-
-Actually, after changing any of SVGA_REG_WIDTH, SVGA_REG_HEIGHT, and
-SVGA_REG_BITS_PER_PIXEL, all of the registers listed in the 'SetMode'
-initialization section above should be reread. Additionally, when changing
-modes, it can be convenient to set SVGA_REG_ENABLE to 0, change
-SVGA_REG_WIDTH, SVGA_REG_HEIGHT, and SVGA_REG_BITS_PER_PIXEL (if available),
-and then set SVGA_REG_ENABLE to 1 again.
-
-
-Capabilities
-------------
-
-The capabilities register (SVGA_REG_CAPABILITIES) is an array of bits that
-indicates the capabilities of the SVGA emulation. A driver should check
-SVGA_REG_CAPABILITIES every time it loads before relying on any feature that
-is only optionally available.
-
-Some of the capabilities determine which FIFO commands are available. This
-table shows which capability indicates support for which command.
-
- FIFO Command Capability
- ------------ ----------
-
- SVGA_CMD_RECT_FILL SVGA_CAP_RECT_FILL
- SVGA_CMD_RECT_COPY SVGA_CAP_RECT_COPY
- SVGA_CMD_DEFINE_BITMAP SVGA_CAP_OFFSCREEN
- SVGA_CMD_DEFINE_BITMAP_SCANLINE SVGA_CAP_OFFSCREEN
- SVGA_CMD_DEFINE_PIXMAP SVGA_CAP_OFFSCREEN
- SVGA_CMD_DEFINE_PIXMAP_SCANLINE SVGA_CAP_OFFSCREEN
- SVGA_CMD_RECT_BITMAP_FILL SVGA_CAP_RECT_PAT_FILL
- SVGA_CMD_RECT_PIXMAP_FILL SVGA_CAP_RECT_PAT_FILL
- SVGA_CMD_RECT_BITMAP_COPY SVGA_CAP_RECT_PAT_FILL
- SVGA_CMD_RECT_PIXMAP_COPY SVGA_CAP_RECT_PAT_FILL
- SVGA_CMD_FREE_OBJECT SVGA_CAP_OFFSCREEN
- SVGA_CMD_RECT_ROP_FILL SVGA_CAP_RECT_FILL +
- SVGA_CAP_RASTER_OP
- SVGA_CMD_RECT_ROP_COPY SVGA_CAP_RECT_COPY +
- SVGA_CAP_RASTER_OP
- SVGA_CMD_RECT_ROP_BITMAP_FILL SVGA_CAP_RECT_PAT_FILL +
- SVGA_CAP_RASTER_OP
- SVGA_CMD_RECT_ROP_PIXMAP_FILL SVGA_CAP_RECT_PAT_FILL +
- SVGA_CAP_RASTER_OP
- SVGA_CMD_RECT_ROP_BITMAP_COPY SVGA_CAP_RECT_PAT_FILL +
- SVGA_CAP_RASTER_OP
- SVGA_CMD_RECT_ROP_PIXMAP_COPY SVGA_CAP_RECT_PAT_FILL +
- SVGA_CAP_RASTER_OP
- SVGA_CMD_DEFINE_CURSOR SVGA_CAP_CURSOR
- SVGA_CMD_DISPLAY_CURSOR SVGA_CAP_CURSOR
- SVGA_CMD_MOVE_CURSOR SVGA_CAP_CURSOR
- SVGA_CMD_DEFINE_ALPHA_CURSOR SVGA_CAP_ALPHA_CURSOR
- SVGA_CMD_DRAW_GLYPH SVGA_CAP_GLYPH
- SVGA_CMD_DRAW_GLYPH_CLIPPED SVGA_CAP_GLYPH_CLIPPING
- SVGA_CMD_ESCAPE SVGA_FIFO_CAP_ESCAPE
-
-Note: SVGA_CMD_DISPLAY_CURSOR and SVGA_CMD_MOVE_CURSOR should not be used.
-Drivers wishing hardware cursor support should use cursor bypass (see below).
-
-Other capabilities indicate other functionality as described below:
-
- SVGA_CAP_CURSOR_BYPASS
- The hardware cursor can be drawn via SVGA Registers (without requiring
- the FIFO be synchronized and will be drawn potentially before any
- outstanding unprocessed FIFO commands).
-
- Note: Without SVGA_CAP_CURSOR_BYPASS_2, cursors drawn this way still
- appear in the guest's framebuffer and need to be turned off before any
- save under / overlapping drawing and turned back on after. This can
- cause very noticeable cursor flicker.
-
- SVGA_CAP_CURSOR_BYPASS_2
- Instead of turning the cursor off and back on around any overlapping
- drawing, the driver can write SVGA_CURSOR_ON_REMOVE_FROM_FB and
- SVGA_CURSOR_ON_RESTORE_TO_FB to SVGA_REG_CURSOR_ON. In almost all
- cases these are NOPs and the cursor will be remain visible without
- appearing in the guest framebuffer. In 'direct graphics' modes like
- Linux host fullscreen local displays, however, the cursor will still
- be drawn in the framebuffer, still flicker, and be drawn incorrectly
- if a driver does not use SVGA_CURSOR_ON_REMOVE_FROM_FB / RESTORE_TO_FB.
-
- SVGA_CAP_8BIT_EMULATION
- SVGA_REG_BITS_PER_PIXEL is writable and can be set to either 8 or
- SVGA_REG_HOST_BITS_PER_PIXEL. Otherwise the only SVGA modes available
- inside a virtual machine must match the host's bits per pixel.
-
- Note: Some versions which lack SVGA_CAP_8BIT_EMULATION also lack the
- SVGA_REG_HOST_BITS_PER_PIXEL and a driver should assume
- SVGA_REG_BITS_PER_PIXEL is both read-only and initialized to the only
- available value if SVGA_CAP_8BIT_EMULATION is not set.
-
- SVGA_CAP_OFFSCREEN_1
- SVGA_CMD_RECT_FILL, SVGA_CMD_RECT_COPY, SVGA_CMD_RECT_ROP_FILL,
- SVGA_CMD_RECT_ROP_COPY can operate with a source or destination (or
- both) in offscreen memory.
-
- Usable offscreen memory is a rectangle located below the last scanline
- of the visible memory:
- x1 = 0
- y1 = (SVGA_REG_FB_SIZE + SVGA_REG_BYTES_PER_LINE - 1) /
- SVGA_REG_BYTES_PER_LINE
- x2 = SVGA_REG_BYTES_PER_LINE / SVGA_REG_DEPTH
- y2 = SVGA_REG_VRAM_SIZE / SVGA_REG_BYTES_PER_LINE
-
-
-Cursor Handling
----------------
-
-Starting with GSX Server Beta 3 (after 11/15/2000), hardware cursor support
-was added. Actually, both a hardware cursor via the FIFO (SVGA_CAP_CURSOR)
-and a hardware cursor via the SVGA registers (SVGA_CAP_CURSOR_BYPASS) were
-added. SVGA_CAP_CURSOR was never available without SVGA_CAP_CURSOR_BYPASS and
-the FIFO hardware cursor should never be used and may be removed without
-warning in the future.
-
-Cursor bypass is programmed using the two FIFO commands SVGA_CMD_DEFINE_CURSOR
-and SVGA_CMD_DEFINE_ALPHA_CURSOR in conjunction with the SVGA registers
-SVGA_REG_CURSOR_ID, SVGA_REG_CURSOR_X, SVGA_REG_CURSOR_Y, and
-SVGA_REG_CURSOR_ON.
-
-A driver defines an AND/XOR hardware cursor using SVGA_CMD_DEFINE_CURSOR to
-assign an ID and establish the AND and XOR masks with the hardware. A driver
-uses SVGA_CMD_DEFINE_ALPHA_CURSOR to define a 32 bit mask whose top 8 bits are
-used to blend the cursor image with the pixels it covers. Alpha cursor
-support is only available when SVGA_CAP_ALPHA_CURSOR is set.
-
-Once a cursor is defined, a driver can draw it to the screen at any time by
-writing the SVGA_REG_CURSOR_ID register with the ID used when the cursor was
-defined, writing SVGA_REG_CURSOR_X and SVGA_REG_CURSOR_Y with the location of
-the cursor, and SVGA_CURSOR_ON_SHOW to SVGA_REG_CURSOR_ON. The drawing occurs
-when SVGA_REG_CURSOR_ON is written.
-
-Writing SVGA_CURSOR_ON_HIDE to SVGA_REG_CURSOR_ON will turn the cursor off and
-make it vanish from the display and, if present, from the framebuffer.
-SVGA_CURSOR_ON_REMOVE_FROM_FB will ensure the cursor is not in the
-framebuffer, but will only turn it off if there's no other way to remove it.
-SVGA_CURSOR_ON_RESTORE_TO_FB is the complement to
-SVGA_CURSOR_ON_REMOVE_FROM_FB. Whenever possible, the device will not put the
-cursor in the framebuffer and Remove From / Restore To will be NOPs.
-
-Note: The cursor must be out of the frame buffer before the driver (or any
-agent in the virtual machine) touches an overlapping portion of the frame
-buffer, because it is actually drawn into the frame buffer memory in the
-case of direct graphics mode (e.g. full screen mode on Linux). The cursor
-does not have to be touched before issuing an accelerated command via the
-command FIFO, this case is handled by the SVGA device.
-
-Note: If SVGA_CAP_CURSOR_BYPASS2 is not present, the driver must use
-SVGA_CURSOR_ON_HIDE and SVGA_CURSOR_ON_HIDE to be certain the cursor is out of
-the framebuffer.
-
-
-Driver Version Numbers
-----------------------
-
-The SVGA drivers use the following convention for their version numbers:
-
-Version 10.0 - The first version that uses the FIFO
-Version 10.1 - The version that uses the hardware cursor emulation via the FIFO
-Version 10.2 - The version that uses the cursor that bypasses the FIFO
-Version 10.3 - The version that can also support the 0405 chipset
-Version 10.4 - The version that knows about SVGA_CAP_CURSOR_BYPASS2
-Version 10.5 - [Never released or well defined]
-Version 10.6 - The version that knows about SVGA_CAP_8BIT_EMULATION
-Version 10.7 - The version that knows about SVGA_CAP_ALPHA_CURSOR
-Version 10.8 - The version that knows about SVGA_CAP_GLYPH
-Version 10.9 - The version that knows about SVGA_CAP_OFFSCREEN_1
-
-Note that this is merely the convention used by SVGA drivers written and
-maintained by VMware, Inc. and describes the capabilities of the driver, not
-the virtual hardware. An SVGA driver can only use the intersection of the
-functionality it supports and the functionality available in the virtual SVGA
-hardware.
-
-
-Frequently Asked Questions
---------------------------
-
-1. My driver doesn't display anything, what's going on?
-
-First check if you are issuing an SVGA_CMD_UPDATE after drawing to
-the screen. Another check you can do is to run your driver in full
-screen mode on a Linux host. In this case you are drawing directly
-on the frame buffer, so what you draw to the screen will be immediately
-visible. If nothing is visible in this case, then most likely your
-driver hasn't mapped the frame buffer correctly.
-
-A discrepancy between what you get in full screen mode and what you
-get in window mode indicates that you have a missing or incorrect
-update command.
-
-
-2. What's the difference between bitmaps and pixmaps?
-
-Pixmaps have the same depth as the screen, while bitmaps have depth one.
-When a bitmap is drawn, the command also takes two colors, foreground and
-background. The set bits in the bitmap are replaced with the foreground
-color, and the unset bits are replaced with the background color.
-
-Pixmaps, on the other hand, can be directly copied to the screen.
-
-
-3. What's the significance of the ROP in the commands SVGA_CMD_RECT_ROP_FILL,
-SVGA_CMD_RECT_ROP_BITMAP_COPY, etc. ?
-
-The ROP in the ...ROP... commands is a raster operation. It has the same
-significance (and encoding) as it does in X. The ROP value SVGA_ROP_COPY
-means the source is copied to the destination, which makes these commands the
-same as their non-ROP counterparts. The most commonly used raster operation
-other than copy is probably SVGA_ROP_XOR, which combines the source and
-destination using exclusive-or.
-
-
-4. Tell me more about bitmaps and pixmaps. For example, the macro
-SVGA_CMD_DEFINE_BITMAP has a field <scanlines>. What should this be
-set to? Likewise with SVGA_CMD_DEFINE_PIXMAP. And when should the
-SCANLINE macros be used?
-
-OK, I'll use pixmaps as an example. First you have to define the pixmap:
-
-#define SVGA_CMD_DEFINE_PIXMAP 6
- /* FIFO layout:
- Pixmap ID, Width, Height, Depth, <scanlines> */
-
-The ID is something you choose, which you subsequently use to refer to
-this pixmap. It must be an integer between 0 and SVGA_MAX_ID.
-
-The width and height and depth are the dimensions of the pixmap. For now,
-the depth of the pixmap has to match the depth of the screen.
-
-The scanlines are the pixels that make up the pixmap, arranged one row
-at a time. Each row is required to be 32-bit aligned. The macros
-SVGA_PIXMAP_SCANLINE_SIZE and SVGA_PIXMAP_SIZE give the size of a
-single scanline, and the size of the entire pixmap, respectively, in
-32-bit words.
-
-The second step is to use it:
-
-#define SVGA_CMD_RECT_PIXMAP_FILL 9
- /* FIFO layout:
- Pixmap ID, X, Y, Width, Height */
-
-The ID here is the one you chose when defining the pixmap. X, Y,
-Width, and Height define a rectangle on the screen that is to be filled
-with the pixmap. The pixmap is screen aligned, which means that the
-coordinates in the pixmap are defined by the screen coordinates modulo
-the pixmap dimensions.
-
-If you want a different alignment between the screen and the pixmap,
-then you can use this command, which allows the pixmap coordinates to
-be defined:
-
-#define SVGA_CMD_RECT_PIXMAP_COPY 11
- /* FIFO layout:
- Pixmap ID, Source X, Source Y, Dest X, Dest Y, Width,
- Height */
-
-The Source X and Source Y are pixmap coordinates, and the Dest X and
-Dest Y are screen coordinates.
-
-
-5. OK, now it works briefly, then stops displaying anything. Also,
-my log file is filled with lines like:
- Unknown Command 0xff in SVGA command FIFO
-What's happening?
-
-The most common problem at this point is that the FIFO gets out
-of sync. This can happen if the amount of data in the FIFO doesn't
-match what the VMware SVGA device expects. To track this down, try
-to isolate the particular command which causes the problem.
-
-Another way this can happen is if the wraparound in the FIFO isn't
-done correctly. Here is some example code for writing to the FIFO
-(mem is an array of 32-bit integers that points to the FIFO memory
-region):
-
-while (TRUE) {
- fifo_min = mem[SVGA_FIFO_MIN] / 4;
- fifo_max = mem[SVGA_FIFO_MAX] / 4;
- fifo_next = mem[SVGA_FIFO_NEXT_CMD] / 4;
- fifo_stop = mem[SVGA_FIFO_STOP] / 4;
-
- tmp_next = fifo_next+1;
- if (tmp_next == fifo_max)
- tmp_next = fifo_min; // Wraparound
-
- if (tmp_next == fifo_stop) {
- sync_fifo(); // FIFO full
- continue; // retry
- }
-
- mem[fifo_next] = item;
- mem[SVGA_FIFO_NEXT_CMD] = tmp_next * 4;
- break;
-}
-
-This isn't the most efficient code, but it should work. It's important
-to do the increment with wraparound before the FIFO full check, and to
-check FIFO full before updating the next command pointer.
-
-
-6. My driver tries to switch modes and either nothing happens or the
-display becomes completely garbled. What's going on?
-
-When you change modes, make very sure you reread all of the registers listed
-above under SetMode. Getting the pitch (SVGA_REG_BYTES_PER_LINE) incorrect
-will cause a heavily garbled display. Also, if you change
-SVGA_REG_BITS_PER_PIXEL, make certain that SVGA_CAP_8BIT_EMULATION is present
-in the SVGA_REG_CAPABILITIES register. Also, even with 8 bit emulation, the
-driver must still use either 8 bpp or SVGA_REG_HOST_BITS_PER_PIXEL bpp,
-nothing else.
-
-
-7. Why does my driver's hardware cursor work when my virtual machine is in
-window mode, but draw/erase incorrectly or in garbled locations in fullscreen
-mode?
-
-You need to make sure you use SVGA_CURSOR_ON_REMOVE_FROM_FB and
-SVGA_CURSOR_ON_RESTORE_TO_FB _every_ time your driver or the virtual machine
-touches a region of the framebuffer that overlaps the cursor. If you forget
-to remove it then it can show up when doing save-under operations or get mixed
-in with other drawing. If you forget to restore it then can disappear. You
-also need to make sure SVGA_CAP_CURSOR_BYPASS2 is available, or else you will
-have to use SVGA_CURSOR_ON_SHOW and SVGA_CURSOR_ON_HIDE (which will flicker,
-even in window mode), or else a software cursor. Newer version of the virtual
-SVGA hardware will never put the hardware cursor in the framebuffer while in
-window mode, so everything will appear to work correctly there.
-
-
-8. Why do my accelerated glyphs look funny? OR Why does the fifo complain
-about invalid commands when I draw accelerated glyphs?
-
-The bitmap data passed to SVGA_CMD_DRAW_GLYPH_* must not have any per-scanline
-alignment. If there are any remaining bits left in the last byte of a scanline,
-the first bits of the next scanline should use them.
-
-The bitmap data as a whole must be 4 byte aligned.
+http://vmware-svga.sourceforge.net/
-$XFree86: xc/programs/Xserver/hw/xfree86/drivers/vmware/README,v 1.5 2002/10/16 22:12:53 alanh Exp $
+--
commit e3769142d80953d6da484eb979f5274c8a3abeb3
Author: Shelley Gong <shelleygong@vmware.com>
Date: Thu Apr 16 13:28:47 2009 -0700
Automatically add modelines for the driver's built-in set of modes.
The driver has had a built-in set of modes for a while, but there
was nothing adding modelines to back them up, causing initial modes
to be rejected at startup with certain Xorg versions.
Reply to: