Instead of reusing xwl_window introduce a persistent window struct for every
window, that asks for Present flips.
This struct saves all relevant data and is only freed on window destroy.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Clean up only if the request points to the presenting window or its top
parent window.
Since in this case all events are removed unconditionally, always stop
the timer.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Roman Gilg <subdiff@gmail.com>
There's no real point - if we don't have EGL then the extension check is
also going to fail - and the entrypoint is new in 1.5.0, which we don't
need to require yet.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
This adds initial support for displaying Xwayland applications through
the use of EGLStreams and nvidia's custom wayland protocol by adding
another egl_backend driver. This also adds some additional egl_backend
hooks that are required to make things work properly.
EGLStreams work a lot differently then the traditional way of handling
buffers with wayland. Unfortunately, there are also a LOT of various
pitfalls baked into it's design that need to be explained.
This has a very large and unfortunate implication: direct rendering is,
for the time being at least, impossible to do through EGLStreams. The
main reason being that the EGLStream spec mandates that we lose the
entire color buffer contents with each eglSwapBuffers(), which goes
against X's requirement of not losing data with pixmaps. no way to use
an allocated EGLSurface as the storage for glamor rendering like we do
with GBM, we have to rely on blitting each pixmap to it's respective
EGLSurface producer each frame. In order to pull this off, we add two
different additional egl_backend hooks that GBM opts out of
implementing:
- egl_backend.allow_commits for holding off displaying any EGLStream
backed pixmaps until the point where it's stream is completely
initialized and ready for use
- egl_backend.post_damage for blitting the content of the EGLStream
surface producer before Xwayland actually damages and commits the
wl_surface to the screen.
The other big pitfall here is that using nvidia's wayland-eglstreams
helper library is also not possible for the most part. All of it's API
for creating and destroying streams rely on being able to perform a
roundtrip in order to bring each stream to completion since the wayland
compositor must perform it's job of connecting a consumer to each
EGLstream. Because Xwayland has to potentially handle both responding to
the wayland compositor and it's own X clients, the situation of the
wayland compositor being one of our X clients must be considered. If we
perform a roundtrip with the Wayland compositor, it's possible that the
wayland compositor might currently be connected to us as an X client and
thus hang while both Xwayland and the wayland compositor await responses
from eachother. To avoid this, we work directly with the wayland
protocol and use wl_display_sync() events along with release() events to
set up and destroy EGLStreams asynchronously alongside handling X
clients.
Additionally, since setting up EGLStreams is not an atomic operation we
have to take into consideration the fact that an EGLStream can
potentially be created in response to a window resize, then immediately
deleted due to another pending window resize in the same X client's
pending reqests before Xwayland hits the part of it's event loop where
we read from the wayland compositor. To make this even more painful, we
also have to take into consideration that since EGLStreams are not
atomic that it's possible we could delete wayland resources for an
EGLStream before the compositor even finishes using them and thus run
into errors. So, we use quite a bit of tracking logic to keep EGLStream
objects alive until we know the compositor isn't using them (even if
this means the stream outlives the pixmap it backed).
While the default backend for glamor remains GBM, this patch exists for
users who have had to deal with the reprecussion of their GPU
manufacturers ignoring the advice of upstream and the standardization of
GBM across most major GPU manufacturers. It is not intended to be a
final solution to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream backend.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This takes all of the gbm related code in wayland-glamor.c and moves it
into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
Additionally, we add the egl_backend struct into xwl_screen in order to
provide hooks for alternative EGL backends such as nvidia's EGLStreams.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Regardless of the order we un-realize windows.
Suggested-by: Roman Gilg <subdiff@gmail.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
xwl_unrealize_window() would use freed xwl_window which can lead to
various memory corruption and crashes, as reported by valgrind:
Invalid read of size 8
at 0x42C802: xwl_present_cleanup (xwayland-present.c:84)
by 0x42BA67: xwl_unrealize_window (xwayland.c:601)
by 0x541EE9: compUnrealizeWindow (compwindow.c:285)
by 0x57E1FA: UnrealizeTree (window.c:2816)
by 0x581189: UnmapWindow (window.c:2874)
by 0x54EB26: ProcUnmapWindow (dispatch.c:879)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
Address 0xf520f60 is 96 bytes inside a block of size 184 free'd
at 0x4C2EDAC: free (vg_replace_malloc.c:530)
by 0x42B9FB: xwl_unrealize_window (xwayland.c:624)
by 0x541EE9: compUnrealizeWindow (compwindow.c:285)
by 0x57E1FA: UnrealizeTree (window.c:2816)
by 0x581189: UnmapWindow (window.c:2874)
by 0x54EB26: ProcUnmapWindow (dispatch.c:879)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
Block was alloc'd at
at 0x4C2FB06: calloc (vg_replace_malloc.c:711)
by 0x42B307: xwl_realize_window (xwayland.c:488)
by 0x541E59: compRealizeWindow (compwindow.c:268)
by 0x57DA40: RealizeTree (window.c:2617)
by 0x580B28: MapWindow (window.c:2694)
by 0x54EA2A: ProcMapWindow (dispatch.c:845)
by 0x554B7D: Dispatch (dispatch.c:479)
by 0x558BE5: dix_main (main.c:276)
by 0x7C4B1BA: (below main) (libc-start.c:308)
This is because UnrealizeTree() traverses the tree from top to bottom,
which invalidates the assumption that if the Window doesn't feature an
xwl_window on its own, it's the xwl_window of its first ancestor with
one.
This reverts commit 82df2ce3
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Present support in Xwayland relies on glamor, make sure Xwayland can
be built without glamor by moving references to Present code inside
the conditional GLAMOR_HAS_GBM.
Reported-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Turns out that's legal, and xts exercises it, and we crash:
Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
dixGetPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:122
122 return (char *) (*privates) + key->offset;
(gdb) bt
#0 dixGetPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:122
#1 dixLookupPrivate (key=0x813660 <xwl_window_private_key>, privates=0x20) at ../../include/privates.h:166
#2 xwl_window_of_top (window=0x0) at xwayland.c:128
#3 xwl_cursor_warped_to (device=<optimized out>, screen=0x268b6e0, client=<optimized out>, window=0x0, sprite=0x300bb30,
x=2400, y=1350) at xwayland.c:292
#4 0x00000000005622ec in ProcWarpPointer (client=0x32755d0) at events.c:3618
In this case, x/y are the screen-space coordinates where the pointer
ends up, and we need to look up the (X) window there.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The caller may ignore the return value (will be addressed with later
commit) so simply zero the count from the get-go. We're pretty much do
so, in all cases but one :-\
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
It makes it perfectly clear that we should not be modifying them.
Should help highlight issues like the one fixed with previous commit.
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The glamor_pixmap_from_fds error path erroneously closes the fds.
We don't own them, plus the caller closes them after the function in
called.
Fixes: cef12efc15 ("glamor: Implement GetSupportedModifiers")
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
dri3_screen_info is the user provide dispatch. Something that we do
not and should not change.
When using the _ptr typecast + const the compiler barfs at us
(rightfully so), so use the _rec one.
[Silence a new const mismatch warning too - ajax]
Fixes: 5631382988 ("dri3: Add DRI3 extension")
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
[735/786] Generating 'hw/xwayland/Xwayland@exe/relative-pointer-unstable-v1-protocol.c'.
Using "code" is deprecated - use private-code or public-code.
See the help page for details.
Use private-code if wayland-scanner is new enough.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Link the newly introduced support for Present flips. For now flips can only
be used in rootless mode together with Glamor.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Queue present events to msc values. Fake msc events with a refresh rate of
about 60fps when flips are not possible. When flips are executed rely on
frame callbacks with a slow updating timer as fallback.
This is important for applications, that want to limit their framerate.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When the compositor is not sending frame callbacks while we still wait
on buffer release events fake a continuous msc counter with a timer.
Having this timer is a prerequisite for queuing events.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Introduce support for Present's window flip mode. The support is not yet
complete, but works reasonable well for the most important use case, that
is fullscreen applications.
We take a Present flip and if the xwl_window->window has the same dimensions
as the presenting window, the flip is represented by a wl_buffer and attached
to the main wl_surface of the xwl_window.
After commit we are listening for the sync callback in order to tell Present,
that the pixmap flip is not longer pending, for the frame callback in order
to update the msc counter and for the buffer release callback in order to tell
Present that the pixmap is idle again.
The following functionality is missing from this patch:
* (slowed down) flips in case the compositor is not sending frame callbacks,
* queuing events to MSC times,
* per window flips for child windows with smaller size than the xwl_window.
To make use of this functionality Xwayland must run rootless and with
Glamor/GBM.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Add arguments to give the caller more information and control
over the creation of a wl_buffer with GBM, in particular let
the caller determine the size of the buffer.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Using modifier might allow the driver to use a more optimal format
(e.g. tiled/compressed). Let's try to use those if possible.
v2: Don't filter out multi-plane modifiers
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Implement function added in DRI3 v1.1.
A newest version of libepoxy (>= 1.4.4) is required as earlier
versions use a problematic version of Khronos
EXT_image_dma_buf_import_modifiers spec.
v4: Only send scanout-supported modifiers if flipping is possible
v5: Fix memory corruption in XWayland (uninitialized pointer)
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
It relies on GBM >= 17.1.0 where we can import BO with multiple
planes and a format modifier (GBM_BO_IMPORT_FD_MODIFIER).
v2: Properly free fds in Xwayland
[Also add glamor_egl_ext.h to Makefile.am for distcheck's sake - ajax]
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Initial implementation for DRI3 v1.1. Only the DRI3 implementation
is there, backends need to implement the proper hooks.
Version is still set to 1.0 so clients shouldn't use the new
requests yet.
v2: Use depth/bpp instead of DRM formats in requests
v3: Remove DMA fence requests from v1.1
Add screen/drawable modifier sets
v4: Free array returned by 'get_drawable_modifiers()'
v5: Fix FD leak
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When xdg_output support was added to Xwayland, need_rotate parameter was
added to output_get_new_size where true gave you the old pre-xdg_output
behavior and false gave the new behavior. Unfortunately, the two places
where this is called, need_rotate was set backwards. This caused input
get clampped to the wrong dimensions. Also, the logic for deciding
whether or not to flip was wrong because, if need_rotate was false, it
would always flip which is not what you want.
v2 (Daniel Stone):
- Fix output_get_new_size so that it doesn't flip the dimensions when
need_rotate is false.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Add a stub for Xnest so it continues to link, but otherwise we support
GLX on every server so there's no need to make every DDX add it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The big change here is MakeCurrent and context tag tracking. We now
delegate context tags entirely to the vnd layer, and simply store a
pointer to the context state as the tag data. If a context is deleted
while it's current, we allocate a fake ID for the context and move the
context state there, so the tag data still points to a real context. As
a result we can stop trying so hard to detach the client from contexts
at disconnect time and just let resource destruction handle it.
Since vnd handles all the MakeCurrent protocol now, our request handlers
for it can just be return BadImplementation. We also remove a bunch of
LEGAL_NEW_RESOURCE, because now by the time we're called vnd has already
allocated its tracking resource on that XID.
v2: Update to match v2 of the vnd import, and remove more redundant work
like request length checks.
v3: Add/remove the XID map from the vendor private thunk, not the
backend. (Kyle Brenneman)
v4: Fix deletion of ghost contexts (Kyle Brenneman)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Unfortunately, on my machine Xwayland immediately crashes when I try to
start it. gdb backtrace:
#0 0x00007ffff74f0e79 in wl_proxy_marshal () from target:/lib64/libwayland-client.so.0
#1 0x0000000000413172 in zwp_confined_pointer_v1_destroy (zwp_confined_pointer_v1=0x700000000)
at hw/xwayland/Xwayland@exe/pointer-constraints-unstable-v1-client-protocol.h:612
#2 0x0000000000418bc0 in xwl_seat_destroy_confined_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2839
#3 0x0000000000418c09 in xwl_seat_unconfine_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2849
#4 0x0000000000410d97 in xwl_cursor_confined_to (device=0xa5a000, screen=0x8b9d80, window=0x9bdb70)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland.c:328
#5 0x00000000004a8571 in ConfineCursorToWindow (pDev=0xa5a000, pWin=0x9bdb70, generateEvents=1,
confineToScreen=0) at /home/lyudess/Projects/xserver/dix/events.c:900
#6 0x00000000004a94b7 in ScreenRestructured (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/dix/events.c:1387
#7 0x0000000000502386 in RRScreenSizeNotify (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/randr/rrscreen.c:160
#8 0x000000000041a83c in update_screen_size (xwl_output=0x8e7670, width=3840, height=2160)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:203
#9 0x000000000041a9f0 in apply_output_change (xwl_output=0x8e7670)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:252
#10 0x000000000041aaeb in xdg_output_handle_done (data=0x8e7670, xdg_output=0x8e7580)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:307
#11 0x00007ffff50e9d1e in ffi_call_unix64 () at ../src/x86/unix64.S:76
#12 0x00007ffff50e968f in ffi_call (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>,
avalue=<optimized out>) at ../src/x86/ffi64.c:525
#13 0x00007ffff74f3d8b in wl_closure_invoke () from target:/lib64/libwayland-client.so.0
#14 0x00007ffff74f0928 in dispatch_event.isra () from target:/lib64/libwayland-client.so.0
#15 0x00007ffff74f1be4 in wl_display_dispatch_queue_pending () from target:/lib64/libwayland-client.so.0
#16 0x00007ffff74f200b in wl_display_roundtrip_queue () from target:/lib64/libwayland-client.so.0
#17 0x0000000000418cad in InitInput (argc=12, argv=0x7fffffffd9c8)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2867
#18 0x00000000004a20e3 in dix_main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30)
at /home/lyudess/Projects/xserver/dix/main.c:250
#19 0x0000000000420cb2 in main (argc=12, argv=0x7fffffffd9c8, envp=0x7fffffffda30)
at /home/lyudess/Projects/xserver/dix/stubmain.c:34
This appears to be the result of xwl_cursor_confined_to() and
xwl_screen_get_default_seat(). While not against protocol, mutter ends
up sending xdg_output before wl_seat. xwl_screen_get_default_seat()
makes the naïve assumption that we always have a valid seat, we end up
returning a pointer to the empty list itself instead of an actual seat
and causing ourselves to segfault.
So, actually return NULL in xwl_screen_get_default_seat() if the seat
list is empty, and skip any pointer confinement processing in
xwl_cursor_confined_to() when we don't have a seat setup yet.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Place a manual redirect on windows on xwl_realize_window() and remove
it on xwl_unrealize_window() to avoid the X11 window manager removing
its redirect before Xwayland has unrealized the window (e.g. if the X11
window manager has terminated unexpectedly)
Suggested by Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
This is a rare occurrence of a crash in Xwayland for which I don't have
the reproducing steps, just a core file.
The backtrace looks as follow:
#0 raise () from /usr/lib64/libc.so.6
#1 abort () from /usr/lib64/libc.so.6
#2 OsAbort () at utils.c:1361
#3 AbortServer () at log.c:877
#4 FatalError () at log.c:1015
#5 OsSigHandler () at osinit.c:154
#6 <signal handler called>
#7 xwl_glamor_pixmap_get_wl_buffer () at xwayland-glamor.c:162
#8 xwl_screen_post_damage () at xwayland.c:514
#9 block_handler () at xwayland.c:665
#10 BlockHandler () at dixutils.c:388
#11 WaitForSomething () at WaitFor.c:219
#12 Dispatch () at dispatch.c:422
#13 dix_main () at main.c:287
The crash is caused by dereferencing “xwl_pixmap->buffer” in
xwl_glamor_pixmap_get_wl_buffer() because “xwl_pixmap” is NULL.
Reason for this is because the corresponding pixmap is from the root
window and xwayland is rootless by default.
This can happen if the window was mapped, redirected, damaged and
unredirected immediately, before the damage is processed by Xwayland.
Make sure to remove the dirty window from the damage list on unrealize
to prevent this from happening.
Credit goes to Adam Jackson <ajax@nwnk.net> and Daniel Stone
<daniel@fooishbar.org> for finding the root cause the issue.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
BTN_STYLUS3 has been introduced by the Linux 4.15 kernel to report the
status of the third button present on Wacom's new "Pro Pen 3D" stylus.
Treat this button like xf86-input-wacom and send a button 8 event
("navigate back") when received from Wayland.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The xdg-output protocol aims at describing outputs in way which is
more in line with the concept of an output on desktop oriented systems.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
This is however much useful for Xwayland to advertise the output size
and position to X11 clients which need this to configure their surfaces
in the global compositor space as the compositor may apply a different
scale from what is advertised by the output scaling property (to achieve
fractional scaling, for example).
This was added in wayland-protocols 1.10.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
If an X11 app draws a little here, some there, and a tiny bit in the
opposite corner, using RegionExtents for the damage to be sent to the
Wayland compositor will cause massive over-damaging.
However, we cannot blindly send an arbitrary number of damage
rectangles, because there is a risk of overflowing the Wayland
connection. If that happens, it triggers an abort in libwayland-client.
Try to be more accurate with the damage by sending up to 256 rectangles
per window, and fall back to extents otherwise. The number is completely
arbitrary.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
When the Wayland compositor notifies of a new keymap, for the first X11
client using the keyboard, the last slave keyboard used might still not
be set (i.e. “lastSlave” is still NULL).
As a result, the new keymap is not applied, and the first X11 window
will have the wrong keymap set initially.
Apply the new keymap to the master keyboard as long as there's one.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=791383
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Xwayland is a pretty standard Wayland client, we want to be able to
capture core dumps on crashes.
Yet using "-core" causes any FatalError() to generate a core dump,
meaning that we would get a core file for all Wayland server crashes,
which would generate a lot of false positives.
Instead of using FatalError() on Wayland socket errors, give up cleanly
to avoid dumping core files when "-core" is used.
See also: https://bugzilla.gnome.org/show_bug.cgi?id=790502
and: https://bugzilla.gnome.org/show_bug.cgi?id=789086
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The tablet/stylus interfaces reused xwl_seat->focus_window, which
would leave a somewhat inconsistent state of that variable for
wl_pointer purposes (basically, everything) if the pointer happened
to lay on the same surface than the stylus while proximity_out
happens.
We just want the stylus xwl_window to correctly determine we have
stylus focus, and to correctly translate surface-local coordinates
to root coordinates, this can be done using a different variable.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
From the bug: "What happens if bits->width is less than 8? :)"
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103012
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
It doesn't matter, none of this matters.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Calling xwl_window_from_window means looping through the window ancestor
chain whenever it is called on a child window or on an automatically
redirected window.
Since these properties and the potential ancestor's xwl_window are constant
between window realization and unrealization, we can omit the looping by
always putting the respective xwl_window in the Window's private field on
its realization. If the Window doesn't feature an xwl_window on its own,
it's the xwl_window of its first ancestor with one.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Not all compositors allow for customizing the Xwayland command line,
gnome-shell/mutter for example have the command line and path to
Xwayland binary hardcoded, which makes it harder for users to disable
glamor acceleration in Xwayland (glamor being used by default).
Add an environment variable XWAYLAND_NO_GLAMOR to disable glamor support
in Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Xwayland would crash in some circumstances while trying to issue a
pointer locking when the cursor is hidden when there is no seat focus
window set.
The crash signature looks like:
#0 zwp_pointer_constraints_v1_lock_pointer ()
#1 xwl_pointer_warp_emulator_lock () at xwayland-input.c:2584
#2 xwl_seat_maybe_lock_on_hidden_cursor () at xwayland-input.c:2756
#3 xwl_seat_maybe_lock_on_hidden_cursor () at xwayland-input.c:2765
#4 xwl_seat_cursor_visibility_changed () at xwayland-input.c:2768
#5 xwl_set_cursor () at xwayland-cursor.c:245
#6 miPointerUpdateSprite () at mipointer.c:468
#7 miPointerDisplayCursor () at mipointer.c:206
#8 CursorDisplayCursor () at cursor.c:150
#9 AnimCurDisplayCursor () at animcur.c:220
#10 ChangeToCursor () at events.c:936
#11 ActivatePointerGrab () at events.c:1542
#12 GrabDevice () at events.c:5120
#13 ProcGrabPointer () at events.c:4908
#14 Dispatch () at dispatch.c:478
#15 dix_main () at main.c:276
xwl_pointer_warp_emulator_lock() tries to use the surface from the
xwl_seat->focus_window leading to a NULL pointer dereference when that
value is NULL.
Check that xwl_seat->focus_window is not NULL earlier in the stack in
xwl_seat_maybe_lock_on_hidden_cursor() and return early if not the case
to avoid the crash.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=102474
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the compositor has no support for the Xwayland keyboard grab
protocol, there is no need to set-up our keyboard grab handler.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The version detect was erroring out with 1.9 protos installed, and we
weren't building the new code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The keyboard grabbing protocol for Xwayland is included in
wayland-protocol 1.9.
Update the wayland-protocol required version in both configure and meson
builds and add support for this new protocol in Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
... where it is named src/egl/wayland/wayland-drm/wayland-drm.xml and
has its requests sorted by protocol version number, avoiding a warning
from wayland-scanner.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
The 'tablet_tool_wheel' function for tablet scrolling was added back in
8a1defcc63 but left unimplemented. This commit fills in the necessary
details, using the "clicks" count as the number of discrete scroll up/down
events to send.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The 'tablet_tool_frame' function treats the button masks as though they
are zero-indexed, but 'tablet_tool_button_state' treats them as one-
indexed. The result is that an e.g. middle click event recieved from
Wayland will be sent from the X server as a right-click instead.
Fixes: 773b04748d ("xwayland: handle button events after motion events")
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Xwayland doesn't override these, so we don't need defining those
in the xwl_screen struct.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In the typical pattern in games of "hide cursor, grab with a confineTo,
warp constantly the pointer to the middle of the window" the last warping
step is actually rather optional. Some games may choose to just set up a
grab with confineTo argument, and trust that they'll get correct relative
X/Y axis values despite the hidden cursor hitting the confinement window
edge.
To cater for these cases, lock the pointer whenever there is a pointer
confinement and the cursor is hidden. This ensures the pointer position
is in sync with the compositor's when it's next shown again, and more
importantly resorts to the relative pointer for event delivery.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This fixes grabs on InputOnly windows whose parent is the root window
failing with GrabNotViewable. This is due to window->borderSize/windowSize
being computed as clipped by its parent, resulting in a null region.
Setting up the right size on the root window makes the InputOnly size
correct too, so the GrabNotViewable paths aren't hit anymore.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Of sorts, actually make it confine to the pointer focus, as the
InputOnly window is entirely invisible to xwayland accounting,
we don't have a xwl_window for it.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Of sorts, as we can't honor pointer warping across the whole root window
coordinates, peek the pointer focus in these cases.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All that was left here was updating the FBO's size. However, the FBO
size was always set correctly already through
glamor_set_pixmap_texture() from whoever had attached a new BO to the
pixmap.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
When running an Xwayland server from the command line, we end up
resetting the server every time all of the clients connected to the
server leave. This would be fine, except that xwayland makes the mistake
of unconditionally calling LoadExtensionList(). This causes us to setup
the glxExtension twice in a row which means that when we lose our last
client on the second server generation, we end up trying to call the glx
destructors twice in a row resulting in a segfault:
(EE)
(EE) Backtrace:
(EE) 0: Xwayland (OsSigHandler+0x3b) [0x4982f9]
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x70845bf]
(EE) 2: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x32897d) [0x1196e5bd]
(EE) 3: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x328a45) [0x1196e745]
(EE) 4: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x32665f) [0x11969f7f]
(EE) 5: Xwayland (__glXDRIscreenDestroy+0x30) [0x54686e]
(EE) 6: Xwayland (glxCloseScreen+0x3f) [0x5473db]
(EE) 7: Xwayland (glxCloseScreen+0x53) [0x5473ef]
(EE) 8: Xwayland (dix_main+0x7b6) [0x44c8c9]
(EE) 9: Xwayland (main+0x28) [0x61c503]
(EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x72b1401]
(EE) 11: Xwayland (_start+0x2a) [0x4208fa]
(EE) 12: ? (?+0x2a) [0x2a]
(EE)
(EE) Segmentation fault at address 0x18
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
Easy reproduction recipe:
- Start an Xwayland session with the default settings
- Open a window
- Close that window
- Open another window
- Close that window
- Total annihilation occurs
Signed-off-by: Lyude <lyude@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In the event that xwayland gets launched on a wayland compositor that
doesn't yet have support for wp_tablet_manager, we end up skipping the
initialization of the lists. This is wrong, because regardless of
whether or not a tablet is present we still attempt to traverse these
lists later in xwl_set_cursor(), expecting that if the lists are empty
from no tablet manager that we simply won't execute any loop iterations.
(EE)
(EE) Backtrace:
(EE) 0: Xwayland (OsSigHandler+0x3b) [0x4982f9]
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7f73722545bf]
(EE) 2: Xwayland (xwl_set_cursor+0x9f) [0x429974]
(EE) 3: Xwayland (miPointerUpdateSprite+0x261) [0x4fe1ca]
(EE) 4: Xwayland (mieqProcessInputEvents+0x239) [0x4f8d33]
(EE) 5: Xwayland (ProcessInputEvents+0x9) [0x4282f0]
(EE) 6: Xwayland (Dispatch+0x42) [0x43e2d4]
(EE) 7: Xwayland (dix_main+0x5c9) [0x44c6dc]
(EE) 8: Xwayland (main+0x28) [0x61c523]
(EE) 9: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x7f7371e9d401]
(EE) 10: Xwayland (_start+0x2a) [0x4208fa]
(EE) 11: ? (?+0x2a) [0x2a]
(EE)
(EE) Segmentation fault at address 0x28
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
Reproduced when trying to run upstream xwayland under fedora 25's weston
package.
Signed-off-by: Lyude <lyude@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hooked up a bit differently to the other tools. Those tools can be static for
all and be re-used. The wacom driver initializes the pad with the correct
number of buttons though and we can't do this until we have the pad done event.
If the tablet is removed and we plug a different one in, we should initialize
that correctly, so unlike the other tools the pad is properly removed and
re-initialized on plug.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Each xwl_tablet_tool gets a xwl_cursor, as on wayland each of those
will get an independent cursor that can be set through
zwp_tablet_tool.set_cursor.
However, all tools (and the pointer) share conceptually the same VCP
on Xwayland, so have cursor changes trigger a xwl_cursor update on
every tool (and the pointer, again). Maybe Xwayland could keep track
of the most recent device and only update that cursor to get better
visual results, but this is simpler, and it's going to be odd
anyway...
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
This struct takes away the cursor info in xwl_seat, and has
an update function so we can share the frame handling code
across several xwl_cursors.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Make sure the button events are sent after the motion events into the new
position.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Translates Wayland tablet events into corresponding X11 tablet events. As
with the prior commit, these events are modeled after those created by the
xf86-input-wacom driver to maximize compatibility with existing applications.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Creates and maintains the canonical trio of X devices (stylus, eraser,
and cursor) to be shared by all connected tablets. A per-tablet trio
could be created instead, but there are very few benefits to such a
configuration since all tablets still ultimately share control of a
single master pointer.
The three X devices are modeled after those created by xf86-input-wacom
but use a generic maximum X and Y that should be large enough to
accurately represent values from even the largest currently-available
tablets.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
The wp_tablet_seat interface provides us with notifications as tablets,
tools, and pads are connected to the system. Add listener functions and
store references to the obtained devices.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
If we're notified about the existence of the wp_tablet_manager interface,
we bind to it so that we can make use of any tablets that are (or later
become) available. For each seat that exists or comes into existance at
a later point, obtain the associated tablet_seat.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <ping.cheng@wacom.com>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We mostly use #ifdef throughout the tree, and this lets the generated
config.h files just be #define TOKEN instead of #define TOKEN 1.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Be more precise in describing the return value.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Following on from the previous change, this adds a DPMS hook to the
ScreenRec and uses that to infer DPMS support. As a result we can drop
the dpms stub code from Xext.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Client resources can survive the client itself, in which case we
may end up in our sync callback trying to access client's data after
it's been freed/reclaimed.
Add a ClientStateCallback handler to monitor the client state changes
and clear the sync callback set up by the glamor drm code if any.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100040
Tested-by: Mark B <mark.blakeney@bullet-systems.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
After an X cursor is unrealized, the seat's corresponding x_cursor is
cleared, but if a frame callback was pending at the time, it will
remain and thus prevent any further cursor update, leaving the window
with no cursor.
Make sure to destroy the frame callback, if any, when that occurs, so
that next time a cursor needs to be set, it won't be ignored for a frame
callback that will never be triggered.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389327
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Rui Matos <tiagomatos@gmail.com>
in XWayland, dri3_send_open_reply() is called from a sync callback, so
there is a possibility that the client might be gone when we get to the
callback eventually, which leads to a crash in _XSERVTransSendFd() from
WriteFdToClient() .
Check if clientGone has been set in the sync callback handler to avoid
this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99149
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100040
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1416553
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Mark B <mark.blakeney@bullet-systems.net>
keyboard_check_repeat() fetches the XWayland seat from the
dev->public.devicePrivate do do its thing.
If a key event is sent programmatically through Xtest, our device is the
virtual core keyboard and that has a dev->public.devicePrivate of NULL,
leading to a segfault in keyboard_check_repeat().
This is the case with "antimicro" which sends key events based on the
joystick buttons.
Don't set the checkRepeat handler on the VCK since it cannot possibly work
anyway and it has no effect on the actual checkRepeat intended functionality.
Bugzilla: https://bugzilla.redhat.com/1416244
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
During the InitInput() phase, the wayland events get dequeued so we
can possibly end up calling dispatch_pointer_motion_event().
If this occurs before xwl_seat->focus_window is set, it leads to a NULL
pointer derefence and a segfault.
Check for xwl_seat->focus_window in both pointer_handle_frame() and
relative_pointer_handle_relative_motion() prior to calling
dispatch_pointer_motion_event() like it's done in
pointer_handle_motion().
Bugzilla: https://bugzilla.redhat.com/1410804
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The X11 window manager (XWM) of a Wayland compositor can use the
_XWAYLAND_ALLOW_COMMITS property to control when Xwayland sends
wl_surface.commit requests. If the property is not set, the behaviour
remains what it was.
XWM uses the property to inhibit commits until the window is ready to be
shown. This gives XWM time to set up the window decorations and internal
state before Xwayland does the first commit. XWM can use this to ensure
the first commit carries fully drawn decorations and the window
management state is correct when the window becomes visible.
Setting the property to zero inhibits further commits, and setting it to
non-zero allows commits. Deleting the property allows commits.
When the property is changed from zero to non-zero, there will be a
commit on next block_handler() call provided that some damage has been
recorded.
Without this patch (i.e. with the old behaviour) Xwayland can and will
commit the surface very soon as the application window has been realized
and drawn into. This races with XWM and may cause visible glitches.
v3:
- introduced a simple setter for xwl_window::allow_commits
- split xwl_window_property_allow_commits() out of
xwl_property_callback()
- check MakeAtom(_XWAYLAND_ALLOW_COMMITS)
v2:
- use PropertyStateCallback instead of XACE, based on the patch
"xwayland: Track per-window support for netwm frame sync" by
Adam Jackson
- check property type is XA_CARDINAL
- drop a useless memcpy()
Weston Bug: https://phabricator.freedesktop.org/T7622
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Fix the following warning due to --disable-glamor:
CC Xwayland-xwayland.o
In file included from /home/pq/local/include/wayland-client.h:40:0,
from xwayland.h:35,
from xwayland.c:26:
xwayland.c: In function ‘block_handler’:
/home/pq/local/include/wayland-client-protocol.h:3446:2: warning: ‘buffer’ may be used uninitialized in this function [-Wmaybe-uninitialized]
wl_proxy_marshal((struct wl_proxy *) wl_surface,
^
xwayland.c:466:23: note: ‘buffer’ was declared here
struct wl_buffer *buffer;
^
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Refactor xwl_screen_post_damage() and split the window specific code
into a new function xwl_window_post_damage().
This is a pure refactoring, there are no behavioral changes. An assert
is added to xwl_window_post_damage() to ensure frame callbacks are not
leaked if a future patch changes the call.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Previously, we would swap the width/height of the Xwayland output based
on the output rotation, so that the overall screen size would match the
actual rotation of each output.
Problem is the RandR's ConstrainCursorHarder() handler will also apply
the output rotation, meaning that when the output is rotated, the
pointer will be constrained within the wrong dimension.
Moreover, XRandR assumes the original output width/height are unchanged
when the output is rotated, so by changing the Xwayland output width and
height based on rotation, Xwayland causes XRandr to report the wrong
output sizes (an output of size 1024x768 rotated left or right should
remain 1024x768, not 768x1024).
So to avoid this issue and keep things consistent between Wayland and
Xwayland outputs, leave the actual width/height unchanged but apply the
rotation when computing the screen size. This fixes both the output size
being wrong in "xrandr -q" and the pointer being constrained in the
wrong dimension with rotated with weston.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
If the Wayland compositor sets a rotation on the output, Xwayland
translates the transformation as an xrandr rotation for the given
output.
However, if the rotation is not supported by the CRTC, this is not
a valid setup and xrandr queries will fail.
Pretend we support all rotations and reflections so that the
configuration remains a valid xrandr setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
For some applications (like fullscreen games) it matters for XRandr
resolution to be correctly set and equal to root window resolution.
In XServer there is already hack for this, adapted it for XWayland.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99574
Signed-off-by: Svitozar Cherepii <razotivs@gmail.com>
Tested-by: Svitozar Cherepii <razotivs@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Sometimes, Xwayland will try to use a cursor that has just been freed,
leading to a crash when trying to access that cursor data either in
miPointerUpdateSprite() or AnimCurTimerNotify().
CheckMotion() updates the pointer's cursor based on which xwindow
XYToWindow() returns, and Xwayland implements its own xwl_xy_to_window()
to fake a crossing to the root window when the pointer has left the
Wayland surface but is still within the xwindow.
But after an xwindow is unrealized, the last xwindow used to match the
xwindows is cleared so two consecutive calls to xwl_xy_to_window() may
not return the same xwindow.
To avoid this issue, update the last_xwindow based on enter and leave
notifications instead of xwl_xy_to_window(), and check if the xwindow
found by the regular miXYToWindow() is a child of the known last
xwindow, so that multiple consecutive calls to xwl_xy_to_window()
return the same xwindow, being either the one found by miXYToWindow()
or the root window.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1385258
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Vít Ondruch <vondruch@redhat.com>
Tested-by: Satish Balay <balay@fastmail.fm>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Commits 816015648f and
fee0827a9a made it so that
wl_keyboard::enter doesn't result in X clients getting KeyPress events
while still updating our internal xkb state to be in sync with the
host compositor.
wl_keyboard::leave needs to be handled in the same way as its
semantics from an X client POV should be the same as an X grab getting
triggered, i.e. X clients shouldn't get KeyRelease events for keys
that are still down at that point.
This patch uses LeaveNotify for these events on wl_keyboard::leave and
changes the current use of KeymapNotify to EnterNotify instead just to
keep some symmetry between both cases.
On ProcessDeviceEvent() we still need to deactivate X grabs if needed
for KeyReleases.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The definition by the manual is:
calloc(size_t nmemb, size_t size)
Swap the arguments of calloc() calls to be the right way around.
Presumably this makes no functional difference, but better follow the
spec.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not needed anymore now that mipointer exposes an API for that,
miPointerInvalidateSprite()
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
posix_fallocate() does an explicit rollback if it gets EINTR, and
this is a problem on slow systems because when the allocation size
is sufficiently large posix_fallocate() will always be interrupted
by the smart scheduler's SIGALRM.
Changes since v1 - big comment in the code to explain what is going on
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ian Ray <ian.ray@ge.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
On some random condition, a touch event may trigger a crash in Xwayland
in GetTouchEvents().
The (simplified) backtrace goes as follow:
(gdb) bt
#0 GetTouchEvents() at getevents.c:1892
#1 QueueTouchEvents() at getevents.c:1866
#2 xwl_touch_send_event() at xwayland-input.c:652
#5 wl_closure_invoke() from libwayland-client.so.0
#6 dispatch_event() from libwayland-client.so.0
#7 wl_display_dispatch_queue_pending() from libwayland-client.so.0
#8 xwl_read_events() at xwayland.c:483
#9 ospoll_wait() at ospoll.c:412
#10 WaitForSomething() at WaitFor.c:222
#11 Dispatch() at dispatch.c:412
#12 dix_main() at main.c:287
#13 __libc_start_main() at libc-start.c:289
#14 _start ()
The crash occurs when trying to access the sprite associated with the
touch device, which appears to be NULL. Reason being the device itself
is more a keyboard device than a touch device.
Moreover, it appears the device is neither enabled nor activated
(inited=0, enabled=0) which doesn't seem right, but matches the code in
init_touch() from xwayland-input.c which would enable the device if it
was previously existing and otherwise would create the device but not
activate it.
Make sure we do activate and enable touch devices just like we do for
other input devices such as keyboard and pointer.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Pointer enter event coordinates are surface relative and we need them to
be screen relative for pScreen->SetCursorPosition().
https://bugzilla.gnome.org/show_bug.cgi?id=758283
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
eglGetDisplay forces the implementation to guess which kind of display
it's been handed. glvnd does something different from Mesa, and in
general it's impossible for the library to get this right. Add a new
inline that gets the logic right, and works around a quirk in epoxy.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Emulate pointer warps by locking the pointer and sending relative
motion events instead of absolute. X will keep track of the "fake"
pointer cursor position given the relative motion events, and the
client warping the cursor will warp the faked cursor position.
Various requirements need to be met for the pointer warp emulator to
enable:
The cursor must be invisible: since it would not be acceptable that a
fake cursor position would be different from the visual representation
of the cursor, emulation can only be done when there is no visual
representation done by the Wayland compositor. Thus, for the emulator
to enable, the cursor must be hidden, and would the cursor be displayed
while the emulator is active, the emulator would be destroyed.
The window that is warped within must be likely to have pointer focus.
For example, warping outside of the window region will be ignored.
The pointer warp emulator will disable itself once the fake cursor
position leaves the window region, or the cursor is made visible.
This makes various games depending on pointer warping (such as 3D
first-person shooters and stategy games using click-to-drag-map like
things) work.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Translate grabbing a pointer device with confineTo set to a window into
confining the Wayland pointer using the pointer constraints protocol.
This makes clients that depend on the pointer not going outside of the
window region, such as certain games and virtual machines viewers, to
function more properly.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If there was an relative pointer motion within the same frame as an
absolute pointer motion, provide both the absolute coordinate and the
unaccelerated delta when setting the valuator mask.
If a frame contained only a relative motion, queue an absolute motion
with an unchanged position, but still pass the unaccelerated motion
event.
If the wl_seat advertised by the compositor is not new enough, assume
each relative and absolute pointer motion arrives within their own
separate frames.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Wait until wl_pointer.frame with dispatching the pointer motion event,
if wl_pointer.frame is supported by the compositor. This will later be
used to combine unaccelerated motion deltas with the absolute motion
delta.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Generating relative and absolute movement events from the same input
device is problematic, because an absolute pointer device doesn't
expect to see any relative motion events. To be able to generate
relative pointer motion events including unaccelerated deltas, create a
secondary pointer device 'xwayland-relative-pointer', and use that for
emitting relative motion events.
Signed-off-by: Krzysztof Sobiecki <sobkas@gmail.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
