GitLab

With a 32-bit build, putting the initialized field at the end of the
struct bumped the struct size from 20 bytes to 24, changing the layout
of other structs embedding struct _SyncObject. While this would be
acceptable on master, it caused crashes with 1.20.

Making the initialized field a char and putting it in the hole before
the beingDestroyed field restores the 32-bit ABI as well.

Fixes xorg/xserver#892Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Alex Goins <agoins@nvidia.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Wrong version got committed, but wasn't noticed since it only builds
with meson, not autoconf.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

This fixes 'non-desktop' displays staying powered on after their lease
has been revoked.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111620
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>

In non-rootless mode, not all pixmaps need a wl_buffer backing.

Suggested-by: Twaik Yont (@twaik) in #834
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

The compositor may send DRM_FORMAT_MOD_INVALID instead of a list of
modifiers for various reasons. Handle this gracefully by ignoring it.

Without this, if a compositor would send DRM_FORMAT_MOD_INVALID, it'd
result in empty windows provided by Xwayland.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

Signed-off-by: Martin Weber <martin.weber@secunet.com>

Add an -icon option to set the screen window icon in windowed mode

Allow cygwin paths in an icon-specification

Update man pages and system.XWinrc appropriately

Also, log an error if the icon specified for TRAYICON cannot be loaded

Also, fix a bug in appending a '\' to IconDirectory only if it doesn't
already end with one, which was fortunately benign.

Note: LoadImageComma would be simpler if we just stated that XWinrc
paths are Cygwin paths on Cygwin, Windows paths on MinGW, but that could
break existing .XWinrc files

Note: Given that we can specify paths in an icon-specifier, I'm not sure
what IconDirectory wins us.

v2:
Fix formatting problems in man page additions

v3:
Fix some more s/_/@/g in man pages

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

This FD also triggers the "wait for WM_S0" paths, so that the
compositor may set up a "maintenance line" for Xwayland, for
services that are essential to run before any client (eg. xrdb).
Those services would use this FD, disguised as an extra display
connection.

This -initfd can be seen as a generalization of -wm, a Wayland
compositor may use -initfd to launch its WM and any other clients
that should start up, or it may use -wm as a dedicated connection for
the WM and optionally use -initfd for the misc. startup clients.

If either of -wm or -initfd is passed, Xwayland will expect a selection
notification on WM_S0 before incorporating the FDs in -listen to the
poll list.

Also, correct a minor typo in the listenfd argument output,
give → given.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>

If Xwayland gets to realize a window meant for composition before the
compositor redirected windows (i.e. redirect mode is not RedirectDrawManual
yet), the window would stay "invisible" as we wouldn't create a
wl_surface/wl_shell_surface for it at any later point.

This scenario may happen if the wayland compositor sets up a X11 socket
upfront, but waits to raise Xwayland until there are X11 clients. In this
case the first data on the socket is the client's, the compositor can hardly
beat that in order to redirect subwindows before the client realizes a
Window.

In order to jump across this hurdle, allow the late creation of a matching
(shell) surface for the WindowPtr on SetWindowPixmapProc, so it is ensured
to be created after the compositor set up redirection.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>

This is just called from xwl_window_realize() ATM, but will be useful in
future commits.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>

This will be dissociated in future commits to handle the cases
where windows are being realized before there is a compositor
handling redirection.

In that case, we still want the DamagePtr to be registered upfront
on RealizeWindowProc before a corresponding xwl_window might be
created. Most notably, it cannot be lazily created on
SetWindowPixmapProc as damage accounting gets broken.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>

The previous commit requires wayland-protocols 1.18. Bump DEBIAN_TAG to
re-generate the Debian image and get the wayland-protocols update.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

This adds support for xdg-output-unstable-v1 version 3, added in [1].

This new version deprecates zxdg_output_v1.done and replaces it with
wl_output.done. If the version is high enough, there's no need to wait for both
an xdg_output.done event and a wl_output.done event -- we only care about
wl_output.done.

[1]: wayland/wayland-protocols@962dd535Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>

The atomic driver has issues with modesetting when stealing
connectors from a different crtc, a black screen when doing rotation
on a different crtc, and in general is just a mapping of the legacy
helpers to atomic. This is already done in the kernel, so just
fallback to legacy by default until this is fixed.

Please backport to 1.20, as we don't want to enable it for everyone
there. It breaks for existing users.

The fixes to make the xserver more atomic have been pending on the
mailing list for ages.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110375
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110030
References: xorg/xserver!36 (commits)Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

No functional change, matches meson style.

