Age | Commit message (Collapse) | Author |
|
This also should fix the build regression introduced with the fix
for this macro.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Fixes multiple instances of these warnings on x86_64:
../../src/vmware.h:180:5: warning: implicit declaration of function 'xf86ScreenToScrn' [-Wimplicit-function-declaration]
../../src/vmware.h:180:5: warning: nested extern declaration of 'xf86ScreenToScrn' [-Wnested-externs]
../../src/vmware.h:180:5: warning: return makes pointer from integer without a cast [enabled by default]
Function `xf86ScreenToScrn' implicitly converted to pointer at ../../src/vmware.h:180
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Robert Hooker <sarvatt@ubuntu.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
This is a port of the vmware driver to the new compat API.
Tested-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
Compile-tested on servers 1.0 through 1.12.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Move things around a bit so the driver compiles with
servers back to Xserver 1.0.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
recent xorg-server
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
The fact that modes were added without names caused segfaults on older
X servers. At least up to and including Xserver 1.4.
Also, for some reason, at least Xserver 1.4 insists on setting the first mode
in the modelist, even if we set another mode as the current one.
Work around this by inserting a new mode with the current screen dimensions,
and add that modename last to the array of display requested mode names.
This means that if none of the previous mode names are found, we will at least
find the newly inserted mode.
Also, if there are no requested mode names at all, the driver previously
chose the largest mode that fit the timings. Now we will, in that case,
always select the newly inserted mode and thus not change resolution unless
specified.
Also add an option to not add this default mode. The option
"AddDefaultMode" is true by default.
Finally when we restore registers at exit and VT switch, make sure we
reprogram the initial width, height and bpp for the next time we start a
server.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
In situations where we have trouble finding a specified mode,
use the resolution given by the width and height device registers.
Signed-off-by: Alan Hourihane <alanh@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Signed-off-by: Jesse Adkins <jesserayadkins@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
this is similar to what xf86_use_hw_cursor() does, which is replaced by
vmwareUseHWCursor (otherwise, the refcount could reach zero and hence the
cursor deallocated while xf86CursorEnableDisableFBAccess() could still bring
it back to life from the saved cursor).
It is probably insane to do refcounting here, but this needs a xserver fix,
and even if that's fixed this fix here shouldn't hurt (though would be
unnecessary).
|
|
|
|
|
|
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.
|
|
Increase the cursor size limit to 64x64, and give a
better explanation of the host's cursor size limits.
|
|
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.
|
|
Push most of the xorg-server version checking into the configure script. With
this change, unmodified driver source compiles in the XFree86 4.3 tree.
|
|
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 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).
|
|
|
|
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.
|
|
With this change, the VMWARE_CTRL extension is updated so that it can
receive topology updates at runtime. I will add some sample client code
separately.
I also intend to add support for a static initial topology defined in
xorg.conf but I haven't got around to it yet due to hating to write
string parsing code.
|
|
is deprecated but support is retained so the driver works with
Workstation 5.5 and friends.
|
|
Lazily allocate the dynamic modes used for pixel precise guest
resizing. They will not appear until they are neeed.
|
|
|
|
|
|
Langdale (plangdale@vmware.com)
|
|
when 8BIT_EMULATION is set. Save/restore the ID register.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|