Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

Povilas Kanapickas authored Oct 10, 2020 and Peter Hutterer committed Dec 14, 2020

Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

Prabhu Sundararaj authored Nov 25, 2020 and Adam Jackson committed Dec 08, 2020

Commit 6a5a4e60 removed the option to
configure useSIGIO option. Indeed, the xfree86 SIGIO support was
reworked to use internal versions of OsBlockSIGIO and OsReleaseSIGIO.

As a result, useSIGIO is no longer needed and can dropped

Fixes: 6a5a4e60 - Remove SIGIO support for input [v5]
Closes: xorg/xserver#1107

Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Prabhu Sundararaj <prabhu.sundararaj@nxp.com>
Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

Olivier Fourdan authored Nov 26, 2020 and Peter Hutterer committed Nov 26, 2020

By default, the macro DebugPresent() is a no-op but it can be enabled
at build time for debugging purpose.

However, doing so prevents the code to build because one debug statement
tries to make use of a non-existent variable:

  present.c: In function ‘ms_present_queue_vblank’:
  present.c:147:18: error: ‘vbl’ undeclared (first use in this function)
    147 |                  vbl.request.sequence));
        |                  ^~~
  present.c:49:32: note: in definition of macro ‘DebugPresent’
    49 | #define DebugPresent(x) ErrorF x
       |                                ^

Fix the build with DebugPresent() by removing the vbl variable from the
debug message.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

Böszörményi Zoltán authored Nov 14, 2019 and Peter Hutterer committed Nov 25, 2020

With !155, the device bus ID received via udev is constructed
properly with the "usb:" prefix. But, it is not enough to
make the following line to work in Section "Device":

    BusID  "usb:0:1.2:1.0"

Introduce BUS_USB, so the prefix can be distinguished from BUS_PCI
and check the supplied BusID value against device->attribs->busid
in xf86PlatformDeviceCheckBusID().
Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>

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>

Resolves warnings from Oracle Parfait static analyser:

Error: Misleading macro
   Misleading macro [misleading-macro]:
      misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
        at line 392 of hw/xfree86/int10/generic.c.
        '|' operator has higher precedence than ternary '?:' operator inside macro body at line 431
        low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431
   Misleading macro [misleading-macro]:
      misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
        at line 392 of hw/xfree86/int10/generic.c.
        '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 431
        low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431
   Misleading macro [misleading-macro]:
      misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
        at line 392 of hw/xfree86/int10/generic.c.
        '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 442
        low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 442
   Misleading macro [misleading-macro]:
      misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
        at line 392 of hw/xfree86/int10/generic.c.
        '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443
        low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443
   Misleading macro [misleading-macro]:
      misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
        at line 392 of hw/xfree86/int10/generic.c.
        '|' operator has higher precedence than ternary '?:' operator inside macro body at line 443
        low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 441
   Misleading macro [misleading-macro]:
      misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
        at line 392 of hw/xfree86/int10/generic.c.
        '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443
        low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.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 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>

Povilas Kanapickas authored Sep 22, 2020 and Adam Jackson committed Sep 24, 2020

Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

Povilas Kanapickas authored Sep 17, 2020 and Adam Jackson committed Sep 24, 2020

This is useful for mock input drivers that control the server in
integration tests. Given that input submission happens on a different
thread than processing, it's otherwise impossible for the driver to
synchronize with the completion of the processing of submitted events.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>

Move the copy in hw/xfree86/common to include/, and remove the one in
hw/kdrive/src/.

Fixes DIX glamor code including an xfree86 DDX header.

Uday Kiran Pichika authored Aug 19, 2020 and Martin Roukala committed Sep 08, 2020

Fetch VariableRefresh option value from X conf file for
modesetting backend DDX driver. This option defaults to false,
and must be set to "true" in conf file for variable refresh
support in the DDX driver.
Signed-off-by: Uday Kiran Pichika <pichika.uday.kiran@intel.com>

Uday Kiran Pichika authored Jun 18, 2020 and Martin Roukala committed Sep 08, 2020

Window wrappers gets the notification when the window
properties changes. These wrappers are mainly used to
keep track of per-window _VARIABLE_REFRESH property values.

These changes have been ported from AMDGPU
Signed-off-by: Uday Kiran Pichika <pichika.uday.kiran@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>

Michel Dänzer authored Aug 31, 2020 and Michel Dänzer committed Aug 31, 2020

The same pointer is kept in CurrentCursor as well, therefore two
RefCursor calls are needed.

Fixes use-after-free after switching VTs.

Closes: xorg/xserver#1067

Ignacio Casal authored Jul 16, 2020 and Peter Hutterer committed Jul 31, 2020

Replicate 7d2543a3 but for
all types of X servers

Commit 1e3f9ea1

 removed some NULL checks from xf86RandR12.c, on the premise that
they can't be reached unless RandR has already been initialized. For threesuch
calls, that's not true:

xf86Crtc.c::xf86CrtcScreenInit():

    if (c == config->num_crtc) {
        xf86RandR12SetRotations(screen, RR_Rotate_0 | RR_Rotate_90 |
                                RR_Rotate_180 | RR_Rotate_270 |
                                RR_Reflect_X | RR_Reflect_Y);
        xf86RandR12SetTransformSupport(screen, TRUE);
    }
    else {
        xf86RandR12SetRotations(screen, RR_Rotate_0);
        xf86RandR12SetTransformSupport(screen, FALSE);
    }

xf86Crtc.c::xf86CrtcCloseScreen():

    xf86RandR12CloseScreen(screen);

