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.
Due to implemtation details on the host side, switching to a multihead
fullscreen mode means multiple mode changes along the way. However,
because rrSetScreenConfig returns before the mode change completes,
we can enter a race, where a subsequent SetDisplayTopology overrides
the current pending one, leading to a mode switch where the resolution
and topology are no longer consistent.
So, we fix this by ignoring any attempts to set the pending topology if
one is already pending.
The X server prunes modes above the initial mode and
the number of default modes varies with distro and
server version. As it's easy to do, let's add a bunch
of useful versions in the driver so that users don't
have to mess with their config files as often.
We have a lot of stale code to 'accelerate' certain operations
through XAA. However, in practice, this acceleration is
completely unhelpful because whenever we encounter an
unaccelerated action, we have to sync and flush the fifo
which kills any performance gain.
As such, the virtual hardware doesn't even advertise these
acceleration capabilities anymore, so the code is completely
unusued.
In addition, XAA is on the way out, so there's no point
leaving in dead code which will have to go in the fairly
near future.
The one operation we can meaningfully accelerate is a
front-only fill and when we get around to implementing
that, we'll use EXA instead.
This change removes the limitation on resizing larger than the
initial size and removes the need for pitch-locking bu resizing
the screen pixmap. Now the only limit on the screen size is
the maximum width/height reported by the virtual hardware which
is configured on the host side.
in xorg.conf. This static configuration will always be used and
any attempts to update it will be ignored.
Note that all xinerama aware apps that I have seen will not
sanity check the xinerama extents against the screen size, so
if the screen doesn't properly enclose the xinerama extents,
expect your apps to punish you accordingly.
