- Dec 20, 2022
-
-
Sultan Alsawaf authored
This adds support for TearFree page flips to eliminate tearing without the use of a compositor. It allocates two shadow buffers for each CRTC, a back buffer and a front buffer, and uses damage tracking to minimize excessive copying between buffers and skip unnecessary flips when the screen's contents remain unchanged. It works on transformed screens too, such as rotated and scaled CRTCs. When PageFlip is enabled, TearFree won't force fullscreen DRI clients to synchronize their page flips to the vblank interval. TearFree is disabled by default. Signed-off-by:Sultan Alsawaf <sultan@kerneltoast.com>
-
Sultan Alsawaf authored
The DRM event queue in the kernel is quite small and can be easily exhausted by DRI clients. When the event queue is full, that means nothing can be queued onto it anymore, which can lead to incorrect presentation times for DRI clients and failure when attempting to queue a page flip. To make matters worse, once an event is placed onto the kernel's event queue, there's no straightforward way to prematurely remove it from the kernel's event queue in userspace, which means that aborting a sequence number doesn't free up space in the event queue. Since vblank events from DRI clients are the largest consumers of the event queue, and since it's often easy to know the desired target MSC of their vblank events without querying the kernel for a CRTC's current MSC, we can coalesce vblank events occurring at the same MSC such that only one of them is placed onto the kernel's event queue, instead of allowing duplicate vblank events to pollute the event queue. This is achieved by tracking the next kernel-queued event's MSC on a per-CRTC basis and then running all of that CRTC's vblank event handlers which have reached their target MSC when the queued MSC is signaled. Signed-off-by: -
Sultan Alsawaf authored
do_queue_flip_on_crtc() is about to be used to flip buffers other than the primary scanout (`ms->drmmode.fb_id`), so make it generic to accept any frame buffer ID, as well as x and y coordinates in the frame buffer, to flip on a given CRTC. Move the retry logic from queue_flip_on_crtc() into it as well, so that it's robust for all callers. Signed-off-by:
-
- Sep 15, 2021
-
-
Rotation is broken for all drm drivers not providing hardware rotation support. Drivers that give direct access to vram and not needing dirty updates still work but only by accident. The problem is caused by modesetting not sending the correct fb_id to drmModeDirtyFB() and passing the damage rects in the rotated state and not as the crtc expects them. This patch takes care of both problems. Signed-off-by:Patrik Jakobsson <pjakobsson@suse.de>
-
- Sep 09, 2021
-
-
Whenever an unredirected fullscreen window uses pageflipping for a DRI3/Present PresentPixmap() operation and the X-Screen has more than one active output, multiple crtc's need to execute pageflips. Only after the last flip has completed can the PresentPixmap operation as a whole complete. If a sync_flip is requested for the present, then the current implementation will synchronize each pageflip to the vblank of its associated crtc. This provides tear-free image presentation across all outputs, but introduces a different artifact, if not all outputs run at the same refresh rate with perfect synchrony: The slowest output throttles the presentation rate, and present completion is delayed to flip completion of the "latest" output to complete. This means degraded performance, e.g., a dual-display setup with a 144 Hz monitor and a 60 Hz monitor will always be throttled to at most 60 fps. It also means non-constant present rate if refresh cycles drift against each other, creating complex "beat patterns", tremors, stutters and periodic slowdowns - quite irritating! Such a scenario will be especially annoying if one uses multiple outputs in "mirror mode" aka "clone mode". One output will usually be the "production output" with the highest quality and fastest display attached, whereas a secondary mirror output just has a cheaper display for monitoring attached. Users care about perfect and perfectly timed tear-free presentation on the "production output", but cares less about quality on the secondary "mirror output". They are willing to trade quality on secondary outputs away in exchange for better presentation timing on the "production output". One example use case for such production + monitoring displays are neuroscience / medical science applications where one high quality display device is used to present visual animations to test subjects or patients in a fMRI scanner room (production display), whereas an operator monitors the same visual animations from a control room on a lower quality display. Presentation timing needs to be perfect, and animations high-speed and tear-free for the production display, whereas quality and timing don't matter for the monitoring display. This commit gives users the option to choose such a trade-off as opt-in: It adds a new boolean option "AsyncFlipSecondaries" to the device section of xorg.conf. If this option is specified as true, then DRI3 pageflip behaviour changes as follows: 1. The "reference crtc" for a windows PresentPixmap operation does a vblank synced flip, or a DRM_MODE_PAGE_FLIP_ASYNC non-synchronized flip, as requested by the caller, just as in the past. Typically flips will be requested to be vblank synchronized for tear-free presentation. The "reference crtc" is the one chosen by the caller to drive presentation timing (as specified by PresentPixmap()'s "target_msc", "divisor", "remainder" parameters and implemented by vblank events) and to deliver Present completion timestamps (msc and ust) extracted from its pageflip completion event. 2. All other crtc's, which also page-flip in a multi-display configuration, will try to flip with DRM_MODE_PAGE_FLIP_ASYNC, ie. immediately and not synchronized to vblank. This allows the PresentPixmap operation to complete with little delay compared to a single-display present, especially if the different crtc's run at different video refresh rates or their refresh cycles are not perfectly synchronized, but drift against each other. The downside is potential tearing artifacts on all outputs apart from the one of the "reference crtc". Successfully tested on a AMD gpu with single-display, dual-display and triple-display setups, and with single-X-Screen as well as dual-X-Screen "ZaphodHeads" configurations. Please consider merging this commit for the upcoming server 1.21 branch. Signed-off-by:Mario Kleiner <mario.kleiner.de@gmail.com>
-
- Nov 25, 2020
-
-
I forgot to add these in commits 4fefe73f, b6985d6b, 245b9db0, and 4e670f12. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com>
-
- Oct 29, 2020
-
-
Aaron Plattner authored
When the "CTM" (color transform matrix) modesetting property is available, create a corresponding RandR property. To match the format of the property available in the amdgpu driver, expose it as an array of 18 32-bit XA_INTEGERs representing a 3x3 matrix in row-major order, where each entry is a S31.32 sign-magnitude fixed-point number with the fractional part listed first. Signed-off-by:
Michel Dänzer <mdaenzer@redhat.com> Reviewed-by:
James Jones <jajones@nvidia.com>
-
Aaron Plattner authored
If the kernel exposes GAMMA_LUT and GAMMA_LUT_SIZE properties and the size is not what the server has pre-configured for the crtc, free the old gamma ramp memory allocated by the server and replace it with new allocations of the appropriate size. In addition, when GAMMA_LUT is available, use drmModeCreatePropertyBlob() and drmModeObjectSetProperty() to set the gamma ramp rather than using the legacy drmModeCrtcSetGamma() function. Add a new option "UseGammaLUT" to allow disabling this new behavior and falling back to drmModeCrtcSetGamma() unconditionally. Signed-off-by: -
Aaron Plattner authored
A later change will need to read the value of the GAMMA_LUT_SIZE property. Signed-off-by:
-
- Sep 25, 2020
-
-
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:
-
Martin Roukala authored
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:
-
- Sep 08, 2020
-
-
These changes have been ported from AMD GPU DDX driver. This patch adds support for setting the CRTC variable refresh property for suitable windows flipping via the Present extension. In order for a window to be suitable for variable refresh it must have the _VARIABLE_REFRESH property set by the MESA and inform Modesetting DDX driver with window property updates. Then the window must pass the checks required to be suitable for Present extension flips - it must cover the entire X screen and no other window may already be flipping. And also DRM connector should be VRR capable. With these conditions met every CRTC for the X screen will have their variable refresh property set to true. Kernel Changes to support this feature in I915 driver is under development. Tested with DOTA2, Xonotic and custom GLX apps. Signed-off-by:Uday Kiran Pichika <pichika.uday.kiran@intel.com>
-
- Jul 09, 2020
-
-
Dave Airlie authored
This is an API and ABI break Reviewed-by:Peter Hutterer <peter.hutterer@who-t.net>
-
- Aug 09, 2019
-
-
Hans de Goede authored
Only log 1 error for consecutive flip failures, instead of filling the log and the disk with errors for each attempted flip. Despite our best efforts we may end up with a BO which gets refused when we try to import it as a framebuffer, see e.g. : https://bugs.freedesktop.org/show_bug.cgi?id=111306 This should not happen, but as the above bugs shows sometimes it does and chances are it will happen again. Note ideally we should check if the import is possible at ms_present_check_flip time, like the amdgpu code is doing since: xorg/driver/xf86-video-amdgpu!35 but that requires a chunk of refactoring work on the modesetting driver, so for now this will have to do. Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
- Aug 06, 2019
-
-
Hans de Goede authored
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: #828 Reviewed-by:
-
Hans de Goede authored
When the pixmapPrivateKeyRec was moved from a global to being embedded inside the drmmode_rec these 2 where missed, clean them up. Reviewed-by:
-
- Aug 02, 2018
-
-
Instead of having every video driver loop over any pending leases to free them during CloseScreen, do this up in the DIX layer by terminating leases when a leased CRTC or Output is destroyed and (just to make sure), also terminating leases in RRCloseScreen. The latter should "never" get invoked as any lease should be associated with a resource which was destroyed. This is required as by the time the driver's CloseScreen function is invoked, we've already freed all of the DIX randr structures and no longer have any way to reference the leases Signed-off-by:
Keith Packard <keithp@keithp.com> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960 Cc: Thomas Hellstrom <thellstrom@vmware.com>
-
- May 07, 2018
-
-
The function is ported from intel-ddx uxa backend around 2013, where its stated purpose was to apply a vblank_offset to msc values to correct for problems with those kernel provided msc values. Some (somewhat magic and puzzling to myself) heuristic tried to guess if provided values were unreasonable and tried to adapt the corrective vblank_offset to account for that. Except: It wasn't applied to kernel provided msc values, but the values delivered by clients via DRI2 or Present, so valid client targetmsc values, e.g., requesting a vblank event > 1000 vblanks in the future, triggered the offset correction in arbitrarily wrong ways, leading to wrong msc values being returned and thereby vblank events queued to the kernel for the wrong time. This causes glXSwapBuffersMscOML and glXWaitForMscOML to swap / return immediately whenever a swap/wait in > 1000 vblanks is requested. The original code was also written to only deal with 32 bit mscs, but server 1.20 modesetting ddx can now use new Linux 4.15+ kernel vblank api to process true 64 bit msc's, which may confuse the heuristic even more due to 32 bit integer truncation/wrapping. This code caused various problems in the intel-ddx in the past since year 2013, and was removed there in 2015 by Chris Wilson in commit 42ebe2ef9646be5c4586868cf332b4cd79bb4618: " uxa: Remove the filtering of bogus Present MSC values If the intention was to filter the return values from the kernel, the filtering would have been applied to the kernel values and not to the incoming values from Present. This filtering introduces crazy integer promotion and truncation bugs all because Present feeds garbage into its vblank requests. " Indeed, i found a Mesa bug yesterday which can cause Mesa's PresentPixmap request to spuriously feed garbage targetMSC's into the driver under some conditions. However, while other video drivers seem to cope relatively well with that, modesetting ddx causes KDE-5's plasmashell to lock up badly quite frequently, and my suspicion is that the code removed in this commit is one major source of the extra fragility. Also my own tests fail for any swap scheduled more than 1000 vblanks into the future, which is not uncommon for some scientific applications. Iow. modesetting's swap scheduling seems to be more robust without this function afaics. Signed-off-by:Adam Jackson <ajax@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Keith Packard <keithp@keithp.com> Tested-by:
Mike Lothian <mike@fireburn.co.uk>
-
- Apr 04, 2018
-
-
We need to make sure that the atomic commit are consistent or else the kernel will reject it. For example, when moving a CRTC from one output to another one, the first output CRTC_ID property needs to be reset. Also if the second output was using another CRTC beforehands, it needs to be disabled to avoid an inconsistent state. Signed-off-by:
Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Tested-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
-
CRTCs and outputs needs to be enabled/disabled when the current DPMS mode is changed. We also try to do it in an atomic commit when possible. Signed-off-by:
-
Keep track of whether or not we fed modifiers into GBM when we allocated a BO. We'll use this later inside Glamor, to reallocate buffer storage if we allocate buffer storage using modifiers, and a non-modifier-aware client requests an export of that pixmap. This makes it possible to run a compositing manager on an old GLX/EGL stack on top of an X server which allocates internal buffer storage using exotic modifiers from modifier-aware GBM/EGL/KMS. Signed-off-by:
-
- Mar 21, 2018
-
-
All the macros are available in the libdrm that we depend on. Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
-
- Mar 05, 2018
-
-
Implement function added in DRI3 v1.1. A newest version of libepoxy (>= 1.4.4) is required as earlier versions use a problematic version of Khronos EXT_image_dma_buf_import_modifiers spec. v4: Only send scanout-supported modifiers if flipping is possible v5: Fix memory corruption in XWayland (uninitialized pointer) Signed-off-by:
-
Add support for 'check_flip2' so that the present core can know why it is impossible to flip in that scenario. The core can then let know the client that the buffer format/modifier is suboptimal. v2: No longer need to implement 'check_flip' Signed-off-by:
-
Retrieve IN_FORMATS property from the plane. It gives the allowed formats and modifiers for BO allocation. Signed-off-by:
-
To make sure we also use the same primary plane and to avoid mixing uses of two APIs, it is better to always use the atomic modesetting API when possible. v2: Don't use mode_output->connector_id Signed-off-by:
-
This allows the uses of CCS compressed or tiled pixmaps as BOs when page-flipping. Signed-off-by:
-
In order to flip between compressed and uncompressed buffers - something drmModePageFlip explicitly bans us from doing - we need to port use the atomic modesetting API. It's only 'fake' atomic though given we still commit for each CRTC separately and CRTC and connector properties are not set with the atomic API. The helper functions to retrieve DRM properties have been borrowed from Weston. Signed-off-by:
-
- Feb 27, 2018
-
-
This adds support for RandR CRTC/Output leases through the modesetting driver, creating a lease using new kernel infrastructure and returning that to a client through an fd which will have access to only those resources. v2: Restore CRTC mode when leases terminate When a lease terminates for a crtc we have saved data for, go ahead and restore the saved mode. v3: Report RR_Rotate_0 rotations for leased crtcs. Ignore leased CRTCs when selecting screen size. Stop leasing encoders, the kernel doesn't do that anymore. Turn off crtc->enabled while leased so that modesetting ignores them. Check lease status before calling any driver mode functions When starting a lease, mark leased CRTCs as disabled and hide their cursors. Also, check to see if there are other non-leased CRTCs which are driving leased Outputs and mark them as disabled as well. Sometimes an application will lease an idle crtc instead of the one already associated with the leased output. When terminating a lease, reset any CRTCs which are driving outputs that are no longer leased so that they start working again. This required splitting the DIX level lease termination code into two pieces, one to remove the lease from the system (RRLeaseTerminated) and a new function that frees the lease data structure (RRLeaseFree). v4: Report RR_Rotate_0 rotation for leased crtcs. v5: Terminate all leases on server reset. Leases hang around after the associated client exits so that the client doesn't need to occupy an X server client slot and consume a file descriptor once it has gotten the output resources necessary. Any leases still hanging around when the X server resets or shuts down need to be cleaned up by calling the kernel to terminate the lease and freeing any DIX structures. Note that we cannot simply use the existing drmmode_terminate_lease function on each lease as that wants to also reset the video mode, and during server shut down that modesetting: Validate leases on VT enter The kernel doesn't allow any master ioctls to run when another VT is active, including simple things like listing the active leases. To deal with that, we check the list of leases whenever the X server VT is activated. xfree86: hide disabled cursors when resetting after lease termination The lessee may well have played with cursors and left one active on our screen. Just tell the kernel to turn it off. v6: Add meson build infrastructure [Also bumped libdrm requirement - ajax] Signed-off-by:
-
- Feb 26, 2018
-
-
If a dri2 screen is not successfully initialized, attempting to close it results in a null dereference. Maintain a flag indicating whether the dri2 screen was successfully initialized, and check it before attempting to close the dri2 screen. https://bugzilla.redhat.com/show_bug.cgi?id=1485811 https://bugzilla.redhat.com/show_bug.cgi?id=1493805 https://bugzilla.redhat.com/show_bug.cgi?id=1534459 https://bugzilla.redhat.com/show_bug.cgi?id=1541745 https://bugs.freedesktop.org/show_bug.cgi?id=101282 Signed-off-by:
Jeff Smith <whydoubt@gmail.com>
-
- Oct 30, 2017
-
-
Roundhouse kick replacing the various (sizeof(foo)/sizeof(foo[0])) with the ARRAY_SIZE macro from dix.h when possible. A semantic patch for coccinelle has been used first. Additionally, a few macros have been inlined as they had only one or two users. Signed-off-by:
Daniel Martin <consume.noise@gmail.com> Reviewed-by:
-
- Aug 15, 2017
-
-
Michel Dänzer authored
This allows making the master screen's pixmap_dirty_list entries explicitly reflect that we're now tracking the root window instead of the screen pixmap, in order to allow Present page flipping on master outputs while there are active slave outputs. Define HAS_DIRTYTRACKING_DRAWABLE_SRC for drivers to check, but leave HAS_DIRTYTRACKING_ROTATION defined as well to make things slightly easier for drivers. Reviewed-by:
-
- Feb 08, 2017
-
-
Currently if modesetting ever fails to set a hardware cursor it will switch to using a software cursor and never go back. Change this to only permanently switch to a software cursor if -ENXIO is returned (which means hardware cursors not supported), and to otherwise still try a hardware cursor first every time a new one is set. This is needed because hardware may be able to handle some cursors in hardware and others not, or virtual hardware may be able to handle hardware cursors at some times and not others. Changes since v1, v2 and v3: * take into account the switch to load_cursor_argb_check * keep the permanent software cursor fall-back if -ENXIO is returned * move parts of v3 into separate patches Reviewed-by:
Michael Thayer <michael.thayer@oracle.com>
-
Based on v4 by Alexandre Courbot <acourbot@nvidia.com> There is currently no reliable way to report failure to set a HW cursor. Still such failures can happen if e.g. the MODE_CURSOR DRM ioctl fails (which currently happens at least with modesetting on Tegra for format incompatibility reasons). As failures are currently handled by setting the HW cursor size to (0,0), the fallback to SW cursor will not happen until the next time the cursor changes and xf86CursorSetCursor() is called again. In the meantime, the cursor will be invisible to the user. This patch addresses that by adding _xf86CrtcFuncs::set_cursor_check and _xf86CursorInfoRec::ShowCursorCheck hook variants that return booleans. This allows to propagate errors up to xf86CursorSetCursor(), which can then fall back to using the SW cursor immediately. v5: - Removed parts of patch already committed as part of 14c21ea1. - Adjusted code slightly to match surrounding code. - Effectively reverted af916477 which is made unnecessary by this patch. Reviewed-by:
-
- Sep 02, 2016
-
-
Signed-off-by:
Qiang Yu <Qiang.Yu@amd.com> Reviewed-by:
-
The modesetting driver may be driving 2 screens (slave and master gpu), which may have different behavior wrt hardware cursor support. So stop using static variables and instead store the hw-cursor support related data in a per screen struct. While at it actually make it per crtc data as in theory different crtc's could have different hw-cursor support. Signed-off-by:
-
- Aug 09, 2016
-
-
Kenneth Graunke authoredEmbarassingly, it looks like I introduced this dead function in commit 13c7d53d a year ago. Nothing ever used it, not even then. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
-
- Jul 02, 2016
-
-
Adam Jackson authored
Server GPUs often have a VNC feature attached to allow remote console. The controller implementing this feature is usually not very powerful, and we can easily swamp it with work. This is made somewhat worse by damage over-reporting the size of the dirty region, and a whole lot worse by applications (or shells) that update the screen with identical pixel content as was already there. Fix this by double-buffering the shadow fb, using memcmp to identify dirty tiles on each update pass. Since both shadows are in host memory the memcmp is cheap, and worth it given the win in network bandwidth. The tile size is somewhat arbitrarily chosen to be one cacheline wide at 32bpp on Intel Core. By default we enable this behaviour for (a subset of) known server GPUs; the heuristic could use work. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Adam Jackson authored
Signed-off-by:
-
Dave Airlie authored
24bpp front buffers tend to be the least well tested path for client rendering. On the qemu cirrus emulation, and on some Matrox G200 server chips, the hardware can't do 32bpp at all. It's better to just allocate a 32bpp shadow and downconvert in the upload hook than expose a funky pixmap format to clients. [ajax: Ported from RHEL and separate modesetting driver, lifted kbpp into the drmmode struct, cleaned up commit message, fixed 16bpp] Reviewed-by:
Dave Airlied <airlied@redhat.com> Reviewed-by:
-
