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>
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 4226c6d, 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 4226c6d, 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 4226c6d, 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 4226c6d, fix the problem by checking
dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv.
Signed-off-by: Alex Goins <agoins@nvidia.com>
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:
deae98ef45Fixes#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>
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>
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>
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>
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: https://gitlab.freedesktop.org/xorg/xserver/-/issues/731
ProcVidModeGetGamma() relies on GetGamma() to initialise values if it
returns TRUE. Without this, we're sending uninitialised values to
clients.
Fixes: xorg/xserver#1040
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>
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: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1024
Fixes: 8774532121 "modesetting: Remove unnecessary fb addition from
drmmode_xf86crtc_resize"
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>
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: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1042
Reviewed-by: Dave Airlie <airlied@redhat.com>
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>
During a VT-Switch a raw pointer to the shared cursor object
is saved which is then freed (in case of low refcount) by a call to
xf86CursorSetCursor with argument pCurs = NullCursor.
This leads to a dangling pointer which can follow in a use after free.
This fix ensures that there is a shared handle saved for the VT-Switch cycle.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
EDID1.4 replaced GTF Bit with Continuous or Non-Continuous Frequency Display.
Check the "Display Range Limits Descriptor" for GTF support.
If panel doesn't support GTF, then add gtf modes.
Otherwise X will only show the modes in "Detailed Timing Descriptor".
V2: Coding style changes.
V3: Coding style changes, remove unused variate.
V4: remove unused variate.
BugLink: https://gitlab.freedesktop.org/drm/intel/issues/313
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When the linux-dmabuf protocol is available, prefer it over the old
wl_drm protocol. Previously wl_drm was used when modifiers aren't
supported, however linux-dmabuf supports formats without modifiers too.
In this case, linux-dmabuf will send a DRM_FORMAT_MOD_INVALID modifier
for each supported format [1].
This allows compositors to better handle these buffers, getting a
DMA-BUF and implementing features like direct scan-out.
A similar logic has been implemented for EGL [2].
DRM_FORMAT_MOD_INVALID is now stored in the xwl_screen->formats list.
glamor_get_modifiers still returns FALSE with zero modifiers if the
only advertised modifier is DRM_FORMAT_MOD_INVALID.
[1]: fb9b2a8731
[2]: c376865f5e
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Previously, linux-dmabuf was used unconditionally if the buffer had a
modifier. However creating a linux-dmabuf buffer with a format/modifier
which hasn't been advertised will fail.
Change xwl_glamor_gbm_get_wl_buffer_for_pixmap to use linux-dmabuf when
the format/modifier has been advertised only.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1035
Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This flag should only be used when the caller intends to display the
buffer on a hardware plane. Xwayland isn't a DRM client, so it doesn't
make sense to use this flag.
This change will allow the driver to potentially use buffer parameters
that are more optimized.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Without this the client library will flail around looking for a default
provider, probably one named "indirect", and that defeats the point of
having the EGL provider for direct context support in the first place.
This assumes that "mesa" will work, of course, and in general it should.
Mesa drivers will DTRT through the DRI3 setup path, and if our glamor is
atop something non-Mesa then you should fall back to llvmpipe like 1.20.
In the future it might be useful to differentiate the vendor here based
on whether glamor is using gbm or streams.
Fixes: xorg/xserver#1032
None of the current BSD is actually using this code.
(checked DragonFly 5.8.1, FreeBSD 11.2, NetBSD 9.0 and OpenBSD 6.7)
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
In file included from ../glx/glxdri2.c:35:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
#include <drm.h>
^~~~~~~
In file included from ../glx/glxdriswrast.c:39:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
#include <drm.h>
^~~~~~~
../os/xsha1.c:36:10: fatal error: 'sha1.h' file not found
#include <sha1.h>
^~~~~~~~
../os/xsha1.c:45:5: error: implicit declaration of function 'SHA1Init' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
SHA1Init(ctx);
^
../os/xsha1.c:54:5: error: implicit declaration of function 'SHA1Update' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
SHA1Update(sha1_ctx, data, size);
^
../os/xsha1.c:63:5: error: implicit declaration of function 'SHA1Final' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
SHA1Final(result, sha1_ctx);
^
Xwayland uses the device private to point to the `xwl_seat`.
Device may be removed at any time, including on suspend.
On resume, if the DIX code ends up calling a function that requires the
`xwl_seat` such as `xwl_set_cursor()` we may end up pointing at random
data.
Make sure the clear the device private data on removal so that we don't
try to use it and crash later.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
https://gitlab.freedesktop.org/xorg/xserver/issues/709
wayland/ci-templates was moved to freedesktop/ci-templates, everything
else stayed the same so the sha is still valid.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Drop GBM_BO_USE_SCANOUT from the GBM_BO_IMPORT_FD import, add
GBM_BO_USE_RENDERING to the GBM_BO_IMPORT_FD_MODIFIER import.
If the DMA-BUF cannot be scanned out, gbm_bo_import with
GBM_BO_USE_SCANOUT will fail. However Xwayland doesn't need to scan-out
the buffer and can work fine without scanout. Glamor only needs
GBM_BO_USE_RENDERING.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
In this pretty Wine/Proton specific kludge, we try to handle confining grabs
on InputOnly windows by trying to find the InputOutput window that the pointer
would get visually confined to.
The grabbing window and the visible window come from different clients, so
we used to simply resort to the pointer focus. This is troublesome though, as
the call may happen very soon at a time that the toplevel wasn't yet mapped by
the Wayland compositor, so the pointer focus may well be out of date soon.
In these situations, it does seem that even though the confining grab happens
too early to have the wayland surface mapped, the xserver view of the WindowPtr
does already reflect the size. Use this to find out the better window to
assign the confining grab to, one whose geometry fully contains the InputOnly
window's.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
xwl_seat_maybe_lock_on_hidden_cursor() checks that the value of
cursor_confinement_window is not NULL, yet there is no code path
that could lead to this.
Remove the test for cursor_confinement_window being set, it's useless.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When an X11 client issues a ConfinePointer wit ha hidden cursor,
Xwayland may translate that as a pointer lock.
However, if the pointer is located on another window at the time,
the request may be ignored, even if the pointer later enters the window.
To avoid that issue, check again if locking the pointer with a hidden
cursor is needed when pointer enters a surface.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When an X11 client has an active grab on the pointer, all events are
reported relative to the window with the grab.
For Xwayland, if an X11 client has a grab with a pointer confinement
active, while pointer focus is on another window, motion events should
not be reported to the client with the grab, because that sets the X11
client appart, the events would be reported when the pointer is on any
X11 window but not on Wayland native surfaces.
Therefore, if the pointer is confined on a window and that window
differs from the actual pointer focus window, just pretend we lost
pointer focus to another window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/962
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If a client issues a grab on the pointer while the cursor is on another
X11 window, and then hides the cursor, we may end up locking the pointer
onto that other window.
Then a button click might end up moving the focus away from the window
which issued the grab, leaving the whole setup in a mixed up state.
Typically, if the pointer is on another X11 window, we should not try to
lock the pointer, so that it can be moved back to the window which
actually issues the grab (and hence the pointer confinement). Typically,
this is the same as an X11 client issuing a pointer grab while the
cursor is on another Wayland native window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/962
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Mostly http->https conversions, but also replaces gitweb.fd.o
with gitlab.fd.o, and xquartz.macosforge.org with xquartz.org.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Roman Gilg
Alex Goins
Michel Dänzer
Emmanuel Gil Peyrot
Lyude Paul
Dave Airlie
Olivier Fourdan
Alan Coopersmith
SimonP
Sjoerd Simons
Jose Maria Casanova Crespo
Martin Weber
Aaron Ma
Simon Ser
Adam Jackson
Matthieu Herrb
Jan Beich
Peter Hutterer
Carlos Garnacho