| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Jesse Adkins <jesserayadkins@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
The idea is that the build system assigns this number if needed.
As an example it might be the commit number since the last version tag.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
The segfault occured because the named function was using resources that
were already taken down, because VMWARECloseScreen was called very late
in the CloseScreen callchain.
Make sure we wrap the CloseScreen pointers late in ScreenInit to avoid this.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Silence warnings and errors on various server versions due to incorrect
usage of libc functions.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
When we switch mode we usually alter the size in a constant DPI environment
rather than keeping the size constant and alter the DPI.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
As pointed out by Julien Cristau XORG_RELEASE_VERSION
gives us that info from configure.ac.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
|
|
|
|
|
|
|
|
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=24541 .
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Bump up version numbers.
|
|
Bump up version numbers.
|
|
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.
|
|
Update the modinfo section and make a configure.ac fix.
|
|
Send down the Xinerama topology from the guest down to the host, by setting
display topology registers in the SVGA device.
|
|
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).
|
|
Fix VMWAREUnmapMem to correctly unmap memory for the libpciaccess case.
|
|
|
|
|
|
global symbol collision with the mouse driver.
|
|
|
|
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.
|
|
maxmimum size and add an explicit mode for the hardware
maximum.
|
|
This release adds truely usable resizing support by
removing the restriction that the you cannot resize
larger than the initial mode.
|
|
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.
|
|
|
|
|
|
|
|
older Xorg versions.
|
|
|
|
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.
|
|
the capabilites of the underlying hardware.
|
