commit 1508ea68065b7976dbf56039f9b20dcaf0394431
Author: Adam Jackson <ajax@redhat.com>
Date:   Tue Aug 7 12:26:05 2018 -0400

    xserver 1.20.1
    
    Signed-off-by: Adam Jackson <ajax@redhat.com>

commit 101d15c7634b26eafb3c5f2edb7cafde102ce208
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Jun 26 09:20:00 2018 -0700

    During reset/shutdown, clean up leases in DIX instead of each driver
    
    Instead of having every video driver loop over any pending leases to
    free them during CloseScreen, do this up in the DIX layer by
    terminating leases when a leased CRTC or Output is destroyed and
    (just to make sure), also terminating leases in RRCloseScreen. The
    latter should "never" get invoked as any lease should be associated
    with a resource which was destroyed.
    
    This is required as by the time the driver's CloseScreen function is
    invoked, we've already freed all of the DIX randr structures and no
    longer have any way to reference the leases
    
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960
    Cc: Thomas Hellstrom <thellstrom@vmware.com>
    (cherry picked from commit 1ef7aed3e2bb2af32330f19b1e7560000512ddfe)

commit 9347326d28fffc7534cad0b084539e936aacfd45
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Jul 18 13:22:43 2018 +1000

    Xext: dynamically allocate the PanoramiXDepths[j].vids array
    
    Control flow is:
       PanoramiXMaybeAddDepth() allocates an array size 240 (pDepth->numVisuals)
       PanoramiXMaybeAddVisual() finds up to 270 matches (pScreen->numVisuals)
       and writes those into the previously allocated array.
    
    This caused invalid reads/writes followed by eventually a double-free abort.
    
    Reproduced with xorg-integration-tests server test
    XineramaTest.ScreenCrossing/* (and a bunch of others).
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Keith Packard <keithp@keithp.com>
    (cherry picked from commit 93cafb0828d2e24bd14616df1aa9883fb843dd6c)

commit cbf1ca2dba7bc3561cf1a8023e5e18706adbdba6
Author: emersion <contact@emersion.fr>
Date:   Fri Jul 13 15:51:26 2018 -0400

    xwayland: rotate logical size for RRMode
    
    The logical size is the size of the output in the global compositor
    space. The mode width/height should be scaled as in the logical
    size, but shouldn't be transformed. Thus we need to rotate back
    the logical size to be able to use it as the mode width/height.
    
    This fixes issues with pointer input on transformed outputs.
    
    Signed-Off-By: Simon Ser <contact@emersion.fr>
    Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
    (cherry picked from commit ce2dde9ed0243a18ae18af0879134f7c1afbd700)

commit 18a52a8e16046d8cabea6cf45913bf0b5be07709
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Wed Jul 25 16:33:23 2018 +0200

    xwayland: Enable DRI3 for glamor
    
    glamor_fds_from_pixmap() will bail out early if DRI3 is not enabled,
    unfortunately Xwayland's glamor code would not set it as enabled which
    would lead to blank pixmaps when using texture from pixmap.
    
    Make sure to mark DRI3 as enabled from glamor_egl_screen_init() in
    Xwayland.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107287
    Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    (cherry picked from commit cdec2b3c195d1d080207ef01c55ff14b45370010)

commit c256e31a9eba20da259f31ee70d1c8e1870993f1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 19 14:38:19 2018 +0200

    modesetting: Fix cirrus 24bpp breakage
    
    The recent rewrite of modesetting driver broke the 24bpp support.
    As typically found on cirrus KMS, it leads to a blank screen, spewing
    the error like:
      failed to add fb -22
      (EE) modeset(0): failed to set mode: Invalid argument
    
    The culript is that the wrong bpp value of the front buffer is passed
    to drmModeAddFB().  Fix it by replacing with the back buffer bpp,
    drmmode->kbpp.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Tested-by: Stefan Dirsch <sndirsch@suse.de>
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    (cherry picked from commit d625e16918ef9104863709eb108346464767c444)

commit 2da0bde4498cf4ee422e5a2cb2c53cbbb73df937
Author: Matt Turner <mattst88@gmail.com>
Date:   Tue May 22 21:10:55 2018 -0700

    xfree86: Inline xf86{Read,Write}Mmio{8,16,32} on alpha
    
    In commit 9db2af6f757e (xfree86: Remove xf86{Map,Unmap}VidMem) we
    somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the
    function pointer indirection was intended to support dense vs sparse and
    sparse support is now gone, we can just make the functions static inline
    in compiler.h and avoid all of this.
    
    Bugzilla: https://bugs.gentoo.org/548906
    Tested-by: Christopher May-Townsend <chris@maytownsend.co.uk>
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    (cherry picked from commit 166ac294aefe21a6cfcc0e7a4c9525eef49c2f0c)

commit b9e9eda08bd9198a6d089acd5d50677cd8713b33
Author: Stefan Agner <stefan@agner.ch>
Date:   Thu Dec 22 15:41:06 2016 +0100

    modesetting: Fix 16 bit depth/bpp mode
    
    When setting DefaultDepth to 16 in the Screen section, the current
    code requests a 32 bpp framebuffer, however the X-Server seems to
    assumes 16 bpp.
    
    Fixes commit 21217d02168d ("modesetting: Implement 32->24 bpp
    conversion in shadow update")
    
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    (cherry picked from commit 1c7f34e99ff9750979a03ae20c6be1f2b42c284c)

commit 5c0662d44852363fe258c045250710ed881e56b7
Author: Lyude Paul <lyude@redhat.com>
Date:   Fri Jun 22 12:49:47 2018 -0400

    meson: ensure the libc has RPC functions when secure-rpc is enabled
    
    Currently our meson.build just makes the assumption that the libc is
    going to provide RPC functions. This doesn't actually seem to be the
    case on Fedora, which causes compilation to fail unexpectedly:
    
    ../../Projects/xserver/os/rpcauth.c:47:10: fatal error: rpc/rpc.h: No such file or directory
     #include <rpc/rpc.h>
              ^~~~~~~~~~~
    compilation terminated.
    
    So, in the event that we can't use libtirpc ensure that we actually
    check whether or not the libc provides rpc/rpc.h. If it doesn't, raise
    an error.
    
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    (cherry picked from commit d95a1310ef8e08a93a28f9766d1b4093f7891404)

commit 10285bc36b411edd923ee5d369244647ba2b714b
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Jun 26 16:34:29 2018 -0700

    xf86-video-modesetting: Lease planes as well if using atomic
    
    If we're using atomic modesetting, then we're also using universal
    planes, and so the lease we create needs to include the plane.
    
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Reviewed-by: Daniel Stone <daniels@collabora.com>
    (cherry picked from commit d83efc47b7a524b4f8d4a993c27a3e402a98fa7c)

commit a530198ac0ffdc4c268d13e59079f7583930a284
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Jun 26 14:05:31 2018 -0700

    xf86-video-modesetting: Don't enable UNIVERSAL_PLANES separately
    
    We don't want universal_planes unless we're using atomic APIs for
    modesetting, and the kernel already enables universal_planes
    automatically when atomic is enabled.
    
    If we enable universal_planes when we're not using atomic, then we
    won't have selected a plane for each crtc, and this will break lease
    creation which requires planes for each output when universal_planes
    is enabled.
    
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Reviewed-by: Daniel Stone <daniels@collabora.com>
    (cherry picked from commit 4a11f66e4690f9e94dc61cb264f5ef78dbdb255a)

commit cd7680adccdf8f6905a83ae08cbde7ac76693fe5
Author: Keith Packard <keithp@keithp.com>
Date:   Thu Jun 28 11:45:16 2018 -0700

    xfree86: Wrap RRCrtcIsLeased and RROutputIsLeased to check for DIX structures
    
    Before DIX structures are allocated for crtcs and outputs, we don't
    want to call DIX randr code with NULL pointers. This can happen if the
    driver sets video modes early in server initialization, which Nouveau
    does in zaphod mode.
    
    Cc: thellstrom@vmware.com
    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106772
    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    (cherry picked from commit 2faf4cef8bcf9bb2034a27219a656ea7221afc6c)

commit ebd4cd71f49151fb699cf45e835f3719e6b31bf5
Author: Keith Packard <keithp@keithp.com>
Date:   Thu Jun 28 11:45:15 2018 -0700

    xfree86: Reset randr_crtc and randr_output early in xf86CrtcCloseScreen
    
    The DIX crtc and output structures are freed when their resources are
    destroyed, which happens before CloseScreen is called. As a result, we
    know these pointers are invalid and referencing them during any of the
    remaining CloseScreen sequence will be bad.
    
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Cc: thellstrom@vmware.com
    Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960
    (cherry picked from commit c55a44a9a86aaece17c1a2e73c77e3e665c4888e)

commit 1f169d5b38d93d725029d5f7dc237b558e8bb137
Author: Jon Turney <jon.turney@dronecode.org.uk>
Date:   Sat Jun 30 12:53:35 2018 +0100

    meson: use absolute paths in manpage substitutions
    
    paths returned by get_option('foodir') are potentially relative to prefix
    
    Noticed when comparing manpages generated by a meson build with those
    generated by an autotools build
    
    Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit 49283e238a0ba6051034ae635e5970891f17f9df)

commit bc1882aa23a129c4b72b0bfc132cfd04db801a90
Author: Keith Packard <keithp@keithp.com>
Date:   Thu Jan 18 18:07:29 2018 -0800

    modesetting: Allow a DRM fd to be passed on command line with -masterfd [v2]
    
    This lets an application open a suitable DRM device and pass the file
    descriptor to the mode setting driver through an X server command line
    option, '-masterfd'.
    
    There's a companion application, xlease, which creates a DRM master by
    leasing an output from another X server. That is available at
    
            git clone git://people.freedesktop.org/~keithp/xlease
    
    v2:
            Always print usage, but note that it can't be used if
            setuid/gid
    
            Suggested-by: Lyude Paul <lyude@redhat.com>
    
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    (cherry picked from commit 38ff29ec8ead0a293f50ac52146199babe4205ca)

commit d60ce5b01f5988abc9957473d7175872c8845b08
Author: Laurent Carlier <lordheavym@gmail.com>
Date:   Sat Jun 16 13:00:01 2018 +0200

    meson: Add configuration of listening on tcp, unix and local
    
    bugzilla: https://bugs.kde.org/show_bug.cgi?id=395419
    bugzilla: https://bugs.archlinux.org/task/59025
    
    Signed-off-by: Laurent Carlier <lordheavym@gmail.com>
    Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit 2f39b2a07805194fdd7def30d941666963d6e670)

commit 79795bf9df395001c8d659ac8d28090ea9cefc8d
Author: Lyude Paul <lyude@redhat.com>
Date:   Wed Jun 27 20:29:42 2018 -0400

    modesetting: Fix uninitialized memory usage in drmmode_crtc_get_fb_id()
    
    This really sucked to find out :(
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Karol Herbst <kherbst@redhat.com>
    (cherry picked from commit c41d4ff48f72aa964afd131b59e1538295d062dc)

commit 820ce7cb8bb07018de89e13aa50ae6090f2d84eb
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Wed Jun 20 19:23:48 2018 +0200

    glamor: Work around GEM usage v2
    
    KMS drivers are not required to support GEM. In particular, vmwgfx
    doesn't support flink and handles and names are identical.
    Getting a bo name should really be part of a lower level API, if needed,
    but in the mean time work around this by setting the name identical to
    the handle if GEM isn't supported.
    
    This fixes modesetting driver dri2 on vmwgfx.
    
    Reviewed-by: Deepak Rawat <drawat@vmware.com>
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    (cherry picked from commit 9f02855e7a1b7a3c1e2ee7bfbc73e87c29126920)

commit ba6a9283817254dca90fd8f9ee695504e7c20908
Author: Lyude Paul <lyude@redhat.com>
Date:   Wed Jun 20 19:12:32 2018 -0400

    randr: Scream when creating a shared pixmap fails
    
    This seems like a problem worth screaming about.
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    (cherry picked from commit dc90b1c3c328f1d0b022a234b69ef32bda7ccb01)

commit 91ec6245d6269a88a3f3ecd10fa7a7b326b0a616
Author: Lyude Paul <lyude@redhat.com>
Date:   Wed Jun 20 19:12:31 2018 -0400

    glamor: Unbreak glamor_fd_from_pixmap()
    
    When support for allocating GBM BOs with modifiers was added,
    glamor_fd_from_pixmap() was changed so that it would return an error if
    it got a bo with modifiers set from glamor_fds_from_pixmap(). The
    problem is that on systems that support BOs with modifiers,
    glamor_fds_from_pixmap() will always return BOs with modifiers.
    
    This means that glamor_fd_from_pixmap() was broken entirely, which broke
    a number of other things including glamor_shareable_fd_from_pixmap(),
    which meant that modesetting using multiple GPUs with the modesetting
    DDX was also broken. Easy reproducer:
    
    - Find a laptop with DRI prime that has outputs connected to the
      dedicated GPU and integrated GPU
    - Try to enable one display on each using the modesetting DDX
    - Fail
    
    Since there isn't a way to ask for no modifiers from
    glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap()
    function used by both glamor_fds_from_pixmap() and
    glamor_fd_from_pixmap() that calls down to the appropriate
    glamor_egl_fd*_from_pixmap() function.
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
    Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
    (cherry picked from commit 186a21c4bac744ffe645c8d1a6dda2d41c6d33d8)

commit 821f38fa56087fcb11d2d2483366307fc88bf365
Author: Lyude Paul <lyude@redhat.com>
Date:   Thu Jun 7 20:30:34 2018 -0400

    modesetting: Also disable CRTC in drmmode_output_disable()
    
    So, this did actually work on older kernels at one point in time,
    however it seems that this working was a result of some of the Linux
    kernel's atomic modesetting helpers not preserving the CRTC's enabled
    state in the right spots. This was fixed in:
    
    846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2")
    
    As a result, atomic commits which simply disassociate a DRM connector
    with it's CRTC while leaving the CRTC in an enabled state aren't enough
    to disable the CRTC, and result in the atomic commit failing. This
    currently can cause issues with MST hotplugging where X will end up
    failing to disable the MST outputs after they've left the system. A
    simple reproducer:
    
    - Start up Xorg
    - Connect an MST hub with displays connected to it
    - Remove the hub
    - Now there should be CRTCs stuck on the orphaned MST connectors, and X
      won't be able to reclaim them.
    
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    (cherry picked from commit c12f1bd4b76088ea66e3bec9ab9721a52b20cdf2)

commit 2f4d0d84266b82d8838b8b9b7972f45d66f0e2d1
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Fri Jun 15 08:57:12 2018 +0200

    modesetting: use drmmode_bo_import() for rotate_fb
    
    drmmode_shadow_allocate() still uses drmModeAddFB() which may fail if
    the format is not as expected, preventing from using a rotated output.
    
    Change it to use the new function drmmode_bo_import() which takes care
    of calling the drmModeAddFB2() API.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106715
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Tested-by: Tomas Pelka <tpelka@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    (cherry picked from commit a85e94a50c94b07574c8701a3ff3c1243f4257f4)

commit 394ed02f8761c7599fa08628a4d28d34337028f6
Author: John Lumby <johnlumby@hotmail.com>
Date:   Tue Jun 26 17:14:34 2018 -0700

    Change the DPMS initialization to be conditional on not set from config
    
    Any DPMS timeout values set in ServerFlags section of the xorg.conf
    are being overwritten by DPMS extension initialization.  Therefore
    change the DPMS initialization of timeout values to be conditional on
    not set from config.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106963
    Signed-off-by: John Lumby <johnlumby@hotmail.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    (cherry picked from commit f5aace7a27d6d61068dcae46c9756b669ab51d50)

commit 8c2f0f8cbdba04f3d2eb65e3ea98f809545f8e87
Author: Damien Leone <dleone@nvidia.com>
Date:   Mon Jun 18 16:24:28 2018 -0700

    os: Recompute whether any clients are ready after check_timers()
    
    If a driver calls AttendClient() from within a timer callback we
    need to re-compute the local 'are_ready' to prevent the attended
    client from waiting until WaitForSomething() times out.
    
    This is a fix similar to commit 9ed5b263.
    
    Signed-off-by: Damien Leone <dleone@nvidia.com>
    Reviewed-by: Keith Packard <keithp@keithp.com>
    (cherry picked from commit f33cb4264387ed14a586ba080885b4d21e4aa48b)

commit 180ab06d4564579cf05cb44c2533ac914b68be77
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Jun 11 09:21:08 2018 +0200

    xwayland: mandatory EGL backend API
    
    The API init_wl_registry() and has_wl_interfaces() are marked as being
    optional, but both GBM And EGLStream backends implement them so there is
    point in keeping those optional.
    
    Suggested-by: Emil Velikov <emil.velikov@collabora.com>
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    (cherry picked from commit 92daeb31fa3235dc791e0444b072ec4bbc6e35ab)

commit c641d10ef04475f2898cc40536bd5a03371f2761
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Jun 11 09:13:30 2018 +0200

    xwayland: simplify xwl_glamor_pixmap_get_wl_buffer()
    
    When retrieving the Wayland buffer from a pixmap, if the buffer already
    exists, the GBM backend will return that existing buffer.
    
    However, as seen with the Present issues, if the call had previously
    passed a wrong size, that buffer will remain at the wrong size for as
    long as the buffer exists, which is error prone.
    
    Considering that the width/height passed to get_wl_buffer() is always the
    actual pixmap  drawable size, and considering that the EGLStream backend
    makes no use of the size either, there is really no point in passing the
    width/height around.
    
    Simplify the xwl_glamor_pixmap_get_wl_buffer() and EGL backends API by
    removing the pixmap size, and use the drawable size instead.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    (cherry picked from commit 792359057bd54548555674d2d309c0cfeebac12d)

commit 79ebd7f689492314067fc863510ad44683b67e64
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:38:45 2018 +0200

    xwayland: EGL_IMG_context_priority required by EGLStream
    
    xwl_glamor_eglstream_init_egl() uses "EGL_IMG_context_priority"
    extension, make sure it's actually available before using it.
    
    Suggested-by: Emil Velikov <emil.velikov@collabora.com>
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit bdadaa25f5c1f62d30d8e76b4ebfcef414ed9c90)

commit 81969ab773ddf7bae04eb7d1cca3fe01344dcae9
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:38:44 2018 +0200

    xwayland: check for EGLStream backend explicitly
    
    Now that we have separate backends for EGLStream and GBM, we can
    explicitly check for the EGLStream backend to disable present support
    in that case.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit 5d843f6947538dabde258584a5795e0b25ea8779)

commit 60020989b9759a05153f832a160e6f573d53e266
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:38:43 2018 +0200

    xwayland: refactor EGL backends for wayland registry
    
    To be able to check for availability of the Wayland interfaces required
    to run a given EGL backend (either GBM or EGLStream for now), we need
    to have each backend structures and vfuncs in place before we enter the
    Wayland registry dance.
    
    That basically means that we should init all backends at first, connect
    to the Wayland compositor and query the available interfaces and then
    decide which backend is available and should be used (or none if either
    the Wayland interfaces or the EGL extensions are not available).
    
    For this purpose, hold an egl_backend struct for each backend we are to
    consider prior to connect to the Wayland display so that, when we get to
    query the Wayland interfaces, everything is in place for each backend to
    handle the various Wayland interfaces.
    
    Eventually, when we need to chose which EGL backend to use for glamor,
    the available Wayland interfaces and EGL extensions available are all
    known to Xwayland.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit d7185a84b60ed03aaa84eb522dcff365218e7211)

commit cb698ec2ba11b827c4e6785693a83a27eec3c635
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:38:42 2018 +0200

    xwayland: move EGL backend init to glamor
    
    Move EGL backends initialization to its own function in
    xwayland-glamor.c
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit 48f037a27c45b571c9750ac812977ac0a33ab12b)

commit 8ffee3a6bd8901b4c87890087b8bd2ccb4a30a5c
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:38:41 2018 +0200

    xwayland: Add Wayland interfaces check
    
    Introduces a new egl_backend function to let the EGL backend check for
    the presence of the required Wayland interfaces.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit f2fcb4877e976d078b0eb4755177170467341484)

commit aad1525180c0352ab9ea22c35405226b3afa69cc
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:38:40 2018 +0200

    xwayland: move egl_backend to its own struct
    
    EGL backend availability requires both EGL extensions and Wayland
    interfaces to be present, so we will need to consider multiple backends
    during initialization.
    
    As a preliminary work, move the egl_backend to its own struct so that we
    can have more than one backend at any given time.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit b74b0f18b8d3032317e38453ee63ae9efd33a098)

commit 831f7194b7006da14424da219661373e7d49114a
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:38:39 2018 +0200

    xwayland: skip drm authentication with render node
    
    If using a render node, we can skip DRM authentication.
    
    Suggested-by: Emil Velikov <emil.velikov@collabora.com>
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit de004eefc60ec595f5d6d81658468e082f8df930)

commit 60eda2af0acd54e05ab794947f106f8f2d421e90
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:38:38 2018 +0200

    xwayland: GBM should fail w/out "GL_OES_EGL_image"
    
    Surely, we should fail to init GBM backend if "GL_OES_EGL_image" is
    missing.
    
    This seems to have been lost with commit 1545e2dba ("xwayland: Decouple
    GBM from glamor").
    
    Suggested-by: Emil Velikov <emil.velikov@collabora.com>
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit b823b43dca143810146f563d09e8996058b9d09e)

commit f8e96b22bfac0733328fb9902c151003db5cc724
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:38:37 2018 +0200

    xwayland: swap "name" and "id" in init_wl_registry()
    
    Both xwl_glamor_init_wl_registry() and the Wayland global registry
    handler use the interface id/name in that order, using name/id in the
    egl_backend vfunc makes things confusing and error prone.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit 78ce4aa979ff3f5870fbc12a7e5c53547084a61a)

commit 443e3348bb3c561160a2542365507179bd8dd825
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:38:36 2018 +0200

    xwayland: move glamor specific routines
    
    Functions such as:
    
      xwl_glamor_egl_supports_device_probing()
      xwl_glamor_egl_get_devices()
      xwl_glamor_egl_device_has_egl_extensions()
    
    Are of no use outside of EGLStream support, move them to the relevant
    source file.
    
    Similarly, the other glamor functions such as:
    
      xwl_glamor_init()
      xwl_screen_set_drm_interface()
      xwl_screen_set_dmabuf_interface()
      xwl_glamor_pixmap_get_wl_buffer()
      xwl_glamor_init_wl_registry()
      xwl_glamor_post_damage()
      xwl_glamor_allow_commits()
      xwl_glamor_egl_make_current()
    
    Are useless without glamor support enabled, move those within a
    a "#ifdef XWL_HAS_GLAMOR" in xwayland.h
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit f6b2109c1b49484af772df518314ec8e8432febe)

commit dea40be93577dff80cf25e9b39c2aaea030b9c9e
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:37:58 2018 +0200

    xwayland: make xwl_output_get_xdg_output() static
    
    Make xwl_output_get_xdg_output() private, it doesn't need to be
    available elsewhere.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit d31a7be15e259275599a9f67e0d921471ae64913)

commit 04a19291c93aaa4feeaf7a87663eaf1ef7c1f4b8
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:37:57 2018 +0200

    xwayland: do not disable glamor if EGLStream failed
    
    EGLStream requires glamor, but the opposite is not true. So if someone
    passes "-eglstream" with a GPU which does not support EGLStream, we
    could maybe still try GBM and be lucky.
    
    That allows Wayland compositors to pass "-eglstream" regardless of the
    actual hardware, if they want to enable EGLStream on GPU which support
    it.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit e16a6da79dea793a335be70ba07d5e1c1295b5eb)

commit de40a55235614d6114e97bd8c6f687bb555bdba8
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:37:56 2018 +0200

    xwayland: process Wayland events after adding screen
    
    When we're done adding a new screen, we need to process any pending
    Wayland events again.
    
    Hence we don't end up processing xdg_output events unexpectedly when
    glamor is disabled. Be that because "-shm" was passed or "-eglstream"
    has failed.
    
    Failing to do that could lead to a crash at startup:
    
        Xwayland: dixGetPrivateAddr: Assertion `key->initialized' failed.
        (EE)
        (EE) Backtrace:
        (EE) 0: Xwayland (OsSigHandler)
        (EE) 1: libpthread.so.0 (funlockfile)
        (EE) 2: libc.so.6 (gsignal)
        (EE) 3: libc.so.6 (abort)
        (EE) 4: libc.so.6 (?+0x0)
        (EE) 5: libc.so.6 (__assert_fail)
        (EE) 6: Xwayland (dixGetPrivateAddr)
        (EE) 7: Xwayland (_fbGetWindowPixmap)
        (EE) 8: Xwayland (getDrawableDamageRef)
        (EE) 9: Xwayland (damageRegionProcessPending)
        (EE) 10: Xwayland (damagePolyFillRect)
        (EE) 11: Xwayland (miPaintWindow)
        (EE) 12: Xwayland (miWindowExposures)
        (EE) 13: Xwayland (miHandleValidateExposures)
        (EE) 14: Xwayland (SetRootClip)
        (EE) 15: Xwayland (update_screen_size)
        (EE) 16: Xwayland (apply_output_change)
        (EE) 17: libffi.so.6 (ffi_call_unix64)
        (EE) 18: libffi.so.6 (ffi_call)
        (EE) 19: libwayland-client.so.0 (wl_log_set_handler_client)
        (EE) 20: libwayland-client.so.0 (_init)
        (EE) 21: libwayland-client.so.0 (wl_display_dispatch_queue_pending)
        (EE) 22: libwayland-client.so.0 (wl_display_roundtrip_queue)
        (EE) 23: Xwayland (InitInput)
        (EE) 24: Xwayland (dix_main)
        (EE) 25: libc.so.6 (__libc_start_main)
        (EE) 26: Xwayland (_start)
        (EE)
        (EE)
        Fatal server error:
        (EE) Caught signal 6 (Aborted). Server aborting
        (EE)
        Aborted (core dumped)
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit 44560af02823239e1b5b236e8cb365b5bdf24b6a)

commit 2d31a40db5ab3dc93863dc5ed9d9865490508575
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:37:55 2018 +0200

    xwayland: "EGL_EXT_device_base" required for EGLStream
    
    eglQueryDevicesEXT() would abort if the required extensions are not
    available, meaning that enabling “-eglstream” on a non-EGLStream
    capable hardware would lead to an abort().
    
    Check that "EGL_EXT_device_base" extension is available and bail out
    early if not, so we don't abort() later in eglQueryDevicesEXT().
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit dbde3fec32641ae23389cffa12a04d3608936795)

commit 65d46b2dfd638f6f6c6e52f3494c64716fc6687e
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 5 19:37:54 2018 +0200

    xwayland: allow "-eglstream" option
    
    The command line option "-eglstream" used to enable EGLStream support
    for NVidia GPU was made available only when Xwayland was built with
    EGLStream support enabled.
    
    Wayland compositors who spawn Xwayland have no easy way to tell whether
    or not Xwayland was built with EGLStream support enabled, and adding
    "-eglstream" command line option to Xwayland when it wasn't built with
    EGLStream support would prevent Xwayland from starting (“Unrecognized
    option” error).
    
    Make sure we support the command line option "-eglstream" regardless of
    EGLStream support in Xwayland. Obviously, if Xwayland was built without
    EGLStream support, this has no effect.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
    (cherry picked from commit 06c31e782e360363238cf20e7afd3e4990a2c304)

commit 38835d1d8f613c3553149fc05e61a8bb9b0aef48
Author: Vladimir Panteleev <git@thecybershadow.net>
Date:   Wed Jun 20 13:37:45 2018 +0000

    glx/vndcmds: Fix vendor hash table key size
    
    The keySize parameter of the hashing/comparison functions was
    incorrectly specified to be sizeof(void*), even though the keys of
    this hashtable are CARD32.
    
    Fixes address sanitizer failure on 64-bit builds.
    
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    (cherry picked from commit 707d0f912b916e7546c4f7e7a5f7023a53e74615)

commit d7220428daee26acecb6ae9771e255c801c83572
Author: Alexander Volkov <a.volkov@rusbitech.ru>
Date:   Tue Jun 5 13:05:39 2018 +0300

    Xext/shm: Refuse to work for remote clients
    
    Avoid access to System V shared memory segment on the X server side
    for clients forwarded via SSH. Also prevent them from hanging while
    waiting for the reply from the ShmCreateSegment request.
    
    v2: Allow ShmQueryVersion request even for remote clients
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=11080
    Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    (cherry picked from commit ec7e2b54c5b4a34b2a077082967bc3ead30e227e)

commit 9e417072bcde15f32dbf083327b6fe0202bb4cf4
Author: Michał Górny <gentoo@mgorny.alt.pl>
Date:   Mon Jun 11 17:17:31 2018 -0400

    xfree86: Makefile shouldn't rely on superuser being named 'root'
    
    Change the 'chown' statement in Makefile.am to use the numeric UID
    of superuser instead of relying on the name 'root'.
    
    Bugzilla: https://bugs.freedesktop.org/27726
    Signed-off-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Michał Górny <gentoo@mgorny.alt.pl>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit 5c95be38e5af28108d8c6c08dfe08d1dfcb7ed42)

commit 2e66ed066e4a9b52bcebf2ca3762f7e1ad141cf0
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Fri Jun 8 16:23:44 2018 +0200

    xwayland: use pixmap size on present flip
    
    If the pixmap size does not match the present box size, flickering
    occurs.
    
    This can happen when the client changes its size (e.g. switching to
    fullscreen), and since the buffer is kept as long as the pixmap is
    valid, once the buffer is created, it remains at the wrong (old) size
    and causes continuous flickering.
    
    Use the actual pixmap's drawable size instead of the present box to
    create the buffer so that it's sized appropriately.
    
    Bugzilla: https://bugs.freedesktop.org/106841
    Fixes: 0fb2cca193e6 "xwayland: Preliminary support for Present's new
                         window flip mode"
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Reviewed-by: Roman Gilg <subdiff@gmail.com>
    (cherry picked from commit 1993f147d08170f07a72e43f0a0f27687e16967b)

commit 883d4d00b46f18902ad402a156d56b1bfcc06ebe
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Jun 7 17:55:21 2018 +0200

    present/wnmd: Preserve window pixmap's screen_x/y on flip
    
    The incorrect values could result in the new pixmap's contents
    getting corrupted down the line.
    
    v2:
    * Guard screen_x/y lines by #ifdef COMPOSITE
    
    Bugzilla: https://bugs.freedesktop.org/106841
    Fixes: 029608dd8020 "present: Add window flip mode"
    Reviewed-by: Adam Jackson <ajax@redhat.com> # v1
    Reviewed-by: Keith Packard <keithp@keithp.com> # v1
    Reviewed-by: Roman Gilg <subdiff@gmail.com>
    Tested-by: Olivier Fourdan <ofourdan@redhat.com> # v1
    (cherry picked from commit 10eec2ccb11701fe29ab246acd6c0bdc2991b775)

commit 55171d738a0c2dd8a37ba2c880ea4658fd8001a2
Author: Dave Airlie <airlied@redhat.com>
Date:   Tue May 29 10:39:22 2018 +1000

    xwayland: fix typo in non-modifier fallback path
    
    Pointed out on irc by q66.
    Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    
    (cherry picked from commit 6300049a9a4b84789a2e8141f5cad17adf22185c)

commit 64bf28572946da1db84f6e61b02b5e6432f13d10
Author: Roman Kapl <code@rkapl.cz>
Date:   Thu Jun 7 03:31:42 2018 +0200

    Xi: add forgotten byte-swaps for Valuator fields
    
    This has caused nonsensical values in xinput output.
    
    Signed-off-by: Roman Kapl <code@rkapl.cz>
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit 40586cc4f8faa271d62fd84fe98c41debb878984)

commit 273115a01285ff2ce4837687f9bfc9d745a519a3
Author: Roman Kapl <code@rkapl.cz>
Date:   Thu Jun 7 03:31:41 2018 +0200

    Xi: fix byte-swapping of button labels
    
    The byte-swapping code forgot that the xXIButtonInfo is followed by a
    button mask, not directly by the button labels. This resulted in client
    crashes in cross-endian setups, for example in `xinput list --long`,
    since the client got an invalid atom.
    
    A new function was introduced to get the right positions for the label
    and mask data.
    
    Signed-off-by: Roman Kapl <code@rkapl.cz>
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit cefbc6a9356e5c6cf935b61557efa897762defae)

commit 69980e4e5a0d8ff3b36acf09e3c1e8eb76710726
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Jun 1 11:57:15 2018 +0200

    exa: Use PictureMatchFormat for source-only picture format description
    
    Their pFormat member is NULL, which resulted in a crash in
    miRenderColorToPixel.
    
    Fixes: 8171d4c2d67b "render: Store and use all 16bpc of precision for
                         solid pixels (v2.1)"
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    (cherry picked from commit 3ebef6ab850675e1091df2125ebdfbb147436e6c)

commit 33f20c38fc15e6664635ad22a581d7860e4b185d
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed May 23 11:18:02 2018 +0200

    glamor: Propagate glamor_fds_from_pixmap error in glamor_fd_from_pixmap
    
    glamor_fds_from_pixmap returns 0 on error, but we were treating that as
    success, continuing with uninitialized stride and fd values.
    
    Also bail if the offset isn't 0, same as in dri3_fd_from_pixmap.
    
    v2:
    * Reduce to a simple one-liner fix (Emil Velikov)
    
    Fixes: c8c276c9569b "glamor: Implement PixmapFromBuffers and
                         BuffersFromPixmap"
    Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
    (cherry picked from commit 4d5950ce14676f970d9de97380929a93948b98f2)

commit 544caffae1b0dc786383b117c036284feb579a66
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed May 23 11:38:13 2018 +0200

    glamor: Always return 0 from glamor_fds_from_pixmap on error
    
    This matches what glamor_egl_fds_from_pixmap and dri3_fds_from_pixmap do
    and what proc_dri3_buffers_from_pixmap expects.
    
    Fixes: c8c276c9569b "glamor: Implement PixmapFromBuffers and
                         BuffersFromPixmap"
    Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
    (cherry picked from commit 3da999a0390407d512bf784e4faf01482bfff9ea)

commit a9a17581ce73a49f0a8d3b9dbb2db083fa44cb69
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri May 18 11:23:01 2018 +0200

    modesetting: Pass O_CLOEXEC when opening a DRM device
    
    We don't want DRM file descriptors to leak to child processes.
    
    Reviewed-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    (cherry picked from commit 315c63c41d833700c505e4f21ffac4c59e1e3b2c)

commit c3a06e330b7e55e1daeefbb5c16a075c80233bb0
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri May 18 11:23:00 2018 +0200

    xfree86: Fix O_CLOEXEC usage in lnx_platform
    
    It was passing O_CLOEXEC as permission bits instead of as a flag.
    
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Reviewed-by: Keith Packard <keithp@keithp.com>
    (cherry picked from commit ab53e2859facecc0486344679dc01ea31fb427e9)

commit 662273397c537d031e1aee7c607c925ec6bb2d10
Author: Lukas F. Hartmann <lukas@mntmn.com>
