- 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: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:
-
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:
-
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:
-
Reviewed-by: -
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:
-
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:
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: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:
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:
-
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:
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:
-
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:
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:
Daniel Stone <daniels@collabora.com> (cherry picked from commit d6a6e1d6)
-
Commits 81601564 and fee0827a 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:
-
Fixes the following warning: test/Makefile.am:69: warning: variable 'os_LDADD' is defined but no program or test/Makefile.am:69: library has 'os' as canonical name (possible typo) Introduced upon the removal of test/os in: commit 6a5a4e60 Author: Keith Packard <keithp@keithp.com> Date: Tue Dec 8 14:39:46 2015 -0800 Remove SIGIO support for input [v5] This removes all of the SIGIO handling support used for input throughout the X server, preparing the way for using threads for input handling instead. Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls to stub functions input_lock/input_unlock so that we don't lose this information. xfree86 SIGIO support is reworked to use internal versions of OsBlockSIGIO and OsReleaseSIGIO. v2: Don't change locking order (Peter Hutterer) v3: Comment weird && FALSE in xf86Helper.c Leave errno save/restore in xf86ReadInput Squash with stub adding patch (Peter Hutterer) v4: Leave UseSIGIO config parameter so that existing config files don't break (Peter Hutterer) v5: Split a couple of independent patch bits out of kinput.c (Peter Hutterer) Signed-off-by:
Rhys Kidd <rhyskidd@gmail.com> Reviewed-by:
-
- Dec 13, 2016
-
-
Adam Jackson authored
The commit message makes the assertion that the code below damage is not allowed to change whether there's a damage monitor for the drawable. That turns out not to be the case! exa's mixed code, at least, will create and destroy a damage in PrepareAccess. The destroy path can then be catastrophic, as damageRegionProcessPending will attempt to RegionEmpty memory from the middle of a freed block. I'd wanted that invariant for performance, but faster isn't worth broken, so revert it. I think what exa's doing is reasonable, so the better way to improve performance for the unmonitored case is to either revisit dynamically wrapping into the GC, or inline damage into dix. This reverts commit 4e124203. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389886 Signed-off-by:
-
- Nov 15, 2016
-
-
Keith Packard authored
Signed-off-by: -
Keith Packard authored
I think it is possible that output could get queued to a client during CloseDownClient. After it is removed from the pending queue, active grabs are released, the client is awoken if sleeping and any work queue entries related to the client are processed. To fix this, move the call removing it from the output_pending chain until after clientGone has been set and then check clientGone in output_pending_mark. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1382444 Signed-off-by:
-
- Nov 02, 2016
-
-
Import changes from these mesa commits: 85ea8deb26da420 i965: Removing PCI IDs that are no longer listed as Kabylake. bdff2e554735ed9 i956: Add more Kabylake PCI IDs. f1fa8b4a1ca73fa i965/bxt: Add 2x6 variant d1ab544bb883d04 i965/chv: Display proper branding 20e8ee36627f874 i965/skl: Update Skylake renderer strings 644c8a515192d28 i965/skl: Add two missing device IDs Reviewed-by:
Timo Aaltonen <tjaalton@ubuntu.com>
-
- Nov 01, 2016
-
-
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:
Ian Ray <ian.ray@ge.com> Acked-by:
-
- Oct 28, 2016
-
-
Keith Packard authored
Signed-off-by: -
Keith Packard authored
[This was originally a workaround for a client-side resource leak: http://lists.freedesktop.org/archives/xorg-devel/2012-November/034555.html Obviously that's a broken app, but the performance problem it illustrates - that walking the linked list ends up burning all your CPU time - is real enough. - ajax] v2: Replace with a shorter code sequence which computes the same results for all but numBits == 7 Reviewed-by:
-
Keith Packard authored
-
Keith Packard authored
If a work proc wakes up a sleeping client and it is ready to execute, we need to re-compute the local 'are_ready' value before deciding what timeout value to use in WaitForSomething. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98030 Signed-off-by:
-
Keith Packard authored
If we're never painting anything in the window, we probably don't need to map it. v2: Drop ephyr_glamor_gles2 from hostx.c Signed-off-by:
-
xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option "SWCursor" is specified, sPriv == NULL. In this case we should assume that HW cursors are not supported. Signed-off-by:
Alex Goins <agoins@nvidia.com> Reviewed-by:
Andy Ritger <aritger@nvidia.com> Signed-off-by:
-
- Oct 27, 2016
-
-
Jon Turney authored
This partially reverts 501d8e2b. Signed-off-by:
Jon Turney <jon.turney@dronecode.org.uk> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com>
-
- Oct 26, 2016
-
-
Peter Hutterer authored
On Linux, setting the main thread's name changes the program name (/proc/self/comm). Setting it to MainThread breaks scripts that rely on the command name, e.g. ps -C Xorg. Signed-off-by:
-
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:
-
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:
Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by:
-
Commit c7e8d4a6 had already unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT but commit 9257b125 didn't notice that. Signed-off-by:
Nikhil Mahale <nmahale@nvidia.com> Reviewed-by:
-
Prior to this commit the Xorg.wrap code to detect if root rights are necessary checked for DRM_IOCTL_MODE_GETRESOURCES succeeding *and* reporting more then 0 output connectors. DRM_IOCTL_MODE_GETRESOURCES succeeding alone is enough to differentiate between old drm only cards (which need ums and thus root) and kms capable cards. Some hybrid gfx laptops have 0 output connectors on one of their 2 GPUs, resulting in Xorg needlessly running as root. This commits removes the res.count_connectors > 0 check, fixing this. Signed-off-by:
-
Fixes DRI2 client driver name mapping for newer AMD GPUs with the modesetting driver, allowing the DRI2 extension to initialize. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
-
Add a missing ifdef needed for --disable-glamor. Signed-off-by:
-
Commit 501d8e2b removed --enable-aiglx, but made xwin always be --enable-glx. Signed-off-by:
-
