In Xwayland's xwl_unrealize_cursor(), the x_cursor is cleared up only
when a device value is provided to the UnrealizeCursor() routine, but
if the device is NULL as called from FreeCursor(), the corresponding
x_cursor for the xwl_seat is left untouched.
This might cause a segfault when trying to access the unrealized
cursor's devPrivates in xwl_seat_set_cursor().
A possible occurrence of this is the client changing the cursor, the
Xserver calling FreeCursor() which does UnrealizeCursor() and then
the Wayland server sending a pointer enter event, which invokes
xwl_seat_set_cursor() while the seat's x_cursor has just been
unrealized.
To avoid this, walk through all the xwl_seats and clear up all x_cursor
matching the cursor being unrealized.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
wl_display_flush() can fail with EAGAIN and Xwayland would make this a
fatal error.
When this happens, it means that Xwayland has flooded the Wayland file
descriptor, either because the Wayland compositor cannot cope or more
likely because of a deadlock situation where the Wayland compositor is
blocking, waiting for an X reply while Xwayland tries to write data to
the Wayland file descriptor.
The general consensus to avoid the deadlock is for the Wayland
compositor to never issue blocking X11 roundtrips, but in practice
blocking rountrips can occur in various places, including Xlib calls
themselves so this is not always achievable without major surgery in the
Wayland compositor/Window manager.
What this patch does is to avoid dispatching to the Wayland file
descriptor until it becomes available for writing again, while at the
same time continue processing X11 requests to release the deadlock.
This is not perfect, as there is still the possibility of another X
client hammering the connection and we'll still fail writing to the
Wayland connection eventually, but this improves things enough to avoid
a 100% repeatable crash with vlc and gtkperf.
Also, it is worth considering that window managers and Wayland
compositors such as mutter already have a higher priority than other
regular X clients thanks to XSyncSetPriority(), mitigating the risk.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1278159
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=763400
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Keeping the shm fd open beyond pixmap creation means we can easily
reach the open file descriptor limit if an X client asks us to create
that many pixmaps. Instead, let's get the wl_buffer immediatly so that
we can destroy the shm pool and close the fd before being asked to
create more.
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Since xwayland's initial commit we have had a check to not process
wayland modifier events while one of our surfaces has keyboard focus
since the normal xkb event processing keeps our internal modifier
state up to date and if we use the modifiers we get from the
compositor we mess up that state.
This was slightly changed in commit
10e9116b3f to allow the xkb group to be
set from the wayland event while we have focus in case the compositor
triggers a group switch.
There's a better solution to the original problem though. Processing
queued events before overriding the xkb state with the compositor's
allows those events to be sent properly modified to X clients while
any further events will be modified with the wayland modifiers as
intended.
This allows us to fully take in the wayland modifiers, including
depressed ones, which fixes an issue where we wouldn't be aware of
already pressed modifiers on enter.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Emitting a LeaveNotify event every time the pointer leaves an X11 window
may confuse focus follow mouse mode in window managers such as
mutter/gnome-shell.
Keep the previously found X window and compare against the new one, and
if they match then it means the pointer has left an Xwayland window for
a native Wayland surface, only in this case fake the crossing to the
root window.
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>
Without this a change in eg Xext/ wouldn't relink Xwayland, making you
wonder why your changes didn't have any effect.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
At shutdown, the Xserver will free all its resources which includes the
RRCrtc and RROutput created.
Xwayland would do the same in its xwl_output_destroy() called from
xwl_close_screen(), leading to a double free of existing RRCrtc
RROutput:
Invalid read of size 4
at 0x4CDA10: RRCrtcDestroy (rrcrtc.c:689)
by 0x426E75: xwl_output_destroy (xwayland-output.c:301)
by 0x424144: xwl_close_screen (xwayland.c:117)
by 0x460E17: CursorCloseScreen (cursor.c:187)
by 0x4EB5A3: AnimCurCloseScreen (animcur.c:106)
by 0x4EF431: present_close_screen (present_screen.c:64)
by 0x556D40: dix_main (main.c:354)
by 0x6F0D290: (below main) (in /usr/lib/libc-2.24.so)
Address 0xbb1fc30 is 0 bytes inside a block of size 728 free'd
at 0x4C2BDB0: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4CCE5F: RRCrtcDestroyResource (rrcrtc.c:719)
by 0x577541: doFreeResource (resource.c:895)
by 0x5787B5: FreeClientResources (resource.c:1161)
by 0x578862: FreeAllResources (resource.c:1176)
by 0x556C54: dix_main (main.c:323)
by 0x6F0D290: (below main) (in /usr/lib/libc-2.24.so)
Block was alloc'd at
at 0x4C2CA6A: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4CC6DB: RRCrtcCreate (rrcrtc.c:76)
by 0x426D1C: xwl_output_create (xwayland-output.c:264)
by 0x4232EC: registry_global (xwayland.c:431)
by 0x76CB1C7: ffi_call_unix64 (in /usr/lib/libffi.so.6.0.4)
by 0x76CAC29: ffi_call (in /usr/lib/libffi.so.6.0.4)
by 0x556CEFD: wl_closure_invoke (connection.c:935)
by 0x5569CBF: dispatch_event.isra.4 (wayland-client.c:1310)
by 0x556AF13: dispatch_queue (wayland-client.c:1456)
by 0x556AF13: wl_display_dispatch_queue_pending
(wayland-client.c:1698)
by 0x556B33A: wl_display_roundtrip_queue (wayland-client.c:1121)
by 0x42371C: xwl_screen_init (xwayland.c:631)
by 0x552F60: AddScreen (dispatch.c:3864)
And:
Invalid read of size 4
at 0x522890: RROutputDestroy (rroutput.c:348)
by 0x42684E: xwl_output_destroy (xwayland-output.c:302)
by 0x423CF4: xwl_close_screen (xwayland.c:118)
by 0x4B6377: CursorCloseScreen (cursor.c:187)
by 0x539503: AnimCurCloseScreen (animcur.c:106)
by 0x53D081: present_close_screen (present_screen.c:64)
by 0x43DBF0: dix_main (main.c:354)
by 0x7068730: (below main) (libc-start.c:289)
Address 0xc403190 is 0 bytes inside a block of size 154 free'd
at 0x4C2CD5A: free (vg_replace_malloc.c:530)
by 0x521DF3: RROutputDestroyResource (rroutput.c:389)
by 0x45DA61: doFreeResource (resource.c:895)
by 0x45ECFD: FreeClientResources (resource.c:1161)
by 0x45EDC2: FreeAllResources (resource.c:1176)
by 0x43DB04: dix_main (main.c:323)
by 0x7068730: (below main) (libc-start.c:289)
Block was alloc'd at
at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
by 0x52206B: RROutputCreate (rroutput.c:84)
by 0x426763: xwl_output_create (xwayland-output.c:270)
by 0x422EDC: registry_global (xwayland.c:432)
by 0x740FC57: ffi_call_unix64 (unix64.S:76)
by 0x740F6B9: ffi_call (ffi64.c:525)
by 0x5495A9D: wl_closure_invoke (connection.c:949)
by 0x549283F: dispatch_event.isra.4 (wayland-client.c:1274)
by 0x5493A13: dispatch_queue (wayland-client.c:1420)
by 0x5493A13: wl_display_dispatch_queue_pending
(wayland-client.c:1662)
by 0x5493D2E: wl_display_roundtrip_queue (wayland-client.c:1085)
by 0x4232EC: xwl_screen_init (xwayland.c:632)
by 0x439F50: AddScreen (dispatch.c:3864)
Split xwl_output_destroy() into xwl_output_destroy() which frees the
wl_output and the xwl_output structure, and xwl_output_remove() which
does the RRCrtcDestroy() and RROutputDestroy() and call the latter only
when an output is effectively removed.
An additional benefit, on top of avoiding a double free, is to avoid
updating the screen size at shutdown.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The frame callback set up via wl_surface_frame() needs to be freed with
wl_callback_destroy() or we'll leak memory.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97065
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This removes the last uses of fd_set from the server interfaces
outside of the OS layer itself.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Otherwise if the geometry changes but the mode doesn't we end up with
the previous geometry from RR's point of view.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=768710
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
This partially reverts commit c1565f3.
When the pointer moves from an X11 window to a Wayland native window,
no LeaveNotify event is emitted which can lead to various unexpected
behaviors like tooltips remaining visible after the pointer has left the
window.
Yet the pointer_handle_leave() is called and so is the DIX CheckMotion()
but since the pointer enters a Wayland native window with no other
Xwayland window matching, DoEnterLeaveEvents() does not get invoked and
therefore no LeaveNotify event is sent to the X11 client at the time the
pointer leaves the window for a Wayland native surface.
Restore the XYToWindow() handler in xwayland-input that was previously
removed with commit c1565f3 and use that handler to pretend that the
pointer entered the root window in this case so that the LeaveNotify
event is emitted.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96437
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The call to 'InitButtonClassDeviceStruct' which initializes the pointer
buttons only results in the first three buttons being created due to a
hardcoded '3'. In order to expose all the buttons defined in the
btn_labels array, we subtitute 'NBUTTONS' in its place.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Substitute a few errant tab characters with eight spaces to conform to the
prevailing style.
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>
On cursor unrealize, the associated pixmap is destroyed, make sure we
clear the pointer from the private resource and check for the value
being non-null when setting or destroying the cursor.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96246
This partially revert commit 984be78
The rountrip in Xwayland's InitInput() is unlikely the culprit for the
crash reported in bug 95337, even though it's triggered from
InitInput().
Startup goes like this:
xwl_screen_init()
xwl_output_create()
wl_display_roundtrip()
InitInput()
wl_display_roundtrip()
ConnectionInfo initialized
What happens in bug 95337 is that some output data is already available
when we reach InitInput()'s wl_display_roundtrip() and therefore we end
up trying to update the ConnectionInfo's data from RR routines before
ConnectionInfo is actually initialized.
Removing the wl_display_roundtrip() from InitInput() will not fix the
issue (although it would make it less lileky to happen), because
xwl_screen_init() also does a wl_display_roundtrip() after creating the
output, so the race that led to bug 95337 remains.
However, re-setting the xwl_screen->expecting_event to 0 again in
InitInput() still doesn't seem right. so this part is not restored
(thus a partial revert).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
Can't find any reference of pointer_limbo_window in the code, let's
remove it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Current Mesa Git master checks that the EGL display actually supports
the API passed to eglBindAPI, which can only succeed after
eglInitialize.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Read and dispatch pending Wayland events to make sure we do not miss a
possible reply from the compositor prior to discard a key repeat.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Key repeat is handled by the X server, but input events need to be
processed and forwarded by the Wayland compositor first.
Make sure the Wayland compositor is actually processing events, to
avoid repeating keys in Xwayland while the Wayland compositor cannot
deal with input events for whatever reason, thus not dispatching key
release events, leading to repeated keys while the user has already
released the key.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762618
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
By default the X server will try CLOCK_MONOTONIC_COARSE before
CLOCK_MONOTONIC, while A Wayland compositor may only support getting
their timestamps from the CLOCK_MONOTONIC clock. This causes various
issues since it may happen that a timestamp from CLOCK_MONOTONIC
retrieved before a sending an X request will still be "later" than the
timestamp the X server than gets after receiving the request, due to the
fact that CLOCK_MONOTONIC_COARSE has a lower resolution.
To avoid these issues, make Xwayland always use CLOCK_MONOTONIC, so
that it becomes possible for Wayland compositor only supporting
CLOCK_MONOTONIC and X server to use the same clock.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This creates a function that invalidates the current sprite and forces
a sprite image reload the next time the sprite is checked, moving that
logic out of the xwayland sources and allowing the miPointerRec
structure to be removed from the server API.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If data is received during XWayland startup, it will be read early in
InitInput() before the connection data is initialized, causing a crash.
Remove the wayland rountrips from InitInput() as this is done again in
xwl_screen_init() where it seems more appropriate.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
Reviewed-by: Adam Jackson <ajax@redhat.com>
If posix_fallocate or ftruncate is interrupted by signal while working,
we return -1 as fd and the allocation process returns BadAlloc error.
That causes xwayland clients to abort with 'BadAlloc (insufficient
resources for operation)' even when there's a lot of resources
available.
Fix it by trying again when we get EINTR.
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
XvWindowMask is defined as 0x00020000 and cannot fit in the XvAdaptor
type which is defined as an unsigned char, thus causing a compiler
warning:
xwayland-glamor-xv.c: In function ‘xwl_glamor_xv_add_adaptors’:
xwayland-glamor-xv.c:339:16: warning: large integer implicitly
truncated to unsigned type [-Woverflow]
This XvWindowMask value is actually not used for XvAdaptor itself but by
the server in its xf86xv implementation, so we don't even need that mask
in our xwayland-glamor-xv implementation.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Some games (namely openttd) will raise an XError and fail with a
BadValue if their request to XF86VidModeSetViewPort fails.
Support only the default zoom and viewport, fail for everything else.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Some applications (e.g. using lwjgl) try to parse the output of the
xrandr command and get confused with the mode name returned by Xwayland,
because it contains "@[frequency]" (e.g. "1024x640@60.0Hz").
Remove the @[frequency] part of the mode name to match what is found in
usual mode names on regular X servers to please those applications.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94589
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
We had HAVE_POSIX_FALLOCATE checks, but no such macros were ever
defined anywhere. This commit makes it so that this macro is defined if
the posix_fallocate is detected during configure.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
On output removal, the CRTC that was added in xwl_output_create()
is not removed in xwl_output_destroy() and would cause a segmentation
fault later on in ProcRRGetMonitors():
(EE) Segmentation fault at address 0x100000001
(EE)
(EE) 10: ? (?+0x29) [0x29]
(EE) 9: /usr/bin/Xwayland (_start+0x29) [0x423299]
(EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7fdd80e7f580]
(EE) 7: /usr/bin/Xwayland (dix_main+0x3b3) [0x544ef3]
(EE) 6: /usr/bin/Xwayland (Dispatch+0x31e) [0x54109e]
(EE) 5: /usr/bin/Xwayland (ProcRRGetMonitors+0x9b) [0x4ca18b]
(EE) 4: /usr/bin/Xwayland (RRMonitorMakeList+0x269) [0x4c9ba9]
(EE) 3: /usr/bin/Xwayland (RRMonitorSetFromServer+0x118) [0x4c9198]
(EE) 2: /usr/bin/Xwayland (MakeAtom+0x30) [0x530710]
(EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7fdd80e93b1f]
(EE) 0: /usr/bin/Xwayland (OsSigHandler+0x29) [0x5792d9]
Remove the output CRTC in xwl_output_destroy() to avoid the crash.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Older games (mostly those based on SDL 1.x) rely on the XVidMode
extension and would refuse to run without.
Add a simple, limited and read-only xvidmode support that reports the
current mode used so that games that rely on xvidmode extension can run
on XWayland.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87806
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Prefix the temporary file names used for allocating pixmaps with
"xwayland-" instead of "weston-". This makes it less confusing while
looking at the file names of the currently open fds of the Xwayland
process.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
216bdbc735 removed the SetRootClip call in the XWayland output-hotplug
handler when running rootless (e.g. as a part of Weston/Mutter), since
the root window has no storage, so generating exposures will result in
writes to invalid memory.
Unfortunately, preventing the segfault also breaks sprite confinement.
SetRootClip updates winSize and borderSize for the root window, which
when combined with RRScreenSizeChanged calling ScreenRestructured,
generates a new sprite-confinment area to update it to the whole screen.
Removing this call results in the window geometry being reported
correctly, but winSize/borderSize never changing from their values at
startup, i.e. out of sync with the root window geometry / screen
information in the connection info / XRandR.
This patch introduces a hybrid mode, where we update winSize and
borderSize for the root window, enabling sprite confinement to work
correctly, but keep the clip emptied so exposures are never generated.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The last cursor frame we commited before the pointer left one of our
surfaces might not have been shown. In that case we'll have a cursor
surface frame callback pending which we need to clear so that we can
continue submitting new cursor frames.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This adds support to Xwayland to try and use OpenGL core
profile for glamor first.
v1.1: use version defines.
v2: let glamor work out core profile itself.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Replace the block/wakeup handler with a NotifyFd callback instead.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When unplugging an output, it's still listed in xrandr and the size
of the root window still includes the removed output.
The RR output should be destroyed when its Wayland counterpart is
destroyed and the screen dimensions must be updated in both the done
and the destroy handlers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92914
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
In Wayland, a client (in this case XWayland) should set the cursor
surface when it receives pointer focus. Not doing this will leave the
curser at whatever it was previously.
When running on XWayland, the X server will not be the entity that
controls what actual pointer cursor is displayed, and it wont be notified
about the pointer cursor changes done by the Wayland compositor. This
causes X11 clients running via XWayland to end up with incorrect pointer
cursors because the X server believes that, if the cursor was previously
set to the cursor C, if we receive Wayland pointer focus over window W
which also has the pointer cursor C, we do not need to update it. This
will cause us to end up with the wrong cursor if cursor C was not the
same one that was already set by the Wayland compositor.
This patch works around this by, when receiving pointer focus, getting
the private mipointer struct changing the "current sprite" pointer to
an invalid cursor in order to trigger the update path next time a cursor
is displayed by dix.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Otherwise the server may try to draw onto the root window when closing
down, but when running rootless the root window has no storage thus
causing a memory corruption.
Thanks to Adam Jackson <ajax@redhat.com> for helping tracking this down!
Reviewed-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93045
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Marek Chalupa <mchqwerty@gmail.com>
check return values of RR.*Create calls
v2. do not bail out if we don't have any output
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
don't leak memory when realizing window fails
v2. take care of all memory allocation and return values,
not just one leak
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
wl_keyboard::enter is the equivalent of FocusIn + KeymapNotify: it
notifies us that the surface/window has now received the focus, and
provides us a set of keys which are currently down.
We should use these keys to update the current state, but not to send
any events to clients.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a pixmap isn't getting exported as a dmabuf, then we don't need to
make an EGLImage/GBM bo for it. This should reduce normal pixmap
allocation overhead, and also lets the driver choose non-scanout
formats which may be much higher performance.
On Raspberry Pi, where scanout isn't usable as a texture source, this
improves x11perf -copypixwin100 from about 4300/sec to 5780/sec under
xcompmgr -a, because we no longer need to upload our x11perf window to
a tiled temporary in order to render it to the screen.
v2: Just use pixmap->usage_hint instead of a new field. Drop the
changes that started storing gbm_bos in the pixmap priv due to
lifetime issues.
v3: Fix a missing gbm_bo_destroy() on the pixmap-from-fd success path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
One less layering violation (EGL should call glamor, if anything, not
the other way around).
v2: Move glamor.c's DestroyPixmap wrapping up above the
glamor_egl_screen_init() call, since glamor.c's DestroyPixmap
needs to be the bottom of the stack (it calls fb directly and
doesn't wrap). Caught by Michel.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
When we have a single output, just set it to the physical size of that
output. Otherwise try to approximate it calculating a mean m.m. per
dot. Last fallback is to default to 96 DPI.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
When a new output is hot-plugged we need to not only update our internal
screen dimensions, but also the dix screen dimensions, screenInfo
dimensions and the root window dimensions.
https://bugs.freedesktop.org/show_bug.cgi?id=92273
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
While we have keyboard focus, the server's xkb code is already locking
and latching modifiers appropriately while processing keyboard
events.
Since there is no guaranteed order between wl_keyboard key and
modifiers events, if we got the modifiers event with a locked or
latched modifier and then process the key press event for that
modifier we would wrongly unlock/unlatch. To prevent this, we ignore
locked and latched modifiers while any of our surfaces has keyboard
focus.
But we always need to set the xkb group index since this might be
triggered programatically by the wayland compositor at any time.
Reviewed-by: Daniel Stone <daniels@collabora.com>
