Using common defaults will reduce errors and maintenance.
Only the very small or inexistent custom section need periodic maintenance
when the structure of the component changes. Do not edit defaults.
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.
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.
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.
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.
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.
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.
Fixes bug : http://bugzilla.eng.vmware.com/show_bug.cgi?id=312853
When we added AUTOPAINT_COLORKEY capability to our VMware video driver,
region functions were used to keep track of colorkey painting.
REGION_EQUAL was one of them.
Unfortunately REGION_EQUAL was not present in regionstr.h shipped with XFree86 version
4.3.0.
This version is used by TurboLinux 10; causing X server to crash while playing videos.
REGION_EQUAL was added in revision 1.8 of regionstr.h and available for xfree86 version
4.3.99
onwards.
Reference:
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/include/regionstr.h.diff?r1=1.7&r2=1.8
When I compiled the existing code(without my change), I see a warning was generated
indicating REGION_EQUAL is not present.
Too bad we missed it.
This patch includes
1) Slightly modified version of miRegionEqual from miRegion.c
2) Some formating cleanup.
We recently added XV_AUTOPAINT_COLORKEY attribute to the X video driver
to enable applications like Real player that rely on this attribute to
display video frames in Linux guest.
When this attribute is SET, we paint the colorkey on 1st frame and from
there on only when the video is moved.
This introduced a bug 305202 with clipping.
Consider a case when the video is playing, obscure the player window
with another window, without moving the player window, move the other
window away. The part of the window that was obscured didn't display
the video.
With this patch instead of relying on the target rectangle, we use
the clipBoxes supplied in every frame.
Applications use XV_AUTOPAINT_COLORKEY capability to let the driver handle the painting
of colorkey.
Real Player assumes this capability as ON by default and hence prior to this patch videos
didn't play with Real player.
With this patch:
a) If AUTOPAINT_COLORKEY is SET then the driver handles the painting of the colorkey.
Painting is done on the 1st frame and from there on only if the video frame moves.
b) Adds UYVY fourcc format to keep it consistent with Windows SVGA driver and the host backends.
c) Changes the default colorkey from a pungent GREEN to a darker shade.
Real Player sets this colorkey and it looks better when the video is moved around.
When Kaffeine player stops a video, it sets the cleanup flag to FALSE and may
start playing the next video. In its present state the driver does not check or
clean up the offscreen area. This is a bug as the newer video might need more
offscreen space for its frame. The fix is to check for the offscreen frame size
in videoPlay and restart the stream if necessary.
Move initialization code for the vmware control and xinerama extensions to
VMWAREScreenInit(), so that auto-resize and multi-mon work fine after a user
logs out and logs in again in a graphical display manager.
Major problem was prototype vmwareInitVideo not matching implementation
vmwareVideoInit. Remaining are adding an "ansification" of a function without
arguments, and removing/disabling unused variables/functions.
This change makes the video driver compile with Xorg 7.0. There are a couple of
trivial changes that bring down the maximum Xserver version down to 2.0. Hacky,
but good enough for now.
This patch adds parameters to the source video frame. Applications can request
only a subset of the source video frame to be displayed. These parameters are
srcX, srcY, srcWidth and srcHeight. width and height represent the entire
source video frame.
This patch implements the Xv extension for VMware's X video driver.
The Xv specification can be found here
http://www.xfree86.org/current/DESIGN16.html
I've written a trivial offscreen memory manager that allocates memory from the
bottom part of the Video RAM and it can handle only 1 video-stream. Eventually
we intend to support upto 32 video-streams (there is already support for
multiple video streams in respective backends).
To allow for easier detection of driver version by other VMware tools,
we are embedding the version in a .modinfo section so that the Linux
kernel 'modinfo' tool can be (ab)used to check it.
