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>

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 <sultan@kerneltoast.com>

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: Sultan Alsawaf <sultan@kerneltoast.com>

Shadow buffers are about to be used for TearFree, so make the shadow buffer
helpers generic such that they can be used to create arbitrary per-CRTC
shadows aside from just the per-CRTC rotated buffer.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

Konstantin Kharlamov authored 5 years ago and Alan Coopersmith committed 2 years ago

Fixes LGTM warning "This parameter of type drmModeModeInfo is 68 bytes -
consider passing a const pointer/reference instead."

Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>

Mario Kleiner authored 3 years ago and Povilas Kanapickas committed 3 years ago

In a setup with both VRR capable and non-VRR capable displays,
it was so far inconsistent if the driver would allow use of
VRR support or not, as "is_connector_vrr_capable" was set to
whatever the capabilities of the last added drm output were.
Iow. the plugging order of monitors determined the outcome.

Fix this: Now if at least one display is VRR capable, the driver
will treat an X-Screen as capable for VRR, plugging order no
longer matters.

Tested with a dual-display setup with one VRR monitor and one
non-VRR monitor. This is also beneficial with the new Option
"AsyncFlipSecondaries".

When we are at it, also add some so far missing description of
the "VariableRefresh" driver option, copied from amdgpu-ddx.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>

Mario Kleiner authored 3 years ago and Povilas Kanapickas committed 3 years ago

A lut size of 4096 slots has been verified to work correctly,
as tested with amdgpu-kms. Intel Tigerlake Gen12 hw has a very
large GAMMA_LUT size of 262145 slots, but also issues with its
current GAMMA_LUT implementation, as of Linux 5.14.

Therefore we keep GAMMA_LUT off for large lut's. This currently
excludes Intel Icelake, Tigerlake and later.

This can be overriden via the "UseGammaLUT" boolean xorg.conf option
to force use of GAMMA_LUT on or off.

See following link for the Tigerlake situation:
https://gitlab.freedesktop.org/drm/intel/-/issues/3916#note_1085315



Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>

Mario Kleiner authored 3 years ago and Povilas Kanapickas committed 3 years ago

This reverts commit 617f591f.

The problem described in that commit exists, but the two
preceeding commits with improvements to the servers RandR
code should avoid the mentioned problems while allowing the
use of GAMMA_LUT's instead of legacy gamma lut.

Use of legacy gamma lut's is not a good fix, because it will reduce
color output precision of gpu's with more than 1024 GAMMA_LUT
slots, e.g., AMD, ARM MALI and KOMEDA with 4096 slot luts,
and some Mediathek parts with 512 slot luts. On KOMEDA, legacy
lut's are completely unsupported by the kms driver, so gamma
correction gets disabled.

The situation is especially bad on Intel Icelake and later:
Use of legacy gamma tables will cause the kms driver to switch
to hardware legacy lut's with 256 slots, 8 bit wide, without
interpolation. This way color output precision is restricted to
8 bpc and any deep color / HDR output (10 bpc, fp16, fixed point 16)
becomes impossible. The latest Intel gen gpu's would have worse
color precision than parts which are more than 10 years old.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>

Patrik Jakobsson authored 3 years ago and Povilas Kanapickas committed 3 years ago

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>

GAMMA_LUT sizes other than 1024 cause a crash during startup if the memcpy()
calls in xf86RandR12CrtcSetGamma() read past the end of the legacy X11 /
XVidMode gamma ramp.

This is a problem on Intel ICL / GEN11 platforms because they report a GAMMA_LUT
size of 262145. Since it's not clear that the modesetting driver will generate a
proper gamma ramp at that size even if xf86RandR12CrtcSetGamma() is fixed, just
disable use of GAMMA_LUT for sizes other than 1024 for now. This will cause the
modesetting driver to disable the CTM property and fall back to the legacy gamma
LUT.

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Fixes: xorg/xserver#1193
Tested-by: Mark Herbert

Rather than trying to create a gamma ramp array of the appropriate size in
drmmode_crtc_init when the GAMMA_LUT property should be used, just flag the crtc
as wanting to use the GAMMA_LUT property and then replace the gamma ramp later,
right before calling xf86HandleColormaps. This avoids a problem during initial
startup where xf86RandR12CreateObjects12 hard-codes a gamma ramp size of 256,
causing xf86RandR12CrtcSetGamma to read past the end of the DIX layer's RandR
gamma ramp array:

  PreInit
    drmmode_pre_init
      drmmode_crtc_init
        crtc->gamma_size = 1024

  ScreenInit
    xf86CrtcScreenInit
      xf86RandR12Init
        xf86RandR12Init12
          xf86RandR12CreateObjects12
            RRCrtcCreate
              randr_crtc->gammaSize = 0
          xf86RandR12InitGamma(pScrn, 256)
            RRCrtcGammaSetSize
              randr_crtc->gammaSize = 256
          xf86RandR12InitGamma
            xf86RandR12CrtcInitGamma
              RRCrtcGammaSet
                xf86RandR12CrtcSetGamma
                  // crtc->gamma_size is 1024 here, while randr_crtc->gammaRed
                  // is a 256-element array.
                  memcpy(crtc->gamma_red, randr_crtc->gammaRed, crtc->gamma_size * sizeof(crtc->gamma_red[0]));
    drmmode_setup_colormap
      xf86HandleColormaps
        xf86RandR12InitGamma
          RRCrtcGammaSetSize
            randr_crtc->gammaSize = 1024

