GitLab

Adam Jackson authored Aug 14, 2020 and Adam Jackson committed Aug 18, 2020

You will not find GL_ARB_* extensions in a GLES context by definition,
the droid you're looking for is named GL_KHR_debug.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

Xwayland is just a Wayland client, no X11 screensaver should be
expected to work reliably on Xwayland when running rootless because
Xwayland cannot grab the input devices so it has no way to actually
lock the screen managed by the Wayland compositor.

Turn off the screensaver on Xwayland when running rootless by setting
the screensaver timeout and interval and their default values to zero
and disable the MIT-SCREEN-SAVER extension.

Closes: xorg/xserver#1051

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

Matthieu Herrb authored Jul 25, 2020 and Alan Coopersmith committed Jul 31, 2020

Avoid leaking un-initalized memory to clients by zeroing the
whole pixmap on initial allocation.

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

Ignacio Casal authored Jul 16, 2020 and Peter Hutterer committed Jul 31, 2020

Replicate 7d2543a3 but for
all types of X servers

Roman Gilg authored Jul 28, 2020 and Michel Dänzer committed Jul 30, 2020

Instead of optionally return early when an event is aborted and potentially
clean it up in there we can only optionally inform Present if not aborted and
afterwards clean it up if required.

Saves some lines of code and conditional branches.
Signed-off-by: Roman Gilg <subdiff@gmail.com>

Update commit ea47af87 renaming master_pixmap to primary_pixmap in
struct PixmapRec.

On a DT-base PCI platform, the sysfs path of vga device is like this:
/sys/devices/platform/bus@10000000/1a000000.pci/pci0000:00/0000:00:11.0/0000:04:00.0.

Then the ID_PATH from udev is platform-1a000000.pci-pci-0000:04:00.0 and
the BusID will be pci-0000:04:00.0, which causes Xorg start fail. This
is because config_udev_odev_setup_attribs() use strstr() to search the
first "pci-" in ID_PATH. To fix this, we implement a strrstr() function
and use it to search the last "pci-" in ID_PATH, which can get a correct
BusID.
Signed-off-by: Huacai Chen <chenhc@lemote.com>

For Pixmap flips to have well defined outcomes the window must be contained by
the valid region if such region was specified.

The valid region is inserted as an argument to the check in window mode.
Setting this argument is missing in screen mode as well but we ignore it for now
and only add it to window mode.

It seems there are none or only very few clients actually making use of valid
regions at the moment. For simplicity we therefore just check if a valid region
was set by the client and in this case do never flip, independently of the
window being contained by the region or not.
Signed-off-by: Roman Gilg <subdiff@gmail.com>

The function is never called from present_screen.c in contrast to the behavior
in screen mode.

In present_wnmd.c we can simply remove the function which does an unnecessary
check of the property before setting it and directly set the property at the
two locations the function was called previously.
Signed-off-by: Roman Gilg <subdiff@gmail.com>

With the newly introduced separate API method for idling a presented Pixmap in
window mode we can simplify the logic by allowing calls to it at any point in
time.

This is done by setting the flip_idler flag if the Pixmap was idled before
being presented.
Signed-off-by: Roman Gilg <subdiff@gmail.com>

Notifying Present about events' states was done prior with the single function
present_wnmd_event_notify just like in screen mode. But it is more intelligible
if at least in window mode we make use of three different functions with names
that directly indicate what their purpose is:

* present_wnmd_event_notify only for queued events feedback.
* present_wnmd_flip_notify for when a presentation occured (flip).
* present_wnmd_idle_notify for when the Pixmap of the event can be reused.

This is an API-breaking change in regards to window mode. DDX written against
the previous version won't work anymore. It is assumed that there only exists
the XWayland DDX at the moment using the window mode such that this is not an
issue for the overall ecosystem.
Signed-off-by: Roman Gilg <subdiff@gmail.com>

Rename the lists release_queue to release_list and event_list to
wait_list.

The prior names release_queue and event_list were ambiguous: in both are event-
like vblanks which can be removed from the lists in random order. In the
release_queue can be flips that are already released but still wait for the
sync or frame callback but normally the release comes later. In the event_list
are queued events waiting for a later msc.
Signed-off-by: Roman Gilg <subdiff@gmail.com>

In xwl_present_window an xwl_screen entry was declared but never actually used.
Signed-off-by: Roman Gilg <subdiff@gmail.com>

Commit 1e3f9ea1

 removed some NULL checks from xf86RandR12.c, on the premise that
they can't be reached unless RandR has already been initialized. For threesuch
calls, that's not true:

