- Mar 02, 2017
-
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
Adam Jackson authored
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 5c44169c)
-
Adam Jackson authored
Apparently I need to fight make distcheck some more, so let's not pretend this is released yet. This reverts commit 0b4112bc.
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
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 fe5c3400)
-
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 8c9909a9)
-
- Mar 01, 2017
-
-
- 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 386fbbe4)
-
- Feb 28, 2017
-
-
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 2855f759)
-
Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Matthieu Herrb <matthieu@herrb.eu> (cherry picked from commit 957e8db3)
-
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 d7ac755f)
-
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 1b12249f)
-
- Feb 23, 2017
-
-
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 38696ea5)
-
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 542d9f68)
-
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 b5b29289) (cherry picked from commit a6566f9e)
-
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 86463981)
-
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 1c78bec9)
-
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 afeace27)
-
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 058809c4)
-
- Feb 17, 2017
-
-
(cherry picked from commit 3eb964e2)
-
(cherry picked from commit cfddd919)
-
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 7198a6d4)
-
- Jan 11, 2017
-
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
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 785053d0)
-
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 555e0a42)
-
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 10125106)
-
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: bab0f450 ("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 e473b2bc)
-
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 9874f73e)
-
Fixes a regression introduced in 0b2f3083. 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>
-
Reviewed-by: Adam Jackson <ajax@redhat.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 05e19644)
-
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 5b74e260)
-
In InitOutput, if xf86HandleConfigFile returns CONFIG_NOFILE (which it does if no config file or directory is present), the autoconfig flag is set, causing xf86AutoConfig to be called later on. xf86AutoConfig calls xf86OutputClassDriverList via the call tree: xf86AutoConfig => listPossibleVideoDrivers => xf86PlatformMatchDriver => xf86OutputClassDriverList and xf86OutputClassDriverList attempts to traverse a linked list that is a member of the XF86ConfigRec struct pointed to by the global xf86configptr, which is NULL at this point because the XF86ConfigRec struct is only allocated (by xf86readConfigFile) AFTER the config file and directory have been successfully opened; the CONFIG_NOFILE return from xf86HandleConfigFile occurs BEFORE the call to xf86readConfigFile which allocates the XF86ConfigRec struct. Rx: In read.c (for symmetry with xf86freeConfig, which already appears in this file), add a new function xf86allocateConfig which tests the value of xf86configptr and, if it's NULL, allocates the XF86ConfigRec struct and deposits the pointer in xf86configptr. In xf86Parser.h, add a prototype for the new xf86allocateConfig function. Back in read.c, #include "xf86Config.h". In xf86readConfigFile, change the open-code call to calloc to a call to the new xf86allocateConfig function. In xf86AutoConfig.c, add a call to the new xf86allocateConfig function to the beginning of xf86AutoConfig to make sure the XF86ConfigRec struct is allocated. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Ben Crocker <bcrocker@redhat.com> (cherry picked from commit 8b335d90)
-
Fix the following error on 'make distcheck': make[6]: *** No rule to make target 'scripts/xvfb-piglit.sh', needed by 'scripts/xvfb-piglit.sh.log'. Stop. make[6]: Leaving directory '/home/pq/git/xserver/xorg-server-1.19.99.1/_build/sub/test' Makefile:1367: recipe for target 'check-TESTS' failed The setup to trigger this is: $ ./configure --prefix=/home/pq/local --disable-docs --disable-devel-docs --enable-xwayland --disable-xorg --disable-xvfb --disable-xnest --disable-xquartz --disable-xwin --enable-debug SCRIPT_TESTS is populated conditionally, but we should distribute the scripts in any case. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> (cherry picked from commit b365c5d1)
-
Adam Jackson authored
When going from border width zero to a non-zero border width, the Composite extension is informed via the ConfigNotify callback. The call-chain looks like this: compConfigNotify -> compReallocPixmap -> compSetPixmap -> TraverseTree -> compSetPixmapVisitWindow. However, at this time, pWindow->borderWidth was not yet updated. Thus, HasBorder() is false and the window border will not be repainted. To fix this, thread the new bw through to the window visitor, and inspect that rather than HasBorder(). For the other callers of compSetPixmap the border does not change size, so we can pass pWin->borderWidth instead. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98499 Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> (cherry picked from commit f3187551)
-
The purpose of rrCheckPixmapBounding is to make sure that the screen_pixmap is *large* enough for the slave-output which crtc is being configured. However until now rrCheckPixmapBounding would also shrink the screen_pixmap in certain scenarios leading to various problems. For example: Take a laptop with its internalscreen on a slave-output and currently disabled and an external monitor at 1920x1080+0+0. Now lets say that we want to drive the external monitor at its native resolution of 2560x1440 and have the internal screen mirror the top left part of the external monitor, so we run: $ xrandr --output eDP --mode 1920x1080 --pos 0x0 --output HDMI \ --mode 2560x1440 --pos 0x0 Here xrandr utility first calls RRSetScreenSize to 2560x1440, then it calls RRSetCrtc 1920x1080+0+0 on the eDP, since this is a slave output, rrCheckPixmapBounding gets called and resizes the screen_pixmap to 1920x1080, undoing the RRSetScreenSize. Then RRSetCrtc 2560x1440+0+0 gets called on the HDMI, depending on crtc->transforms this will either result in a BadValue error from ProcRRSetCrtcConfig; or it will succeed, but the monitor ends up running at 2560x1440 while showing a 1920x1080 screen_pixmap + black borders on the right and bottom. Neither of which is what we want. This commit removes the troublesome shrinking behavior, fixing this. Note: 1) One could argue that this will leave us with a too large screen_pixmap in some cases, but rrCheckPixmapBounding only gets called for slave outputs, so xrandr clients already must manually shrink the screen_pixmap after disabling crtcs in normal setups. 2) An alternative approach would be to also call rrCheckPixmapBounding on RRSetCrtc on normal (non-slave) outputs, but that would result in 2 unnecessary resizes of the screen_pixmap in the above example, which seems undesirable. Cc: Nikhil Mahale <nmahale@nvidia.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit a46afee8)
-
The purpose of rrCheckPixmapBounding is to make sure that the screen_pixmap is large enough for the slave-output which crtc is being configured. This should include crtc->x and crtc->y, otherwise the crtc might still end up scanning out an area outside of the screen-pixmap. For example: Take a laptop with an external monitor on a slave-output at 1920x1080+0+0 and its internal-screen at 3840x2160+1920+0 and in gnome-settings-daemon move the external monitor to be on the ri ght of the internal screen rather then on the left. First g-s-d will do a RRSetScreenSize to 5760*2160 (which is a nop), then it calls RRSetCrtc to move the slave output to 1920x1080+3840+0, since this is a slave output, rrCheckPixmapBounding gets called, since the 2 crtcs now overlap the code before this commit would shrinks the screen_pixmap to 3180*2160. Then g-s-d calls RRSetCrtc to move the internal screen to 3180*2160+0+0. And we end up with the slave-output configured to scan-out an area which completely falls outside of the screen-pixmap (and end up with a black display on the external monitor). This commit fixes this by not substracting the x1 and y1 coordinates of the union-ed region when determining the new screen_pixmap size. Cc: Nikhil Mahale <nmahale@nvidia.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 3b624aa9)
-
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> (cherry picked from commit 59ad0e6a)
-
In glamor_init(), if the minimum requirements are not met, glamor may fail after setting up its own CloseScreen() and DestroyPixmap() routines, leading to a crash when either of the two routines is called if glamor failed to complete its initialization, e.g: (EE) Backtrace: (EE) 0: Xwayland (OsSigHandler+0x29) (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) (EE) 2: Xwayland (glamor_sync_close+0x2a) (EE) 3: Xwayland (glamor_close_screen+0x52) (EE) 4: Xwayland (CursorCloseScreen+0x88) (EE) 5: Xwayland (AnimCurCloseScreen+0xa4) (EE) 6: Xwayland (present_close_screen+0x42) (EE) 7: Xwayland (dix_main+0x4f9) (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf1) (EE) 9: Xwayland (_start+0x2a) Restore the previous CloseScreen() and DestroyPixmap() vfunc handlers in case of failure when checking for the minimum requirements, so that if any of the requirement is not met we don't leave the CloseScreen() and DestroyPixmap() from glamor handlers in place. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1390018 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit f43207c1)
-
The previous code only worked when the barrier was created by the same client as the one calling XIChangeDeviceHierarchy. http://bugzilla.redhat.com/show_bug.cgi?id=1384432 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Daniel Stone <daniels@collabora.com> (cherry picked from commit d6a6e1d6)
-