GitLab

Copied TGL PCI ID from MESA iris_pci_ids.h
This update brings in a significant number of new platform ID's
Sync up until commit f02ae698
Signed-off-by: Mazlan, Hazwan Arif <hazwan.arif.mazlan@intel.com>

Only cross-build for x86 MinGW-w64, as x64 MinGW-w64 will probably
require fixing LLP64 issues.

I don't know any source for pre-built cross-dependencies of the X
server, so build these from git.

Don't build with GLX enabled, so I don't have to deal with
cross-building mesa and it's dependencies, for the moment.

On FreeBSD 13.0-CURRENT for PowerPC64 big-endian (BE), X was
crashing in some cases. For instance, when twm was started
and the background was clicked to open its menu, X crashed
with a segmentation fault, trying to dereference a null pointer
at CreatePicture().

There were 2 issues with xorg-server handling of RGB masks that
caused the pointer above to be null and thus the crash:
- wrong use of ffs() to get the RGB offsets from the masks
- overflow when shifting a 16-bit integer

This change fixes both issues. They happen when the system is BE
but has a video adapter using a little-endian (LE) ARGB32
framebuffer. In order to display the correct colors, this setup
requires a BE RGBA32 color format to be used by X, by setting
the RGB masks appropriately, that didn't work properly because of
the issues above.

A lot of that code is the same as in xf86-amdgpu and xf86-nouveau drivers. By removing that functions from
ms namespace we can move that code to common implementation.
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>

Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>

Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>

Instead of getting the current msc value from the window crtc,
which not exist take the last saved msc value saved in
the window_priv struct
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>

Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>

Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>

CVE-2021-3472 / ZDI-CAN-1259

This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>

xkb.c: In function ‘ProcXkbSetMap’:
xkb.c:2747:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
 2747 |     DeviceIntPtr master = GetMaster(dev, MASTER_KEYBOARD);
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Rework the function to use a single snprintf call instead of a mix of
strcpy/strcats. This now also appends a trailing slash where needed so we
don't rely on the build system to set this for us.

Also, since /tmp/ is the fallback and we never check if everything succeeded,
assert if we can't use /tmp/. This will never be triggered anyway, the only
caller to OutputDirectory() uses sizeof(PATH_MAX-sized array).

Follow-up from 6c51818a

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Checking for function "getpeereid" : YES
Checking for function "getpeerucred" : NO
[...]
include/meson.build:182:7: ERROR: Argument to "not" is not a boolean.

Fixes: 68c2cfad ("meson: Make sure defines are either set to 1 or not defined")

FreeBSD < 12.2 and OpenBSD only have pthread_set_name_np.
As libpthread isn't in scope use -Werror to trip the check.

Header <pthread.h> has symbol "PTHREAD_MUTEX_RECURSIVE" : YES
Checking if "pthread_setname_np(tid, name)" compiles: YES

os/inputthread.c:326:5: error: implicit declaration of function 'pthread_setname_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    pthread_setname_np (pthread_self(), "InputThread");
    ^
os/inputthread.c:447:5: error: implicit declaration of function 'pthread_setname_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    pthread_setname_np (pthread_self(), "MainThread");
    ^

Fixes: c20e7b5e ("meson: Automatically detect HAVE_PTHREAD_SETNAME_NP")

Provides an implementation for the pixmap_from_buffers DRI3 function for
xwayland's eglstream backend. This will be used by the NVIDIA GLX driver
to pass buffers from client applications to the server. These can then
be presented using the PRESENT extension.

To hopefully make this less error-prone, we also introduce a "type"
field for this struct to distinguish between xwl_pixmaps for the new
DRI3-created pixmaps and those for the existing glamor-created pixmaps.

Additionally, the patch enables wnmd present mode with the eglstream backend.
This involves creating a wl_buffer for the provided dma-buf before importing it
into EGL and passing this to the compositor so it can be scanned out directly
if possible.

Since both backends now support this present mode, the HAS_PRESENT_FLIP flag is
no longer needed, so it can be removed.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>

This is preliminary work for hardware accelerated rendering with the
NVIDIA driver.

This exposes a new glamor backend function, check_flip, which can be
used to control whether flipping is supported for the given pixmap.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>

This is preliminary work for hardware accelerated rendering with the
NVIDIA driver.

This moves the modifiers and formats functions previously only available
to the GBM backend to the common glamor code so that it can be used by
both the GBM and EGLStream backends.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>

This is preliminary work for hardware accelerated rendering with the
NVIDIA driver.