Fixes: 245b9db0 - modesetting: Use GAMMA_LUT when available
Closes: #1126


Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>

Aaron Plattner authored 4 years ago and Peter Hutterer committed 4 years ago

I forgot to add these in commits 4fefe73f, b6985d6b, 245b9db0, and 4e670f12.

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

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: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: James Jones <jajones@nvidia.com>

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 <aplattner@nvidia.com>

Modeset properties can be set even when ms->atomic_modeset is disabled by using
the drmModeObjectSetProperty() function.

This will be necessary in a later change in order to set the GAMMA_LUT and CTM
properties.

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

A later change will need to read the value of the GAMMA_LUT_SIZE property.

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Kishore409 authored 4 years ago and Martin Roukala committed 4 years ago

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

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>

Uday Kiran Pichika authored 4 years ago and Martin Roukala committed 4 years ago

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>

This is an API and ABI break

Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

Most (but not all) of these were found by using
  codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

José María Casanova Crespo authored 4 years ago and José María Casanova Crespo committed 4 years ago

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: #1024
Fixes: 87745321 "modesetting: Remove unnecessary fb addition from
       drmmode_xf86crtc_resize"

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>

Yuriy Vasilev authored 5 years ago and Adam Jackson committed 5 years ago

Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>

Yuriy Vasilev authored 5 years ago and Adam Jackson committed 5 years ago

This allow x-server to run with -depth 16.

Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>

Resulted in a build failure with -Werror:

../hw/xfree86/drivers/modesetting/drmmode_display.c: In function ‘drmmode_crtc_set_mode’:
../hw/xfree86/drivers/modesetting/drmmode_display.c:759:15: error: unused variable ‘screen’ [-Werror=unused-variable]
  759 |     ScreenPtr screen = crtc->scrn->pScreen;
      |               ^~~~~~

Fixes: c66c548e "modesetting: Call glamor_finish from
                     drmmode_crtc_set_mode"
Reviewed-by: Adam Jackson <ajax@redhat.com>

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: 9257b125 ("modesetting: add dynamic connector hotplug support (MST) (v3)")
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Michel Dänzer authored 5 years ago and Kenneth Graunke committed 5 years ago

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>

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>

Should be slightly more efficient.

Reviewed-by: Adam Jackson <ajax@redhat.com>

Fixes random garbage being visible intermittently.

Reviewed-by: Adam Jackson <ajax@redhat.com>

This makes sure any pending drawing to a new scanout buffer will be
visible from the start.

This makes the finish call in drmmode_copy_fb superfluous, so remove it.

Reviewed-by: Adam Jackson <ajax@redhat.com>

This will simplify backporting the following fix to the 1.20 branch.

Reviewed-by: Adam Jackson <ajax@redhat.com>

Now that we've fixed LoaderSymbolFromModule this should work properly.

This reverts commit 5c7c6d5c.

Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

This reverts commit dd63f717.

Caused a crash at least on some systems.

Closes: #934

Adam Jackson authored 5 years ago and Adam Jackson committed 5 years ago

Prerequisite for building all of xserver with -z now.

Gitlab: #692

Ville Syrjälä authored 5 years ago and Adam Jackson committed 5 years ago

Populate outout possible_crtcs as the union of possible_crtcs from
the encoders rather than the intersection. Otherwise we're easily left
with possible_crtcs==0 when all the possible encoders have
non-overlapping possible_crtcs.

No idea what the magic 0x7f is about, but keep it around in case
it matters.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

This seems like a simple typo to me; thanks to C it isn't caught by
the compiler.

Signed-off-by: Keith Packard <keithp@keithp.com>

Caused assertion failures / crashes with Xorg.

Closes: #916

Currently we parse through xf86Info.debug to check if we the modifiers
should be disabled. Handle that within DDX and pass GLAMOR_NO_MODIFIERS
into the glamor_init() flags.

This allows individual DDX control over the setting - say when modifiers
are woking OK with one implementation and not the other.

Most importantly, this removes the final xf86 piece from the codebase.

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>