dix/ is typically not in the include path, and this properly belongs in
include anyway since it's needed from os/ too.

This was a workaround for very old versions of dtrace(1) that didn't
support the -h switch. We no longer support such old OSes.

GLX_EXT_import_context allows multiple clients to share the same
indirect context. If you can't create an indirect context, you're
certainly not going to be able to share one. Hide the extension from the
server string if we've disabled indirect contexts.

This turns piglit's tests from fail to skip when indirect contexts are
disabled. Since GLX_EXT_import_context has been supported in
xfree86-derived servers since day 1 (it was included in the initial GLX
code drop from SGI), this is now also a hint to the client that indirect
contexts are unlikely to work at all.
Reviewed-by: Michel Dänzer <michel@daenzer.net>

Old behavior was to translate the middle mouse button, as well as
every other button that isn't the left or right mouse button,
to act as the middle mouse button (2).

New behavior is to translate only the middle mouse button to 2,
and translate higher-numbered buttons to 8 and higher.
This allows additional mouse buttons to behave under XQuartz
more like they do by default under X11 on other platforms
(e.g. Linux and BSD distributions).
Signed-off-by: Christopher Chavez <chrischavez@gmx.us>

The Render protocol requires this format, but it is wrong to do so. We
are not aware of any hardware with a real 4bpp implementation of this
format. Some GL hardware may have GL_LUMINANCE4_ALPHA4_EXT, and may also
be able to wire L to 1, but that would win you none of memory, quality,
or (likely) performance over A8. Any attempt to use this format is
therefore likely a (painful) software fallback.

Pleasantly (and given the above, unsurprisingly) it seems to be unused
in the wild. None of the major toolkits will try to use it, and
rendercheck does not in fact validate that all of the "standard" picture
formats exist.

Drop the explicit A4 setup from picture format initialization. Note that
the DDXes are not changed and still expose a depth-4 pixmap format, but
we only add picture formats for True/DirectColor-credible depths (i.e.
depth >= 15).

Implements: xorg/proto/xorgproto!1Signed-off-by: Adam Jackson <ajax@redhat.com>

Dynamically added outputs should have their properties
properly updated as well. Otherwise we're left with an output
with many of its propeties not exposed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>

The initialized field was added in:

    commit 82f01ad7
    Author: Alex Goins <agoins@nvidia.com>
    Date:   Wed Apr 10 13:48:02 2019 -0500

        xsync: Add resource inside of SyncCreate, export SyncCreate

But it added this field not at the end of SyncObject. It may not have
been _usefully_ possible to create those from another extension prior to
that commit, but that's still an ABI-incompatible change.

vnd has already verified that the context tag is valid before this gets
called, and we only set the context tag private data to non-null for
indirect clients. Mesa happens to be buggy and doesn't send MakeCurrent
requests nearly as much as it should for direct contexts, but if you fix
that, then unbinding a direct context would fail here with
GLXBadContextTag.

Sadly Mesa will still need to carry a workaround here for broken
servers, but we should still fix the server.

When building Xwayland with neither DRI nor GLamor support enabled with
the Meson build system, the resulting binary would still link against
libdrm and epoxy even though those are not used/needed.

Make sure we require and link against libdrm and epoxy only if needed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

When using the Meson build system, miext/sync would be build only for
dri3.

As a result, when building with Meson without DRI3 enabled, Xwayland
would fail to link because `miSyncShmScreenInit()` is nowhere to be
found.

Make sure to build miext/sync for either DRI3 or Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

Some modules are required in multiple places in the meson file.

Move the actual requirements to the top of the file as a variable so
that updating a version does not require changing the actual value in
multiple places.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

When building Xwayland without neither DRI nor GLamor support enabled
with the autotools build system, the resulting binary would still link
against libdrm and epoxy even though those are not used/needed.

Make sure we require and link against libdrm and epoxy only if needed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

Consider these two facts:

- You can't rely on resource deletion order
- damageDestroyWindow automatically destroys any damage listener
  connected to the doomed window

