xf86_platform_devices[i].pdev may be NULL in cases we fail to parse the
busid in config_udev_odev_setup_attribs() (see also [1], [2]) such as
when udev does not give use ID_PATH. This in turn leads to
platform_find_pci_info() being not called and pdev being NULL.
[1]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/993
[2]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1076
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
This is the only place where we don't check whether
primaryBus.id.plat->pdev is not NULL before accessing its members.
It may be NULL in cases we fail to parse the busid in
config_udev_odev_setup_attribs() (see also [1], [2]) such as when udev
does not give use ID_PATH. This in turn leads to
platform_find_pci_info() being not called and pdev being NULL in one of
the items within the xf86_platform_devices array. For this to cause a
crash we only need it to become the primaryBus device.
[1]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/993
[2]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1076
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
screenp->displays[count] (passed to configDisplay() in
configScreen()) is NULL if there is no Virtual setting
in the configuration.
Fixes: f8a6be04d0 ("xfree86: Change
displays array to pointers array to fix invalid pointer issues
after table reallocation")
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
Physical dimmension of display can be obtained not just by configuration or
DDC, but also directly from kernel via drmModeGetConnector(). Until now
xserver silently discarded these values even when no configuration nor EDID
were present and fallbacked to default DPI.
There are rare cases when xf86SetDepthBpp is resizing displays array in confScreen.
As that array is shared between set of ScrnInfoRec's then realloc might invalidate chached DispPtr display values in
otheres ScrnInfoRec objects.
If we will change displays array as an array of pointers to DispRec then cached DispRec pointers in ScrnInfoRec
won't be invalid after reallocation of displays array.
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
In certain circumstances we will have a lot of flip errors without a
reasonable way to prevent them. In such case we reduce the number of
logged messages to at least not fill the error logs.
The details are as follows:
At least on i915 hardware support for async page flip support depends on
the used modifiers which themselves can change dynamically for a screen.
This results in the following problems:
- We can't know about whether a particular CRTC will be able to do an
async flip without hardcoding the same logic as the kernel as there's no
interface to query this information.
- There is no way to give this information to an application, because
the protocol of the present extension does not specify anything about
changing of the capabilities on runtime or the need to re-query them.
Even if the above was solved, the only benefit would be avoiding a
roundtrip to the kernel and reduced amount of error logs. The former
does not seem to be a good enough benefit compared to the amount of work
that would need to be done. The latter is solved in this commit.
Reviewed-by: Eero Tamminen <eero.t.tamminen@intel.com>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
This mode for displays running on evdi/udl as side effect of failed glamor_egl_init
reverse_prime_offload_mode was initialized to FALSE
After Mesa upgrade to 21.0.0 GL_RENDERER is not llvmpipe that results in successful glamor_egl_init
and reverse_prime_offload_mode enabled.
This commit is explicitly disabling reverse_prime_offload_mode for evdi and udl drivers
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
Copied TGL PCI ID from MESA iris_pci_ids.h
This update brings in a significant number of new platform ID's
Sync up until commit f02ae698
Signed-off-by: Mazlan, Hazwan Arif <hazwan.arif.mazlan@intel.com>
On FreeBSD 13.0-CURRENT for PowerPC64 big-endian (BE), X was
crashing in some cases. For instance, when twm was started
and the background was clicked to open its menu, X crashed
with a segmentation fault, trying to dereference a null pointer
at CreatePicture().
There were 2 issues with xorg-server handling of RGB masks that
caused the pointer above to be null and thus the crash:
- wrong use of ffs() to get the RGB offsets from the masks
- overflow when shifting a 16-bit integer
This change fixes both issues. They happen when the system is BE
but has a video adapter using a little-endian (LE) ARGB32
framebuffer. In order to display the correct colors, this setup
requires a BE RGBA32 color format to be used by X, by setting
the RGB masks appropriately, that didn't work properly because of
the issues above.
A lot of that code is the same as in xf86-amdgpu and xf86-nouveau drivers. By removing that functions from
ms namespace we can move that code to common implementation.
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
According to the "VESA Enhanced EDID Standard", all GTF compliant
displays are continuous frequency.
The GTF support flags in 'Display Range Limits Descriptor' cannot be
used if the display is a non-continuous frequency multi-mode display.
Closes#1105
Signed-off-by: Pascal VITOUX <vitoux.pascal@gmail.com>
Fixes: 6a79a737 ("xfree86: add drm modes on non-GTF panels")
Reviewed-by: Aaron Ma aaron.ma@canonical.com
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: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1126
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>
This brings the behavior closer than what we currently have with
autotools-based build system.
Meson does not currently have native support for symlinks.
See https://github.com/mesonbuild/meson/issues/1602.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Meson gets confused when there are two targets of the same name within
the same directory, so we use a different intermediate name.
This is a problem with the Xorg SUID wrapper which has the same filename
as the real Xorg executable and is configured in the same meson.build
file. This commit works around this by using a different filename in
build stage and renaming only when installing.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
The code path added by commit 69e4b8e6 (xfree86: attempt to autoconfig
gpu slave devices (v3)) assumes that it will only be run if the primary
device on the screen is the first device in xf86configptr->conf_device_lst.
While this is true most of the time, there are two specific cases where
this assumption fails.
First, if the first device in conf_device_lst is assigned to a different
seat than the running X server, it will be skipped by the previous
FIND_SUITABLE macro usage. Second, if the primary device was explicitly
assigned to the screen but auto_gpu_device is still set and no secondary
devices were explicitly listed, that device may not be the first device
in conf_device_lst.
When the first device in conf_device_lst is not the primary device
assigned to the screen, two problems emerge. First, the first device in
conf_device_lst will never be assigned to the screen as a secondary
device. Second, the primary device is additionally assigned to the
screen as a secondary device. The combination of these problems causes
certain otherwise valid configurations to be invalid. For example, if a
primary device is assigned to a screen and a secondary device is listed
in the config but not explicitly assigned to the screen, then one order
of the device sections results in a usable PRIME or Reverse PRIME setup
and the other order does not.
This commit removes the assumption that the primary device is the first
device in conf_device_lst by starting the loop from the start of
conf_device_lst and skipping the primary device when it is encountered.
Signed-off-by: Jacob Cherry <jcherry@nvidia.com>
This add a new flag POINTER_RAWONLY for GetPointerEvents() which does
pretty much the opposite of POINTER_NORAW.
Basically, this tells GetPointerEvents() that we only want the
DeviceChanged events and any raw events for this motion but no actual
motion events.
This is preliminary work for Xwayland to be able to use relative motion
events for raw events. Xwayland would use absolute events for raw
events, but some X11 clients (wrongly) assume raw events to be always
relative.
To allow such clients to work with Xwayland, it needs to switch to
relative raw events (if those are available from the Wayland
compositor).
However, Xwayland cannot use relative motion events for actual pointer
location because that would cause a drift over time, the pointer being
actually controlled by the Wayland compositor.
So Xwayland needs to be able to send only relative raw events, hence
this API.
Bump the ABI_XINPUT_VERSION minor version to reflect that API addition.
v2: Actually avoid sending motion events (Peter)
v3: Keep sending raw emulated events with RAWONLY (Peter)
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Related: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1130
Not all extensions can be enabled or disabled at runtime, list the
extensions which can from the help message rather than on error only.
v2:
* Print the header message in the ListStaticExtensions() (Peter
Hutterer)
* Do not export ListStaticExtensions() as Xserver API
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The definition relies on IOPortBase, which is only ever set in
hw/xfree86/os-support/bsd/arm_video.c
This caused build failures on linux/mips with GCC 10, due to this
change (from https://gcc.gnu.org/gcc-10/changes.html#c):
"GCC now defaults to -fno-common. As a result, global variable accesses
are more efficient on various targets. In C, global variables with
multiple tentative definitions now result in linker errors. With
-fcommon such definitions are silently merged during linking."
As a result anything including compiler.h would get its own definition
of IOPortBase and the linker would error out.
Commit 6a5a4e6037 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1024
Fixes: 8774532121 "modesetting: Remove unnecessary fb addition from
drmmode_xf86crtc_resize"
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: https://gitlab.freedesktop.org/drm/intel/issues/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>
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>
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>
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: c66c548eab "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: 9257b1252d ("modesetting: add dynamic connector hotplug support (MST) (v3)")
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Avoids a crash in xf86RotatePrepare -> DamageRegister during
CreateScreenResources if rotation or another transform is configured for
any connected RandR output in xorg.conf. The generic rotation/transform
code generally can't work without the root window currently.
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/969
Fixes: 094f42cdfe "xfree86/modes: Call xf86RotateRedisplay from
xf86CrtcRotate"
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
There's a free(name) at the end of the function.
GCC warned about this:
../hw/xfree86/loader/loadmod.c: In function ‘LoadModule’:
../hw/xfree86/loader/loadmod.c:702:18: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
702 | m = name = "int10";
| ^
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>
Since commit d8ec33fe05, an include on
glxvndabi.h has been added to hw/xfree86/common/xf86Init.c
However, if glx is disabled through --disable-glx and GLX headers are
not installed in the build's environment, build fails on:
In file included from xf86Init.c:81:
../../../include/glxvndabi.h:64:10: fatal error: GL/glxproto.h: No such file or directory
64 | #include <GL/glxproto.h>
| ^~~~~~~~~~~~~~~
Fix this failure by removing this include which does not seem to be
needed (an other option would have been to keep it under an ifdef GLXEXT
block)
Fixes:
- http://autobuild.buildroot.org/results/de838a843f97673d1381a55fd4e9b07164693913
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
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:
fd66f5c0be/src/amdgpu_kms.c (L388)
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Commit cb1b1e184 modified msSharePixmapBacking() to derive modesettingPtr from
the 'screen' argument. Unfortunately, the name of the argument is misleading --
the screen is the slave screen. If the master is modesetting,
and the slave is not modesetting, it will segfault.
To fix the problem, this change derives modesettingPtr from
ppix->drawable.pScreen. This method is already used when calling
ms->glamor.shareable_fd_from_pixmap() later in the function.
To avoid future issues, this change also renames the 'screen' argument to
'slave'.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
New now ask Glamor to use EGL_MESA_query_driver to obtain the DRI driver
name; if successful, we use that as the DRI driver name. Following the
existing dri2.c logic, we also use the same name for the VDPAU driver,
except for i965 (and now iris), where we switch to the "va_gl" fallback.
This allows us to bypass the PCI ID lists in xserver and centralize the
driver selection mechanism inside Mesa. The hope is that we no longer
have to update these lists for any future hardware.
If a new rotate buffer was allocated. This makes sure the new buffer
has valid transformed contents when it starts being displayed.
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>
isastream() was never more than a stub in glibc, and was removed in
glibc-2.30 by commit a0a0dc83173c ("Remove obsolete, never-implemented
XSI STREAMS declarations").
Bug: https://bugs.gentoo.org/700838
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Now that we've fixed LoaderSymbolFromModule this should work properly.
This reverts commit 5c7c6d5cff.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The thing you get back from xf86LoadSubModule is a ModuleDescPtr, not a
dlsym handle. We don't expose ModuleDescPtr to the drivers, so change
LoaderSymbolFromModule to cast its void * argument to a ModuleDescPtr.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
During startup, the xfree86 DDX's InitOutput() calls PreInit for
protocol screens first, and then GPU screens. On teardown, dix_main()
calls CloseScreen in the reverse order: GPU screens first starting with
the last one and then working backwards, and then protocol screens also
in reverse order.
InitOutput() calls ScreenInit in the wrong order: for GPU screens first and then
for protocol screens. This causes a problem for drivers that have global state
that is tied to the first screen that calls ScreenInit.
Fix this by simply re-ordering the for loops to call PreInit for
protocol screens first and then for GPU screens second.
ms_present_get_crtc() returns an RRCrtcPtr, but derives it from a xf86CrtcPtr
found via ms_dri2_crtc_covering_drawable()=>ms_covering_crtc(). As a result, it
depends on all associated DIX ScreenRecs having an xf86CrtcConfigPtr DDX
private.
Some DIX ScreenRecs don't have an xf86CrtcConfigPtr DDX private, but do have an
rrScrPrivPtr DDX private. Given that we can derive all of the information we
need from RandR, we can support these screens by avoiding the use of xf86Crtc.
This change implements an RandR-based path for ms_present_get_crtc(), allowing
drawables to successfully fall back to syncing to the primary output, even if
the slave doesn't have an xf86CrtcConfigPtr DDX private.
Without this change, if a slave doesn't have an xf86CrtcConfigPtr DDX private,
drawables will fall back to 1 FPS if they overlap an output on that slave.
Signed-off-by: Alex Goins <agoins@nvidia.com>
DIX ScreenRecs don't necessarily have an xf86CrtcConfigPtr DDX private.
ms_covering_crtc() assumes that they do, which can result in a segfault.
Update ms_covering_crtc() to check the XF86_CRTC_CONFIG_PTR() returned pointer
before dereferencing it. This will still mean that ms_covering_crtc() can't fall
back to the primary output when a drawable overlaps a slave output (going to the
1 FPS default instead), but it won't segfault.
Signed-off-by: Alex Goins <agoins@nvidia.com>
ms_covering_crtc() uses RRFirstOutput() to determine a primary output to fall
back to if a drawable is overlapping a slave output.
If the primary output is a slave output, RRFirstOutput() will return a slave
output even if passed a master ScreenPtr. ms_covering_crtc() dereferences the
output's devPrivate, which is invalid for non-modesetting outputs, and can
crash.
Changing RRFirstOutput() could have unintended side effects for other callers,
so this change replaces the call to RRFirstOutput() with ms_first_output().
ms_first_output() ignores the primary output if it doesn't match the given
ScreenPtr, choosing the first connected output instead.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Slightly simplifies the callers since they don't need to check for
non-NULL anymore.
I do extremely hate the workarounds here to suppress misprite taking the
cursor down though. Surely there's a better way.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
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>
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>
Move from the xf86 specific ScrnInfoRec::privates, to the dix private
handling. Since there's no FreeScreen function in ScreenPtr, fold the
former within the existing CloseScreen.
Users, such as modesetting are updated, and out of tree drivers will
need equivalent, yet trivial, patch.
Note: we need to ensure that the screen private is unset and the screen
callbacks are restored in our CloseScreen function.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The autoconf build for the modesetting driver still relied on
xorg-macros.m4 for string replacements and did not include the
top-level manpages.am. As a result, no substitutions took place after
commit 2e497bf887.
This should be a candidate for the 1.20 branch.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
There's not really a good reason to keep these separate, the vbe code
requires int10 and is not very large. This change eliminates the
build-time options for vbe; if you build int10, you get vbe.
Gitlab: https://gitlab.freedesktop.org/xorg/xserver/issues/692
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
i965 and radeonsi, respectively, are the drivers that have been
receiving new hardware support. It's really silly to need to update the
server side to know specific new devices IDs every time a new ASIC comes
out.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This might be an error or not, for example refusing to work on llvmpipe
is normal and expected. glamor_egl_init() will print X_ERROR messages if
appropriate, so we don't need to here.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This fixes 'non-desktop' displays staying powered on after their lease
has been revoked.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111620
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
The atomic driver has issues with modesetting when stealing
connectors from a different crtc, a black screen when doing rotation
on a different crtc, and in general is just a mapping of the legacy
helpers to atomic. This is already done in the kernel, so just
fallback to legacy by default until this is fixed.
Please backport to 1.20, as we don't want to enable it for everyone
there. It breaks for existing users.
The fixes to make the xserver more atomic have been pending on the
mailing list for ages.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110375
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110030
References: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/36/commits
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.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>
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:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/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>
Before this commit ms_do_pageflip logged a single error for both the
drmmode_bo_import failure path as well as for the queue_flip_on_crtc
path. This commit splits this into 2 separate error logs so that it is
clear what the cause of the flip-failure is.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Currently on present-flip failures we log 2 messages for each failure,
1 from ms_do_pageflip and then another one from ms_present_flip which
is the caller of ms_do_pageflip. This commit adds a log_prefix argument
to ms_do_pageflip so that its log messages can show if it is a DRI2 or
a Present flip which fails and removes the redundant error message from
ms_present_flip.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a modified version of a patch we've been carry-ing in Fedora and
RHEL for years now. This patch automatically adds secondary GPUs to the
master as output sink / offload source making e.g. the use of
slave-outputs just work, with requiring the user to manually run
"xrandr --setprovideroutputsource" before he can hookup an external
monitor to his hybrid graphics laptop.
There is one problem with this patch, which is why it was not upstreamed
before. What to do when a secondary GPU gets detected really is a policy
decission (e.g. one may want to autobind PCI GPUs but not USB ones) and
as such should be under control of the Desktop Environment.
Unconditionally adding autobinding support to the xserver will result
in races between the DE dealing with the hotplug of a secondary GPU
and the server itself dealing with it.
However we've waited for years for any Desktop Environments to actually
start doing some sort of autoconfiguration of secondary GPUs and there
is still not a single DE dealing with this, so I believe that it is
time to upstream this now.
To avoid potential future problems if any DEs get support for doing
secondary GPU configuration themselves, the new autobind functionality
is made optional. Since no DEs currently support doing this themselves it
is enabled by default. When DEs grow support for doing this themselves
they can disable the servers autobinding through the servers cmdline or a
xorg.conf snippet.
Signed-off-by: Dave Airlie <airlied@gmail.com>
[hdegoede@redhat.com: Make configurable, fix with nvidia, submit upstream]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
---
Changes in v2:
-Make the default enabled instead of installing a xorg.conf
snippet which enables it unconditionally
Changes in v3:
-Handle GPUScreen autoconfig in randr/rrprovider.c, looking at
rrScrPriv->provider, rather then in hw/xfree86/modes/xf86Crtc.c
looking at xf86CrtcConfig->provider. This fixes the autoconfig not
working with the nvidia binary driver
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: https://gitlab.freedesktop.org/xorg/xserver/issues/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>
When the pixmapPrivateKeyRec was moved from a global to being embedded
inside the drmmode_rec these 2 where missed, clean them up.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The modesetting driver (which now often is used with Intel GPUs),
relies on DRI2ScreenInit() to setup the DRI and VDPAU driver names.
Before this commit it would always assign the same name to the 2 names,
but the VDPAU driver for i965 GPUs should be va_gl.
This commit adds a special case for the i965 case, replacing the
VDPAU driver name with "va_gl" if the GPU is using the i965 driver
for DRI.
Note this commit adds a FIXME comment for a related memory leak, that leak
was already present and fixing it falls outside of the scope of this commit.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1413733
Cc: kwizart@gmail.com
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This script generates a header that has a comment containing the build path for
no real reason. As this source can end up deployed on targets in debug packages
this means there is both potentially sensitive information leakage about the
build environment, and a source of change for reproducible builds.
Stop trying to link to a shared library we no longer build
Fixes: commit c1703cdf3b - "xfree86: Link fb statically"
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
"bool" conflicts with C++ (meh) and stdbool.h (ngh alright fine). This
is a driver-visible change and will likely break the build for mach64,
but it can be fixed by simply using xf86ReturnOptValBool like every
other driver.
Signed-off-by: Adam Jackson <ajax@redhat.com>
<sys/io.h> on ARM hasn't worked for a long, long time, so it was removed
it from glibc upstream.
Remove the include to avoid a compilation failure on ARM with glibc.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/840
Don't link against fb, it's the driver's responsibility to load that
first. Underlinking like this is unpleasant but this matches what
autotools does.
Fixes: xorg/xserver#540
Copied from Mesa with no modifications.
This update brings in a significant number of new platform ID's.
Syncs with mesa up to commit e334a595e ("intel/icl: Add new ICL
PCI-IDs").
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Promote the generated file containing the date & time build was
configured to top-level.
Rename it from xf86Build.h to buildDateTIme.h.
Use it as well in XQuartz, stringize BUILD_DATE when needed.
If SYSTEMD_LOGIND is not defined, systemd_logind_take_fd is defined as a
macro evaluating to -1 by systemd-logind.h, leaving paused
uninitialized.
../hw/xfree86/common/xf86Xinput.c: In function ‘xf86NewInputDevice’:
../hw/xfree86/common/xf86Xinput.c:919:16: warning: ‘paused’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../hw/xfree86/common/xf86Xinput.c:877:10: note: ‘paused’ was declared here
../hw/xfree86/os-support/stub/stub_init.c: In function ‘xf86OSInputThreadInit’:
../hw/xfree86/os-support/stub/stub_init.c:29:1: warning: old-style function definition [-Wold-style-definition]
Drivers may need to loop over the allocated screens during PreInit, for example
to consolidate xorg.conf options that apply to a GPU device as a whole.
Currently, this works for protocol screens becuase x86Screens is exported, but
does not work for GPU screens.
Export xf86GPUScreens and xf86NumGPUScreens for consistency with xf86Screens and
xf86NumScreens.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
If the user sets Option "Enable" "TRUE" for a monitor, the X
server will connect the connector a crtc but tell the user it
is disconnected.
However the user in this case is mutter, when it gets it's view
of the output configuration it sees the output is disconnected
and never sets it up again, which seems like the right thing to do.
If we let the user enable a monitor, lets just set it as always
connected.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
systemd-logind since version 234 (released 2017-07-12) supports being
restarted without losing state [1]. From the systemd NEWS file [2]:
* systemd-logind may now be restarted without losing state. It stores
the file descriptors for devices it manages in the system manager
using the FDSTORE= mechanism. Please note that further changes in
other components may be required to make use of this (for example
Xorg has code to listen for stops of systemd-logind and terminate
itself when logind is stopped or restarted, in order to avoid using
stale file descriptors for graphical devices, which is now
counterproductive and must be reverted in order for restarts of
systemd-logind to be safe. See
https://cgit.freedesktop.org/xorg/xserver/commit/?id=dc48bd653c7e101.)
This reverts commit dc48bd653c.
Closes: #531
[1] https://github.com/systemd/systemd/pull/5600
[2] 9f09a95a7e
Normally, the X server infers the initial screen size based on any
connected outputs. However, if no outputs are connected, the X server
picks a default screen size of 1024 x 768. This option overrides the
default screen size to use when no outputs are connected. In contrast
to the "Virtual" Display SubSection entry, which applies unconditionally,
"NoOutputInitialSize" is only used if no outputs are detected when the
X server starts.
Parse this option in the new exported helper function
xf86AssignNoOutputInitialSize(), so that other XFree86 loadable drivers
can use it, even if they don't use xf86InitialConfiguration().
Signed-off-by: Andy Ritger <aritger@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Since the Solaris kernel tracks IOPL per thread, and doesn't inherit
raised IOPL levels when creating a new thread, we need to turn it on
in the input thread for input drivers like vmmouse that need register
access to work correctly.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Keeping track of kernel state in user space doesn't buy us anything,
and introduces bugs, as we were keeping global state but the Solaris
kernel tracks IOPL per thread.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The VGA arbiter controls the PCI bus' routing of legacy VGA resources,
specifically the video memory aperture at 0xa0000-0xb0000 (640k should
be etc.) and a handful of I/O ports. Since 128k is far too small for a
real framebuffer these days, every driver instead maps a linear version
of VRAM through the PCI BAR. And no DRI2 drivers ever need I/O port
access, because all operations they might be used for (legacy VGA CRTC
setup, mostly) happen on the kernel side.
In other words, this just works, and we can stop breaking it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
A user of Adélie Linux reported that modesetting wasn't working properly on
their Intel i7-9700K-integrated UHD 630 GPU. Xorg.0.log showed:
[ 131.902] (EE) modeset(0): [DRI2] No driver mapping found for PCI device 0x8086 / 0x3e98
[ 131.902] (EE) modeset(0): Failed to initialize the DRI2 extension.
Indeed, that PCI ID is missing from i965_pci_ids. Adding it fixed the issue
and allowed the system to work with i965_dri under modesetting.
All of the null checks here are redundant, you can't get to those paths
unless RANDR's already been initialized. Delete them, and remove the
pointer too.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
If the driver calls xf86HandleColormaps, CMapChangeGamma updates the HW
gamma LUT of all CRTCs via xf86RandR12LoadPalette. However,
xf86RandR12ChangeGamma was then clobbering the gamma LUT of the RandR
1.2 compatibility output's CRTC with the gamma curves computed from the
screen's global gamma values.
Fix this by bailing if xf86RandR12LoadPalette is installed.
Fixes: 02ff0a5d7e "xf86RandR12: Fix XF86VidModeSetGamma triggering a
BadImplementation error"
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>
Gitlab very kindly exposes the details of the git commit message (among
much else) in the environment. Unfortunately, piglit tries to handle the
environment in non-UTF8-safe ways, which means if the top-of-tree commit
mentions non-ASCII characters (say, in the author's name) then all the
tests fail and so does the pipeline.
Fortunately none of those variables are things our piglit invocation
needs. Since I've failed to rebuild the docker image as yet, just clear
the likely variables from the environment before running piglit.
This-makes-me: ☹
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>
Some Broadcom set-top-box boards have PCI busses, but the GPU is still
probed through DT. We would dereference a null busid here in that
case.
Signed-off-by: Eric Anholt <eric@anholt.net>
Lifted from vfb. xfree86 had almost the same thing but unparameterized,
port it to the vfb style.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Could cause privilege elevation and/or arbitrary files overwrite, when
the X server is running with elevated privileges (ie when Xorg is
installed with the setuid bit set and started by a non-root user).
CVE-2018-14665
Issue reported by Narendra Shinde and Red Hat.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
At the point where xf86BusProbe runs we haven't yet taken our own VT,
which means we can't perform drm "master" operations on the device. This
is tragic, because we need master to fish the bus id string out of the
kernel, which we can only do after drmSetInterfaceVersion, which for
some reason stores that string on the device not the file handle and
thus needs master access.
Fortunately we know the format of the busid string, and it happens to
almost be the same as the ID_PATH variable from udev. Use that instead
and stop calling drmSetInterfaceVersion.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
If the X server is terminated while its VT is not active, it should
not change the current VT.
v2: Query current state in xf86CloseConsole using VT_GETSTATE instead of
keeping track in xf86VTEnter/xf86VTLeave/etc.
This hasn't done anything besides return TRUE in a long long time.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
These are so close to identical that most DDXes implement one in terms
of the other. All the relevant cases can be distinguished by the error
code, so merge the functions together to make things simpler.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
No supported driver supports 1bpp anymore, nor has in a very long time.
This option only worked with vgahw anyway.
Signed-off-by: Adam Jackson <ajax@redhat.com>
I don't think this is useful information to have in the log, and it's
a bunch of autotools and meson logic to produce it.
Signed-off-by: Eric Anholt <eric@anholt.net>
60ec8ead broke the autotools build:
sdksyms.o:(.data+0x58): undefined reference to `InitConnectionLimits'
sdksyms.o:(.data+0x2ec8): undefined reference to `xf86ServerName'
collect2: error: ld returned 1 exit status
Makefile:811: recipe for target 'Xorg' failed
Likewise 3a4d7c79 for InitConnectionLimits.
Signed-off-by: Adam Jackson <ajax@redhat.com>
If it's really this important we should just do it and not complain. We
never do it so it must not matter.
Signed-off-by: Adam Jackson <ajax@redhat.com>
I'm sure printing the address of function pointers in modules you'd
loaded might have made sense back when we rolled our own dlopen, but we
got better.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The old code would not in fact validate the option value, though it
might complain about it in the log. It also didn't let you set some
legal values that the -maxclients command line option would.
Signed-off-by: Adam Jackson <ajax@redhat.com>
DGAShutdown() walks every screen and attempts to reset the mode. That's
maybe a reasonable thing to do, although the explicit loop is certainly
a bad smell.
In ddxGiveUp it's called after we've torn down the vga arbiter - and in
fact most of the rest of screen state - which is... very very bad. The
other place it's called is from the Control-Alt-BackSpace handler, where
we don't even attempt to do vga arb setup, and where in any case we're
going to escape the main loop eventually anyway.
Move all that cleanup work inside DGACloseScreen. This means it happens
earlier in server teardown than previously, but not in a way you're ever
going to be upset about.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The X will be crashed on the system with other DDX driver,
such as amdgpu.
show the log like:
randr: falling back to unsynchronized pixmap sharing
(EE)
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e)
(EE) 1: /usr/lib/xorg/Xorg (0x55cb0151a000+0x1b5ce9)
(EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1587a1d000+0x11390)
(EE)
(EE) Segmentation fault at address 0x0
(EE)
The issue is that modesetting as the master, and amdgpu as the slave.
Thus, when the master attempts to access pSlavePixPriv in ms_dirty_update(),
problems result due to the fact that it's accessing AMD's 'ppriv' using the
modesetting structure definition.
Apart from fixing crash issue, the patch fix other issue in master interface
in which driver should refer to master pixmap.
Signed-off-by: Jim Qu <Jim.Qu@amd.com>
Reviewed-by: Alex Goins <agoins@nvidia.com>
This makes us match the featureset of autotools, and also fixes the
non-Linux default value to match.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
I don't have a BSD to test on, but this should do the same as what
autotools did.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have pm_noop.c being built most of the time for the
no-OS-PM case, so just switch to always using it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
The recent rewrite of modesetting driver broke the 24bpp support.
As typically found on cirrus KMS, it leads to a blank screen, spewing
the error like:
failed to add fb -22
(EE) modeset(0): failed to set mode: Invalid argument
The culript is that the wrong bpp value of the front buffer is passed
to drmModeAddFB(). Fix it by replacing with the back buffer bpp,
drmmode->kbpp.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Stefan Dirsch <sndirsch@suse.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When setting DefaultDepth to 16 in the Screen section, the current
code requests a 32 bpp framebuffer, however the X-Server seems to
assumes 16 bpp.
Fixes commit 21217d0216 ("modesetting: Implement 32->24 bpp
conversion in shadow update")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
If we're using atomic modesetting, then we're also using universal
planes, and so the lease we create needs to include the plane.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
We don't want universal_planes unless we're using atomic APIs for
modesetting, and the kernel already enables universal_planes
automatically when atomic is enabled.
If we enable universal_planes when we're not using atomic, then we
won't have selected a plane for each crtc, and this will break lease
creation which requires planes for each output when universal_planes
is enabled.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
The DIX crtc and output structures are freed when their resources are
destroyed, which happens before CloseScreen is called. As a result, we
know these pointers are invalid and referencing them during any of the
remaining CloseScreen sequence will be bad.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Cc: thellstrom@vmware.com
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960
This lets an application open a suitable DRM device and pass the file
descriptor to the mode setting driver through an X server command line
option, '-masterfd'.
There's a companion application, xlease, which creates a DRM master by
leasing an output from another X server. That is available at
git clone git://people.freedesktop.org/~keithp/xlease
v2:
Always print usage, but note that it can't be used if
setuid/gid
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
So, this did actually work on older kernels at one point in time,
however it seems that this working was a result of some of the Linux
kernel's atomic modesetting helpers not preserving the CRTC's enabled
state in the right spots. This was fixed in:
846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2")
As a result, atomic commits which simply disassociate a DRM connector
with it's CRTC while leaving the CRTC in an enabled state aren't enough
to disable the CRTC, and result in the atomic commit failing. This
currently can cause issues with MST hotplugging where X will end up
failing to disable the MST outputs after they've left the system. A
simple reproducer:
- Start up Xorg
- Connect an MST hub with displays connected to it
- Remove the hub
- Now there should be CRTCs stuck on the orphaned MST connectors, and X
won't be able to reclaim them.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
drmmode_shadow_allocate() still uses drmModeAddFB() which may fail if
the format is not as expected, preventing from using a rotated output.
Change it to use the new function drmmode_bo_import() which takes care
of calling the drmModeAddFB2() API.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106715
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Tomas Pelka <tpelka@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Change the 'chown' statement in Makefile.am to use the numeric UID
of superuser instead of relying on the name 'root'.
Bugzilla: https://bugs.freedesktop.org/27726
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michał Górny <gentoo@mgorny.alt.pl>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In commit 9db2af6f75 (xfree86: Remove xf86{Map,Unmap}VidMem) we
somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the
function pointer indirection was intended to support dense vs sparse and
sparse support is now gone, we can just make the functions static inline
in compiler.h and avoid all of this.
Bugzilla: https://bugs.gentoo.org/548906
Tested-by: Christopher May-Townsend <chris@maytownsend.co.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
We don't want DRM file descriptors to leak to child processes.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
It was passing O_CLOEXEC as permission bits instead of as a flag.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Fixes DRI2 client driver name mapping for newer AMD GPUs with the
modesetting driver, allowing the DRI2 extension to initialize.
Fixes using GL with the modesetting driver for me.
Seems we were way behind on this one, time to look into something
more scalable?
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Modifiers support needs gbm as a dependency. Without setting the dependency
included headers are not found reliably and the build might fail if the
headers are not placed in the default system include paths.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The old 32-Bit wraparound handling didn't actually work, due to some
integer casting bug, and the mapping was ill equipped to deal with input
from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's
introduced in Linux 4.15.
For 32-Bit truncated input from pageflip events and old vblank events
and old drmWaitVblank ioctl, implement new wraparound handling, which
also allows to deal with wraparound in the other direction, e.g., if a
32-Bit truncated sequence value is passed in, whose true 64-Bit
in-kernel hw value is within 2^30 counts of the previous processed
value, but whose 32-bit truncated sequence value happens to lie just
above or below a 2^32 boundary, iow. one of the two values 'sequence'
vs. 'msc_prev' lies above a 2^32 border, the other one below it.
The method is directly translated from Mesa's proven implementation of
the INTEL_swap_events extension, where a true underlying 64-Bit wide
swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB
truncated SBC transported over the X11 protocol wire. Same conditions
apply, ie. successive true 64-Bit SBC values are close to each other,
but don't always get received in strictly monotonically increasing
order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx:
Handle out-of-sequence swap completion events correctly. (v2)") for
explanation.
Additionally add a separate path for true 64-bit msc input originating
from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and
corresponding 64-bit vblank events. True 64-bit msc's don't need
remapping and must be passed through.
As a reliability bonus, they are also used here to update the tracking
values msc_prev and ms_high with perfect 64-Bit ground truth as baseline
for mapping msc from pageflip completion events, because pageflip events
are always 32-bit wide, even when the new kernel api's are used. Because
each pageflip(-event) is always preceeded close in time (and vblank
count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence
query as part of DRI2 or DRI3+Present swap scheduling, we can be certain
that each pageflip event will get its truncated 32-bit msc remapped
reliably to the true 64-bit msc of flip completion whenever the sequence
api is available, ie. on Linux 4.15 or later.
Note: In principle at least the 32-bit mapping path could also be
backported to earlier server branches, as this seems to be broken for at
least server 1.16 to 1.19.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
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: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-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>
Copied from Mesa with no modifications.
Gives us Cofeelake platform names updates and sync on Kaby Lake,
Ice Lake PCI IDs.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
GBM objects were never destroyed after looking for format and
modifier compatibility when deciding whether flipping or copying
a presented pixmap.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106106
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Kludge sdksyms.c generator to not fail on GetClientPid.
It returns pid_t which on NetBSD is #define pid_t __pid_t
This slightly alters the GCC preprocessor output which this fragile
code could not deal with when using GCC 5+
Signed-off-by: Adam Jackson <ajax@redhat.com>
Use the DRM_CAP_ADDFB2_MODIFIERS query to make sure the kms
driver supports modifiers in the addfb2 ioctl, and fall back
to addfb ioctl without modifiers if modifiers are unsupported.
E.g., as of Linux 4.17, nouveau-kms so far does not suppport
modifiers and gets angry if drmModeAddFB2WithModifiers() is
called (-> failure to set a video mode -> blank screen), but
Mesa's nvc0+ gallium driver causes gbm_bo_get_modifier() to
return a valid modifier by translating the default tiling of
bo's created via gbm_bo_create() into a modifier other than
DRM_FORMAT_MOD_INVALID (see Mesa's nvc0_miptree_get_modifier()).
Testing for != DRM_FORMAT_MOD_INVALID is apparently not
sufficient for safe use of drmModeAddFB2WithModifiers.
Bonus: Handle potential failure of populate_format_modifiers().
The required DRM_CAP is defined since libdrm v2.4.65, and we
require v2.4.89+ for the server, so we can use it unconditionally.
Tested on intel-kms, radeon-kms, nouveau-kms. Fixes failure on
NVidia Pascal.
Fixes: 2f807c2324 ("modesetting: Add support for multi-plane pixmaps when page-flipping")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
ms_queue_vblank() returns false on failure.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Apparently on NetBSD we can hit failures like this:
sdksyms.c:1773:15: error: expected expression before ',' token
(void *) &, /* ../../dri3/dri3.h:110 */
I've been unable to reproduce that locally (even in a NetBSD vm), but
an obvious workaround might be to just notice empty symbol names and
ignore them rather than emit invalid C code.
Tested-by: Thomas Klausner <wiz@netbsd.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This was never merged upstream. It was a Fedora kernel patch but dropped from
Fedora in 2013 with kernel 3.12.
The reason for the KDSKBMUTE proposal has been fixed in systemd in Feb 2013,
systemd 198.
https://lists.freedesktop.org/archives/systemd-devel/2013-February/008795.html
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
../hw/xfree86/utils/gtf/gtf.c: In function ‘print_fb_mode’:
../hw/xfree86/utils/gtf/gtf.c:241:50: warning: cast from function call of type ‘double’ to non-matching type ‘int’ [-Wbad-function-cast]
printf(" timings %d %d %d %d %d %d %d\n", (int) rint(1000000.0 / m->pclk), /* pixclock in picoseconds */
That's pretty nitpicky of you, gcc, but at least it's easy to fix.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
We would fail to get the FB ID if it wasn't already imported, since we
were checking to see if the pointer was NULL (it never was) rather than
if the content of the pointer was 0.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
drmmode_crtc_set_mode has a loop nested inside another loop, where both
of them were using 'i' as the loop iterator. Rename it to avoid an
infinite loop.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Non-atomic kms drivers like radeon-kms (or nouveau-kms with
default setting of "atomic ioctl disabled") don't export
any formats, so num_formats == 0.
Some atomic drivers (nouveau-kms with boot param nouveau.atomic=1,
or intel-kms on, e.g., Linux 4.13) expose num_formats == 0, or
don't expose any modifiers, so num_modifiers == 0.
Let the drmmode_is_format_supported() check pass in these cases
to allow page flipping, as it works just fine.
Tested on NV-96 for nouveau, HD-5770 for radeon, Intel Ivybridge
with Linux 4.13 and drm-next to fix page flipping.
Fixes: 9d147305b4 ("modesetting: Check if buffer format is supported when flipping")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
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: Adam Jackson <ajax@redhat.com>
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: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Tested-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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: Daniel Stone <daniels@collabora.com>
Reported-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The newline before the protocl version got lost in commit
6cbefc3e0a. Prior to that commit, the
release date printed a newline at the end:
X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.14.12-1-ARCH x86_64
Now, that string gets run together with the version:
X.Org X Server 1.19.99.903 (1.20.0 RC 3)X Protocol Version 11, Revision 0
Build Operating System: Linux
Since the version string printing has a variety of #ifdefs in it, just
add the newline to the begining of the protocol version string.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The framebuffer can include multiple CRTCs in multi-monitors
setup. So we shouldn't use the buffer size but the CRTC size
instead. Rotated displays are shadowed, so we don't need to
worry about it there.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Fixes a regression caused by modifiers support. For some hw to
continue working even if not supporting ARGB8888 and ARGB2101010
formats, we assume that all imported BOs are opaque.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Otherwise the same content is shown on all outputs.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.comM>
The respective ISA functions were dropped back in 2008
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Install missing headers to the SDK directory to allow external modules
to properly build against the SDK. After this commit, the list of files
installed in the SDK include directory is the same as the list of files
installed by the autotools-based build.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
drmmode_output_dpms is called especially with !output->crtc found in
xf86DisableUnusedFunctions so we have to guard for it, else the server
segfaults:
0 0x00007fdc1706054b in drmmode_output_dpms (output=0x55e15243c210, mode=3) at
drmmode_display.c:2243
1 0x000055e1500b6873 in xf86DisableUnusedFunctions (pScrn=0x55e152133f00) at
xf86Crtc.c:3021
2 0x000055e1500be940 in xf86RandR12CrtcSet (pScreen=<optimized out>,
randr_crtc=0x55e1524b2b90, randr_mode=0x0, x=0, y=0, rotation=<optimized out>,
num_randr_outputs=0, randr_outputs=0x0) at xf86RandR12.c:1244
3 0x000055e1500fa1c2 in RRCrtcSet (crtc=<optimized out>, mode=0x0, x=0, y=0,
rotation=rotation@entry=1, numOutputs=numOutputs@entry=0, outputs=0x0) at
rrcrtc.c:763
4 0x000055e1500fba9e in ProcRRSetCrtcConfig (client=0x55e152bfae50) at
rrcrtc.c:1390
5 0x000055e150044008 in Dispatch () at dispatch.c:478
6 0x000055e150047ff8 in dix_main (argc=13, argv=0x7ffc68561038,
envp=<optimized out>) at main.c:276
7 0x00007fdc1a0c6a87 in __libc_start_main () at /lib64/libc.so.6
8 0x000055e150031d0a in _start () at ../sysdeps/x86_64/start.S:120
Fixes: ba0c75177 ("modesetting: Fix up some XXX from removing GLAMOR_HAS_DRM_*")
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
... for xfree86, at least for now. Things appear to work for Xwayland
but not yet for modesetting. Hopefully we can fix that before 1.20 but
in the meantime this makes testing both paths easier than a rebuild.
Signed-off-by: Adam Jackson <ajax@redhat.com>
We don't use flink in the GetFB import path anymore, as we do an
FD-based import instead.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
A cosmetic change for automake (though we have to replicate some of
xorg-macros.m4 in manpages.am now), but meson's configure_file() wants
@-delimited strings.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
The check for "no modifier specified" in drmmode_is_format_supported()
should check for DRM_FORMAT_MOD_INVALID, not for zero, as zero actually
means DRM_FORMAT_MOD_LINEAR.
This allows page-flipping again when appropriate, as
tested under nouveau and ati drivers.
Fixes: 9d147305b4 ("modesetting: Check if buffer format is supported when flipping")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
[... but leave it defined and exported, since we're ABI-frozen - ajax]
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Ben Crocker <bcrocker@redhat.com>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
Tested-by: Ben Crocker <bcrocker@redhat.com>
restore abi
Having different types of code all trying to check for elevated privileges
is a bad idea. This implementation is the most thorough one.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Ben Crocker <bcrocker@redhat.com>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
Tested-by: Ben Crocker <bcrocker@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
All the macros are available in the libdrm that we depend on.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
We already require libdrm 2.4.89 which provides the definition plus
guarding kernel UABI like that is generally a bad idea.
See previous commit for details why :-)
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The macro was available in libdrm for ages. Furthermore having a guard
like this is a very bad idea.
Building on an old server will result in a missing run-time functionality.
Since it's UABI one can use a local fallback, old kernels will return
-EINVAL and the fallback path will kick in.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
With earlier commit the required version was bumped to 2.4.89, thus the
guards always evaluate to true.
Fixes: e4e3447603 ("Add RandR leases with modesetting driver support
[v6]")
Cc: Keith Packard <keithp@keithp.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This reverts commit 8c455db0eb.
Since xf86platformBus.h is only included when XSERVER_PLATFORM_BUS is
defined, and configure.ac only defines that on systems with udev, this
commit breaks the build on non-udev systems like Solaris.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Copied from Mesa with no modifications.
Gives us Geminilake and Kaby Lake platform names updates and
sync on Coffee Lake PCI IDs.
Cc: Timo Aaltonen <timo.aaltonen@canonical.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Use most optimal buffer format (e.g. tiled/compressed) available
for scanout.
v2: Don't use multi-plane modifier to create scanout buffer
v3: Add flag to retrieve modifiers set from enabled CRTCs only
v4: Fix uses when GBM/EGL driver doesn't support modifiers
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Retrieve IN_FORMATS property from the plane. It gives the
allowed formats and modifiers for BO allocation.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This allows the uses of CCS compressed or tiled pixmaps as BOs when
page-flipping.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This lets a DRM client map between X outputs and kernel connectors.
v2:
Change CONNECTOR_ID to enum -- Adam Jackson <ajax@nwnk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@nwnk.net>
Save any value of the kernel non-desktop property in the xf86Output
structure to avoid non-desktop outputs in the default configuration.
[Also bump randrproto requirement to a version that defines
RR_PROPERTY_NON_DESKTOP - ajax]
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@nwnk.net>
At startup, we want to ignore non-desktop monitors unless we don't
find any desktop monitors. Because there are no DIX RandR resources
allocated, let the driver store this information in a new field in the
xf86Output structure and then use that value to help decide whether to
include an output as part of the default configuration.
v2:
Suggested-by: Michel Dänzer <michel@daenzer.net>
Bump XF86_CRTC_VERSION from 7 to 8. This will let out-of-tree
drivers know whether this field is available.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@nwnk.net>
glamor now supports depth 30, so allow use of it.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
This retains old behavior for depths <= 24, but allows gamma
table and colormap updates to work properly at depth 30.
This needs the xf86Randr12CrtcComputeGamma() fix for depth 30
from a previous commit to work. Otherwise the server will work,
but gamma table updates will silently fail, iow. the server
would always run with a default identity gamma lut.
v2: Simplify as proposed by Michel.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk> (v1)
At screen depths > 24 bit, the color palettes passed into
xf86Randr12CrtcComputeGamma() can have a larger number of slots
than the crtc's hardware lut. E.g., at depth 30, 1024 palette
slots vs. 256 hw lut slots. This palette size > crtc gamma size
case is not handled yet and leads to silent failure, so gamma
table updates do not happen.
Add a new subsampling path for this case.
This makes lut updates work again, as tested with the xgamma
utility (uses XF86VidMode extension) and some RandR based
gamma ramp animation.
v2: Better resampling when subsampling the palette, as
proposed by Ville. Now reaches the max index of the
palette and deals with non-power-of-two sizes. Thanks.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk> (v1)
Cc: <ville.syrjala@linux.intel.com>
Support x-screens of depth 30, so init doesn't fail.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
Turns out that the kernel DRM ioctl handling returns EINVAL
instead of ENOTTY if one tries to call the new drmCrtcGetSequence()
or drmCrtcQueueSequence() ioctl's introduced in Linux 4.15 on an
older kernel where they are missing. This causes the fallback code
not to fall back to the old drmWaitVblank() ioctl and thereby
failure of vblank stuff.
E.g., on Linux 4.13, glxgears -info runs unthrottled at 10000 fps
instead of 60 fps. Also breakage of OML_sync_control extension.
Check for errno != EINVAL before setting has_queue_sequence = TRUE.
Additionally in case of supported drmCrtcQueueSequence(), set
has_queue_sequence = TRUE on success, or we might get at
least a temporary failure in ms_queue_vblank().
One slight ambiguity is that we can also get EINVAL if
drm_crtc_vblank_get() fails in the kernel, so if that
happened at first invocation of the new api, we'd fall
back to drmWaitVblank() and then fail there, instead of
failing in the new api, but the end result would be the
same.
Fixes: 44d5f2eb8a ("xf86-video-modesetting: Support new vblank kernel API [v2]")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Add the missing arguments to the function signature.
Fixes: e46820fb89 ("miinitext: introduce LoadExtensionList() to replace
over LoadExtension()")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Add a stub for Xnest so it continues to link, but otherwise we support
GLX on every server so there's no need to make every DDX add it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The big change here is MakeCurrent and context tag tracking. We now
delegate context tags entirely to the vnd layer, and simply store a
pointer to the context state as the tag data. If a context is deleted
while it's current, we allocate a fake ID for the context and move the
context state there, so the tag data still points to a real context. As
a result we can stop trying so hard to detach the client from contexts
at disconnect time and just let resource destruction handle it.
Since vnd handles all the MakeCurrent protocol now, our request handlers
for it can just be return BadImplementation. We also remove a bunch of
LEGAL_NEW_RESOURCE, because now by the time we're called vnd has already
allocated its tracking resource on that XID.
v2: Update to match v2 of the vnd import, and remove more redundant work
like request length checks.
v3: Add/remove the XID map from the vendor private thunk, not the
backend. (Kyle Brenneman)
v4: Fix deletion of ghost contexts (Kyle Brenneman)
Signed-off-by: Adam Jackson <ajax@redhat.com>
DoConfigure() attempts to call the PreInit handler on a device without
checking that the handler exists.
Check that the PreInit handler exists for a device before attempting to
call it.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When the dev2screen is sized to xf86NumDrivers in DoConfigure(),
subsequent code may attempt to write past the end of the array.
Size the dev2screen array to nDevToConfig instead.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Commits b5dffbb and d75ffcd introduce code in xf86platformProbe() that
references a member of xf86configptr. However, when using the
"-configure" option, xf86configptr may not be initialized when
xf86platformProbe() is called.
Avoid referencing a member of xf86configptr if uninitialized.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100405
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
dri2.c:516:21: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if (front->name < 0)
Prevents a failure from being ignored.
xf86pciBus.c:1464:21: warning: comparison of constant 256 with expression of type 'uint8_t' (aka 'unsigned char') is always true [-Wtautological-constant-out-of-range-compare]
if (pVideo->bus < 256)
The code used to be in xf86FormatPciBusNumber and compared parameter which was int, but since b967bf2a it was inlined now it works with uint8_t.
xf86PruneDuplicateModes is passed a linked list of modes, and after
pruning the duplicate nodes, the new head of the list is returned. If
the first element is removed, the head of the list will change and the
returned value needs to be assigned.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103722
Thanks: John Lumby <johnlumby@hotmail.com>
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The only way to get at xf86Info.disableRandR from configuration is
Option "RANDR" "foo" in ServerFlags, which probably nobody is using
seeing as it's not documented. The other way it could be set is if a
screen supports RANDR 1.2, in which case we set it to avoid trying to
use the RANDR 1.1 compat code. If the second screen is not 1.2-aware
then this would mean we don't do RANDR setup on the second screen at
all, which would almost certainly crash the first time you try to do
RANDR operations on the second screen.
Fix that all by deletion, and just check whether the screen already has
RANDR initialized before installing the stub support. If you want to
disable RANDR, use the Extensions section of xorg.conf instead.
v2: Also remove a now entirely pointless log message, telling you to
ignore a line we will no longer print.
v3: Explain the fallback path in InitOutput. (Keith Packard)
v4: Check whether the RANDR private key is initialized before trying to
use it to look up the screen private.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tsk. This broke vesa for me, the rrGetScrPriv in InitOutput will crash
if randr's screen private key hasn't been initialized yet. That seems
dumb, but let's not leave it broken.
This reverts commit c08d7c1cdd.
The only way to get at xf86Info.disableRandR from configuration is
Option "RANDR" "foo" in ServerFlags, which probably nobody is using
seeing as it's not documented. The other way it could be set is if a
screen supports RANDR 1.2, in which case we set it to avoid trying to
use the RANDR 1.1 compat code. If the second screen is not 1.2-aware
then this would mean we don't do RANDR setup on the second screen at
all, which would almost certainly crash the first time you try to do
RANDR operations on the second screen.
Fix that all by deletion, and just check whether the screen already has
RANDR initialized before installing the stub support. If you want to
disable RANDR, use the Extensions section of xorg.conf instead.
v2: Also remove a now entirely pointless log message, telling you to
ignore a line we will no longer print.
v3: Explain the fallback path in InitOutput. (Keith Packard)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Fixes double-free later in xf86XvMCCloseScreen, which would generally
cause fireworks.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
This really just wants to be the list of disable booleans and
initialization functions, and nothing else. Stop including the protocol
headers from extinit.h, remove a stray mention of xgl, and move an
XInput declaration to a better place.
v2: A bunch of drivers assume they'll get the DPMS tokens implicitly,
so add it to globals.h.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This makes sure the CRTC's cursor is hidden before we hand the CRTC
over to some other application.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We were updating the link-status property when a uevent came in, but
we also want to update the non-desktop property, and potentially
others as well. We also want to check at detect time in case we don't
get a hotplug event.
This patch updates every property provided by the kernel, sending
changes to DIX so it can track things as well.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
drmCrtcGetSequence returns the current vblank sequence and time.
drmCrtcQueueSequence queues an event for delivery at a specified
vblank sequence.
Use these (when available) in preference to drmWaitVBlank.
v2: Remove FIRST_PIXEL_OUT_FLAG. This has been removed from the kernel
API.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When the call to queue a vblank event fails, we need to clean up by
removing the user-space queue entry. That is indexed by the local
sequence number, not by the kernel vblank count. The call in this
case was just passing the wrong value.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
With -Wformat-nonliteral and a debug build you'd get yelled at here:
../hw/xfree86/x86emu/x86emu/debug.h:188:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
To fix this, rewrite the printf code to actually use varargs and the
appropriate format attribute. All callers of DECODE_PRINTF() pass a
string with no % specifiers, so we pass that as the argument to
printf("%s"). For DECODE_PRINTF2() we just pass the args through.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Avoid adding a "standard" mode timing if we've already got a matching
detailed timing. To help with that, parse CEA blocks for detailed
timings before doing standard or established timings.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Fix meson_option.txt to align with the check of the int10 option against
'disabled', not 'false' in hw/xfree/meson.build, to see if it shouldn't be
built at all.
This keeps everything consistent that 'false' always turns things off.
Not noticed before as options weren't validated against choices until meson
0.43
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
The install rule of Xorg.wrap is currently a dependency of the
install-data target instead of the install-exec target. The build also
uses install-exec-hook to change the ownership and set the SUID bit on
the Xorg.wrap binary. The problem is that install-exec-hook is only
ordered respective to the install-exec target, the rules of install-data
may or may not have been executed.
If install-exec-hook runs before the Xorg.wrap binary is in place,
a message similar to the following will be present in the build log:
chown: cannot access '/pkgdir/usr/lib/xorg-server/Xorg.wrap': No such file or directory
make[6]: [Makefile:1151: install-exec-hook] Error 1 (ignored)
All that needs to be done is to change the name of the program variable
to contain 'exec' for the install rule to depend on the install-exec
target.
Excerpt from the Automake manual, chapter 12.2 The Two Parts of Install:
"Any variable using a user-defined directory prefix with ‘exec’ in the
name (e.g., myexecbin_PROGRAMS) is installed by install-exec. All other
user-defined prefixes are installed by install-data."
https://bugs.freedesktop.org/show_bug.cgi?id=104419
Signed-off-by: Lukáš Krejčí <lskrejci@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The "done" label restores crtc-> {x,y,rotation,mode}, frees output_id.
Doing the calloc() before writing to those values frees us from
necessity to restore them if calloc fails, and allows to merge
"if (mode)" block.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This no longer does anything useful.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The only consumer of this is the Linux vm86 backend for int10 (which you
should not use), and there all it serves to do is make signals generated
by the vm86 task non-fatal. In practice this error appears never to
happen, and marching ahead with root privileges after arbitrary code has
raised a signal seems like a poor plan.
Remove the usage in the vm86 code, making this error fatal.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This was added in ~2004 for the sis driver, to detect whether it could
use SSE for memcpy. Charmingly, the code to check whether that feature
exists in the server is:
#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(6,8,99,13,0)
#define SISCHECKOSSSE /* Automatic check OS for SSE; requires SigIll facility */
#endif
Which means it has never worked in any modular server release.
A less gross way to do this is to check for SSE support with getauxval()
or /proc/cpuinfo or similar. Since no driver is using the existing
intercept mechanism, drop it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
CMAP_LOAD_EVEN_IF_OFFSCREEN has been encapsulated since the import of
xf86-video-modesetting into the tree.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
If drmModeGetConnector() fails in drmmode_output_detect(), we have to
reset the output_id to -1 too.
Yet another spot leading to a potential NULL dereference when handling
the mode_output member as output_id was != -1. Though, this case should
be very hard to hit.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Add a missing new-line character and make the message more verbose than
"Failed".
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Those warnings are generated, when building without systemd support:
../hw/xfree86/os-support/linux/lnx_platform.c: In function ‘get_drm_info’:
../hw/xfree86/os-support/linux/lnx_platform.c:29:16: warning: variable ‘minor’ set but not used [-Wunused-but-set-variable]
int major, minor, fd;
^~~~~
../hw/xfree86/os-support/linux/lnx_platform.c:29:9: warning: variable ‘major’ set but not used [-Wunused-but-set-variable]
int major, minor, fd;
^~~~~
In this case the functions are macros, which don't use theese arguments.
v2: Add comments, why the warnings appear. Suggested by Emil Velikov
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
The CEA extension short video descriptors contain the VIC, which starts
at 1, not 0.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
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: Adam Jackson <ajax@redhat.com>
If one misconfigures a ZaphodHeads value (more than 20 characters
without a delimiter), we get an overflow of our buffer. Use
xstrtokenize() instead of writing/fixing our own tokenizer.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Change 677c32bc refactored all usages of drmWaitVBlank() into a helper function,
ms_queue_vblank().
ms_queue_vblank() takes in an MS_QUEUE_RELATIVE flag to indicate that the
sequence number is relative rather than absolute, but still treats the actual
sequence number as absolute, passing it through ms_crtc_msc_to_kernel_msc()
unconditionally before calling drmWaitVBlank().
ms_crtc_msc_to_kernel_msc() works by subtracting a vblank offset from the
provided sequence number, which only makes sense for absolute sequence numbers.
In the case of PRIME Sync, drmmode_SharedPixmapPrsentOnVBlank() passes in 1,
which results in a large negative vblank offset. After subtracting, we're left
with a relative sequence number of 100,000+, i.e. wait for 100,000+ vblanks...
In the relative case we want to pass in the sequence number unmodified. Simply
add a check to do this.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Similar to change cba5a10f, xf86ScreenSetCursor() would dereference ScreenPriv
without NULL checking it. If Option "SWCursor" is specified, ScreenPriv == NULL.
Without this fix, it is observed that setting Option "SWCursor" "on" on the
modesetting driver in a PRIME configuration will segfault the server.
It is important to return success rather than failure in the instance that
ScreenPriv == NULL and pCurs == NullCursor, because otherwise xf86SetCursor()
can fall into infinite recursion: xf86SetCursor(pCurs) calls
xf86ScreenSetCursor(pCurs), and if FALSE, calls xf86SetCursor(NullCursor). If
xf86ScreenSetCursor(NullCursor) returns FALSE, it calls
xf86SetCursor(NullCursor) again and this repeats forever.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
No need to lookup the link-status property if we don't have a crtc.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
XF86_PDEV_SERVER_FD is defined since:
commit 5fb641a29b
Author: Hans de Goede <hdegoede@redhat.com>
Date: Mon Jan 13 12:03:46 2014 +0100
hotplug: Extend OdevAttributes for server-managed fd support
ifdef'ing for it is a leftover from the external xf86-video-modesetting.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
../hw/xfree86/drivers/modesetting/driver.c: In function ‘redisplay_dirty’:
../hw/xfree86/drivers/modesetting/driver.c:586:20: warning: unused variable ‘ms’ [-Wunused-variable]
modesettingPtr ms = modesettingPTR(xf86ScreenToScrn(screen));
Move the variable ms into #ifdef GLAMOR_HAS_GBM, where it is used.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Warnings come from the fact that PRIx32 is not used for printing 32 bit
values instead of "%lx", and "%lx" evaluates to a 64 bit long on 64 bit
systems while PRIx32 always evaluates to the right type for the
respective arch.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
fbdevhw is the only file in X's source that actually uses #if DEBUG to
check for debugging instead of #ifdef DEBUG. This is contrary to
everything else that checks the DEBUG macro in the source, so let's make
it consistent and in turn, make our meson files a little simpler.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
For the loadable modules it makes sense to build for PE/COFF targets, link
those loadable modules with the import library for the Xorg executable, so
that symbols provided by the executable can be satisfied at link time (as
required by PE/COFF).
Since this uses the syntax of using the returned build target object from an
executable() with an implib: kwarg to link_with:, introduced in meson 0.42
and a syntax error with older meson, also update the minimum meson version
which we require in project() to that.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
This provides an API wrapper around the kernel interface for queueing
a vblank event, simplifying all of the callers.
v2: Fix missing '|' in computing vbl.request.type
v3: Remove spurious bit of next patch (thanks, Michel Dänzer)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Outputs may have NULL mode_output (connector) pointers if the
connector disappears while the server is running. Skip these when
resetting outputs with BAD link status.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Spotted by Appveyor:
xf86Crtc.c:3281:1: warning: ‘xf86_crtc_box_area’ defined but not used [-Wunused-function]
xf86_crtc_box_area(BoxPtr box)
^~~~~~~~~~~~~~~~~~
xf86Crtc.c:3268:1: warning: ‘x86_crtc_box’ defined but not used [-Wunused-function]
x86_crtc_box(xf86CrtcPtr crtc, BoxPtr crtc_box)
^~~~~~~~~~~~
xf86Crtc.c:3256:1: warning: ‘x86_crtc_box_intersect’ defined but not used [-Wunused-function]
x86_crtc_box_intersect(BoxPtr dest, BoxPtr a, BoxPtr b)
^~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
UDL (usb) devices are blacklisted because of they weird behaviour when
it comes to vblank events. As EVDI uses very similar model of handling
vblanks it should be treated similarly.
When doing a page flip, EVDI does not wait for real vblank, but
simulates it by adding constant delay. It also does not support
DRM_IOCTL_WAIT_VBLANK.
In contrast to UDL, EVDI uses platform devices, thus instead of 'usb' in
path they all have 'platform'.
It is possible to blacklist by 'platform', so without explicitly saying
'evdi', but it might be misleading when it comes to real reason for it.
Signed-off-by: Dawid Kurek <dawid.kurek@displaylink.com>
Makes it easer to follow if 8 is between 7 and 9 ;-)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
By having it as a custom_target with build_always, every "ninja -C
build" would rebuild Xorg for the new date/time, even if the rest of
Xorg didn't change.
We could build the rest of Xorg into a static lib, and regenerate
date/time when the static lib changes and link that into a final Xorg,
but BUILD_DATE/TIME is such a dubious feature (compared to including a
git sha, which is easy with meson) it doesn't seem worth the build
time cost.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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: Adam Jackson <ajax@redhat.com>
There were two bugs here: The comparison function was not stable when
one or more of the drivers being compared is a fallback, and the last
driver in the list would never be moved.
Signed-off-by: Adam Jackson <ajax@redhat.com>
libdrm's busid matching for the legacy three-integer bus string format
simply ignores the domain number, rather than what we were doing here of
packing the domain into the bus number. Whatever, just use the existing
code to build a busid string, since that gets the domain right.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Copied from Mesa with no modifications.
Gives us Coffee Lake and Cannon Lake PCI IDs.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
We had a bug reported with a touchscreen where we could end up
in here with a NULL cursor, so let's not crash the X server.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xf86str.h is parsed into sdksyms unconditionally but the symbol is only
defined when building with PCI support. Move the decl to a header that
sdksyms only parses when building PCI support.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
This symbol is used by some DRI2+ drivers and there's nothing
DRI1-specific about it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
It was attempting to use the <bus>@<domain> format accepted by the BusID
stanza, but the two values were swapped.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
The PCI domain has to be specified like this:
"PCI:<bus>@<domain>:<device>:<function>"
Example before:
(--) PCI:*(0:0:1:0) 1002:130f:1043:85cb [...]
(--) PCI: (0:1:0:0) 1002:6939:1458:229d [...]
after:
(--) PCI:*(0@0:1:0) 1002:130f:1043:85cb [...]
(--) PCI: (1@0:0:0) 1002:6939:1458:229d [...]
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Don't build BSD ossupport when there is no specific support, build stubs
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
The client could have said anything here, and if what they said doesn't
actually name an atom NameForAtom() will return NULL, and strcmp() will
be unhappy about that.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the default behaviour was changed from clone mode to horizontal
extended layout, a boolean ScrnInfoRec member preferClone was introduced
to choose the old default behaviour. Option "PreferCloneMode" allows
setting this preferClone member.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
All that was left here was updating the FBO's size. However, the FBO
size was always set correctly already through
glamor_set_pixmap_texture() from whoever had attached a new BO to the
pixmap.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Commit aa6717ce2 switched xf86WaitForInput from using select(2) to using
poll(2). Before this change, the timeout was interpreted as being in
microseconds; afterwards it is fed directly to xorg_poll which interprets
it as being in milliseconds. This results in the function potentially
blocking 1000x longer than intended. This commit scales down the timeout
argument before passing it to xorg_poll, being careful to ensure the result
is not rounded down due to integer division.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
./hw/xfree86/common/xf86pciBus.c: In function ‘xf86MatchDriverFromFiles’:
../hw/xfree86/common/xf86pciBus.c:1330:52: warning: ‘snprintf’ output may be
truncated before the last format character [-Wformat-truncation=]
snprintf(path_name, sizeof(path_name), "%s/%s", ^~~~~~~
../hw/xfree86/common/xf86pciBus.c:1330:13: note: ‘snprintf’ output between 2
dirent->d_name is 256, so sprintf("%s/%s") into a 256 buffer gives us:
and 257 bytes into a destination of size 256
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The glamor_egl module that the GLAMOR paths are using is only built if
GLAMOR_HAS_GBM is true, and there's no plan for implementing the
module without GBM. Simplify modesetting's code as a result.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Because we can use a shared lib in dlsym() for the symbol loader test,
but we can't use the executable.
v2: Drop a stray ' ' and rebase on 820a4cbe9f, by anholt
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Whatever problem this is trying to fix, we don't care. Just include the
thing and stop worrying about whether _POSIX_SOURCE is defined.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
gcc -std=c99 does not define the former, and it's a horrible namespace
confusion anyway.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add options for DRI{1,2,3}
shmfence is required for DRI3
libdrm is required for any DRI{1,2,3}
Consolidate calls to dependency('libdrm')
Set WITH_LIBDRM when building with libdrm
v2:
Initialize libxserver_dri3 to []
Manually flatten libxserver, since meson doesn't (currently)
Use version_compare rather than circumloctions with dependency()
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Implementation of new drivers matching algorithm. New approach
doesn't add duplicate drivers and ease drivers matching phase.
v2: Re-commit the patch reverted in
2388f5e583, with Aaron Plattner's
fix squashed in (by anholt).
Signed-off-by: Karol Kosik <kkosik@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v1)
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Eric Anholt <eric@anholt.net>
This reverts commit 112d0d7d01.
It broke Xorg for Adam, Peter, and myself, by failing hard when a
module load failed.
Signed-off-by: Eric Anholt <eric@anholt.net>
I clearly hadn't run ninja test, since fb no longer had any of the fb
symbols in it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
glibc would like to stop declaring major()/minor() macros in
<sys/types.h> because that header gets included absolutely everywhere
and unix device major/minor is perhaps usually not what's expected. Fair
enough. If one includes <sys/sysmacros.h> as well then glibc knows we
meant it and doesn't warn, so do that if it exists.
Signed-off-by: Adam Jackson <ajax@redhat.com>
I converted Xorg when meson 0.40 came out, but fumbled my grep and
forgot that I had instances of the .extract_all_objects() workaround
in dixmods, too.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Implementation of new drivers matching algorithm. New approach
doesn't add duplicate drivers and ease drivers matching phase.
Signed-off-by: Karol Kosik <kkosik@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We mostly use #ifdef throughout the tree, and this lets the generated
config.h files just be #define TOKEN instead of #define TOKEN 1.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Without this, assertion failures can make life hard for users and those
trying to help them.
v2:
* Change commit log wording slightly to "can make life hard", since
apparently e.g. logind can alleviate that somewhat.
* Set default handler for SIGABRT in
hw/xfree86/common/xf86Init.c:InstallSignalHandlers() and
hw/xquartz/quartz.c:QuartzInitOutput() (Eric Anholt)
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
The number for it was merged to drm_mode.h in kernel 4.7, and the
output_names[] array just requires that we slot in new strings in
order.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The build defines these, so having the defaults is just a way for the
build system's configuration to get out of sync with the code.
v2: Drop #ifndefs around the other two defines.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
parser/scan.c was checking for #ifdef XCONFIGFILE and XCONFIGDIR and
defaulting to "xorg.conf", and "xorg.conf.d", so if you had changed
__XCONFIGFILE__ to anything else, it would have got out of sync.
Settle on the name without gratuitous underscores.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
E.g. because Xinerama is enabled.
Fixes crash on startup and wrong colours in that case.
Bugzilla: https://bugs.freedesktop.org/100293
Bugzilla: https://bugs.freedesktop.org/100294
Fixes: 62f4405257 ("xfree86/modes: Move gamma initialization to
xf86RandR12Init12 v2")
Tested-by: Mariusz Bialonczyk <manio@skyboo.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Despite all the careful planning of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending connector's
link-status to BAD and send the userspace a hotplug event. This may
happen right after a modeset or later on.
Upon receiving a hot-plug event, we iterate through the connectors to
re-apply the currently-set mode on all the connectors that have a
link-status property set to BAD. The kernel may be able to get the
link to work by dropping to using a lower link bpp (with the same
display bpp). However, the modeset may fail if the kernel has pruned
the mode, so to make users aware of this problem a warning is outputed
in the logs to warn about having a potentially-black display.
This patch does not modify the current behaviour of always propagating
the events to the randr clients. This allows desktop environments to
re-probe the connectors and select a new resolution based on the new
(currated) mode list if a mode disapeared. This behaviour is expected in
order to pass the Display Port compliance tests.
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. modesetting was blindly asserting
it supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
Set the version as 2, which should be bumped only with the appropriate
version checks.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
No driver is using these, as far as I know.
v2: Tripwire the entity hook arguments to xf86Config*Entity, fix
documentation (Eric Anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Most of this is a legacy of the old "extmod" design where you could load
_some_ extensions dynamically but only if the server had been built with
support for them in the first place.
Note that since we now only initialize the DPMS extension if at least
one screen supports it, we no longer need DPMSCapableFlag: if it would
be false, we would never read its value.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Following on from the previous change, this adds a DPMS hook to the
ScreenRec and uses that to infer DPMS support. As a result we can drop
the dpms stub code from Xext.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Rather than setting up a per-screen private, just conditionally
initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
that to determine whether DPMS is supported.
We also move the "turn the screen back on at CloseScreen" logic into the
DPMS extension's (new) reset hook. This would be a behavior change for
the non-xfree86 servers, if any of them had non-stub DPMS support.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The X Server never generates a global config.h, and instead all these
paths are including dix-config.h or xorg-config.h.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Multiple calls to xf86EdidMonitorSet (which can be triggered e.g. by
running xrandr) would potentially keep adding the same modes, causing
the Monitor->Modes list to keep growing larger and using up more memory.
Fix this by calling xf86PruneDuplicateModes after adding the modes
returned by xf86DDCGetModes. This makes sure there's only one instance
of each unique mode in the list.
v2:
* Replace semicolon with {} for empty for loop (Emil Velikov)
* Slightly tweak commit log to avoid minor inaccuracy about what
xf86PruneDuplicateModes does
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99521
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Copied from Mesa with no modifications. Gives us Geminilake PCI IDs.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
There's really no reason to pretend to support this, apps hate it, all
we're doing is giving people a way to injure themselves. It doesn't work
anyway with any Radeon, any NVIDIA chip, or any Intel chip since i810.
Rip out all the logic for handling 24bpp pixmaps and framebuffers, and
silently ignore the old options that would ask for it.
The cirrus alpine driver has been updated to default to 16bpp, and both
it and the i810 driver can now use the 32->24 conversion code in shadow
if they want. All other drivers support 32bpp. Configurations that
explicitly request 24bpp in order to fit in VRAM will be broken now
though.
v2: Fix command line options to silently ignore 24bpp rather than fail
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The linemarkers in the preprocessor output from gcc5 on Cygwin have
canonicalized paths to included files (e.g. xserver/build/../include/misc.h
is canonicalized to xserver/build/include/misc.h). (see gcc svn rev 210264,
which causes the transformation performed by -fcanonical-system-headers to
be applied to all include pathnames)
These canonicalized paths won't match $topdir, so sdksyms doesn't look at
the contents of those headers for sdk exported symbols.
Workaround this by canonicalizing all the paths we consider, using readlink.
v2:
Keep a cache of readlink results so it isn't quite so dreadfully slow.
Reviewed-by: Adam Jackson <ajax@redhat.com>
The code as written would match anything declared extern. _X_EXPORT is
what we really mean here. That's a macro, so check for what it expands
to and skip if not found.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This touches everything that ends up in the Xorg binary; the big missing
part is GLX since that's all generated code. Cuts about 14k from the
binary on amd64.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
First, move them to the end of the struct, for marginally better cache
locality for the struct members that actually have meaning; move the
existing slots at the end of the struct up near some others with similar
meanings. Second, only keep four slots each of integer, data pointer,
and function pointer; we've rarely used this escape hatch so this is
still plenty.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Never set by the core, not used in any modern driver.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Just no.
The ddxDesign chunk removes the whole para about xf86FixPciResource,
since it turns out that function doesn't exist at all anymore.
The only drivers that reference this at all are i128 and mga, and even
then only in the non-pciaccess path.
v2:
- Update commentary about i128/mga
- Don't remove the BiosBase keyword from the config parser since that
would turn a no-op into a fatal error (Aaron Plattner)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Seriously not worth the effort of tracking this, especially now that
competent drivers don't have a limit. The sis driver does inspect this
member, but hilariously does so only so it can print the same information
as the core does.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Only mach64 and rendition actually use this feature. Everyone else just
checks it in their ValidMode hook, they can too.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We don't actually need (or intend) to keep this struct the same across
revisions.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
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: Adam Jackson <ajax@redhat.com>
Signed-off-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: Adam Jackson <ajax@redhat.com>
Signed-off-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: Updated the patch to apply to current git HEAD, split up into two
patches (server and modesetting driver) and adjusted the code slightly
to match surrounding code. I also removed the new exported function
ShowCursorCheck(), as instead just changing ShowCursor() to return Bool
should not affect its current callers.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
xf86RecolorCursor() may be called directly from XRecolorCursor as well
as from xf86ScreenSetCursor(). In the latter case, the input lock is
already held, but not for the former and so we need to add a wrapper
function that acquires the input lock before performing
xf86RecolorCursor()
References: https://bugs.freedesktop.org/show_bug.cgi?id=99358
This can happen when a module fails to load:
Program received signal SIGSEGV, Segmentation fault.
UnloadModule (_mod=0x5555559d9280) at ../../../../hw/xfree86/loader/loadmod.c:848
848 name = mod->VersionInfo->modname;
(gdb) bt
#0 UnloadModule (_mod=0x5555559d9280) at ../../../../hw/xfree86/loader/loadmod.c:848
#1 0x00005555555ddd1b in LoadModule (module=module@entry=0x5555559c7ce0 "fbdev", options=0x0, modreq=modreq@entry=0x0, errmaj=errmaj@entry=0x7fffffffe8ec) at ../../../../hw/xfree86/loader/loadmod.c:824
#2 0x00005555555edfe9 in xf86LoadModules (list=list@entry=0x5555559dcf50, optlist=optlist@entry=0x0) at ../../../../hw/xfree86/common/xf86Init.c:1506
#3 0x00005555555ee7bc in InitOutput (pScreenInfo=pScreenInfo@entry=0x5555559abf80 <screenInfo>, argc=argc@entry=4, argv=argv@entry=0x7fffffffeb18) at ../../../../hw/xfree86/common/xf86Init.c:484
#4 0x00005555555a885c in dix_main (argc=4, argv=0x7fffffffeb18, envp=<optimized out>) at ../../dix/main.c:197
#5 0x00007ffff5d582b1 in __libc_start_main (main=0x555555593130 <main>, argc=4, argv=0x7fffffffeb18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffeb08) at ../csu/libc-start.c:291
#6 0x000055555559316a in _start ()
Fixes: 8e83eacb9e ("loader: Remove unused path and name from ModuleDescPtr")
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
V2:
1. update comment
2. check bustype if PCI
3. configure add libdrm version check for drmGetDevice
Get PCI information from info->fd with drmGetDevice instead of
assuming the info->fd is the first entity of scrn which is not
true for multi entities scrn.
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Just a waste of memory. Path was never referenced at all, and name was
only used when unloading the module; we can just as well get the
module's internal idea of its name from VersionInfo.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Nobody was ever calling this with a non-null argument for subdir list or
pattern list. Having done this, InitSubdirs is only ever called with a
NULL argument, so it's really just a complicated way of duplicating the
default list; we can remove that and just walk the list directly.
The minor error code was only ever used to distinguish among two cases
of LDR_BADUSAGE. Whatever.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Callers only ever use this for a single directory anyway.
While we're at it, also move xf86DriverListFromCompile near its only
user in the X -configure code (and inline it out of existence), and
remove LoaderFreeDirList as it's unused (since X -configure is just
going to exit anyway, none of that code cares about cleanup).
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
There's no reason a driver should ever care about this.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
indent(1) gets confused by function-like macros with no trailing
semicolon, which is fair enough really.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The idea here is that the driver might have once been old enough to not
have the driverFunc slot in DriverRec, with the module ABI not having
changed when it was added. That was ages ago, and drivers always declare
themselves with DriverRec not DriverRec1, so uninitialized slots will
simply be zero.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Everybody using this functionality specifies a major version, which
makes sense. If you don't care about a minor version, that's equivalent
to saying you require minor >= 0, so just say so; likewise patch level.
Likewise ABI class is always specified.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The enum has been unused since at least the removal of elfloader.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This looks like more, but only if you don't compare it to the number
pulled in by misc.h.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This API is dumb. uname(3) exists, feel free to use it, but ideally
write to the interface not to the OS. There are a couple of drivers
using this API, they could all reasonably just not.
This also removes the OS name from the loader subdirectory path search.
Having /usr/lib/xorg shared across OSes is a non-goal here.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Now that users can set the path only via LoaderSetPath(), we can simplify
things.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Afaics the argument hasn't been part of the API since the documentation
has been converted to xml with commit fc6ebe1e1d "Convert LinuxDoc
documents to DocBook/XML"
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Similar to its little brother - LoadSubModule. Currently all call sites
provide NULL anyway ;-)
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The "copying selected object files" message appears as some source
files have the same name, and some objects are included twice.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
Detailed mode reports 108 mm x 68 mm which is for smaller display.
Maximum image size reports 15 cm x 10 cm which aligns with its physical
size, use this size instead.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Allow OutputClass config snippets to modify the module-path.
Note that any specified ModulePaths will be pre-pended to the normal
ModulePath. The idea behind this is that any output hardware specific
modules should have preference over the normal modules.
One use-case for this is the nvidia binary driver, this allows a
config snippet like this:
Section "OutputClass"
MatchDriver "nvidia"
Modulepath "/usr/lib64/nvidia/modules"
EndSection
To get the nvidia glx specific glx module loaded, but only when the
nvidia kernel driver is loaded.
Together with the glvnd work done recently, this allows the nouveau
+ mesa and nvidia-binary userspace stacks to co-exist on the same
system without any ldconfig / xorg.conf tweaking and the xserver will
automatically do the right thing depending on which kernel driver
(nouveau or nvidia) is loaded.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Allow using:
Option "PrimaryGPU" "yes"
In an OutputClass section to override the default primary GPU device
selection which selects the GPU used as output by the firmware.
If multiple output devices match an OutputClass section with
the PrimaryGPU option set, the first one enumerated becomes the
primary GPU.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a preparation patch for allowing an OutputClass section to
override the default primary GPU device selection.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add support for setting options in OutputClass Sections and having these
applied to any matching output devices.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Make OutputClassMatches directly take a xf86_platform_device as argument,
rather then an index into xf86_platform_devices. This makes things
easier for callers which already have a xf86_platform_device pointer.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
xf86MatchDevice returns a dynamically allocated list of GDevPtr-s,
free this when we're done with it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
In InitOutput, if xf86HandleConfigFile returns CONFIG_NOFILE
(which it does if no config file or directory is present), the
autoconfig flag is set, causing xf86AutoConfig to be called
later on.
xf86AutoConfig calls xf86OutputClassDriverList via the
call tree:
xf86AutoConfig =>
listPossibleVideoDrivers =>
xf86PlatformMatchDriver =>
xf86OutputClassDriverList
and xf86OutputClassDriverList attempts to traverse a linked list
that is a member of the XF86ConfigRec struct pointed to by the
global xf86configptr, which is NULL at this point because the
XF86ConfigRec struct is only allocated (by xf86readConfigFile)
AFTER the config file and directory have been successfully
opened; the CONFIG_NOFILE return from xf86HandleConfigFile
occurs BEFORE the call to xf86readConfigFile which allocates
the XF86ConfigRec struct.
Rx: In read.c (for symmetry with xf86freeConfig, which already
appears in this file), add a new function xf86allocateConfig
which tests the value of xf86configptr and, if it's NULL,
allocates the XF86ConfigRec struct and deposits the pointer
in xf86configptr. In xf86Parser.h, add a prototype for the
new xf86allocateConfig function.
Back in read.c, #include "xf86Config.h". In xf86readConfigFile,
change the open-code call to calloc to a call to the new
xf86allocateConfig function.
In xf86AutoConfig.c, add a call to the new xf86allocateConfig function
to the beginning of xf86AutoConfig to make sure the XF86ConfigRec struct
is allocated.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ben Crocker <bcrocker@redhat.com>
If we did not find any non GPU Screens, try again ignoring the notion
of any video devices being the primary device. This fixes Xorg exiting
with a "no screens found" error when using virtio-vga in a
virtual-machine and when using a device driven by simpledrm.
This is a somewhat ugly solution, but it is the best I can come up with
without major surgery to the bus and probe code.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is primarily a preparation patch for fixing the xserver exiting with
a "no screens found" error even though there are supported video cards,
due to the server not recognizing any card as the primary card.
This also fixes the (mostly theoretical) case of a platformBus capable
driver adding a device as GPUscreen before a driver which only supports
the old PCI probe method gets a chance to claim it as a normal screen.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
If foundScreen is TRUE, then all the code below the removed if
will not execute until we reach the return foundScreen; at the
end, so this entire if block is redundant.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Łukasz Spintzyk
Povilas Kanapickas
Zoltán Böszörményi
Daniel Strnad
Lukasz Spintzyk
Mazlan, Hazwan Arif
luporl
Pascal VITOUX
Aaron Plattner
Jacob Cherry
Olivier Fourdan
Julien Cristau
Prabhu Sundararaj
Alan Coopersmith
Kishore Kadiyala
Martin Peres
Michel Dänzer
Uday Kiran Pichika
Ignacio Casal Quinteiro
Alex Goins
Dave Airlie
Jose Maria Casanova Crespo
Martin Weber
Aaron Ma
Matthieu Herrb
Jan Beich
Tobias Stoeckmann
Michael Stapelberg
Yuriy Vasilev
Zoltán Böszörményi
Fabrice Fontaine
Kenneth Graunke
Matt Turner
Adam Jackson
Ville Syrjälä
Keith Packard
Emil Velikov
Sven Joachim
Andres Rodriguez
Maarten Lankhorst
Hans de Goede
Ross Burton
Matt Roper
brian
Jon Turney
Adam Richter
Michael Biebl
Andy Ritger
A. Wilcox
Michel Dänzer
Maya Rashish
Ilia Mirkin
Lyude Paul
Eric Anholt
rpm-build
Michal Srb
Peter Hutterer
Julien Isorce
Jim Qu
Takashi Iwai
Stefan Agner
Michał Górny
Bas Nieuwenhuizen
Roman Gilg
Mario Kleiner
Anuj Phogat
Louis-Francis Ratté-Boulianne
Thomas Klausner
Daniel Stone
Thierry Reding
Tobias Klausmann
Nicolai Hähnle
Rodrigo Vivi
Laurent Carlier
Jeffrey Smith
Rinat Ibragimov
Martin Wilck
Lukáš Krejčí
Konstantin Kharlamov
Daniel Martin
Hector Martin
Nathan Kidd
Nick Sarnie
Dawid Kurek
Jason Gerecke
Frank Binns
Karol Kosik
Michael Thayer
Chris Wilson
Qiang Yu
Emil Velikov
Mihail Konev
Kai-Heng Feng
Ben Crocker