-
Peter Harris authored
client->errorValue is already set in validGlxFBConfig. Set it in __glXDisp_CreateContextAttribsARB for consistency. Signed-off-by:
Peter Harris <pharris@opentext.com>
1626e9fa -
Aaron Plattner authored
A later change will need to read the value of the GAMMA_LUT_SIZE property. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com>
4fefe73f -
Aaron Plattner authored
Modeset properties can be set even when ms->atomic_modeset is disabled by using the drmModeObjectSetProperty() function. This will be necessary in a later change in order to set the GAMMA_LUT and CTM properties. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com>
b6985d6b -
Aaron Plattner authored
If the kernel exposes GAMMA_LUT and GAMMA_LUT_SIZE properties and the size is not what the server has pre-configured for the crtc, free the old gamma ramp memory allocated by the server and replace it with new allocations of the appropriate size. In addition, when GAMMA_LUT is available, use drmModeCreatePropertyBlob() and drmModeObjectSetProperty() to set the gamma ramp rather than using the legacy drmModeCrtcSetGamma() function. Add a new option "UseGammaLUT" to allow disabling this new behavior and falling back to drmModeCrtcSetGamma() unconditionally. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com>
245b9db0 -
Aaron Plattner authored
When the "CTM" (color transform matrix) modesetting property is available, create a corresponding RandR property. To match the format of the property available in the amdgpu driver, expose it as an array of 18 32-bit XA_INTEGERs representing a 3x3 matrix in row-major order, where each entry is a S31.32 sign-magnitude fixed-point number with the fractional part listed first. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> Acked-by:
Michel Dänzer <mdaenzer@redhat.com> Reviewed-by:
James Jones <jajones@nvidia.com>
4e670f12 -
Adam Jackson authored
Instead, bump the pixmap's refcount at the bottom of post_damage to reflect the compositor's hold on the buffer, and "destroy" the pixmap in the buffer release callback (which will dec the pixmap's refcount and free if necessary). Signed-off-by:
Adam Jackson <ajax@redhat.com>
affc4745 -
When making a pixmap exportable, glamor will currently create a temporary exported pixmap backed by a GBM bo, with the devKind updated to the stride of the bo. However, when the backing of the exported pixmap is swapped into the original, the devKind of the original is not updated. Some GBM bos may get implicitly padded, in which case the devKind of the pixmap will not match the stride of the backing bo. For example, an 800x600 pixmap will have a devKind of 3200, but the bo's stride will be 3328. This can cause corruption with PRIME, when the sink uses the wrong stride to display the shared pixmap. This commit changes glamor_make_pixmap_exportable() to update the devKind of the original pixmap after it swaps exported pixmap's backing into it, keeping everything consistent. Fixes issue #1018. Signed-off-by:
Alex Goins <agoins@nvidia.com> Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
7a7e55c5 -
When running non-rootless, Xwayland requires that the Wayland compositor supports the XDG-WM-Base protocol. Check for XDG-WM-Base protocol support at startup and exit cleanly if missing rather than segfaulting later in ensure_surface_for_window() while trying to use xdg_wm_base_get_xdg_surface(). Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Reviewed-by:
Simon Ser <contact@emersion.fr>
ffd02d9b -
One general assumption in Xwayland is that the xwl_window remains the same for all the child windows of the toplevel window. When mapping a new X11 window, ensure_surface_for_window() checks for an existing xwl_window by using xwl_window_get() which will just check for the registered xwl_window for the window. That means that a client mapping a child window of an existing window with a xwl_window will get another different xwl_window. If an X11 client issues a Present request on the parent window, hence placed underneath its child window of the same size, the Wayland compositor may not send the frame callback event for the parent's Wayland surface which is reckoned to be not visible, obscured behind the other Wayland surface for the child X11 window. That bug affects some games running in wine which may get 1 fps because the repaint occurs only on timeout with a long interval (as with, e.g. https://bugs.winehq.org/show_bug.cgi?id=47066) Fix ensure_surface_for_window() by using xwl_window_from_window() which will walk the window tree, so that a child window won't get another xwl_window than its parent. #1099 See-also: https://bugs.winehq.org/show_bug.cgi?id=47066 Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
606ba7fc -
With autoconf, hashtable support is built along with Xres support. Yet, glvnd also use it, so when disabling Xres from configure, the build will fail at link time because hashtable functions are not available. Untie the build of hashtable from Xres support, just like meson build does. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Closes: #1091
899cebb7 -
Michel Dänzer authored
Noticed while reading the code. Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com>
df3aa492 -
Olivier Fourdan authored
The command line options "-shm" is used to instruct Xwayland to prefer shared-memory for passing buffers to the Wayland server, rather than using glamor and DRI3. The option was there from the beginning, yet not documented in the "-help" message. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Martin Peres <martin.peres@mupuf.org>
d163f938 -
Olivier Fourdan authored
As Xwayland is usually spawned by the Wayland server/compositor, its command line options are not always adjustable. Yet, if EGLStream is not supported in a given Xwayland build, the option will do nothing (yet we must still accept it otherwise Xwayland would refuse to run if the Wayland compositor uses it). If Xwayland was built without support for EGLStream, there is not point in showing the option in the help message though. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Martin Peres <martin.peres@mupuf.org>
d14cef85 -
Olivier Fourdan authored
Xwayland was missing a man page, add one. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Martin Peres <martin.peres@mupuf.org>
28ed4b95 -
Michel Dänzer authored
To take advantage of more than 4 CPU cores available to the container. Acked-by:
Olivier Fourdan <ofourdan@redhat.com>
9a751594 -
Michel Dänzer authored
It doesn't need a full checkout of the xserver Git tree, so this can save some time and resources. Acked-by:
Olivier Fourdan <ofourdan@redhat.com>
8fc84a00 -
Michel Dänzer authored
Noticed this was missing while making changes in this area. Acked-by:
Olivier Fourdan <ofourdan@redhat.com>
996ba1b9 -
Michel Dänzer authored
So that they only need to be listed once. Acked-by:
Olivier Fourdan <ofourdan@redhat.com>
8469935f -
Michel Dänzer authored
Instead of relying on apt-get build-dep. Acked-by:
Olivier Fourdan <ofourdan@redhat.com>
852d6d49 -
Michel Dänzer authored
They now ensure the image is up to date in forked projects, and we no longer need to reconstruct the image name. Acked-by:
Olivier Fourdan <ofourdan@redhat.com>
ab73c169 -
Michel Dänzer authored
By its nature, testing incurs a risk of breaking something every time we bump the image. This requires building wayland-protocols locally, since the package in buster is too old for current Xwayland. Acked-by:
Olivier Fourdan <ofourdan@redhat.com>
821399a9 -
Michel Dänzer authored
It runs XTS via piglit on (non-rootless) Xwayland on weston using the headless backend. Xwayland might use glamor if enabled in the build, but we're making sure it uses software rendering. v2: * Use weston-info to wait for weston to be ready, instead of just a fixed sleep. (Martin Peres) v3: * Build wayland 1.18 & weston 9.0 locally, since the packages in Debian buster are too old for current Xwayland. Acked-by:
Olivier Fourdan <ofourdan@redhat.com>
250db870 -
Alan Coopersmith authored
Resolves warning from Oracle Parfait static analyser: Warning: Impossible or redundant condition Impossible or redundant condition [impossible-redundant-condition]: Condition 'dev != NULL' of branch is determined by previous branch at line 270 of dix/devices.c in function 'AddInputDevice'. Condition 'dev != NULL' from this branch implies following branch is always true at line 262 Fixes: commit 493ad833 Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com>
d00594eb -
Alan Coopersmith authored
Resolves warning from Oracle Parfait static analyser: Error: Unchecked result Unchecked result [unchecked-result-call-X]: Unchecked return value from call to XOpenDisplay. Value display must be ch ecked to ensure this function was successful. at line 73 of hw/dmx/examples/xbell.c in function 'main'. Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com>
034e7926 -
Alan Coopersmith authored
Resolves warning from Oracle Parfait static analyser: Error: Uninitialised memory Uninitialised memory variable [uninitialised-mem-var] (CWE 457): Possible access to uninitialised memory referenced by variable 'mask' at line 721 of xkb/XKBMisc.c in function 'XkbUpdateKeyTypeVirtualMods'. Path in callee avoiding write at line 720 mask allocated at line 718 Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com>
a6574033 -
Alan Coopersmith authored
Resolves warnings from Oracle Parfait static analyser: Error: Misleading macro Misleading macro [misleading-macro]: misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses at line 392 of hw/xfree86/int10/generic.c. '|' operator has higher precedence than ternary '?:' operator inside macro body at line 431 low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431 Misleading macro [misleading-macro]: misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses at line 392 of hw/xfree86/int10/generic.c. '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 431 low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431 Misleading macro [misleading-macro]: misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses at line 392 of hw/xfree86/int10/generic.c. '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 442 low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 442 Misleading macro [misleading-macro]: misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses at line 392 of hw/xfree86/int10/generic.c. '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443 low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443 Misleading macro [misleading-macro]: misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses at line 392 of hw/xfree86/int10/generic.c. '|' operator has higher precedence than ternary '?:' operator inside macro body at line 443 low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 441 Misleading macro [misleading-macro]: misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses at line 392 of hw/xfree86/int10/generic.c. '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443 low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443 Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com>
e5386011 -
Commit 77658741 - "xwayland: Add buffer release callback" added an API to deal with Wayland buffer release callbacks. The EGLstream implementation has its own wl_buffer callback, move that to the buffer release API instead so we don't have to deal with Wayland buffers directly and match the other Xwayland pixmap backend implementations. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Tested-by:
Erik Kurzinger <ekurzinger@nvidia.com>
662b2bcb -
Olivier Fourdan authored
EGLStream implementation in Xwayland keeps a list of pending streams for a window. If the windows's pixmap is destroyed while there is a pending stream, the pending stream will point to freed memory once the callback is triggered. Make sure to cancel the pending stream if there's one when the pixmap is destroyed. v2: * Use xorg_list_for_each_entry() instead of the safe variant (Michel Dänzer <mdaenzer@redhat.com>) Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Tested-by:
Karol Szuster <karolsz9898@gmail.com> Acked-by:
Michel Dänzer <mdaenzer@redhat.com> Closes xorg/xserver#1096
d18dcecb -
Jon Turney authored
Provide an actual definition of noDriExtension where used, rather than a tentative definition in a header, to fix compilation with -fno-common (the default with gcc 10).
bb7aab6a -
acd819ac
-
5b0c5344
-
56d72059
-
f6e0bf68
-
8bd8b3af
-
23a8b62d
-
36f8dacc
-
f5220117
-
XI2LASTEVENT identifies the bit number, not the mask size in bits. The mask size in bits is XI2LASTEVENT + 1 and the mask size in bytes is (XI2LASTEVENT + 8) / 8 or XI2MASKSIZE.
07e69350 -
I forgot to add these in commits 4fefe73f, b6985d6b, 245b9db0, and 4e670f12. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com>
af4622d3 -
The ID_PATH for a udl device looks like this: $ udevadm info /dev/dri/card2 | grep -w ID_PATH E: ID_PATH=pci-0000:00:14.0-usb-0:9.1:1.0 The parsing added in 0816e8fc ("linux: Make platform device probe less fragile"), sets OdevAttributes::busid to "pci:0000:00:14.0", where drmGetBusid() would have returned "3-9.1:1.0". Identifying this as a "pci:*" device eventually causes the vendor/device id check in probeSingleDevice() to fail, because a USB controller isn't a supported device: $ udevadm info --path=/devices/pci0000:00/0000:00:14.0 | grep -e VENDOR -e ID_PCI_CLASS E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation Instead of parsing out "pci:0000:00:14.0" in this case, use "usb:0:9.1:1.0" so the device probe will succeed. Fixes: 0816e8fc ("linux: Make platform device probe less fragile") Signed-off-by:
Reza Arbab <arbab@linux.ibm.com>
c0dcadad -
With !155, the device bus ID received via udev is constructed properly with the "usb:" prefix. But, it is not enough to make the following line to work in Section "Device": BusID "usb:0:1.2:1.0" Introduce BUS_USB, so the prefix can be distinguished from BUS_PCI and check the supplied BusID value against device->attribs->busid in xf86PlatformDeviceCheckBusID(). Signed-off-by:
Böszörményi Zoltán <zboszor@pr.hu>
68216747 -
Fabrice Fontaine authored
Kernel modesettings support also depends on dri2, see http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesetting/Makefile.am#n46 Fix #479 Signed-off-by:
Bernd Kuhls <bernd.kuhls@t-online.de> [Patch retrieved (with a small update of commit message) from: https://git.buildroot.net/buildroot/tree/package/x11r7/xserver_xorg-server/1.20.6/0001-modesettings-needs-dri2.patch ] Signed-off-by:
Fabrice Fontaine <fontaine.fabrice@gmail.com>
9c81b8f5 -
Querying the GLX_RENDER_TYPE of a GLX context via glXQueryContext will currently return the render type of the context's FB config, which is a bitmask of GLX_RGBA_BIT / GLX_COLOR_INDEX_BIT / ... values. However, this query should really return the render type that was specified when creating the context, which is one of GLX_RGBA_TYPE / GLX_COLOR_INDEX_TYPE / .... To enable this, save the render type when creating a new context (defaulting to GLX_RGBA_TYPE if unspecified), and then include this value in the context attributes sent to clients.
95b79aa9 -
By default, the macro DebugPresent() is a no-op but it can be enabled at build time for debugging purpose. However, doing so prevents the code to build because one debug statement tries to make use of a non-existent variable: present.c: In function ‘ms_present_queue_vblank’: present.c:147:18: error: ‘vbl’ undeclared (first use in this function) 147 | vbl.request.sequence)); | ^~~ present.c:49:32: note: in definition of macro ‘DebugPresent’ 49 | #define DebugPresent(x) ErrorF x | ^ Fix the build with DebugPresent() by removing the vbl variable from the debug message. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
3ce05a44 -
Michel Dänzer authored
GCC warned about it: ../../../glx/indirect_dispatch_swap.c:85:1: warning: ‘bswap_CARD64’ defined but not used [-Wunused-function] 85 | bswap_CARD64(const void *src) | ^~~~~~~~~~~~
b0530fe4 -
Michel Dänzer authored
The region as passed in is in the source pixmap's coordinate space, so intersecting it with the clipList (which is in screen space) resulted in disappointment. Fixes Firefox popups such as the hamburger menu when using the EGL backend. v2: * Drop vblank->x/y_off from RegionTranslate call, since they're always 0 here (present_wnmd_check_flip rejects flips for x/y_off != 0). Reported-by:
Robert Mader <robert.mader@posteo.de> Tested-by:
Robert Mader <robert.mader@posteo.de> Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com> Tested-by: Joakim Tjernlund <joakim.tjernlund@infinera.com> # v1
11652706 -
Matthieu Herrb authored
ZDI-CAN 11389 / CVE-2020-25712 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
Matthieu Herrb <matthieu@herrb.eu>
87c64fc5 -
Matthieu Herrb authored
Avoid out of bounds memory accesses on too short request. ZDI-CAN 11572 / CVE-2020-14360 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
Matthieu Herrb <matthieu@herrb.eu>
446ff2d3
- .gitlab-ci.yml 17 additions, 22 deletions.gitlab-ci.yml
- .gitlab-ci/debian-install.sh 117 additions, 20 deletions.gitlab-ci/debian-install.sh
- Xext/Makefile.am 8 additions, 2 deletionsXext/Makefile.am
- Xi/exevents.c 49 additions, 49 deletionsXi/exevents.c
- Xi/xiselectev.c 8 additions, 5 deletionsXi/xiselectev.c
- config/udev.c 6 additions, 1 deletionconfig/udev.c
- configure.ac 7 additions, 1 deletionconfigure.ac
- dix/devices.c 24 additions, 4 deletionsdix/devices.c
- dix/events.c 103 additions, 73 deletionsdix/events.c
- dix/inpututils.c 25 additions, 0 deletionsdix/inpututils.c
- dix/touch.c 20 additions, 57 deletionsdix/touch.c
- glamor/glamor_egl.c 3 additions, 0 deletionsglamor/glamor_egl.c
- glx/Makefile.am 3 additions, 1 deletionglx/Makefile.am
- glx/createcontext.c 8 additions, 2 deletionsglx/createcontext.c
- glx/glxcmds.c 10 additions, 5 deletionsglx/glxcmds.c
- glx/glxcontext.h 5 additions, 0 deletionsglx/glxcontext.h
- glx/indirect_dispatch_swap.c 0 additions, 12 deletionsglx/indirect_dispatch_swap.c
- hw/dmx/examples/xbell.c 8 additions, 1 deletionhw/dmx/examples/xbell.c
- hw/xfree86/common/xf86Bus.c 2 additions, 0 deletionshw/xfree86/common/xf86Bus.c
- hw/xfree86/common/xf86str.h 2 additions, 0 deletionshw/xfree86/common/xf86str.h