Now consider a redirected window being destroyed. If the damage
associated with the redirection is destroyed before the window, then
when compFreeClientWindow tries to unredirect the window, the call to
compSetParentPixmap may see that cw->damageRegistered is still true, and
call DamageUnregister(NULL) (because compDestroyDamage already zeroed
out cw->damage), and you get a backtrace that looks like:

    #6  <signal handler called>
    #7  DamageUnregister (pDamage=0x0) at damage.c:1773   <-----------------
    #8  0x000000000051f767 in compSetParentPixmap (pWin=pWin@entry=0x28489c0) at compalloc.c:646
    #9  0x000000000051fa01 in compFreeClientWindow (pWin=0x28489c0, id=<optimized out>) at compalloc.c:291
    #10 0x000000000051a499 in FreeCompositeClientWindow (value=<optimized out>, ccwid=<optimized out>) at compext.c:74
    #11 0x0000000000597932 in doFreeResource (res=0x28494c0, skip=0) at resource.c:880
    #12 0x000000000059850e in FreeResource (id=857, skipDeleteFuncType=skipDeleteFuncType@entry=0) at resource.c:910
    #13 0x000000000051ee01 in compUnredirectWindow (pClient=0x1f6b4e0, pWin=pWin@entry=0x28489c0, update=update@entry=0) at compalloc.c:336
    #14 0x000000000051b723 in compCheckBackingStore (pWin=0x28489c0) at compinit.c:131
    #15 compChangeWindowAttributes (pWin=0x28489c0, mask=<optimized out>) at compinit.c:152
    #16 0x000000000051d1f9 in compDestroyWindow (pWin=0x28489c0) at compwindow.c:664
    #17 0x00000000004d85be in damageDestroyWindow (pWindow=0x28489c0) at damage.c:1570
    #18 0x00000000004896f0 in DbeDestroyWindow (pWin=0x28489c0) at dbe.c:1326
    #19 0x00000000004d229e in present_destroy_window (window=0x28489c0) at present_screen.c:163
    #20 0x000000000059c4e4 in FreeWindowResources (pWin=pWin@entry=0x28489c0) at window.c:1032
    #21 0x000000000059f2c6 in DeleteWindow (value=0x28489c0, wid=<optimized out>) at window.c:1101
    #22 0x0000000000597932 in doFreeResource (res=0x2843bd0, skip=skip@entry=0) at resource.c:880
    #23 0x0000000000598b0c in FreeClientResources (client=client@entry=0x2848560) at resource.c:1146
    #24 0x0000000000572e2f in CloseDownClient (client=0x2848560) at dispatch.c:3473

Fix this by zeroing out more of the CompWindowPtr when the damage is
destroyed, so that any further calls into composite will avoid touching
cw->damage.

All this does is make reproducible builds impossible.

When compiling with link time optimization, GCC thinks it's discovered
undefined behavior:

events.c: In function 'XineramaConfineCursorToWindow':
events.c:609:13: warning: iteration 2147483647 invokes undefined behavior [-Waggressive-loop-optimizations]
events.c:609:11: note: within this loop
events.c:605:49: warning: array subscript -1 is below array bounds of 'struct _Window *[16]' [-Warray-bounds]
events.c:606:31: warning: array subscript -1 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
events.c:610:39: warning: array subscript -2 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
events.c:617:38: warning: array subscript -2 is below array bounds of 'struct _Window *[16]' [-Warray-bounds]
events.c:619:35: warning: array subscript -2 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]

This results from

    i = PanoramiXNumScreens - 1;

    RegionCopy(&pSprite->Reg1, &pSprite->windows[i]->borderSize);
    off_x = screenInfo.screens[i]->x;
    off_y = screenInfo.screens[i]->y;

where GCC believes that PanoramiXNumScreens might be 0. Unfortunately
GCC is just smart enough to be an annoyance because this case is not
actually possible: XineramaConfineCursorToWindow() is only called when
noPanoramiXExtension is false, and if noPanoramiXExtension is false then
PanoramiXNumScreens must be >1 (see PanoramiXExtensionInit()).

So, add an assert(!noPanoramiXExtension), which to my surprise provides
GCC with information even in release builds and lets GCC understand that
the code is not doing anything that is undefined behavior.

I chose this solution instead of the proposed assert(i >= 0) because the
same pattern occurs in CheckVirtualMotion() but is inside an
'if (!noPanoramiXExtension)' and does not generate any warnings.

Fixes: xorg/xserver#590Signed-off-by: Matt Turner <mattst88@gmail.com>

Only log 1 error for consecutive flip failures, instead of filling the
log and the disk with errors for each attempted flip.

Despite our best efforts we may end up with a BO which gets refused
when we try to import it as a framebuffer, see e.g. :
https://bugs.freedesktop.org/show_bug.cgi?id=111306
This should not happen, but as the above bugs shows sometimes it does
and chances are it will happen again.

Note ideally we should check if the import is possible at
ms_present_check_flip time, like the amdgpu code is doing since:
xorg/driver/xf86-video-amdgpu!35
but that requires a chunk of refactoring work on the modesetting driver,
so for now this will have to do.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

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: xorg/xserver#828Reviewed-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>