Implements the xwayland_shell protocol which makes the surface
association happen via a shared serial, rather than sharing a wl_surface
resource ID across an X atom.

This solves a race that can happen if the wl_surface
associated with a WL_SURFACE_ID for a window was destroyed before the
update of the atom was processed by the compositor and another surface
(or other object) had taken its id due to recycling.

Closes: #1157

Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>

Debian Bullseye only has 1.20, so we need to bump this.

Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

wayland-protocols requires wayland-scanner 1.20, but Debian bullseye has 1.18 only

Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

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

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

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

If atomic modesetting is to be enabled in the configuration file, log
whether this is supported and eventually enabled or disabled.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>

The modesetting driver has atomic modesetting disabled by default but
can be enabled (if supported) using a configuration option.

Add this option in the man page.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>

This adds support for TearFree page flips to eliminate tearing without the
use of a compositor. It allocates two shadow buffers for each CRTC, a back
buffer and a front buffer, and uses damage tracking to minimize excessive
copying between buffers and skip unnecessary flips when the screen's
contents remain unchanged. It works on transformed screens too, such as
rotated and scaled CRTCs.

When PageFlip is enabled, TearFree won't force fullscreen DRI clients to
synchronize their page flips to the vblank interval.

TearFree is disabled by default.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

The DRM event queue in the kernel is quite small and can be easily
exhausted by DRI clients. When the event queue is full, that means nothing
can be queued onto it anymore, which can lead to incorrect presentation
times for DRI clients and failure when attempting to queue a page flip.

To make matters worse, once an event is placed onto the kernel's event
queue, there's no straightforward way to prematurely remove it from the
kernel's event queue in userspace, which means that aborting a sequence
number doesn't free up space in the event queue.

Since vblank events from DRI clients are the largest consumers of the
event queue, and since it's often easy to know the desired target MSC of
their vblank events without querying the kernel for a CRTC's current MSC,
we can coalesce vblank events occurring at the same MSC such that only one
of them is placed onto the kernel's event queue, instead of allowing
duplicate vblank events to pollute the event queue.

This is achieved by tracking the next kernel-queued event's MSC on a
per-CRTC basis and then running all of that CRTC's vblank event handlers
which have reached their target MSC when the queued MSC is signaled.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

When a driver uses TearFree to flip all frames synchronized to the vblank
interval, Present has no idea and still assumes that each presentation
occurs immediately upon copying its damages to the primary scanout. This
faulty assumption breaks presentation timestamping, potentially leading to
A/V de-synchronization and dropped frames.

Present needs to have some awareness of a driver using TearFree so that it
can know when each presentation actually becomes visible on the screen.

Teach Present about drivers using TearFree by expanding PresentFlipReason
to allow drivers to export some contextual info about TearFree when Present
cannot page-flip directly anyway.

PRESENT_FLIP_REASON_DRIVER_TEARFREE indicates that a driver has TearFree
enabled but doesn't have a TearFree flip currently pending.

PRESENT_FLIP_REASON_DRIVER_TEARFREE_FLIPPING indicates that a driver has a
TearFree flip currently pending.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

do_queue_flip_on_crtc() is about to be used to flip buffers other than the
primary scanout (`ms->drmmode.fb_id`), so make it generic to accept any
frame buffer ID, as well as x and y coordinates in the frame buffer, to
flip on a given CRTC. Move the retry logic from queue_flip_on_crtc() into
it as well, so that it's robust for all callers.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

Shadow buffers are about to be used for TearFree, so make the shadow buffer
helpers generic such that they can be used to create arbitrary per-CRTC
shadows aside from just the per-CRTC rotated buffer.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

xf86RotateCrtcRedisplay() is about to be used outside of xf86Rotate.c in
order to copy transformed pixmaps, so fix up its interface by specifying
the source drawable and destination pixmap rather than assuming the root
drawable and rotated pixmap, respectively. In addition, add an argument to
make xf86RotateCrtcRedisplay() not perform any transformations, which is an
indicator that it should only copy a transformed pixmap rather than
actually transform a pixmap.

These changes make it possible to use xf86RotateCrtcRedisplay() to not
only copy transformed pixmaps, but also actually transform pixmaps, making
it very useful outside of xf86Rotate.c.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

PixmapDirtyCopyArea() is about to be used outside of pixmap.c, so fix up
its interface by specifying the dirty area directly rather than passing a
`PixmapDirtyUpdatePtr`. This makes it easier to use outside of pixmap.c, as
the caller doesn't need to create a bulky PixmapDirtyUpdateRec to use this
function.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

In commit b320ca0f the mask was inadvertently changed from octal 0177 to
hexadecimal 0x177.

Fixes commit b320ca0f
  Xtest: disallow GenericEvents in XTestSwapFakeInput

Found by Stuart Cassoff

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

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

John D Pell authored 3 years ago and Jeremy Huddleston Sequoia committed 2 years ago

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

Unlike other elements of the keymap, this pointer was freed but not
reset. On a subsequent XkbGetKbdByName request, the server may access
already freed memory.

