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 Jun 09, 2021 and Povilas Kanapickas committed 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>

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: xorg/xserver#1126

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

Aaron Plattner authored Nov 20, 2020 and Peter Hutterer committed Nov 25, 2020

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 Sep 19, 2020 and Martin Roukala committed 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 u...

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 Jun 18, 2020 and Martin Roukala committed 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>

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 May 15, 2020 and José María Casanova Crespo committed Jun 27, 2020

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: xorg/xserver#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: drm/intel#313

Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>

Yuriy Vasilev authored Mar 06, 2020 and Adam Jackson committed Mar 13, 2020

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

Yuriy Vasilev authored Mar 05, 2020 and Adam Jackson committed Mar 13, 2020

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>

Michel Dänzer authored Feb 10, 2020 and Michel Dänzer committed Feb 11, 2020

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 Jan 14, 2020 and Kenneth Graunke committed Jan 14, 2020

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>

Michel Dänzer authored Nov 22, 2019 and Michel Dänzer committed Nov 25, 2019

Should be slightly more efficient.
Reviewed-by: Adam Jackson <ajax@redhat.com>

Michel Dänzer authored Nov 18, 2019 and Michel Dänzer committed Nov 25, 2019

Fixes random garbage being visible intermittently.
Reviewed-by: Adam Jackson <ajax@redhat.com>

Michel Dänzer authored Nov 22, 2019 and Michel Dänzer committed Nov 25, 2019

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>

Michel Dänzer authored Nov 22, 2019 and Michel Dänzer committed Nov 25, 2019

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>

Michel Dänzer authored Nov 15, 2019 and Michel Dänzer committed Nov 15, 2019

This reverts commit dd63f717.

Caused a crash at least on some systems.

Closes: xorg/xserver#934

Adam Jackson authored Oct 08, 2019 and Adam Jackson committed Nov 13, 2019

Prerequisite for building all of xserver with -z now.

Gitlab: xorg/xserver#692

Ville Syrjälä authored Sep 03, 2019 and Adam Jackson committed Oct 29, 2019

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>

Michel Dänzer authored Oct 14, 2019 and Michel Dänzer committed Oct 14, 2019

Caused assertion failures / crashes with Xorg.

Closes: xorg/xserver#916

Emil Velikov authored Jul 18, 2019 and Emil Velikov committed Oct 11, 2019

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>

Dynamically added outputs should have their properties
properly updated as well. Otherwise we're left with an output
with many of its propeties not exposed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>

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: xorg/xserver#828

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Fix the following compiler warning:

drmmode_display.c: In function ‘drmmode_create_bo’:
drmmode_display.c:1019:9: warning: ISO C90 forbids mixed declarations and code [
 1019 |         uint32_t num_modifiers;
      |         ^~~~~~~~
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Ilia Mirkin authored Dec 10, 2018 and Adam Jackson committed Dec 11, 2018

Noticed when porting this logic to xf86-video-nouveau, and valgrind
complained about conditional jump based on uninitialized data.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Lyude Paul authored Nov 13, 2018 and Adam Jackson committed Nov 29, 2018

Believe it or not, somehow we've never done this in legacy mode! We
currently simply change the DPMS property on the CRTC's output's
respective DRM connector, but this means that we're just setting the
CRTC as inactive-not disabled. From the perspective of the kernel, this
means that any shared resources used by the CRTC are still in use.

This can cause problems for drivers that are not yet fully atomic,
despite using the atomic helpers internally. For instance: if CRTC-1 and
CRTC-2 are still enabled and use shared resources within the kernel (an
MST topology, for example), and then userspace tries to go enable CRTC-3
on the same topology this might suddenly fail if CRTC-3 needs the shared
resources CRTC-1 and CRTC-2 are using. While I don't know of any
situations in the mainline kernel that actually trigger this, future
plans for reworking the atomic check of MST drivers are absolutely
going to make this into a real issue (they already are in my WIP
branches for the kernel).

So: actually do the right thing here and disable CRTCs when they're not
going to be used anymore, even in legacy mode.
Signed-off-by: Lyude Paul <lyude@redhat.com>

Verbosity level 0 is "always print", just make it a normal message.
Signed-off-by: Adam Jackson <ajax@redhat.com>

The destination is always either on the stack or in the middle of some
struct.
Signed-off-by: Adam Jackson <ajax@redhat.com>