Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY
is raised, in which case the texture returned is zero.
But the texture value is not checked in glamor_create_fbo() and glamor
will abort in glamor_pixmap_ensure_fb() because the fbo->tex is 0:
Truncated backtrace:
Thread no. 1 (10 frames)
#4 glamor_pixmap_ensure_fb at glamor_fbo.c:57
#5 glamor_create_fbo_from_tex at glamor_fbo.c:112
#6 glamor_create_fbo at glamor_fbo.c:159
#7 glamor_create_fbo_array at glamor_fbo.c:210
#8 glamor_create_pixmap at glamor.c:226
#9 compNewPixmap at compalloc.c:536
#10 compAllocPixmap at compalloc.c:605
#11 compCheckRedirect at compwindow.c:167
#12 compRealizeWindow at compwindow.c:267
#13 RealizeTree at window.c:2617
Check the value returned by _glamor_create_tex() in glamor_create_fbo()
and return NULL in the texture is zero.
All callers of glamor_create_fbo() actually check the returned value and
will use a fallback code path if it's NULL.
Please cherry-pick this to active stable branches.
Bugzilla: https://bugzilla.redhat.com/1433305
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 8805a48ed3)
This ends up passing 0 as the bpp argument to fb screen setup, which is
not really the best plan.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 83c4297d2c)
We were binding the screen pixmap as the dash and sampling its alpha,
which is usually just 1.0 (no dashing at all).
Please cherry-pick this to active stable branches.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit fe0b297420)
This code is using GetImage to accumulate a logical view of the window
image (since the windows will be clipped to their containing screen),
and then PutImage to load that back into the pixmap. What it wasn't
doing was constructing a region for the obscured areas of the window and
emitting graphics exposures for same.
v2: Fix coordinate translation when the source is the root window
v3: Create sourceBox with the right coordinates initially instead of
translating (Keith Packard)
v4: Clamp the region to 15 bits to avoid overflow (Keith Packard)
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit e337de2d48)
Check the value returned by glamor_set_destination_drawable() and use
the fallback code path where possible.
Bugzilla: https://bugzilla.redhat.com/1417575
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 455051a0f1)
The fbo_array of a given glamor pixmap can be NULL in some cases, as
glamor_create_fbo_array() can fail to allocate the FBO array.
If this is the case, glamor_pixmap_fbo_at() will return NULL even though
the box index is valid, and glamor_set_destination_drawable() simply
assumes glamor_pixmap_fbo_at() will return an FBO prior to pass the
value to glamor_set_destination_pixmap_fbo(), which will segfault.
We need a way for glamor_set_destination_drawable() to fail safely and
let the caller know about the failure.
Add a boolean return value to glamor_set_destination_drawable() for that
purpose.
Bugzilla: https://bugzilla.redhat.com/1417575
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 04b4bad7c0)
If the screen pixmap or the corresponding texture creation with glamor
fails, exit cleanly with an error message instead of segfaulting.
Fixes: https://bugzilla.redhat.com/1431633
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit b0ce1d088a)
glamor_create_pixmap() would return a NullPixmap if the given size is
larger than the maximum size of a pixmap.
But glamor_get_pixmap_texture() won't check if the given pixmap is
non-null, leading to a segfault if glamor_create_pixmap() failed.
This can be reproduced by passing Xephyr a very large screen width,
e.g.:
$ Xephyr -glamor -screen 32768x1024 :10
(EE)
(EE) Backtrace:
(EE) 0: Xephyr (OsSigHandler+0x29)
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
(EE) 2: Xephyr (glamor_get_pixmap_texture+0x30)
(EE) 3: Xephyr (ephyr_glamor_create_screen_resources+0xc6)
(EE) 4: Xephyr (ephyrCreateResources+0x98)
(EE) 5: Xephyr (dix_main+0x275)
(EE) 6: /lib64/libc.so.6 (__libc_start_main+0xf1)
(EE) 7: Xephyr (_start+0x2a)
(EE) 8: ? (?+0x2a) [0x2a]
(EE)
(EE) Segmentation fault at address 0x0
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
Aborted (core dumped)
Bugzilla: https://bugzilla.redhat.com/1431633
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit f40ff18c96)
Fixes a regression from
commit 41da295eb5
Author: Keith Packard <keithp@keithp.com>
Date: Sun Nov 3 13:12:40 2013 -0800
Trap SIGBUS to handle truncated shared memory segments
that causes the SIGBUS handler to fail to chain up correctly and
corrupts nearby memory instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit acdb5bf2de)
ProcRenderCreateRadialGradient and ProcRenderCreateConicalGradient must
be protected against an integer overflow during length check. This is
already included in ProcRenderCreateLinearGradient since the fix for
CVE-2008-2362.
This can only be successfully exploited on a 32 bit system for an
out of boundary read later on. Validated by using ASAN.
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit ac15d4cecc)
Fixes a GLSL compilation error:
Failed to compile VS: 0:13(43): error: `pos' undeclared
0:13(14): error: operands to arithmetic operators must be numeric
0:13(13): error: operands to arithmetic operators must be numeric
[1.19: Squash in Michel's typo fix from 0c1574d9]
Tested-by: Stefan Dirsch <sndirsch@suse.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit d8161aeb50)
(cherry picked from commit 0c1574d988)
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() .
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://bugzilla.redhat.com/show_bug.cgi?id=1416553
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>
(cherry picked from commit 937527f979)
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>
(cherry picked from commit d4b7e0eaa4)
This prevents the tearing of moving window in a composite WM
desktop when output slave is attached but none of its crtc is
really active.
[1.19: Also fix DMX_LIBS= in configure.ac so it still links - ajax]
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit bb9128fdc8)
This reverts commit b5b292896f.
This breaks the concept of the screen->pixmap_dirty_list as it no longer
tracks the relationship between the PixmapDirtyUpdate src and slave_dst,
for the supposed convenience of not tracking present flips.
Bugzilla: https://bugs.freedesktop.org/100086
Reviewed-by: Adam Jackson <ajax@redhat.com>
timingsafe_memcmp.c:21:1: warning: no previous prototype for ‘timingsafe_memcmp’ [-Wmissing-prototypes]
timingsafe_memcmp(const void *b1, const void *b2, size_t len)
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 5c44169cae)
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>
(cherry picked from commit fe5c340046)
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>
(cherry picked from commit 8c9909a992)
- typo in #ifdef check
- also need to add AC_CHECK_FUNCS([arc4random_buf])
Reported-by Eric Engestrom. Thanks
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
(cherry picked from commit 386fbbe410)
And the current code for MitToId has a use-after-free() issue.
[Also remove the actual implementations - ajax]
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 2855f759b1)
Provide the function definition for systems that don't have it.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit d7ac755f0b)
The input thread should generate events, not send them. Make it easier to
find the instances where it's doing so.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 1b12249fd6)
The lower layers also do this, but no damage may be reported there,
since we unwrap before calling down.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99220
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 38696ea568)
Works fine now.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 542d9f6807)
The screen pixmap doesn't receive updates while there's a Present flip
window.
[1.19: Squashed in a6566f9e to avoid intermediate regression - ajax]
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit b5b292896f)
(cherry picked from commit a6566f9e4d)
When selecting "CA_TWO_PASS" in glamor_composite_clipped_region() when
the hardware does not support "GL_ARB_blend_func_extended", we call
glamor_composite_choose_shader() twice in a row, which in turn calls
glamor_pixmap_ensure_fbo().
On memory pixmaps, the first call will set the FBO and the second one
will fail an assertion in glamor_upload_picture_to_texture() because
the FBO is already set.
Bail out earlier when the mask pixmap is in memory and the hardware
capabilities would require to use two pass, so that the assertion is not
failed and the rendering is correct.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99346
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 8646398136)
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>
(cherry picked from commit 1c78bec9ca)
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>
(cherry picked from commit afeace27d3)
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>
(cherry picked from commit 058809c43e)
xf86RecolorCursor() may be called directly from XRecolorCursor as well
as from xf86ScreenSetCursor(). In the latter case, the input lock is
already held, but not for the former and so we need to add a wrapper
function that acquires the input lock before performing
xf86RecolorCursor()
References: https://bugs.freedesktop.org/show_bug.cgi?id=99358
(cherry picked from commit 7198a6d4e7)
A client which is attended while a grab is blocking execution of its
requests needs to be placed in the saved_ready_clients list so that it
will get scheduled once the grab terminates. Otherwise, if the client
never sends another request, there is no way for it to be placed in
the ready_clients list.
v2: Wrap comment above mark_client_saved_ready.
Remove test for OS_COMM_IGNORED which will always be true.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99333
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 785053d033)
xrandr --setprovideroutputsource <screen> <gpu screen>
Xorg: ../../../xserver/dix/dispatch.c:4018: AttachOutputGPU:
Assertion `new->isGPU' failed.
GPUScreen is not allowed to be sink output.
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 555e0a42d1)
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 1012510620)
We are no longer using the present_flip_queue list only for presents
which have already been submitted to the driver for page flipping, but
also for those which we are queueing up to be flipped later, marked
with vblank->queued == TRUE. We were incorrectly calling
present_flip_notify for such entries, failing the assertion in
present_flip_notify (or presumably resulting in other undesirable
behaviour with assertions disabled).
Reproduction recipe: Run the JavaFX test case referenced by
https://bugs.freedesktop.org/show_bug.cgi?id=98831#c6 and alt-tab out
of it while it's fullscreen. May take a few attempts to hit the
assertion failure.
Fixes: bab0f450a7 ("present: Fix presentation of flips out of order")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98854
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e473b2bc01)
Detailed mode reports 108 mm x 68 mm which is for smaller display.
Maximum image size reports 15 cm x 10 cm which aligns with its physical
size, use this size instead.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9874f73e88)
Fixes a regression introduced in 0b2f30834b. If a driver posts input
events during a timer function (wacom and synaptics do this during tap
timeouts), ProcessInputEvents() is not called for these events. There are no
new events on any fds, so the events just sit in the queue waiting for
something else to happen.
Fix this by simply returning 0 from check_timers if we ran at least one of
them or reset them all. This way the callers ospoll_wait will exit and
continue with normal processing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
If the libEGL we are using has eglGetPlatformDisplayEXT, yet it still
returns NULL, then this very likely means that it does not support the
type (e.g. EGL_PLATFORM_GBM_MESA) passed in, and then returning NULL is
the right thing to do.
This avoids falling back to an eglGetDisplay() implementation which does
not understands the passed in gbm handle, treats it as a pointer to
something else completely, followed by a crash sooner or later.
Specifically this fixes using the nvidia binary driver, with nvidia's
libEGL + the modesetting driver on a secondary GPU crashing inside
glamor_egl_init() sometimes.
[1.19: squash in typo fix from 29a4f3db - ajax]
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 05e1964425)
The custom os/os.O library reuses *.o files of os/libos.la.
The current rule assumes automake puts all the objects into per-target
am__*_la_OBJECTS variable. At least with AC_REPLACE_FUNCS, this no
longer holds (as wanted objects are put into LTLIBOBJS instead).
Depend on automake's result, the *.la library instead, to express demand
of any its dependencies being built.
Should be fixing randomly occuring "undefined reference to `strlcpy'"
errors when linking Xvfb and other DDX-es that could use os.O.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
(cherry picked from commit 5b74e260e0)