CVE-2022-4283, ZDI-CAN-19530

This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>

This fixes an OOB read and the resulting information disclosure.

Length calculation for the request was clipped to a 32-bit integer. With
the correct stuff->num_items value the expected request size was
truncated, passing the REQUEST_FIXED_SIZE check.

The server then proceeded with reading at least stuff->num_items bytes
(depending on stuff->format) from the request and stuffing whatever it
finds into the property. In the process it would also allocate at least
stuff->num_items bytes, i.e. 4GB.

The same bug exists in ProcChangeProperty and ProcXChangeDeviceProperty,
so let's fix that too.

CVE-2022-46344, ZDI-CAN 19405

This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>

Both ProcXChangeDeviceProperty and ProcXIChangeProperty checked the
property for validity but didn't actually return the potential error.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>

This fixes a use-after-free bug:

When a client first calls ScreenSaverSetAttributes(), a struct
ScreenSaverAttrRec is allocated and added to the client's
resources.

When the same client calls ScreenSaverSetAttributes() again, a new
struct ScreenSaverAttrRec is allocated, replacing the old struct. The
old struct was freed but not removed from the clients resources.

Later, when the client is destroyed the resource system invokes
ScreenSaverFreeAttr and attempts to clean up the already freed struct.

Fix this by letting the resource system free the old attrs instead.

CVE-2022-46343, ZDI-CAN 19404

This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>

This fixes a use-after-free bug:

When a client first calls XvdiSelectVideoNotify() on a drawable with a
TRUE onoff argument, a struct XvVideoNotifyRec is allocated. This struct
is added twice to the resources:
  - as the drawable's XvRTVideoNotifyList. This happens only once per
    drawable, subsequent calls append to this list.
  - as the client's XvRTVideoNotify. This happens for every client.

The struct keeps the ClientPtr around once it has been added for a
client. The idea, presumably, is that if the client disconnects we can remove
all structs from the drawable's list that match the client (by resetting
the ClientPtr to NULL), but if the drawable is destroyed we can remove
and free the whole list.

However, if the same client then calls XvdiSelectVideoNotify() on the
same drawable with a FALSE onoff argument, only the ClientPtr on the
existing struct was set to NULL. The struct itself remained in the
client's resources.

If the drawable is now destroyed, the resource system invokes
XvdiDestroyVideoNotifyList which frees the whole list for this drawable
- including our struct. This function however does not free the resource
for the client since our ClientPtr is NULL.

Later, when the client is destroyed and the resource system invokes
XvdiDestroyVideoNotify, we unconditionally set the ClientPtr to NULL. On
a struct that has been freed previously. This is generally frowned upon.

Fix this by calling FreeResource() on the second call instead of merely
setting the ClientPtr to NULL. This removes the struct from the client
resources (but not from the list), ensuring that it won't be accessed
again when the client quits.

Note that the assignment tpn->client = NULL; is superfluous since the
XvdiDestroyVideoNotify function will do this anyway. But it's left for
clarity and to match a similar invocation in XvdiSelectPortNotify.

CVE-2022-46342, ZDI-CAN 19400

This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>

The XKB protocol effectively prevents us from ever using keycodes above
255. For buttons it's theoretically possible but realistically too niche
to worry about. For all other passive grabs, the detail must be zero
anyway.

This fixes an OOB write:

ProcXIPassiveUngrabDevice() calls DeletePassiveGrabFromList with a
temporary grab struct which contains tempGrab->detail.exact = stuff->detail.
For matching existing grabs, DeleteDetailFromMask is called with the
stuff->detail value. This function creates a new mask with the one bit
representing stuff->detail cleared.

However, the array size for the new mask is 8 * sizeof(CARD32) bits,
thus any detail above 255 results in an OOB array write.

CVE-2022-46341, ZDI-CAN 19381

This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>

XTestSwapFakeInput assumes all events in this request are
sizeof(xEvent) and iterates through these in 32-byte increments.
However, a GenericEvent may be of arbitrary length longer than 32 bytes,
so any GenericEvent in this list would result in subsequent events to be
misparsed.

Additional, the swapped event is written into a stack-allocated struct
xEvent (size 32 bytes). For any GenericEvent longer than 32 bytes,
swapping the event may thus smash the stack like an avocado on toast.

Catch this case early and return BadValue for any GenericEvent.
Which is what would happen in unswapped setups anyway since XTest
doesn't support GenericEvent.

CVE-2022-46340, ZDI-CAN 19265

This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>

Doğukan Korkmaztürk authored 2 years ago and Olivier Fourdan committed 2 years ago

In CommonMakeCurrent() function, the tag of the old context is freed
before the new context is made current. This is problematic because if
the CommonMakeNewCurrent() function fails, the tag of the old context
ends up being removed, even though it is still active. This causes
subsequent glXMakeCurrent() or glXMakeContextCurrent() requests to
generate a GLXBadContextTag error.

