summaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2020-12-01modesetting: keep going if a modeset fails on EnterVTKishore Kadiyala3-9/+36
There was a time when setting a mode on a CRTC would not depend on the associated connector's state. If a mode had been set successfully once, it would mean it would work later on. This changed with the introduction of new connectors type that now require a link training sequence (DP, HDMI 2.0), and that means that some events may have happened while the X server was not master that would then prevent the mode from successfully be restored to its previous state. This patch relaxes the requirement that all modes should be restored on EnterVT, or the entire X-Server would go down by allowing modesets to fail (with some warnings). If a modeset fails, the CRTC will be disabled, and a RandR event will be sent for the desktop environment to fix the situation as well as possible. Additional patches might be needed to make sure that the user would never be left with all screens black in some scenarios. v2 (Martin Peres): - whitespace fixes - remove the uevent handling (it is done in a previous patch) - improve the commit message - reduce the size of the patch by not changing lines needlessly - return FALSE if one modeset fails in ignore mode - add comments/todos to explain why we do things - disable the CRTCs that failed the modeset Signed-off-by: Kishore Kadiyala <kishore.kadiyala@intel.com> Signed-off-by: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Kishore Kadiyala <kishore.kadiyala@intel.com> Closes: #1010 (cherry picked from commit efb3abddd49fb75bd6d0e31046fed43d258c93da)
2020-12-01modesetting: check the kms state on EnterVTMartin Peres3-13/+24
Normally, we would receive a uevent coming from Linux's DRM subsystem, which would trigger the check for disappearing/appearing resources. However, this event is not received when X is not master (another VT is selected), and so the userspace / desktop environment would not be notified about the changes that happened while X wasn't master. To fix the issue, this patch forces a refresh on EnterVT by splitting the kms-checking code from the uevent handling into its own (exported) function called drmmode_update_kms_state. This function is then called from both the uevent-handling function, and on EnterVT right before restoring the modes. Signed-off-by: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Kishore Kadiyala <kishore.kadiyala@intel.com> Tested-by: Kishore Kadiyala <kishore.kadiyala@intel.com> (cherry picked from commit 293cf660c95d7ba36510bcc4114d7fd5c5f3801c)
2020-11-09xwayland: Create an xwl_window for toplevel onlyOlivier Fourdan1-1/+1
One general assumption in Xwayland is that the xwl_window remains the same for all the child windows of the toplevel window. When mapping a new X11 window, ensure_surface_for_window() checks for an existing xwl_window by using xwl_window_get() which will just check for the registered xwl_window for the window. That means that a client mapping a child window of an existing window with a xwl_window will get another different xwl_window. If an X11 client issues a Present request on the parent window, hence placed underneath its child window of the same size, the Wayland compositor may not send the frame callback event for the parent's Wayland surface which is reckoned to be not visible, obscured behind the other Wayland surface for the child X11 window. That bug affects some games running in wine which may get 1 fps because the repaint occurs only on timeout with a long interval (as with, e.g. https://bugs.winehq.org/show_bug.cgi?id=47066) Fix ensure_surface_for_window() by using xwl_window_from_window() which will walk the window tree, so that a child window won't get another xwl_window than its parent. https://gitlab.freedesktop.org/xorg/xserver/-/issues/1099 See-also: https://bugs.winehq.org/show_bug.cgi?id=47066 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 606ba7fc51e5420646f75c4e672fbe61eb7c7e6e)
2020-11-09xwayland: non-rootless requires the wl_shell protocolOlivier Fourdan1-0/+5
When running non-rootless, Xwayland requires that the Wayland compositor supports the wl_shell protocol. Check for wl_shell protocol support at startup and exit cleanly if missing rather than segfaulting later in ensure_surface_for_window() while trying to use wl_shell_get_shell_surface(). Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Reviewed-by: Simon Ser <contact@emersion.fr> (cherry picked from commit ffd02d9b26bd560849c407a6dd4f5c4d7d2c1736)
2020-10-01xwayland: Remove pending stream reference when freeingOlivier Fourdan1-1/+1
The EGLStream backend keeps a queue of pending streams for each Xwayland window. However, when this pending queue is freed, the corresponding private data may not be cleared (typically if the pixmap for this window has changed before the compositor finished attaching the consumer for the window's pixmap's original eglstream), leading to a use-after-free and a crash when trying to use that data as the window pixmap. Make sure to clear the private data when the pending stream is freed. Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1055 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Tested-by: Karol Szuster <karolsz9898@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit a5f439dcd21b4fda093cb382bb1a758b434a1444)
2020-10-01xwayland: use drmGetNodeTypeFromFd for checking if a node is a render oneGreg V1-17/+2
Major/minor numbers are a.. major (ha) source of pain in FreeBSD porting. In this case, Xwayland was thinking that /dev/dri/card0 is already a render node, because the st_rdev on FreeBSD was passing the Linux-style check, and because of the assumption, acceleration would fail because various ioctls like AMDGPU_INFO would be denied on the non-render node. Switch to libdrm's function that already works correctly on all platforms. Signed-off-by: Greg V <greg@unrelenting.technology> Reviewed-by: Emmanuel Vadot <manu@FreeBSD.org> (cherry picked from commit 239ebdc9e447d4f836d0c2aa6068c6064fffb46c)
2020-09-30xwayland: Do not discard frame callbacks on allow commitsOlivier Fourdan1-13/+0
Currently, when a X11 client (usually the X11 window manager from a Wayland compositor) changes the value of the X11 property `_XWAYLAND_ALLOW_COMMITS` from `false` to `true`, all pending frame callbacks on the window are discarded so that the commit occurs immediately. Weston uses that mechanism to prevent the content of the window from showing before it's ready when mapping the window initially, but discarding the pending frame callbacks has no effect on the initial mapping of the X11 window since at that point there cannot be any frame callback on a surface which hasn't been committed yet anyway. However, discarding pending frame callbacks can be problematic if we were to use the same `_XWAYLAND_ALLOW_COMMITS` mechanism to prevent damages to be posted before the X11 toplevel is updated completely (including the window decorations from the X11 window manager). Remove the portion of code discarding the pending frame callback, Xwayland should always wait for a pending frame callback if there's one before posting new damages. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> https://gitlab.freedesktop.org/xorg/xserver/merge_requests/333 (cherry picked from commit 66da95a172c4941b75ffedcdaa0138c0a48f11fb)
2020-09-30xwayland: Check window pixmap in xwl_present_check_flip2Michel Dänzer1-0/+8
We can only flip if the window pixmap matches that of the toplevel window. Doing so regardless could cause the toplevel window pixmap to get destroyed while it was still referenced by the window, resulting in use-after-free and likely a crash. Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1033 Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Roman Gilg <subdiff@gmail.com> (cherry picked from commit 4c25356d6cd908c5030c70e712076dff318ac00d)
2020-09-30xfree86: Take second reference for SavedCursor in xf86CursorSetCursorMichel Dänzer1-0/+3
The same pointer is kept in CurrentCursor as well, therefore two RefCursor calls are needed. Fixes use-after-free after switching VTs. Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1067 (cherry picked from commit 919f1f46fc67dae93b2b3f278fcbfc77af34ec58)
2020-09-08Revert "linux: Make platform device probe less fragile"Olivier Fourdan1-2/+18
This reverts commit 74b7427c41b4e4104af7abf70a996c086d3d7628. https://gitlab.freedesktop.org/xorg/xserver/-/issues/1068
2020-08-18linux: Make platform device probe less fragileAdam Jackson1-18/+2
At the point where xf86BusProbe runs we haven't yet taken our own VT, which means we can't perform drm "master" operations on the device. This is tragic, because we need master to fish the bus id string out of the kernel, which we can only do after drmSetInterfaceVersion, which for some reason stores that string on the device not the file handle and thus needs master access. Fortunately we know the format of the busid string, and it happens to almost be the same as the ID_PATH variable from udev. Use that instead and stop calling drmSetInterfaceVersion. (backported from commit 0816e8fca6194dfb4cc94c3a7fcb2c7f2a921386) Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Huacai Chen <chenhc@lemote.com>
2020-08-18xfree86: add drm modes on non-GTF panelsAaron Ma5-4/+48
EDID1.4 replaced GTF Bit with Continuous or Non-Continuous Frequency Display. Check the "Display Range Limits Descriptor" for GTF support. If panel doesn't support GTF, then add gtf modes. Otherwise X will only show the modes in "Detailed Timing Descriptor". V2: Coding style changes. V3: Coding style changes, remove unused variate. V4: remove unused variate. BugLink: https://gitlab.freedesktop.org/drm/intel/issues/313 Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 6a79a737e2c0bc730ee693b4ea4a1530c108be4e)
2020-08-18xwayland: Handle NULL xwl_seat in xwl_seat_can_emulate_pointer_warpMichel Dänzer1-1/+6
This can happen e.g. with weston's headless backend. Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit e33453f9111b21e4814d628e6ae00bc7b200f404)
2020-08-18xwayland: Propagate damage x1/y1 coordinates in xwl_present_flipMichel Dänzer1-1/+3
This couldn't have worked correctly for non-0 x1/y1. Noticed by inspection. Reviewed-by: Simon Ser <contact@emersion.fr> (cherry picked from commits 9141196d3104ab37385c3e385deaa70c002dd184) (cherry picked fixup from commit 85a6fd11c723888ca093785a3df43066fdca9c33)
2020-08-18xwayland: Use a fixed DPI value for core protocolOlivier Fourdan2-40/+8
The way Xwayland works (like all Wayland clients), it first queries the Wayland registry, set up all relevant protocols and then initializes its own structures. That means Xwayland will get the Wayland outputs from the Wayland compositor, compute the physical size of the combined outputs and set the corresponding Xwayland screen properties accordingly. Then it creates the X11 screen using fbScreenInit() but does so by using a default DPI value of 96. That value is used to set the physical size of the X11 screen, hence overriding the value computed from the actual physical size provided by the Wayland compositor. As a result, the DPI computed by tools such as xdpyinfo will always be 96 regardless of the actual screen size and resolution. However, if the Wayland outputs get reconfigured, or new outputs added, or existing outputs removed, Xwayland will recompute and update the physical size of the screen, leading to an unexpected change of DPI. To avoid that discrepancy, use a fixed size DPI (defaults to 96, and can be set using the standard command lime option "-dpi") and compute a physical screen size to match that DPI setting. Note that only affects legacy core protocols, X11 clients can still get the actual physical output size as reported by the Wayland compositor using the RandR protocol, which also allows for the size to be 0 if the size is unknown or meaningless. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Simon Ser <contact@emersion.fr> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/731 (cherry picked from commit b0413b6e99c6b5fbc04229ce64ddf1f41b08e63e)
2020-08-18xwayland: only use linux-dmabuf if format/modifier was advertisedSimon Ser1-4/+24
Previously, linux-dmabuf was used unconditionally if the buffer had a modifier. However creating a linux-dmabuf buffer with a format/modifier which hasn't been advertised will fail. Change xwl_glamor_gbm_get_wl_buffer_for_pixmap to use linux-dmabuf when the format/modifier has been advertised only. Signed-off-by: Simon Ser <contact@emersion.fr> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1035 Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit c0e13cbf5a56e1fdd1e4ce58ebdefb6d2904e4b3)
2020-08-18hw/xfree86: Avoid cursor use after freeMartin Weber1-1/+2
During a VT-Switch a raw pointer to the shared cursor object is saved which is then freed (in case of low refcount) by a call to xf86CursorSetCursor with argument pCurs = NullCursor. This leads to a dangling pointer which can follow in a use after free. This fix ensures that there is a shared handle saved for the VT-Switch cycle. Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 7ae221ad5774756766dc78a73d71f4163ac7b1c6)
2020-08-18Update URL's in man pagesAlan Coopersmith4-7/+7
Mostly http->https conversions, but also replaces gitweb.fd.o with gitlab.fd.o, and xquartz.macosforge.org with xquartz.org. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit a5151f58cf98d1696d60a3577dc50851f159da8a)
2020-08-12xwayland: Disable the MIT-SCREEN-SAVER extension when rootlessOlivier Fourdan1-0/+13
Xwayland is just a Wayland client, no X11 screensaver should be expected to work reliably on Xwayland when running rootless because Xwayland cannot grab the input devices so it has no way to actually lock the screen managed by the Wayland compositor. Turn off the screensaver on Xwayland when running rootless by setting the screensaver timeout and interval and their default values to zero and disable the MIT-SCREEN-SAVER extension. Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1051 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 5c20e4b834145f590c68dbc98e33c7d3d710001a)
2020-07-22xwayland: Hold a pixmap reference in struct xwl_present_eventMichel Dänzer2-5/+14
In the log of the commit below, I claimed this wasn't necessary on the 1.20 branch, but this turned out to be wrong: It meant that event->buffer could already be destroyed in xwl_present_free_event, resulting in use-after-free and likely a crash. Fixes: 22c0808ac88f "xwayland: Free all remaining events in xwl_present_cleanup"
2020-07-21modesetting: Fix front_bo leak at drmmode_xf86crtc_resize on XRandR rotationJose Maria Casanova Crespo1-3/+3
Since the introduction of "modesetting: Remove unnecessary fb addition from drmmode_xf86crtc_resize" the fb_id isn't initialited at drmmode_xf86crtc_resize. Rotate operation of XRandR uses rotate_bo. So in this case the fb_id associated to the front_bo is not initialized at drmmode_set_mode_major. So fd_id remains 0. As every call to drmmode_xf86crtc_resize allocates a new front_bo we should destroy unconditionally the old_front_bo if operation success. So we free the allocated GBM handles. This avoids crashing xserver with a OOM in the RPI4 1Gb at 4k resolution after 3 series xrandr rotations from normal to left and vice versa reported at https://github.com/raspberrypi/firmware/issues/1345 Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Reviewed-by: Keith Packard <keithp@keithp.com> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1024 Fixes: 8774532121 "modesetting: Remove unnecessary fb addition from drmmode_xf86crtc_resize" (cherry picked from commit 73480f172aeced074dd9301ae4d97f7d2f3a9a45)
2020-07-20xwayland: Store xwl_tablet_pad in its own private keyLyude Paul1-2/+10
When a slave device causes the master virtual pointer device to change device types, the device's private data pointer (device->public.devicePrivate) is also changed to match the type of the slave device. This can be a problem though, as tablet pad devices will set the device's private data pointer to their own xwl_tablet_pad struct. This can cause us to dereference the pointer as the wrong type, and result in a segfault: Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault. wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at src/wayland-client.c:792 792 va_start(ap, opcode); (gdb) bt 0 wl_proxy_marshal (proxy=0x51, opcode=opcode@entry=0) at src/wayland-client.c:792 1 0x00005610b27b6c55 in wl_pointer_set_cursor (hotspot_y=0, hotspot_x=0, surface=0x0, serial=<optimized out>, wl_pointer=<optimized out>) at /usr/include/wayland-client-protocol.h:4610 2 xwl_seat_set_cursor (xwl_seat=xwl_seat@entry=0x5610b46d5d10) at xwayland-cursor.c:137 3 0x00005610b27b6ecd in xwl_set_cursor (device=<optimized out>, screen=<optimized out>, cursor=<optimized out>, x=<optimized out>, y=<optimized out>) at xwayland-cursor.c:249 4 0x00005610b2800b46 in miPointerUpdateSprite (pDev=0x5610b4501a30) at mipointer.c:468 5 miPointerUpdateSprite (pDev=0x5610b4501a30) at mipointer.c:410 6 0x00005610b2800e56 in miPointerDisplayCursor (pCursor=0x5610b4b35740, pScreen=0x5610b3d54410, pDev=0x5610b4501a30) at mipointer.c:206 7 miPointerDisplayCursor (pDev=0x5610b4501a30, pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at mipointer.c:194 8 0x00005610b27ed62b in CursorDisplayCursor (pDev=<optimized out>, pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at cursor.c:168 9 0x00005610b28773ee in AnimCurDisplayCursor (pDev=0x5610b4501a30, pScreen=0x5610b3d54410, pCursor=0x5610b4b35740) at animcur.c:197 10 0x00005610b28eb4ca in ChangeToCursor (pDev=0x5610b4501a30, cursor=0x5610b4b35740) at events.c:938 11 0x00005610b28ec99f in WindowHasNewCursor (pWin=pWin@entry=0x5610b4b2e0c0) at events.c:3362 12 0x00005610b291102d in ChangeWindowAttributes (pWin=0x5610b4b2e0c0, vmask=<optimized out>, vlist=vlist@entry=0x5610b4c41dcc, client=client@entry=0x5610b4b2c900) at window.c:1561 13 0x00005610b28db8e3 in ProcChangeWindowAttributes (client=0x5610b4b2c900) at dispatch.c:746 14 0x00005610b28e1e5b in Dispatch () at dispatch.c:497 15 0x00005610b28e5f34 in dix_main (argc=16, argv=0x7ffc7a601b68, envp=<optimized out>) at main.c:276 16 0x00007f8828cde042 in __libc_start_main (main=0x5610b27ae930 <main>, argc=16, argv=0x7ffc7a601b68, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc7a601b58) at ../csu/libc-start.c:308 17 0x00005610b27ae96e in _start () at cursor.c:1064 Simple reproducer in gnome-shell: open up an Xwayland window, press some tablet buttons, lock and unlock the screen. Repeat if it doesn't crash the first time. So, let's fix this by registering our own device-specific private key for storing a backpointer to xwl_tablet_pad, so that all input devices have their private data pointers set to their respective xwl_seat. Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Lyude Paul <lyude@redhat.com> (cherry picked from commit ba0e789b912671c724a21b3a30291247718bcf7d)
2020-07-20xwayland: Initialise values in xwlVidModeGetGamma()SimonP1-0/+1
ProcVidModeGetGamma() relies on GetGamma() to initialise values if it returns TRUE. Without this, we're sending uninitialised values to clients. Fixes: xorg/xserver#1040 (cherry picked from commit 6748a4094158d2bde1630b915a5318f9f22c8e0a)
2020-07-20xwayland: Fix crashes when there is no pointerSjoerd Simons1-0/+6
When running with a weston session without a pointer device (thus with the wl_seat not having a pointer) xwayland pointer warping and pointer confining should simply be ignored to avoid crashes. Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> (cherry picked from commit d35f68336b0a462dc660797d1779581f348af04e)
2020-07-20xwayland: Clear private on device removalOlivier Fourdan1-16/+39
Xwayland uses the device private to point to the `xwl_seat`. Device may be removed at any time, including on suspend. On resume, if the DIX code ends up calling a function that requires the `xwl_seat` such as `xwl_set_cursor()` we may end up pointing at random data. Make sure the clear the device private data on removal so that we don't try to use it and crash later. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/xorg/xserver/issues/709 (cherry picked from commit 4195e8035645007be313ade79032b8d561ceec6c)
2020-07-20xwayland: Free all remaining events in xwl_present_cleanupMichel Dänzer1-15/+11
At the end of xwl_present_cleanup, these events aren't reachable anymore, so if we don't free them first, they're leaked. (cherry picked from commit 64565ea344fef0171497952ef75f019cb420fe3b) v2: * Simpler backport, no need to keep a reference to the pixmap on the 1.20 branch.
2020-07-20xwayland: Always use xwl_present_free_event for freeing Present eventsMichel Dänzer1-15/+12
Minor cleanup, and will make the next change simpler. No functional change intended. Reviewed-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 1beffba699e2cc3f23039d2177c025bc127966de)
2020-07-03xwayland: import DMA-BUFs with GBM_BO_USE_RENDERING onlySimon Ser1-2/+3
Drop GBM_BO_USE_SCANOUT from the GBM_BO_IMPORT_FD import, add GBM_BO_USE_RENDERING to the GBM_BO_IMPORT_FD_MODIFIER import. If the DMA-BUF cannot be scanned out, gbm_bo_import with GBM_BO_USE_SCANOUT will fail. However Xwayland doesn't need to scan-out the buffer and can work fine without scanout. Glamor only needs GBM_BO_USE_RENDERING. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Reviewed-by: Daniel Stone <daniels@collabora.com> (cherry picked from commit 421ce458f1d295015c108eb32f9611e527649cf8)
2020-05-29xwayland: Fix infinite loop at startupOlivier Fourdan3-14/+18
Mutter recently added headless tests, and when running those tests the Wayland compositor runs for a very short time. Xwayland is spawned by the Wayland compositor and upon startup will query the various Wayland protocol supported by the compositor. To do so, it will do a roundtrip to the Wayland server waiting for events it expects. If the Wayland compositor terminates before Xwayland has got the replies it expects, it will loop indefinitely calling `wl_display_roundtrip()` continuously. To avoid that issue, add a new `xwl_screen_roundtrip()` that checks for the returned value from `wl_display_roundtrip()` and fails if it is negative. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Roman Gilg <subdiff@gmail.com> Reviewed-by: Jonas Ådahl <jadahl@gmail.com> (cherry picked from commit 785e59060c00129e47da6c0877604a56d7e0e32f)
2020-05-22modesetting: Disable pageflipping when using a swcursorHans de Goede6-6/+165
The miPointerSpriteFunc swcursor code expects there to only be a single framebuffer and when the cursor moves it will undo the damage of the previous draw, potentially overwriting what ever is there in a new framebuffer installed after a flip. This leads to all kind of artifacts, so we need to disable pageflipping when a swcursor is used. The code for this has shamelessly been copied from the xf86-video-amdgpu code. Fixes: https://gitlab.freedesktop.org/xorg/xserver/issues/828 Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> (cherry picked from commit 0aaac8d783e78c040a70a55ba8d67809abd7e625) Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@displaylink.com>
2020-03-22Fix old-style definition warning for xf86OSInputThreadInit()Jon Turney5-5/+5
../hw/xfree86/os-support/stub/stub_init.c: In function ‘xf86OSInputThreadInit’: ../hw/xfree86/os-support/stub/stub_init.c:29:1: warning: old-style function definition [-Wold-style-definition] (cherry picked from commit 7c266cafed14b38c039091651069ae9888c3a8ae)
2020-03-22Add xf86OSInputThreadInit to stub os-support as wellJon Turney1-0/+6
stub os support also needs to provide xf86OSInputThreadInit, omitted in ea1527a8 (cherry picked from commit c020769dbfb965740c8441d8242b738ef572a7c9)
2020-03-18xwayland: Delete all frame_callback_list nodes in xwl_unrealize_windowMichel Dänzer3-10/+11
We were only calling xwl_present_unrealize_window for the toplevel window, but the list can contain entries from child windows as well, in which case we were leaving dangling pointers to freed memory. Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/1000 Fixes: c5067feaeea1 "xwayland: Use single frame callback for Present flips and normal updates" Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> Tested-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 5e91587302e85fd6f0e8d5ffbe30182e18c6913f)
2020-03-12xwayland/glamor-gbm: Handle DRM_FORMAT_MOD_INVALID gracefullyJonas Ådahl1-0/+4
The compositor may send DRM_FORMAT_MOD_INVALID instead of a list of modifiers for various reasons. Handle this gracefully by ignoring it. Without this, if a compositor would send DRM_FORMAT_MOD_INVALID, it'd result in empty windows provided by Xwayland. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit edf964434eac10ffbe27cc883e3ab95505669aee)
2020-03-07Fix building with `-fno-common`David Seifert4-5/+3
* GCC 10 will switch the default to `-fno-common`. https://gcc.gnu.org/PR85678 Bug: https://bugs.gentoo.org/705880 Signed-off-by: Matt Turner <mattst88@gmail.com>
2020-03-02xwayland: Use frame callbacks for Present vblank eventsMichel Dänzer2-10/+14
Instead of only the fallback timer. Fixes https://gitlab.freedesktop.org/xorg/xserver/issues/854 v2: * Drop unused frame_callback member of struct xwl_present_window (Olivier Fourdan) Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 9b31358c52e951883bf7c01c953a9da080542244)
2020-03-02xwayland: Use single frame callback for Present flips and normal updatesMichel Dänzer3-31/+39
Using a list of Present windows that need to be called back. This prepares for the following change, there should be no change in observed behaviour. v2: * Use xwl_window_create_frame_callback instead of making the frame_listener struct non-static (Olivier Fourdan) Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit c5067feaeea115761f0a72f37407c6e5e943d1a1)
2020-03-02xwayland: Add xwl_window_create_frame_callback helperMichel Dänzer2-3/+11
This will be used by the following changes. No functional change intended. Reviewed-by: Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit f80eea0529b2cfb805a9c7d4994a4235451131e3)
2020-02-21xwayland: clear pixmaps after creation in rootless modeDor Askayo1-1/+5
When a pixmap is created with a backing FBO, the FBO should be cleared to avoid rendering uninitialized memory. This could happen when the pixmap is rendered without being filled in its entirety. One example is when a top-level window without a background is resized. The pixmap would be reallocated to prepare for more pixels, but uninitialized memory would be rendered in the resize offset until the client sends a frame that fills these additional pixels. Another example is when a new top-level window is created without a background. Uninitialized memory would be rendered after the pixmap is allocated and before the client sends its first frame. This issue is only apparent in OpenGL implementations that don't zero the VRAM of allocated buffers by default, such as RadeonSI. Signed-off-by: Dor Askayo <dor.askayo@gmail.com> Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/636 Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 0e9a0c203c2ae4eae12bdbb95428f398211c7bee) [ Michel Dänzer: * Squashed in commit ebf549db2d9341d99e0d0847b948dd798d98f7dc * Dropped code related to glamor_format, which only exists on master ]
2020-02-21xwayland: Call glamor_block_handler from xwl_screen_post_damageMichel Dänzer1-0/+11
In between the two phases introduced by the previous change. This makes sure all pending drawing to the new buffers is flushed before they're committed to the Wayland server. (cherry picked from commit a542224ea28e2e8ccaf5e0df85bf6c603e97599a)
2020-02-21xwayland: Split up xwl_screen_post_damage into two phasesMichel Dänzer1-3/+14
The first phase sets the new surface properties for all damaged windows, then the second phase commits all surface updates. This is preparatory for the next change, there should be no observable change in behaviour (other than the order of Wayland protocol requests). Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit f88d9b1f779835302e02e255fcd45989db7f488d)
2020-02-19modesetting: Disable atomic support by defaultMaarten Lankhorst2-2/+8
The atomic driver has issues with modesetting when stealing connectors from a different crtc, a black screen when doing rotation on a different crtc, and in general is just a mapping of the legacy helpers to atomic. This is already done in the kernel, so just fallback to legacy by default until this is fixed. Please backport to 1.20, as we don't want to enable it for everyone there. It breaks for existing users. The fixes to make the xserver more atomic have been pending on the mailing list for ages. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110375 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110030 References: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/36/commits Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit f0d78b47ac49977a6007f5fe081f00c6eb19a12e)
2020-02-06modesetting: remove unnecessary error message, fix zaphod leasesDave Airlie1-4/+5
I introduced this error with the MST hotplug code, but it can trigger on zaphod setups, and is perfectly fine. There is no support for MST/hotplug on zaphod setups currently, so we can just skip over the dynamic connector handling here. However we shouldn't skip over the lease handling so move it into the codepath. Fixes: 9257b1252da9 ("modesetting: add dynamic connector hotplug support (MST) (v3)") Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 1cfdd1a96580733df3625bcea3384ffee3dc92df)
2020-02-06xfree86/modes: Bail from xf86RotateRedisplay if pScreen->root is NULLMichel Dänzer1-1/+1
Avoids a crash in xf86RotatePrepare -> DamageRegister during CreateScreenResources if rotation or another transform is configured for any connected RandR output in xorg.conf. The generic rotation/transform code generally can't work without the root window currently. Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/969 Fixes: 094f42cdfe5d "xfree86/modes: Call xf86RotateRedisplay from xf86CrtcRotate" Acked-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> (cherry picked from commit 6a5e47c57d16de8b6a6a2636f3cbad1aebec32e2)
2020-01-14modesetting: Explicitly #include "mi.h"Michel Dänzer1-0/+1
For the miClearDrawable prototype. Apparently it doesn't get pulled in for some build configurations, breaking the build. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit a24a786fc8490fda08b15c3dab6fa6750f008ecb)
2020-01-13os-support/solaris: Set IOPL for input thread tooAlan Coopersmith1-1/+5
Since the Solaris kernel tracks IOPL per thread, and doesn't inherit raised IOPL levels when creating a new thread, we need to turn it on in the input thread for input drivers like vmmouse that need register access to work correctly. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit 12769c516d9356bd92f90e2f53a4853dbfdc4aed)
2020-01-13Add xf86OSInputThreadInit call from common layer into os-support layerAlan Coopersmith6-0/+26
Allows os backends to run additional code as necessary to set up the input thread. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit ea1527a8a662dcc5ac3ed49135740aa5f24f74bc)
2020-01-13Add ddxInputThread call from os layer into ddx layerAlan Coopersmith7-0/+63
Allows ddx's to run additional code as necessary to set up the input thread. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit 4ad21c3247d98ac6c5ad71fa36be60ed04f7c92c)
2020-01-13os-support/solaris: Drop ExtendedEnabled global variableAlan Coopersmith1-13/+0
Keeping track of kernel state in user space doesn't buy us anything, and introduces bugs, as we were keeping global state but the Solaris kernel tracks IOPL per thread. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> (cherry picked from commit 7533fa9bd5a4a0f7743d553be186514d684308c8)
2020-01-13modesetting: Check whether RandR was initialized before calling rrGetScrPrivAaron Plattner3-6/+20
Calling rrGetScrPriv when RandR isn't initialized causes an assertion failure that aborts the server: Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed. Thread 1 "Xorg" received signal SIGABRT, Aborted. 0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6 #1 0x00007ffff7892897 in abort () from /usr/lib/libc.so.6 #2 0x00007ffff7892767 in __assert_fail_base.cold () from /usr/lib/libc.so.6 #3 0x00007ffff78a1526 in __assert_fail () from /usr/lib/libc.so.6 #4 0x00007ffff7fb57c1 in dixGetPrivateAddr (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:121 #5 0x00007ffff7fb5822 in dixGetPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:136 #6 0x00007ffff7fb586a in dixLookupPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:166 #7 0x00007ffff7fb8445 in CreateScreenResources (pScreen=0x555555ab1790) at ../hw/xfree86/drivers/modesetting/driver.c:1335 #8 0x000055555576c5e4 in xf86CrtcCreateScreenResources (screen=0x555555ab1790) at ../hw/xfree86/modes/xf86Crtc.c:744 #9 0x00005555555d8bb6 in dix_main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/main.c:214 #10 0x00005555557a4f0b in main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/stubmain.c:34 This can happen, for example, if the server is configured with Xinerama and there is more than one X screen: Section "ServerLayout" Identifier "crash" Screen 0 "modesetting" Screen 1 "dummy" RightOf "modesetting" Option "Xinerama" EndSection Section "Device" Identifier "modesetting" Driver "modesetting" EndSection Section "Screen" Identifier "modesetting" Device "modesetting" EndSection Section "Device" Identifier "dummy" Driver "dummy" EndSection Section "Screen" Identifier "dummy" Device "dummy" EndSection The problem does not reproduce if there is only one X screen because of this code in xf86RandR12Init: #ifdef PANORAMIX /* XXX disable RandR when using Xinerama */ if (!noPanoramiXExtension) { if (xf86NumScreens == 1) noPanoramiXExtension = TRUE; else return TRUE; } #endif Fix the problem by checking dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv. This is similar to what the xf86-video-amdgpu driver does: https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/blob/fd66f5c0bea2b7c22a47bfd5eb1f22d32d166d9c/src/amdgpu_kms.c#L388 Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 4226c6d0329df440551b7b91ae573a82c64a1ac9)
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-30 18:48:32 +0000