The EGLStream backend can possibly also use the dmabuf interface, so
move the relevant code from the GBM specific source to the common bits.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

`-flto=auto` together with `-Wl,-wrap` causes link errors at least in
certain compilers (e.g. GCC 10.2.0). Since this is reoccurring issue
(internet search shows similar problems with GCC 4.6 a decade ago) let's
disable LTO for tests even if it's disabled elsewhere.

Fixes: xorg/xserver#1116

Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

This will make the behavior of meson consistent with autotools. The
configuration macros are exposed to public headers so any inconsistency
is likely to break code for anyone who's not careful to use #ifdef
instead of #if.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

The rest of dix code uses INPUTTHREAD, so having a different name in
meson configuration was an oversight.

Fixes: xorg/xserver#936

Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

This has not been tested, but os_deps is not used anywhere in the file,
so it's likely this was a typo.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

This effectively changes the versioning to be as if xserver 21.0 was
xserver 1.21.0. This should keep any client-side version checks that
know about the Xorg 7.0 -> xserver 1.0 epoch from getting confused.

This changes the operating system identifier tested against
host_machine.system() in meson build files from "dragonflybsd"
to the officially stable "dragonfly".
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>

Fixes: https://github.com/XQuartz/XQuartz/issues/140

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>

According to the "VESA Enhanced EDID Standard", all GTF compliant
displays are continuous frequency.

The GTF support flags in 'Display Range Limits Descriptor' cannot be
used if the display is a non-continuous frequency multi-mode display.

Closes #1105
Signed-off-by: Pascal VITOUX <vitoux.pascal@gmail.com>
Fixes: 6a79a737 ("xfree86: add drm modes on non-GTF panels")
Reviewed-by: Aaron Ma aaron.ma@canonical.com

Rather than trying to create a gamma ramp array of the appropriate size in
drmmode_crtc_init when the GAMMA_LUT property should be used, just flag the crtc
as wanting to use the GAMMA_LUT property and then replace the gamma ramp later,
right before calling xf86HandleColormaps. This avoids a problem during initial
startup where xf86RandR12CreateObjects12 hard-codes a gamma ramp size of 256,
causing xf86RandR12CrtcSetGamma to read past the end of the DIX layer's RandR
gamma ramp array:

  PreInit
    drmmode_pre_init
      drmmode_crtc_init
        crtc->gamma_size = 1024

  ScreenInit
    xf86CrtcScreenInit
      xf86RandR12Init
        xf86RandR12Init12
          xf86RandR12CreateObjects12
            RRCrtcCreate
              randr_crtc->gammaSize = 0
          xf86RandR12InitGamma(pScrn, 256)
            RRCrtcGammaSetSize
              randr_crtc->gammaSize = 256
          xf86RandR12InitGamma
            xf86RandR12CrtcInitGamma
              RRCrtcGammaSet
                xf86RandR12CrtcSetGamma
                  // crtc->gamma_size is 1024 here, while randr_crtc->gammaRed
                  // is a 256-element array.
                  memcpy(crtc->gamma_red, randr_crtc->gammaRed, crtc->gamma_size * sizeof(crtc->gamma_red[0]));
    drmmode_setup_colormap
      xf86HandleColormaps
        xf86RandR12InitGamma
          RRCrtcGammaSetSize
            randr_crtc->gammaSize = 1024

Fixes: 245b9db0 - modesetting: Use GAMMA_LUT when available
Closes: #1126

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>

This helps on KAME-based systems which want to get rid of this hack.
The assumption is that if sin6_scope_id is set, then the interface index
is no longer embedded in the address.
Signed-off-by: Jeremie Courreges-Anglas <jca@wxcvbn.org>

The xkb spec defines that the 7th element of the DeviceValuator key
action description is "valuator 2 value".

This error most likely was accidentally introduced as a copy-paste error
in edeb033f

.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

This brings the behavior closer than what we currently have with
autotools-based build system.

Meson does not currently have native support for symlinks.
See https://github.com/mesonbuild/meson/issues/1602

.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

Meson gets confused when there are two targets of the same name within
the same directory, so we use a different intermediate name.

This is a problem with the Xorg SUID wrapper which has the same filename
as the real Xorg executable and is configured in the same meson.build
file. This commit works around this by using a different filename in
build stage and renaming only when installing.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

In both cases we check for width > 0 just above, and the variable is not
modified between the checks, so the condition is always true.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

The current URL points to an unrelated patch for acpid.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>