The XA version was bumped from 2.3 to 2.4 to signal that there were no
significant correctness or performance regressions when running dri3
compared to dri2 on the vmware driver stack.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
fbGetRotatedPixmap went away with 24bpp support, just treat it as NULL
and we'll do the right thing.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
In some enviroments, "index", "y1" and "y2" are defined globally causing
warnings about shadowed declarations. Fix this.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Some versions of the Gallium loader close our drm file descriptor if
xa_tracker_create() fails (typically 2D VMs.) While this is mostly fixed
everywhere, we implement a workaround to avoid tracking down the same bug
again and again on those setups where this is not fixed in mesa.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
There are a number of compilation warnings caused by const char pointers
being either explicitly or implicitly cast to char pointers. There
are a number of ABI differences that have hindered this so far, but
make a new attempt using the common_compat.h defines.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Compilation on CentOS failed due to some code not being conditioned on
DRI3 headers being present.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Add server-side DRI3 support
Currently DRI3 introduces extra latency with gnome-shell for
the following reasons:
1) We enable GLX_EXT_buffer_age. Causes gnome-shell to post fullscreen damage.
2) We enable GLX_OML_sync_control. Cases additional slowdown.
Not exactly sure why.
Probably we want to implement workarounds in mesa so that we don't enable
these extensions for gnome-shell. That can be done with driconf, using some
trickery.
v2: Verify that sharing an ARGB surface as XRGB works before enabling
DRI3.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
This reverts commit d5550b7f83.
The commit was intended to support video drivers, but has the side effect
that GLX thinks our driver supports more than it does.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Due to following commit in xserver there were
build warnings, as variables now declared const.
d89b42bda46d36fc0879611cc3b3566957ce36d0
e1e01d2e33c632e395d7e396f73fba8ae606b15a
Added a compat header file.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>:q
Add server-side DRI3 support
Currently DRI3 introduces extra latency with gnome-shell for
the following reasons:
1) We enable GLX_EXT_buffer_age. Causes gnome-shell to post fullscreen damage.
2) We enable GLX_OML_sync_control. Cases additional slowdown.
Not exactly sure why.
Probably we want to implement workarounds in mesa so that we don't enable
these extensions for gnome-shell. That can be done with driconf, using some
trickery.
v2: Verify that sharing an ARGB surface as XRGB works before enabling
DRI3.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
This reverts commit d5550b7f83.
The commit was intended to support video drivers, but has the side effect
that GLX thinks our driver supports more than it does.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Support sending multiple driver names and dri2 INFOREC v4.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
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>