This change adds checks back to xf86RandR12Set{Rotations,TransformSupport}() and
xf86RandR12CloseScreen(), checking that xf86RandR12KeyRec has been registered.
Without this, X will hit an assert that causes it to abort.
Signed-off-by: Alex Goins <agoins@nvidia.com>

This gives out of tree drivers a fighting chance to build against both
sides of
xorg/xserver!468

 .
Reviewed-by: Dave Airlie <airlied@redhat.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"

Martin Weber authored Jun 19, 2020 and Michel Dänzer committed Jun 24, 2020

During a VT-Switch a raw pointer to the shared cursor object
is saved which is then freed (in case of low refcount) by a call to
xf86CursorSetCursor with argument pCurs = NullCursor.
This leads to a dangling pointer which can follow in a use after free.

This fix ensures that there is a shared handle saved for the VT-Switch cycle.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>

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>

None of the current BSD is actually using this code.
(checked DragonFly 5.8.1, FreeBSD 11.2, NetBSD 9.0 and OpenBSD 6.7)
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>

In file included from ../glx/glxdri2.c:35:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
 #include <drm.h>
          ^~~~~~~
In file included from ../glx/glxdriswrast.c:39:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
 #include <drm.h>
          ^~~~~~~

Mostly http->https conversions, but also replaces gitweb.fd.o
with gitlab.fd.o, and xquartz.macosforge.org with xquartz.org.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Tobias Stoeckmann authored Apr 19, 2020 and Adam Jackson committed Apr 30, 2020

On systems with ACPI but disabled APM (e.g. --disable-linux-apm)
the code does not compile due to preprocessor directives.

If APM is disabled, the final return statement is considered to
be part of ACPI's last if-statement, leading to a function which
has no final return statement at all.

I have refactored the code so ACPI and APM are independent of each
other.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

This option was implemented before the drivers were split in ≈2006,
and e.g. XWin still supports it.

With this commit, Xorg regains support, so that the following configuration can
be used to set the repeat rate for all keyboard devices without having to modify
Xorg command-line flags or having to automate xset(1):

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "de"
        Option "XkbVariant" "neo"
	Option "AutoRepeat" "250 30"
EndSection
Signed-off-by: Michael Stapelberg <stapelberg@google.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>

Zoltán Böszörményi authored Feb 12, 2020 and Adam Jackson committed Feb 12, 2020

xf86platformProbeDev didn't check the device path, fix it.

This is a problem when trying to set up a non-PCI device via
explicit xorg.conf.d configuration.

An USB DisplayLink device, being non-PCI was always set up
as a GPU device assigned to screen 0 instead of a regular
framebuffer, potentially having its own dedicated screen,
despite such configuration as below. Only the relevant parts
of the configuration are quoted, it's part of a larger context
with an Intel chip that has 3 outputs:
* DP1 connected to an LCD panel,
* VGA1 connected to an external monitor,
* HDMI1 unconnected and having no user visible connector

Section "ServerFlags"
        Option          "AutoBindGPU" "false"
EndSection

...

Section "Device"
        Identifier      "Intel2"
        Driver          "intel"
        BusID           "PCI:0:2:0"
        Screen          2
        Option          "Monitor-HDMI1" "HDMI1"
        Option          "ZaphodHeads" "HDMI1"
EndSection

Section "Device"
        Identifier      "UDL"
        Driver          "modesetting"
        Option          "kmsdev" "/dev/dri/card0"
        #BusID          "usb:0:1.2:1.0"
        Option          "Monitor-DVI-I-1" "DVI-I-1"
        Option          "ShadowFB" "on"
        Option          "DoubleShadow" "on"
EndSection

...

Section "Screen"
        Identifier      "SCREEN2"
        Option          "AutoServerLayout" "on"
        Device          "UDL"
        GPUDevice       "Intel2"
        Monitor         "Monitor-DVI-I-1"
        SubSection      "Display"
                Modes   "1024x768"
                Depth   24
        EndSubSection
EndSection

Section "ServerLayout"
        Identifier      "LAYOUT"
        Option          "AutoServerLayout" "on"
        Screen          0 "SCREEN"
        Screen          1 "SCREEN1" RightOf "SCREEN"
        Screen          2 "SCREEN2" RightOf "SCREEN1"
EndSection

On the particular machine I was trying to set up an UDL device,
I found the following structure was being used to match
the device to a platform device while I was debugging the issue:

xf86_platform_devices[0] == Intel, /dev/dri/card1, primary platform device
xf86_platform_devices[1] == UDL, /dev/dri/card0

devList[0] == "Intel0", ZaphodHeads: DP1
devList[1] == "Intel1", ZaphodHeads: VGA1
devList[2] == "UDL"
devList[3] == "Intel2", ZaphodHeads: HDMI1 (intended GPU device to UDL)

When xf86platformProbeDev() matched the UDL device, the BusID
check failed in both cases of:
* BusID "usb:0:1.2:1.0" was specified
* Option "kmsdev" "/dev/dri/card0" was specified

As a result, xf86platformProbeDev() went on to call probeSingleDevice()
with xf86_platform_devices[0] and devList[2], resulting in the
UDL device being set up as a GPU device assigned to the first screen
instead of as a framebuffer on the third screen as the configuration
specified.

Checking Option "kmsdev" in code code may be a layering violation.
But the modesetting driver is actually part of the Xorg sources
instead of being an external driver, so he "kmsdev" path knowledge
may be used here.
Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>