Before this commit ms_do_pageflip logged a single error for both the
drmmode_bo_import failure path as well as for the queue_flip_on_crtc
path. This commit splits this into 2 separate error logs so that it is
clear what the cause of the flip-failure is.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Currently on present-flip failures we log 2 messages for each failure,
1 from ms_do_pageflip and then another one from ms_present_flip which
is the caller of ms_do_pageflip. This commit adds a log_prefix argument
to ms_do_pageflip so that its log messages can show if it is a DRI2 or
a Present flip which fails and removes the redundant error message from
ms_present_flip.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a modified version of a patch we've been carry-ing in Fedora and
RHEL for years now. This patch automatically adds secondary GPUs to the
master as output sink / offload source making e.g. the use of
slave-outputs just work, with requiring the user to manually run
"xrandr --setprovideroutputsource" before he can hookup an external
monitor to his hybrid graphics laptop.
There is one problem with this patch, which is why it was not upstreamed
before. What to do when a secondary GPU gets detected really is a policy
decission (e.g. one may want to autobind PCI GPUs but not USB ones) and
as such should be under control of the Desktop Environment.
Unconditionally adding autobinding support to the xserver will result
in races between the DE dealing with the hotplug of a secondary GPU
and the server itself dealing with it.
However we've waited for years for any Desktop Environments to actually
start doing some sort of autoconfiguration of secondary GPUs and there
is still not a single DE dealing with this, so I believe that it is
time to upstream this now.
To avoid potential future problems if any DEs get support for doing
secondary GPU configuration themselves, the new autobind functionality
is made optional. Since no DEs currently support doing this themselves it
is enabled by default. When DEs grow support for doing this themselves
they can disable the servers autobinding through the servers cmdline or a
xorg.conf snippet.
Signed-off-by: Dave Airlie <airlied@gmail.com>
[hdegoede@redhat.com: Make configurable, fix with nvidia, submit upstream]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
---
Changes in v2:
-Make the default enabled instead of installing a xorg.conf
snippet which enables it unconditionally
Changes in v3:
-Handle GPUScreen autoconfig in randr/rrprovider.c, looking at
rrScrPriv->provider, rather then in hw/xfree86/modes/xf86Crtc.c
looking at xf86CrtcConfig->provider. This fixes the autoconfig not
working with the nvidia binary driver
As discussed in issue #829 the "mi: Shortcut miDoCopy/miCopyArea based
on clipList" change leads to pointer-trails (area under pointer not
restored when it moves) when using a software cursor.
Checking pGC->pCompositeClip instead of pDstDrawable->clipList fixes
this problem.
Fixes: #829
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The miPointerSpriteFunc swcursor code expects there to only be a single
framebuffer and when the cursor moves it will undo the damage of the
previous draw, potentially overwriting what ever is there in a new
framebuffer installed after a flip.
This leads to all kind of artifacts, so we need to disable pageflipping
when a swcursor is used.
The code for this has shamelessly been copied from the xf86-video-amdgpu
code.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/issues/828
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fix the following compiler warning:
drmmode_display.c: In function ‘drmmode_create_bo’:
drmmode_display.c:1019:9: warning: ISO C90 forbids mixed declarations and code [
1019 | uint32_t num_modifiers;
| ^~~~~~~~
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When the pixmapPrivateKeyRec was moved from a global to being embedded
inside the drmmode_rec these 2 where missed, clean them up.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The modesetting driver (which now often is used with Intel GPUs),
relies on DRI2ScreenInit() to setup the DRI and VDPAU driver names.
Before this commit it would always assign the same name to the 2 names,
but the VDPAU driver for i965 GPUs should be va_gl.
This commit adds a special case for the i965 case, replacing the
VDPAU driver name with "va_gl" if the GPU is using the i965 driver
for DRI.
Note this commit adds a FIXME comment for a related memory leak, that leak
was already present and fixing it falls outside of the scope of this commit.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1413733
Cc: kwizart@gmail.com
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This script generates a header that has a comment containing the build path for
no real reason. As this source can end up deployed on targets in debug packages
this means there is both potentially sensitive information leakage about the
build environment, and a source of change for reproducible builds.
Stop trying to link to a shared library we no longer build
Fixes: commit c1703cdf3b - "xfree86: Link fb statically"
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Building Xwayland without glamor support would raise a warning at build
time:
xwayland.c: In function ‘xwl_screen_init’:
xwayland.c:980:10: warning: unused variable ‘use_eglstreams’
980 | Bool use_eglstreams = FALSE;
| ^~~~~~~~~~~~~~
When building without glamor support, we cannot have EGL Streams support
either, the two being related. So we do not need to declare the variable
`use_eglstreams` if glamor is not enabled.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
When building Xwayland without glamor support enabled using automake,
the build would fail at link time trying to find `glamor_block_handler`:
/usr/bin/ld: xwayland-glx.o: in function `egl_drawable_wait_x':
hw/xwayland/xwayland-glx.c:102: undefined reference to
`glamor_block_handler'
Make sure we don't try to build `xwayland-glx.c` without glamor in the
Xwayland Makefile.
Note: Meson build is fine because it's already build only with glamor
enabled.
Fixes: commit 8469241 - "xwayland: Add EGL-backed GLX provider"
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Both `gbm_bo_create()` and `gbm_bo_create_with_modifiers()` can fail and
return `NULL`.
If that occurs, `xwl_glamor_gbm_create_pixmap()` will not create a
pixmap for the (NULL) GBM bo, but would still try to free the bo which
leads to a crash in mesa:
[...]
#7 <signal handler called>
#8 in gbm_bo_destroy (bo=0x0) at ../src/gbm/main/gbm.c:439
#9 in xwl_glamor_gbm_create_pixmap () at xwayland-glamor-gbm.c:245
#10 in ProcCreatePixmap () at dispatch.c:1440
#11 in Dispatch () at dispatch.c:478
#12 in dix_main () at main.c:276
To avoid the crash, only free the GBM bo if not `NULL`.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Bugzilla: https://bugzilla.redhat.com/1729925
"bool" conflicts with C++ (meh) and stdbool.h (ngh alright fine). This
is a driver-visible change and will likely break the build for mach64,
but it can be fixed by simply using xf86ReturnOptValBool like every
other driver.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Run Cygwin's setup a second time to workaround for it's defective
handling of obsolete packages.
(Specifically, python3-lxml is currently obsoleted by python36-lxml, but
that doesn't get installed on the first run)
mate-terminal apparently requires these to be present to work
We just set them to describe one desktop, for the moment.
It seems we can safely ignore the _NET_WM_DESKTOP property on child
windows, and any _NET_WM_DESKTOP messages, as we only support one
desktop for windows to be on.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
WM_WM_MAP was removed in 52e05b92
Rename WM_WM_MAP2 as WM_WM_MAP_UNMANAGED (meaning an override-redirect
window, which manages it's own activation)
Rename WM_WM_MAP3 as WM_WM_MAP_MANAGED (meaning a normal window, which
is activated when clicked)
There's not really a good way to query this from the wayland server, so
just set the maximum to the X11 protocol limits. While we're at it,
lower the minimum screen size to something implausibly small too, just
in case.
Fixes: xorg/xserver#850
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
<sys/io.h> on ARM hasn't worked for a long, long time, so it was removed
it from glibc upstream.
Remove the include to avoid a compilation failure on ARM with glibc.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/840
Running Xwayland non-rootless and resizing the output would lead to a
crash while trying to update the larger areas of the root window.
Make sure we resize the backing pixmap according to the new output size
to avoid the crash.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/834
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Don't link against fb, it's the driver's responsibility to load that
first. Underlinking like this is unpleasant but this matches what
autotools does.
Fixes: xorg/xserver#540
Copied from Mesa with no modifications.
This update brings in a significant number of new platform ID's.
Syncs with mesa up to commit e334a595e ("intel/icl: Add new ICL
PCI-IDs").
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
This reverts commit ef91da2757.
I thought this couldn't work under any circumstances, but I was wrong,
and drivers are already checking for cases that really cannot work.
Fixes issue #839.
Set a linear gamma ramp. This avoids the xrandr command always warning
'Failed to get size of gamma for output default'
(perhaps we should be using GDI GetDeviceGammaRamp(), if possible?)
Make CRTC report non-zero physical dimensions initially
The rrGetInfo hook is not called for all RANDR requests (e.g.
RRGetOutputInfo), so we must always keep the fake mode information up to
date, rather than doing it lazily in the rrGetInfo hook)
Because we are so bad, most GTK+3 versions treat the output name 'default'
specially, and don't try to use RANDR with it. But versions 3.21.6 to
3.22.24, don't do this, and get badly confused by a CRTC with size 0x0.
See:
https://bugzilla.gnome.org/show_bug.cgi?id=771033https://bugzilla.gnome.org/show_bug.cgi?id=780101
Future work: Rather than reporting a single fake CRTC with a mode matching
the entire virtual display, the fake CRTCs we report should match our
'pseudo-xinerama' monitors
Make QueryMonitor() slightly less insane, making it return TRUE if the
specified monitor exists, rather than always returning TRUE (which we
are uselessly checking, and then also checking if the specified monitor
exists)
(Note that EnumDisplayMonitors() doesn't seem to have meaningful way to
return errors, see 5940580f)
Also: Spamming the long UseMsg() after "Invalid monitor number" isn't very
helpful.
Also: If we are exiting in ddxProcessArgument() due to an error in
options, use a non-zero exit status.
The PresentOptionSuboptimal support code is not optional (once you've
enabled building Present at all), so require a protocol package version
that defines what we need.
Fixes: xorg/xserver#821
Suppose you're in a Hyper-V guest and are trying to use PCI passthrough.
The ID_PATH that udev will construct for that looks something like
"acpi-VMBUS:00-pci-b8c8:00:00.0", and obviously looking for "pci-" in
the first four characters of that is going to not work.
Instead, strstr. I suppose it's possible you could have _multiple_ PCI
buses in the path, in which case you'd want strrstr, if that were a
thing.
Using the existing command line option "-listen" for passing file
descriptors between the Wayland compositor and Xwayland is misleading,
Xwayland should add is own command line option for that specific use.
As XWayland is spawned by the Wayland compositor, we cannot just change
the option, as that would break all existing Wayland compositors using
Xwayland, so we add a new options "-listenfd" and mark the previous one
as deprecated and log a warning, but it still works for backward
compatibility.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/214
Xwayland uses the command line option “-listen” to pass file descriptors
from the Wayland compositor.
That breaks the traditional, documented behavior of the “-listen”
command line option which is to enable a transport type.
Checks if the given option starts with a digit, otherwise treat it as a
regular transport type.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/817
Suggested-by: Rodrigo Exterckötter Tjäder
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
a2rgb10 configs would end up with channel masks corresponding to
argb8888. This would confuse the GLX core code into matching an a2rgb10
config to the root window visual, and that would make things look wrong
and bad.
Fix this by handling more cases. We're still not fully general here, and
this could still be wrong on big-endian. The XXX comment about doing
something less ugly still applies, ideally we would get this information
out of EGL instead of making lucky guesses. Still, better than it was.
Fixes: xorg/xserver#824
Add an option to turn on the use of the X window's alpha channel in
multiwindow mode, i.e. this uses the X window's alpha channel for
compositing into the native desktop.
This works on W7/Vista (using DwmEnableBlurBehindWindow()), and Windows
10 (using the undocumented SetWindowCompositionAttribute()), but not on
Windows 8/8.1
-compositewm must be enabled for this to be useful, as we only have a
pixmap with an alpha channel for the X window in that case. The
framebuffer/root window doesn't have one (unless perhaps you are using
the rootless extension, maybe...).
v2:
Update meson.build
Future work:
A window property to control use of alpha?
Option to turn off blur on W7/Vista
Implement _NET_WM_WINDOW_OPACITY
I think that a major cost in the current implementation is doing a
CreateDIBSection()/DestroyObject() on every refresh. So provide our own
CreatePixmap() instead, which does the CreateDIBSection(), once.
Testcase: glxgears or foobillard with direct swrast
Testcase: scrolling in a full-screen xterm
v2:
Fix handling of RENDER Scratch Pixmaps
(A problem easily shown with gitk or emacs)
v3:
Note that we don't own screen pixmap to release in DestroyPixmap
Log if unimplemented slow-path ever gets hit
Rather than drawing the window contents from the shadow framebuffer, use
Composite extension redirection to cause the server to maintain a bitmap
image of each top-level X window, and draw the window contents from
that, so that window contents which are occluded in the framebuffer show
correctly in the task bar and task switcher previews.
v2:
Fix incorrect use of memset() found by gcc5
hw/xwin/winshadgdi.c: In function ‘winBltExposedWindowRegionShadowGDI’:
hw/xwin/winshadgdi.c:861:9: warning: ‘memset’ used with constant zero length parameter; this could be due to transposed parameters [-Wmemset-transposed-args]
v3:
Turn on -compositewm by default
v4:
Ignore -swcursor if -compositewm
-swcursor is not compatible with -compositewm (because the window
contents are drawn from an off-screen pixmap, not from the screen
pixmap, where the software cursor will be drawn).
v5:
Update meson.build also
Add -compositewm option to help output
Update CI to install prerequisites