xf86Crtc.c::xf86CrtcScreenInit():

    if (c == config->num_crtc) {
        xf86RandR12SetRotations(screen, RR_Rotate_0 | RR_Rotate_90 |
                                RR_Rotate_180 | RR_Rotate_270 |
                                RR_Reflect_X | RR_Reflect_Y);
        xf86RandR12SetTransformSupport(screen, TRUE);
    }
    else {
        xf86RandR12SetRotations(screen, RR_Rotate_0);
        xf86RandR12SetTransformSupport(screen, FALSE);
    }

xf86Crtc.c::xf86CrtcCloseScreen():

    xf86RandR12CloseScreen(screen);

This change adds checks back to xf86RandR12Set{Rotations,TransformSupport}() and
xf86RandR12CloseScreen(), checking that xf86RandR12KeyRec has been registered.
Without this, X will hit an assert that causes it to abort.
Signed-off-by: Alex Goins <agoins@nvidia.com>

RRHasScanoutPixmap() is called from xf86CheckHWCursor(), regardless of whether
or not RandR has been initialized.

As mentioned in commit 4226c6d0, it's possible that RandR has not been
initialized if the server is configured with Xinerama and there is more than one
X screen. Calling rrGetScrPriv when RandR isn't initialized causes an assertion
failure that aborts the server:

      Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion
      key->initialized' failed.

Just as in commit 4226c6d0

, fix the problem by checking
dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv.
Signed-off-by: Alex Goins <agoins@nvidia.com>

RRProviderAutoConfigGpuScreen() is called from outside RandR, so there is no
guarantee that RandR has been initialized when it is called.

As mentioned in commit 4226c6d0, it's possible that RandR has not been
initialized if the server is configured with Xinerama and there is more than one
X screen. Calling rrGetScrPriv when RandR isn't initialized causes an assertion
failure that aborts the server:

  Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion
  key->initialized' failed.

Just as in commit 4226c6d0

, fix the problem by checking
dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv.
Signed-off-by: Alex Goins <agoins@nvidia.com>

Michel Dänzer authored Jul 10, 2020 and Michel Dänzer committed Jul 21, 2020

This can happen e.g. with weston's headless backend.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>

Link Mauve authored Jul 11, 2020 and Peter Hutterer committed Jul 20, 2020

This (so-far) Linux-only API lets users create file descriptors purely
in memory, without any backing file on the filesystem and the race
condition which could ensue when unlink()ing it.

It also allows seals to be placed on the file, ensuring to every other
process that we won’t be allowed to shrink the contents, potentially
causing a SIGBUS when they try reading it.

This patch is best viewed with the -w option of git log -p.

This is a port of this commit from Weston:
wayland/weston@deae98ef



Fixes #848.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>

When a slave device causes the master virtual pointer device to change
device types, the device's private data pointer
(device->public.devicePrivate) is also changed to match the type of the
slave device. This can be a problem though, as tablet pad devices will
set the device's private data pointer to their own xwl_tablet_pad
struct. This can cause us to dereference the pointer as the wrong type,
and result in a segfault:

Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at src/wayland-client.c:792
792             va_start(ap, opcode);
(gdb) bt
0  wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at
  src/wayland-client.c:792
1  0x00005610b27b6c55 in wl_pointer_set_cursor (hotspot_y=0,
  hotspot_x=0, surface=0x0, serial=<optimized out>, wl_pointer=<optimized
  out>) at /usr/include/wayland-client-protocol.h:4610
2  xwl_seat_set_cursor (xwl_seat=xwl_seat@entry=0x5610b46d5d10) at
  xwayland-cursor.c:137
3  0x00005610b27b6ecd in xwl_set_cursor (device=<optimized out>,
  screen=<optimized out>, cursor=<optimized out>, x=<optimized out>,
  y=<optimized out>) at xwayland-cursor.c:249
4  0x00005610b2800b46 in miPointerUpdateSprite (pDev=0x5610b4501a30) at
  mipointer.c:468
5  miPointerUpdateSprite (pDev=0x5610b4501a30) at mipointer.c:410
6  0x00005610b2800e56 in miPointerDisplayCursor (pCursor=0x5610b4b35740,
  pScreen=0x5610b3d54410, pDev=0x5610b4501a30) at mipointer.c:206
7  miPointerDisplayCursor (pDev=0x5610b4501a30, pScreen=0x5610b3d54410,
  pCursor=0x5610b4b35740) at mipointer.c:194
