- 03 Dec, 2020 1 commit
-
-
For reverse PRIME heads, with 'modesetting' as the source, scaling was broken as the compositing of the shared pixmaps wasn't properly configured to take into account scaling (and other transformations). For example, by scaling a reverse PRIME head by 2x2 the user would only see the top-left quadrant of the 2x2 screenspace instead of the full screenspace scaled down to the size of the shared pixmap. This change brings the RandR transformation available for tracking and updating of dirty regions in the modesetting driver, and subsequently the CompositeRotate() function which renders the transformed screen to the shared pixmap. For transforms with simple translations only a separate execution path is tracked so that direct copying can be used. These changes should fix scaling, and to some extent, arbitrary transformations, for all heads that are reverse PRIME sinks driven from 'modesetting' source. Note that these changes only clean up certain parts of the viewport transformation and composition pipeline. A more thorough overhaul of how all the offsets and transformations are managed would be in order to make all combinations of randr screen configurations work seamlessly. I tried to be careful not to break existing functionality but there are things that were broken in the first place and remain to be so. As a quick test, basic scaling like this should now work properly with reverse PRIME outputs: xrandr --output <X> --scale 0.5x0.5 xrandr --output <X> --scale 2x2 Arbitrary transforms still exhibit various quirks and artifacts but something like a basic free rotation should now behave a bit better than before with reverse PRIME outputs: xrandr --output <X> --transform 0.707,-0.707,0,0.707,0.707,0,0,0,1 With this change, this command yields a screen that is at least now rotated yet still wrongly clipped as it was also before this change.
-
- 01 Dec, 2020 3 commits
-
-
Matthieu Herrb authoredAvoid 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> -
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> -
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:
Olivier Fourdan <ofourdan@redhat.com> Tested-by: Joakim Tjernlund <joakim.tjernlund@infinera.com> # v1
-
- 30 Nov, 2020 1 commit
-
-
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) | ^~~~~~~~~~~~
-
- 26 Nov, 2020 2 commits
-
-
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: -
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.
-
- 25 Nov, 2020 13 commits
-
-
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>
-
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>
-
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>
-
I forgot to add these in commits 4fefe73f, b6985d6b, 245b9db0, and 4e670f12 . Signed-off-by:
Aaron Plattner <aplattner@nvidia.com>
-
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.
-
-
-
-
-
-
-
-
-
- 24 Nov, 2020 1 commit
-
-
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).
-
- 23 Nov, 2020 1 commit
-
-
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:
Karol Szuster <karolsz9898@gmail.com> Acked-by:
Michel Dänzer <mdaenzer@redhat.com> Closes xorg/xserver#1096
-
- 19 Nov, 2020 1 commit
-
-
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:
Erik Kurzinger <ekurzinger@nvidia.com>
-
- 18 Nov, 2020 4 commits
-
-
Alan Coopersmith authoredResolves 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> -
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> -
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> -
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>
-
- 17 Nov, 2020 7 commits
-
-
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: -
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: -
They now ensure the image is up to date in forked projects, and we no longer need to reconstruct the image name. Acked-by: -
Instead of relying on apt-get build-dep. Acked-by: -
So that they only need to be listed once. Acked-by: -
Noticed this was missing while making changes in this area. Acked-by: -
It doesn't need a full checkout of the xserver Git tree, so this can save some time and resources. Acked-by:
-
- 12 Nov, 2020 1 commit
-
-
To take advantage of more than 4 CPU cores available to the container. Acked-by:
-
- 10 Nov, 2020 3 commits
-
-
Olivier Fourdan authored
Xwayland was missing a man page, add one. Signed-off-by:
Martin Peres <martin.peres@mupuf.org>
-
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 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:
-
- 09 Nov, 2020 2 commits
-
-
Noticed while reading the code. Reviewed-by: -
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:
-
