- 24 Apr, 2021 3 commits
-
-
-
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>
-
Jon Turney authored
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.
-
- 16 Apr, 2021 7 commits
-
-
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>
-
- 13 Apr, 2021 1 commit
-
-
Matthieu Herrb authored
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>
-
- 09 Apr, 2021 13 commits
-
-
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")
-
Jan Beich authored
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>
-
Povilas Kanapickas authored
`-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>
-
Povilas Kanapickas authored
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>
-
Povilas Kanapickas authored
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>
-
Povilas Kanapickas authored
Signed-off-by:
Povilas Kanapickas <povilas@radix.lt>
-
Povilas Kanapickas authored
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>
-
- 08 Apr, 2021 4 commits
-
-
Povilas Kanapickas authored
-
Povilas Kanapickas authored
-
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>
-
- 07 Apr, 2021 2 commits
-
-
Edouard Gaulué authored
-
Jeremy Huddleston Sequoia authored
Fixes: https://github.com/XQuartz/XQuartz/issues/140 Signed-off-by:
Jeremy Huddleston Sequoia <jeremyhu@apple.com>
-
- 06 Apr, 2021 1 commit
-
-
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
-
- 05 Apr, 2021 1 commit
-
-
Aaron Plattner authored
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: xorg/xserver#1126 Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> Reviewed-by:
Robert Morell <rmorell@nvidia.com>
-
- 04 Apr, 2021 1 commit
-
-
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>
-
- 30 Mar, 2021 1 commit
-
-
Povilas Kanapickas authored
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>
-
- 26 Mar, 2021 5 commits
-
-
Povilas Kanapickas authored
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>
-
Povilas Kanapickas authored
-
Povilas Kanapickas authored
-
Povilas Kanapickas authored
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>
-
Povilas Kanapickas authored
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>
-
- 25 Mar, 2021 1 commit
-
-
Povilas Kanapickas authored
The current URL points to an unrelated patch for acpid. Signed-off-by:
Povilas Kanapickas <povilas@radix.lt>
-