While this may never be an official release, bump minor to enable the
new resolutionKMS functionality. This signals the availability of
autolayout and resolutionKMS support.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Using the vmwgfx ldu backend works just as fine except that we're limited
to implicit layout placement.
With this test on, we may end up in the odd situation that the vmwgfx kernel
module and the vwmare legacy Xorg driver are enabled simultaneously, and that
is an unsupported configuration. It will also break resolutionKMS which will
be enabled based on vmwgfx version but should be disabled since the legacy
Xorg driver runs...
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
While the autolayout feature should really avoid races both with the old
resolutionSet RandR12 code and with new compositor layout code, let's
disable the autolayout feature if someone tries to set the
layout / resolution through the vmwarectrl interface.
That's most likely an old resolutionSet.
Autolayout is turned on on each new screen generation.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
This information is used to switch to software cursors if we have
multiple overlapping explicit outputs and thus might need to display
two cursors simultaneously.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Add a handler that, on hotplug events, scans for a new GUI layout and
tries to set that layout using XRandR similar to what the RandR1.2 part of
vmware tools resolutionSet module is doing today.
v2: Address review comments
- Keep the old layout in case of screen resizing errors
- Fix the vmwgfx_layout handler() declaration.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Update also RandR output properties when we receive hotplug events;
the RRGetInfo function doesn't do this.
This makes sure RandR sends out property change events to clients.
Also remove some debugging printouts.
v2: Address review comment from Sinclair Yeh;
make sure struct output_private::drm_connector is always valid.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Much of this code is borrowed from the xf86-video-modesetting driver.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
If screen targets are enabled and there is a reasonable chance that the vmwgfx
drm driver can use the surface backing a pixmap as a screen target surface,
then make that surface a modesetting framebuffer rather than the corresponding
DMA buffer. In practice this applies when we start scanning out from the
origin (0,0) of the pixmap. However, we would also like to apply the constraint
that the scanout area is the entire pixmap, since that is the constraint used
by the drm driver, but that would currently require drm framebuffer
reallocations and possible flicker, so disable that for now. The drm driver
will correctly handle the possibly oversized surface handed to it anyway, and
the cost we pay for this is an extra hardware copy of the dirtied area when
doing a software update of the scanout.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
1.17 always stores the client clip as a region, so there's no longer a
clientClipType member to look at. Change the code to just inspect
whether the clientClip is non-null, since that works both before and
after 1.17.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
As screens grow larger, attempt to make large Xv video blits cheaper by
performing the color conversion and scaling in two steps:
1) Color conversion which has a 4x4 matrix multiplication shader is performed
to a bounce buffer the size of which is never larger than the source image.
2) Scaling is performed as a src composite blit to the destination image with
a simple copy shader.
This split is done only if the destination image is substantially larger than
the source image / bounce buffer
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Without this the build fails on systems with the latest glibc,
throwing this error:
In file included from /usr/include/string.h:634:0,
from /usr/include/xorg/os.h:53,
from /usr/include/xorg/misc.h:115,
from /usr/include/xorg/screenint.h:50,
from /usr/include/xorg/scrnintstr.h:50,
from /usr/include/xorg/xvdix.h:55,
from /usr/include/xorg/xf86xv.h:32,
from vmwgfx_overlay.c:38:
/usr/include/xorg/os.h:579:1: error: expected identifier or '(' before '__extension__'
strndup(const char *str, size_t n);
This is caused by HAVE_STRNDUP not being set (it is set from xorg-server.h),
causing os.h to redefine it.
Signed-off-by: Stefan Dirsch <sndirsch@suse.de>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Thomas Hellstrom <thellstrom@vmware.com>
We were not clipping the dirty region correctly, Fix this.
Also actually do what the comment in the function says: If there are more than
an ad-hoc number of rectangles to read back, then revert to the default
saa_check_poly_fill_rect function that reads back the whole damage region.
v2: Fix commit log message.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
The saa_check_copy_window could dirty regions that were never touched, since
we were using the X server provided damage region rather than the more
detailed region actually copied. This would have been OK if we had first done
a read-back of the region to be dirtied, but since we want to avoid that,
instead compute the detailed destination region and use that for dirtying.
This fixes rendering glitches seen with motif applications.
v2: Fix whitespace error.
v3: Move dirty region computation.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
This reverts commit 88c487cb19.
While the commit made the rendering artefacts less frequent, they didn't
disappear completely and are likely caused by something else, so revert this
commit.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Acked-by: Sinclair Yeh <syeh@vmware.com>
In a multimon environment, the cursor would sometimes disappear on the
newly enabled screen. Fix this.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
This could cause loops through the list to spin indefinitely.
This would most likely occur at VT switches.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Introduced by commit:
vmware/legacy: Apply same fix to auto colrkey fill
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Introduced by commit
Add support for XSERVER_PLATFORM_BUS
Note that the vmware DriverRec declaration can be cleaned up
considerably using C99 designated initializers. Perhaps something for
the next release...
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
In some situations the fbdev driver may have set this register before legacy
driver startup causing a weird-looking desktop. Make sure this register
is cleared on each modeset.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Introduced in 268307 "Add support for server managed fds"
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Fixed bug where video stopped working on systems that didn't have the new kms
enabled kernel driver installed. Found on CentOS 6.4.
After updating the register header SVGA_VIDEO_NUM_REGS value got upped by two
in order to support GMR and Screen Objects. Since this path is mostly used
on older hosts that may not support them, don't send them at all.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Part of freedesktop.org bugzilla bug #80645
If taking a scanout reference on a pixmap fails, the
struct vmwgfx_screen_entry::pixmap pointer must be set to NULL, otherwise
the driver will incorrectly attempt to remove the scanout reference in the
error path, causing a segfault.
This problem is seen in the above-mentioned bug, but it is not the root
cause of the problem. With this patch applied, the server will terminate
cleanly instead of segfaulting.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
This is a preparation patch for adding support for server managed fds.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
It causes rendering artefacts with some motif applications due to
damage area confusion. Until that is sorted out, temporarily disable the
optimization.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
When storage is attached to pixmaps for the first time the dirty region is
set to cover either the hardware surface or the software buffer based on
the presence of the hardware surface.
However, if the storage was created as part of an accelerated operation,
the dirty region was assigned before the hardware surface was assigned to the
pixmap, causing the dirty region to incorrectly cover the software buffer.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
While XMir does initial mode configuration, it leaves setting initial
modes to the DDX driver.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
In some cases, the X server sends us a composit operation with
mask_pict != NULL, but mask_pix == NULL. Assume there's no mask
involved in that case.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
With option "HwPresents" on, the driver would sometimes change backing
store of active scanout surfaces, making the kernel module refuse to
present. This was caused by scanout surfaces not having the RENDERTARGET flag
on by default. So when rendered to, using copies or composites, they
would be reallocated. Fix this by adding the RENDERTARGET flag from start.
Also add code that prints out an error message when we change backing store
of active scanout surfaces
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Found by Bryan Lee. Later versions of X.org turns dispMode pointers
into const upsetting gcc, turn them into size_t's instead.
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Hardware surfaces are all likely to be shared at some point, and we *really*
don't want to change a hardware surface that is bound as a drm framebuffer.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
A previous commit and the hosted merge unfortunately brought in some build
errors / warnings on early X servers.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Since there is currently no _good_ way to get the surface format of a
prime surface, we block DMA to these surfaces; we don't know if our
software data is compatible with the surface format.
This patch also makes sure that there is a hardware surface backing the
drawable we copy from.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Enable direct dmas instead of using the xa-provided dma functionality.
This saves a bounce-buffer software copy of all dma'd contents.
This also implies that all drawables with mixed software / hardware contents
will use a kernel buffer for software rendering.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Use the hosted infrastructure to add support for XMir.
Helpers go in vmwgfx_saa.c.
v2: Added comments for the helpers, and added a
vmwgfx_flush_dri2 to be executed when coming back from vt switch.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Figure out what's needed both for XMir and XWayland and make a common
driver structure out of it.
v2: Added a lot of comments. No code change.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
