summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* xwayland: Keep the CVT timings for non-standard modesHEADmasterOlivier Fourdan2023-05-151-18/+6
| | | | | | | | | | | | | | | The current code, as changed by commit ad2d461de „Do not round non-standard modes“ is reported to be logically incongruent. We should either drop libxcvt entirely or simply fix the size, keeping the CVT timings unchanged. For backward compatibility and simplicity, I'd rather simply fix the hdisplay/vdisplay to match the given size. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Fixes: ad2d461de - xwayland: Do not round non-standard modes Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1549
* xwayland: Fix spelling of modeinfo in function nameOlivier Fourdan2023-05-151-9/+9
| | | | | | | | Commit ad2d461de „xwayland: Do not round non-standard mode“ introduced a spelling error in the names of the local functions. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Fixes: ad2d461de - xwayland: Do not round non-standard modes
* Xephyr: fix tiny memleak in KdParseKeyboard().Tamura Dai2023-05-121-0/+2
| | | | | | | ki->name has already initialized in KdNewKeyboard() with strdup(). But initialized in KdParseKeyboard() again. Signed-off-by: Tamura Dai <kirinode0@gmail.com>
* xwayland: Use our CVT function for fixed mode as wellOlivier Fourdan2023-05-111-17/+4
| | | | | | | | Now that our CVT function is able to deal with non-standard modes, we can safely use it for the fixed mode as well. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: Do not round non-standard modesOlivier Fourdan2023-05-111-16/+46
| | | | | | | | | | | | | | | | | | Currently, Xwayland uses libxcvt to generate the mode info and then passes that to RRModeGet() to generate a RRMode. However, libxcvt may round down the width to match the horizontal granularity (8), and that's a problem when the Wayland compositor is running a non-standard size (like, e.g. running nested with a custom size) because XRandR would report a width smaller than the actual size. To avoid that, check whether the CVT computed size differs from the expected size, and fallback to a simpler computation not doing any rounding if that's the case. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1540 Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland/window: Queue damage after commits are allowedJonas Ådahl2023-04-261-0/+12
| | | | | | | | | | | | | | | Compositors may use XWAYLAND_ALLOW_COMMITS to communicate when Xwayland may or may not commit new buffers to a wl_surface. If commits are denied, then later allowed, we'll only get a buffer attached if there is actual damage posted, which might be long after. This fixes an issue where the window manager would reparent a window while denying commits, then after reparenting, allow commits. The window in question belonged to a game and took several seconds produce the next frame, resulting in an empty window appearing as if it had just disappeared. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* xwayland/window: Move set-allow functions lower downJonas Ådahl2023-04-261-35/+35
| | | | | | | This will make some helper functions in the same file usable without extra declarations. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* Revert "fb: Remove even/odd tile slow-pathing"Izumi Tsutsui2023-04-195-38/+206
| | | | | | This reverts commit e572bcc7f4236b7e0f23ab762f225b3bce37db59. Closes: #1056
* fb: Declare wfbFinishScreenInit, wfbScreenInit for !FB_ACCESS_WRAPPERFlorian Weimer2023-04-191-2/+0
| | | | | | | | | xf86-video-nouveau calls wfbScreenInit without defining FB_ACCESS_WRAPPER (which has other unintended side effects). Presently, this compiles and links because compilers still support implicit function declarations, but this is going to change fairly soon. This seems to be the most straightforward change to keep the driver building.
* build: set _GNU_SOURCE when checking for SO_PEERCREDSimon Ser2023-04-141-1/+1
| | | | | | | | | | | | SO_PEERCRED is not POSIX, so might be hidden unless _GNU_SOURCE is defined. See [1]: cc.has_header_symbol() does not inherit the project arguments. [1]: https://github.com/mesonbuild/meson/issues/3301 Signed-off-by: Simon Ser <contact@emersion.fr>
* xwayland: Use the new API to set scanoutOlivier Fourdan2023-04-121-3/+10
| | | | | | | | | If the format and modifiers are from a tranche which supports scanout, we can set the corresponding flag to gbm_bo_create_with_modifiers2() to benefit from scanout buffers where applicable. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: Add xwl_glamor_get_drawable_modifiers_and_scanout()Olivier Fourdan2023-04-122-6/+32
| | | | | | | | | | | | Add a new API similar to xwl_glamor_get_drawable_modifiers() but also returning whether the format and modifiers are from a tranche which supports scanout. This is preparation work for adding scanout support with gbm_bo_create_with_modifiers2() when supported. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: use gbm_bo_create_with_modifiers2()Simon Ser2023-04-122-1/+10
| | | | | | | | This allows us to pass flags to the function, avoiding the forced implicit GBM_BO_USE_SCANOUT which happens with the older version. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: Fix build without GBMOlivier Fourdan2023-04-122-4/+7
| | | | | | | | | The present code in Xwayland cannot be used without GBM, so if GBM is not available (or too old), the build would fail. Make sure we do not use the present code without GBM support. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
* glamor: Fix build without GBMOlivier Fourdan2023-04-121-0/+2
| | | | | | | | | | | | The functions glamor_egl_fd_from_pixmap()/glamor_egl_fds_from_pixmap() are not available without GBM support. So if GBM is not available or too old, the code would fail to link trying to find the references to those functions. Make sure we skip that code when glamor is built without GBM. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
* xwayland: Make Wayland logs non-fatalOlivier Fourdan2023-04-071-2/+1
| | | | | | | | | | The Wayland library may log warnings, we do not need to make that fatal to the Xserver. By killing the Xserver whenever a warning is raised, we hide other log messages that might be also interesting. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
* ddxLoad: Check XDG_RUNTIME_DIR before fallback to /tmp/Alessandro Bono2023-04-061-2/+11
| | | | | | | | | | | | | | | | | The XKM_OUTPUT_DIR folder by default is defined as ${datadir}/X11/xkb/compiled and it is usually defined as /var/lib/xkb or %{_localstatedir}/lib/xkb by distributions. If X is executed as non-root it won't have permissions to write into that folder. If we fallback directly to /tmp we might get name collisions: ``` > Error: Cannot open "/tmp/server-10.xkm" to write keyboard description > Exiting ``` Where the file /tmp/server-10.xkm already exists but is owned by another user that previously executed X and had the display number 10. This is specially problematic when exeuting Xvfb. Before falling back to /tmp/ check first the XDG_RUNTIME_DIR.
* xwayland: Recycle buffers when dmabuf feedback changesOlivier Fourdan2023-04-031-0/+6
| | | | | | | | Whenever the linux-dmabuf v4 feedback changes, we need to recreate the existing buffers so they use the current linux-dmabuf v4 feedback. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: Try the Xwayland glamor hook to create pixmapsOlivier Fourdan2023-04-031-5/+12
| | | | | | | | | | | | When creating the window buffer's backing pixmap, try the Xwayland glamor hook first and fallback to the regular CreatePixmap() code path otherwise. That allows to enable direct scanout if possible, either through the regular dmabuf v4 code path, or from the implicit fallback code path. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: Create scanout capable BO with the fallback pathOlivier Fourdan2023-04-031-8/+9
| | | | | | | | | | | | | | | Before linux_dmabuf v4 support was added, the BO were created using gbm_bo_create_with_modifiers() which incidentally creates scanout capable buffers. We now need to replicate that explicitly when using the fallback path, with buffers window, otherwise direct scanout will not be possible in that case. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1535 Suggested-by: Michel Dänzer <mdaenzer@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: Add create_pixmap_for_window() to GBM backendOlivier Fourdan2023-04-031-8/+40
| | | | | | | | | | | | | | | | Add the implementation for create_pixmap_for_window() in the GBM glamor backend. To do so, we just rename the existing xwl_glamor_gbm_create_pixmap() as internal and add an optional drawable parameter, so that it can be used either from the regular CreatePixmap code path, or from the new direct Xwayland glamor's hook. v2: Fallback to xwl_glamor_get_modifiers() if xwl_glamor_get_drawable_modifiers() returned 0 modifiers. (Michel) Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: Add a direct hook to create pixmaps with glamorOlivier Fourdan2023-04-032-0/+18
| | | | | | | | | | | | | | With linux dmabuf v4 support, for direct scanout support, we need more context that just what CreatePixmap() provides, as we need the actual drawable to invoke xwl_glamor_get_drawable_modifiers(). Add a specific hook in Xwayland's glamor implementation that we can use for that purpose. This is preparation work for the direct scanout fixes. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: Check for implicit scanout availabilityOlivier Fourdan2023-04-032-0/+10
| | | | | | | | | | | | With implicit modifiers, DRM_FORMAT_MOD_INVALID is an allowed modifier, to indicate that the server can support the format. When looking for a scanout capable tranche with implicit modifiers, we ought to check for the availability of a tranche with an invalid modifier for the given format. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: Check for scanout support in tranchesOlivier Fourdan2023-04-031-3/+7
| | | | | | | | | | | | | | | The helper function xwl_feedback_is_modifier_supported() walks all the formats of a feeedback tranche and checks for format/modifier support availability. Add scanout support to that so that a caller can easily restrict the tranches to those which support scanout. This is preparation work for the implicit scanout support, no functional change. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* xwayland: Use a dedicated feedback callback for windowsOlivier Fourdan2023-04-031-18/+96
| | | | | | | | | | | Separate the callbacks for the default's feedback from the one for regular windows. This is preparation work to recreate the window buffer of feedback updates, no functional change. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* composite: Fix use-after-free of the COWOlivier Fourdan2023-03-291-0/+5
| | | | | | | | | | | | | | | | | ZDI-CAN-19866/CVE-2023-1393 If a client explicitly destroys the compositor overlay window (aka COW), we would leave a dangling pointer to that window in the CompScreen structure, which will trigger a use-after-free later. Make sure to clear the CompScreen pointer to the COW when the latter gets destroyed explicitly by the client. This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
* xkbUtils: use existing symbol names instead of deleted deprecated onesBenno Schulenberg2023-03-271-2/+2
| | | | Symbols `XK_Cyrillic_DZHE` and `XK_Serbian_DZE` were pure synonyms.
* xwayland: Prevent nested xwl_present_for_each_frame_callback callsMichel Dänzer2023-03-273-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It could happen with the following call path: frame_callback xwl_present_frame_callback xwl_present_msc_bump xwl_present_execute xwl_present_flip xwl_window_create_frame_callback The nested loop called xwl_present_reset_timer, which may end up calling xorg_list_del for the entry after the one frame_callback started the chain for. This resulted in the outer loop never terminating, because its next element wasn't hooked up to the list anymore. We avoid this by calling xwl_present_reset_timer as needed in frame_callback, and bailing from xwl_window_create_frame_callback if it was called from the former. We also catch nested calls and FatalError if they ever happen again due to another bug. v2: * Leave xwl_present_reset_timer call in xwl_present_frame_callback, needed if xwl_present_msc_bump didn't hook up the window to the frame callback list again. Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442
* xwayland: Refactor xwl_present_for_each_frame_callback helperMichel Dänzer2023-03-273-27/+20
| | | | Preparation for following changes, no functional change intended.
* test: Use either wayland-info or weston-infoOlivier Fourdan2023-03-221-1/+6
| | | | | | | | | | weston-info has been deprecated for quite some time, whereas wayland-info may not be available yet. So we use either, depending on what's actually available. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* glamor: Don't glFlush/ctx switch unless any work has been performedJoshua Ashton2023-03-174-7/+15
| | | | | | | | | | | | | | | | | | | | `glamor_make_current` is always called before any calls to GL. Apply some dirty-tracking to whenever we call `glamor_make_current` so that we can avoid a decent amount of redundant GL work on each Dispatch cycle. Gamescope previously was waking up an empty Xwayland server with an XQueryPointer and I noticed a significant amount of churn doing redundant GL work. This has been addressed on the Gamescope side as well, but avoiding any useless GL context switches and flushes when glamor is doing nothing is still beneficial for CPU and power usage on portable devices. Signed-off-by: Joshua Ashton <joshua@froggi.es> Reviewed-by: Emma Anholt <emma@anholt.net> Acked-by: Olivier Fourdan <ofourdan@redhat.com
* Add a .mailmap file to canonicalize author names and emailsAlan Coopersmith2023-03-151-0/+365
| | | | | | Based in part on Mesa's .mailmap Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
* gitlab CI: add workflow rulesAlan Coopersmith2023-03-141-0/+9
| | | | | | | Needed due to the gitlab config changes described in: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/438 Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
* xwayland: Fix uninitialised value created by a stack allocationOlivier Fourdan2023-03-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 3c07a01c4 (xwayland: Use xdg-output name for XRandR) changed the logic to use a fixed sized buffer allocated on the stack to pass to RROutputCreate() which would then copy it. Valgrind complains about this: == Conditional jump or move depends on uninitialised value(s) == at 0x49954B: MakeAtom (atom.c:87) == by 0x5108B3: RRMonitorCrtcName (rrmonitor.c:33) == by 0x510BBB: RRMonitorSetFromServer (rrmonitor.c:92) == by 0x511882: RRMonitorMakeList (rrmonitor.c:373) == by 0x512175: ProcRRGetMonitors (rrmonitor.c:634) == by 0x508091: ProcRRDispatch (randr.c:748) == by 0x4A860E: Dispatch (dispatch.c:546) == by 0x4B692F: dix_main (main.c:271) == by 0x431C90: main (stubmain.c:34) == Uninitialised value was created by a stack allocation == at 0x42122C: xwl_output_create (xwayland-output.c:816) This is actually harmless, but also simple to avoid by just initializing the content of the array with zeros, so let's just fix that. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Fixes: commit 3c07a01c4 - xwayland: Use xdg-output name for XRandR
* xwayland/glamor: Track if a xwl_pixmap uses explicit modifiersJonas Ådahl2023-03-081-20/+30
| | | | | | | | | | | If we allocated with implicit modifiers, then we shouldn't use the modifier returned by gbm_bo when checking whether the modifier is supported or not, since it won't be if the compositor only advertises implicit modifiers, nor should we use the modifier when creating the Wayland buffer object, as it wasn't explicitly advertised. Fixes: c6f2598a4 ("xwayland: don't fall back to wl_drm with explicit modifier") Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* xwayland/glamor/gbm: Use helper for implicit buffer params tooJonas Ådahl2023-03-081-6/+26
| | | | Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* xwayland/glamor/gbm: Initialize explicit buffer params in helperJonas Ådahl2023-03-081-31/+55
| | | | | | This is preparing for cleaning up the macro mess. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* xwayland/glamor/gbm: Only use modifier gbm API if explicitJonas Ådahl2023-03-081-2/+4
| | | | | | | If we're using implicit modifiers, we'll pass NULL and zero modifiers. Lets just use the legacy API directly instead. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
* Allow disabling the SHAPE extension at runtimeSimon Ser2023-03-033-1/+3
| | | | | | | | | To correctly render a window making use of SHAPE, a compositor must query the shape rectangles. This may not be a desirable feature for a Wayland compositor. Allow SHAPE to be turned off at runtime, so that the compositor can opt-out. Signed-off-by: Simon Ser <contact@emersion.fr>
* xwayland: use drmDevice to compare DRM devicesSimon Ser2023-03-035-21/+37
| | | | | | | | | The linux_dmabuf_v1 protocol doesn't guarantee any DRM node type: the compositor may send a primary node or a render node. Use drmDevice so that device comparisons are node-type-insensitive. Signed-off-by: Simon Ser <contact@emersion.fr> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1447
* Add libdrm 2.4.109 requirementAustin Shafer2023-03-033-2/+10
| | | | Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
* xwayland: Use MAP_PRIVATE for keymapsOlivier Fourdan2023-03-031-1/+1
| | | | | | | | | | | | | With wl_pointer.axis_v120 support, the wl_seat supported version has been bumped to 8, but Xwayland is still using MAP_SHARED which is prohibited, wl_seat version 7 and above enforces the use of MAP_PRIVATE for keymaps. Use MAP_PRIVATE for the keymaps mmap(). Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1512 Fixes: 3a02f56b4 - hook up wl_pointer.axis_v120 events
* xwayland: don't fall back to wl_drm with explicit modifierSimon Ser2023-03-031-1/+1
| | | | | | | | | | | | | | It's incorrect to strip an explicit modifier. Daniels' docs [1] states: > when importing a buffer, the user may supply `DRM_FORMAT_MOD_INVALID` as the > buffer modifier (or not supply a modifier) to indicate that the modifier is > unknown for whatever reason; this is only acceptable when the buffer has > not been allocated with an explicit modifier [1]: https://lore.kernel.org/dri-devel/20210905122742.86029-1-daniels@collabora.com/ Signed-off-by: Simon Ser <contact@emersion.fr>
* xwayland: fix error path when modifier is not supportedSimon Ser2023-03-031-2/+3
| | | | | | | | When the modifier is not supported by the compositor, and the DMA-BUF contains multiple planes, xwl_pixmap->buffer is NULL. Avoid crashing when calling wl_buffer_add_listener(). Signed-off-by: Simon Ser <contact@emersion.fr>
* xwayland: Include <sys/type.h> where neededOlivier Fourdan2023-03-032-0/+5
| | | | | | | | | | | | | | With the addition of linux_dmabuf v4, the code adds dev_t in various places but did not include <sys/types.h>. While that works on glibc, it may fail to build on other libc implementations such as musl libc. Make sure to explicitly include <sys/types.h> where we use dev_t. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1445 Fixes: bddfe190de - Implement linux_dmabuf_feedback event handlers
* present: Document the TearFree flip reasons in PresentFlipReasonSultan Alsawaf2023-02-281-0/+6
| | | | | | | | | | Adding new flip reasons after the TearFree ones would break the assumption that `reason >= PRESENT_FLIP_REASON_DRIVER_TEARFREE` implies either of the TearFree reasons. Document this in the PresentFlipReason enum in order to save someone a very bad headache in the future. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
* present: Fix inaccurate PresentCompleteNotify timing for TearFreeSultan Alsawaf2023-02-281-20/+38
| | | | | | | | | | | | | | | | The timing of PresentCompleteNotify events is inaccurate when a driver uses TearFree because there's no way to know exactly when a presentation will appear on the display without receiving a notification directly from the driver indicating that the TearFree flip containing a presentation's pixmap is actually visible on the display. To fix the inaccurate PresentCompleteNotify timing, make use of the new assumption that drivers which export TearFree permit a NULL pixmap to be passed to their flip callback in order to make a presentation track the exact TearFree flip responsible for rendering it onto the display. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Acked-by: Martin Roukala <martin.roukala@mupuf.org>
* present: Prevent double vblank enqueue on error when TearFree is usedSultan Alsawaf2023-02-281-17/+19
| | | | | | | | | | | | | | | | | | | | It's possible for present_execute_copy to enqueue a vblank even when TearFree is used, specifically when the present_queue_vblank in present_scmd_pixmap fails and the subsequent vblank enqueue in present_execute_copy somehow doesn't. This could happen if the DRM event queue is exhausted when present_queue_vblank is called, but is no longer exhausted by the time present_execute_copy is reached. This exceedingly unlikely chain of events can lead to a vblank getting enqueued a second time by the TearFree machinery in present_execute, which is not good. Although this scenario is very unlikely, prevent it by first checking that the vblank wasn't enqueued by present_execute_copy before attempting to enqueue it for TearFree. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Acked-by: Martin Roukala <martin.roukala@mupuf.org>
* modesetting: Support accurate DRI presentation timing with TearFreeSultan Alsawaf2023-02-286-4/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using TearFree, DRI clients have no way of accurately knowing when their copied pixmaps appear on the display without utilizing the kernel driver's notification indicating that the TearFree flip containing their pixmap is complete. This is because the target CRTC's MSC can change while the predicted completion MSC is calculated and even while the page flip IOCTL is sent to the kernel due to scheduling delays and/or unfortunate timing. Even worse, a page flip isn't actually guaranteed to be finished after one vblank; it may be several MSCs until a flip actually finishes depending on delays and load in hardware. As a result, DRI clients may be off by one or more MSCs when they naively expect their pixmaps to be visible at MSC+1 with TearFree enabled. This, for example, makes it impossible for DRI clients to achieve precise A/V synchronization when TearFree is enabled. This change therefore adds a way for DRI clients to receive a notification straight from the TearFree flip-done handler to know exactly when their pixmaps appear on the display. This is done by checking for a NULL pixmap pointer to modesetting's DRI flip routine, which indicates that the DRI client has copied its pixmap and wants TearFree to send a notification when the copied pixmap appears on the display as part of a TearFree flip. The existing PageFlip scaffolding is reused to achieve this with minimal churn. The Present extension will be updated in an upcoming change to utilize this new mechanism for DRI clients' presentations. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Acked-by: Martin Roukala <martin.roukala@mupuf.org>
* modesetting: Ensure vblank events always run in sequential orderSultan Alsawaf2023-02-281-4/+9
| | | | | | | | | | | | | | | | | | | | | It is possible for vblank events to run out of order with respect to one another because the event which was queued to the kernel has the privilege of running before all other events are handled. This allows kernel-queued events to run before other, older events which should've run first. Although this isn't a huge problem now, it will become more problematic after the next change which ties DRI client notifications to TearFree page flips. This increases the likelihood of DRI clients erroneously receiving presentation-completion notifications out of order; i.e., a client could receive a notification for a newer pixmap it submitted *before* receiving a notification for an older pixmap. Ensure vblank events always run in sequential order by removing the bias towards kernel-queued events, and therefore forcing them to run at their sequential position in the queue like other events. Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
View Lorry Controller Status