This change moves the function call that frees the old tag to a location
where the result of CommonMakeNewCurrent() call is known and it is safe
to free it.

Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com>

Updated the for-loop that iterates over the received EGLConfigs to
include the very first EGLConfig with index 0.

Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com>
Fixes: 84692415 - xwayland: Add EGL-backed GLX provider

For now, it sets .version=120, which prevents shader from compiling on ES.
We just force version of shaders to be always 100 on ES, because we use
only 120 shaders on ES anyway, and all shaders works.

Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>

Vasily Khoruzhick authored 2 years ago and Konstantin committed 2 years ago

ARB_blend_func_extended may be exposed even without GLSL 1.30.
In order to use it we need GLES2 shaders that are available if
ARB_ES2_compatibility is exposed.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>

Yuriy Vasilev authored 3 years ago and Konstantin committed 2 years ago

In GLES2, we cannot do GL_RED or GL_RG without GL_EXT_texture_rg.
So, add check for GL_EXT_texture_rg to make it working. Also add
a yuv2 pixman format into render.h to make Xv yuv rendering works.

Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>

glUniformMatrix3fv is used with argument transpose set to GL_TRUE.
According to the Khronos OpenGL ES 2.0 pages transpose must be GL_FALSE.
Actually we can just return transformed matrix from
_glamor_gradient_convert_trans_matrix (@anholt suggest),
so @uvas workaround is not required

Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>

For 24 and 32 bit depth pictures xserver uses PICT_x8r8g8b8 and PICT_a8r8g8b8 formats,
which must be backed with GL_BGRA format. It is present in OpenGL ES 2.0 only with
GL_EXT_texture_format_BGRA8888 extension. We require such extension in glamor_init,
so, why not to make use of it?
Fixes #1208
Fixes #1354

Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>

Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>

Corentin Noël authored 2 years ago and Emma Anholt committed 2 years ago

The virgl driver exposes the name of the host renderer which might be llvmpipe.
In this case we still need glamor to be initialized.

Only check if the renderer starts with llvmpipe (which is what llvmpipe exposes).

Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>

The only reason we still depend on xorg/font/utils is because we pull a
pkgconfig variable from that .pc file. Let's drop that dependency by
providing that option ourselves.

And where the option isn't specified and font-utils isn't found, default
to $datadir/fonts/X11, same path it's always been.

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

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

This will allow side-wide customization.

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


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

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

Shashank Sharma authored 2 years ago and Shashank Sharma committed 2 years ago

The current X server infrastructure sets modesetting driver as default driver
to handle PCI-hotplug of a GPU device. This prevents the respective DDX driver
(like AMDGPU DDX driver) to take control of the card.

This patch:
- Adds a few functions and fine-tunes the GPU hotplug infrastructure to allow
  the DDX driver to be loaded, if it is configured in the X config file
  options as "hotplug-driver".
- Scans and updates the PCI device list before adding the new GPU device
  in platform, so that the association of the platform device and PCI device
  is in place (dev->pdev).
- Adds documentation of this new option

An example usage in the config file would look like:

Section "OutputClass"
        Identifier "AMDgpu"
        MatchDriver "amdgpu"
        Driver "amdgpu"
	HotplugDriver "amdgpu"
EndSection

V2:
Fixed typo in commit message (Martin)
Added R-B from Adam.
Added ACK from Alex and Martin.

V3:
Added an output class based approach for finding the DDX driver (Aaron)
Rebase

V4:
Addressed review comment from Aaron:
GPU hot-plug handling driver's name to be read from the DDX config file options.
In this way only the DDX drivers interested in handling GPU hot-plug will be
picked and loaded, for others modesetting driver will be used as usual.

V5:
Addressed review comments from Aaron:
- X config option to be listed in CamelCase.
- Indentation fix at one place.
- Code readability related optimization.

V6:
Addressed review comments from Aaron:
- Squash the doc in the same patch
- Doc formatting changes

Cc: Alex Deucher <alexander.deucher@amd.com>
Suggested-by: Aaron Plattner aplattner@nvidia.com (v3)
Acked-by: Martin Roukala <martin.roukala@mupuf.org(v1)>
Acked-by: Alex Deucher alexander.deucher@amd.com (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com(v1)>
Signed-off-by: Shashank Sharma <shashank.sharma@amd.com>

pkubaj authored 2 years ago and Alan Coopersmith committed 2 years ago

Current error:
ld: error: undefined symbol: xf86EnableIO
>>> referenced by xf86Configure.c
>>>               libxorg_common.a.p/xf86Configure.c.o:(DoConfigure) in archive hw/xfree86/common/libxorg_common.a
>>> referenced by xf86Events.c
>>>               libxorg_common.a.p/xf86Events.c.o:(xf86VTEnter) in archive hw/xfree86/common/libxorg_common.a
>>> referenced by xf86Init.c
>>>               libxorg_common.a.p/xf86Init.c.o:(InitOutput) in archive hw/xfree86/common/libxorg_common.a
>>> referenced 1 more times