8  0x00005610b27ed62b in CursorDisplayCursor (pDev=<optimized out>,
  pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at cursor.c:168
9  0x00005610b28773ee in AnimCurDisplayCursor (pDev=0x5610b4501a30,
  pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at animcur.c:197
10 0x00005610b28eb4ca in ChangeToCursor (pDev=0x5610b4501a30,
  cursor=0x5610b4b35740) at events.c:938
11 0x00005610b28ec99f in WindowHasNewCursor
  (pWin=pWin@entry=0x5610b4b2e0c0) at events.c:3362
12 0x00005610b291102d in ChangeWindowAttributes (pWin=0x5610b4b2e0c0,
  vmask=<optimized out>, vlist=vlist@entry=0x5610b4c41dcc,
  client=client@entry=0x5610b4b2c900) at window.c:1561
13 0x00005610b28db8e3 in ProcChangeWindowAttributes (client=0x5610b4b2c900)
  at dispatch.c:746
14 0x00005610b28e1e5b in Dispatch () at dispatch.c:497
15 0x00005610b28e5f34 in dix_main (argc=16, argv=0x7ffc7a601b68,
  envp=<optimized out>) at main.c:276
16 0x00007f8828cde042 in __libc_start_main (main=0x5610b27ae930 <main>,
  argc=16, argv=0x7ffc7a601b68, init=<optimized out>, fini=<optimized
  out>, rtld_fini=<optimized out>, stack_end=0x7ffc7a601b58) at
  ../csu/libc-start.c:308
17 0x00005610b27ae96e in _start () at cursor.c:1064

Simple reproducer in gnome-shell: open up an Xwayland window, press some
tablet buttons, lock and unlock the screen. Repeat if it doesn't crash
the first time.

So, let's fix this by registering our own device-specific private key
for storing a backpointer to xwl_tablet_pad, so that all input devices
have their private data pointers set to their respective xwl_seat.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Lyude Paul <lyude@redhat.com>

Roman Gilg authored Jul 08, 2020 and Michel Dänzer committed Jul 14, 2020

In 9141196d

 positional coordinates were added to the damage call of pixmap
flips. The damage box coordinates are in screen space though and we need
to convert them first to surface-relative ones by substracting the origin
of the window.
Signed-off-by: Roman Gilg <subdiff@gmail.com>

This gives out of tree drivers a fighting chance to build against both
sides of
xorg/xserver!468

 .
Reviewed-by: Dave Airlie <airlied@redhat.com>

This is an API and ABI break
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

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

Olivier Fourdan authored Apr 20, 2020 and Olivier Fourdan committed Jul 08, 2020

Xwayland is usually spawned by the Wayland compositor which sets the
command line options.

If a command line option is not supported, Xwayland will fail to start.

That somehow makes the Xwayland command line option sort of ABI, the
Wayland compositor need to know if a particular option is supported by
Xwayland at build time.

Also, currently, Xwayland is being installed along with the rest of the
common executable programs that users may run, which is sub-optimal
because, well, Xwayland is not a common executable program, it's meant
to be a proxy between the Wayland compositor and the legacy X11 clients
which wouldn't be able to run on Wayland otherwise.

Xwayland would be better installed in `libexec` but that directory is
(purposedly) not in the user `PATH` and therefore the Wayland compositor
may not be able to find Xwayland in that case.

To solve both problems (which options are supported by Xwayland and
where to look for it), add a `pkg-config` file specifically for Xwayland
which gives the full path to Xwayland (`xwayland`) and which options it
supports (using `pkg-config` variables).

The `pkg-config` file also provides the `Version` so the build scripts
can check for a particular version if necessary.

Obviously, Wayland compositors are not required to use the `pkg-config`
file and can continue to use whatever mechanism they deem preferable.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

Michel Dänzer authored Mar 17, 2020 and Michel Dänzer committed Jul 07, 2020

It was already declared in xwayland-screen.h, and only takes a screen
parameter, no window ones.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>

Michel Dänzer authored Jun 25, 2020 and Michel Dänzer committed Jul 07, 2020

Seems clearer.

While we're at it, also drop the unused pixmap parameter.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>

Michel Dänzer authored Jun 25, 2020 and Michel Dänzer committed Jul 07, 2020

No need for the separate boolean.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>

Michel Dänzer authored Mar 17, 2020 and Michel Dänzer committed Jul 07, 2020

This couldn't have worked correctly for non-0 x1/y1.

Noticed by inspection.
Reviewed-by: Simon Ser <contact@emersion.fr>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Most (but not all) of these were found by using
  codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Olivier Fourdan authored Jun 02, 2020 and Michel Dänzer committed Jul 03, 2020

The way Xwayland works (like all Wayland clients), it first queries the
Wayland registry, set up all relevant protocols and then initializes its
own structures.

That means Xwayland will get the Wayland outputs from the Wayland
compositor, compute the physical size of the combined outputs and set
the corresponding Xwayland screen properties accordingly.

Then it creates the X11 screen using fbScreenInit() but does so by using
a default DPI value of 96. That value is used to set the physical size
of the X11 screen, hence overriding the value computed from the actual
physical size provided by the Wayland compositor.

As a result, the DPI computed by tools such as xdpyinfo will always be
96 regardless of the actual screen size and resolution.

However, if the Wayland outputs get reconfigured, or new outputs added,
or existing outputs removed, Xwayland will recompute and update the
physical size of the screen, leading to an unexpected change of DPI.

To avoid that discrepancy, use a fixed size DPI (defaults to 96, and can
be set using the standard command lime option "-dpi") and compute a
physical screen size to match that DPI setting.

Note that only affects legacy core protocols, X11 clients can still get
the actual physical output size as reported by the Wayland compositor
using the RandR protocol, which also allows for the size to be 0 if the
size is unknown or meaningless.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Closes: xorg/xserver#731

SimonPilkington authored Jun 09, 2020 and Michel Dänzer committed Jul 03, 2020

ProcVidModeGetGamma() relies on GetGamma() to initialise values if it
returns TRUE. Without this, we're sending uninitialised values to
clients.

Fixes: #1040

Sjoerd Simons authored Apr 10, 2020 and Peter Hutterer committed Jul 02, 2020

When running with a weston session without a pointer device (thus with
the wl_seat not having a pointer) xwayland pointer warping and pointer
confining should simply be ignored to avoid crashes.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

José María Casanova Crespo authored May 15, 2020 and José María Casanova Crespo committed Jun 27, 2020

Since the introduction of "modesetting: Remove unnecessary fb addition from
drmmode_xf86crtc_resize" the fb_id isn't initialited at
drmmode_xf86crtc_resize.

Rotate operation of XRandR uses rotate_bo. So in this case the fb_id
associated to the front_bo is not initialized at drmmode_set_mode_major.
So fd_id remains 0.

As every call to drmmode_xf86crtc_resize allocates a new front_bo we should
destroy unconditionally the old_front_bo if operation success. So we free
the allocated GBM handles.

This avoids crashing xserver with a OOM in the RPI4 1Gb at 4k resolution
after 3 series xrandr rotations from normal to left and vice versa reported at
https://github.com/raspberrypi/firmware/issues/1345

Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Closes: xorg/xserver#1024
Fixes: 87745321 "modesetting: Remove unnecessary fb addition from
       drmmode_xf86crtc_resize"

Michel Dänzer authored Jun 19, 2020 and Michel Dänzer committed Jun 25, 2020

These events aren't reachable after xwl_present_cleanup, so they're
leaked if we don't free them first.

This requires storing the pixmap pointer in struct xwl_present_window.
Luckily, the buffer pointer isn't used for anything, so just replace
that.

v2:
* Bump pixmap reference count in xwl_present_flip and drop it in
  xwl_present_free_event, fixes use-after-free in the latter due to the
  pixmap already being destroyed.
Reviewed-by: Dave Airlie <airlied@redhat.com>

Michel Dänzer authored Jun 19, 2020 and Michel Dänzer committed Jun 25, 2020

Minor cleanup, and will make the next change simpler. No functional
change intended.
Reviewed-by: Dave Airlie <airlied@redhat.com>

Michel Dänzer authored Jun 19, 2020 and Michel Dänzer committed Jun 25, 2020

When present_wnmd_clear_window_flip is done, present_destroy_window
frees struct present_window_priv, and the events in the flip queue
become unreachable. So if we don't free them first, they're leaked.

Also drop the call to present_wnmd_set_abort_flip, which just sets a
flag in struct present_window_priv and thus can't have any observable
effect after present_destroy_window.

Closes: xorg/xserver#1042

Reviewed-by: Dave Airlie <airlied@redhat.com>

Michel Dänzer authored Jun 19, 2020 and Michel Dänzer committed Jun 25, 2020

The comment was incorrect: Any reference held by the window (see
present_wnmd_execute) is in addition to the one in struct present_vblank
(see present_vblank_create). So if we don't drop the latter, the pixmap
will be leaked.
Reviewed-by: Dave Airlie <airlied@redhat.com>