This allows manual handling of IdleAction and IdleHint rather than automatically
calling the IdleAction every IdleSecs, due to inactivity on the underlying tty.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1194
Signed-off-by: aarondill <aaronsacks2006@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When using TearFree, DRI clients have no way of accurately knowing when
their copied pixmaps appear on the display without utilizing the kernel
driver's notification indicating that the TearFree flip containing their
pixmap is complete. This is because the target CRTC's MSC can change while
the predicted completion MSC is calculated and even while the page flip
IOCTL is sent to the kernel due to scheduling delays and/or unfortunate
timing. Even worse, a page flip isn't actually guaranteed to be finished
after one vblank; it may be several MSCs until a flip actually finishes
depending on delays and load in hardware.
As a result, DRI clients may be off by one or more MSCs when they naively
expect their pixmaps to be visible at MSC+1 with TearFree enabled. This,
for example, makes it impossible for DRI clients to achieve precise A/V
synchronization when TearFree is enabled.
This change therefore adds a way for DRI clients to receive a notification
straight from the TearFree flip-done handler to know exactly when their
pixmaps appear on the display. This is done by checking for a NULL pixmap
pointer to modesetting's DRI flip routine, which indicates that the DRI
client has copied its pixmap and wants TearFree to send a notification when
the copied pixmap appears on the display as part of a TearFree flip. The
existing PageFlip scaffolding is reused to achieve this with minimal churn.
The Present extension will be updated in an upcoming change to utilize this
new mechanism for DRI clients' presentations.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Acked-by: Martin Roukala <martin.roukala@mupuf.org>
It is possible for vblank events to run out of order with respect to one
another because the event which was queued to the kernel has the privilege
of running before all other events are handled. This allows kernel-queued
events to run before other, older events which should've run first.
Although this isn't a huge problem now, it will become more problematic
after the next change which ties DRI client notifications to TearFree page
flips. This increases the likelihood of DRI clients erroneously receiving
presentation-completion notifications out of order; i.e., a client could
receive a notification for a newer pixmap it submitted *before* receiving a
notification for an older pixmap.
Ensure vblank events always run in sequential order by removing the bias
towards kernel-queued events, and therefore forcing them to run at their
sequential position in the queue like other events.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
There is more than one place with the confusing TearFree state check for a
CRTC. Instead of open-coding the TearFree check everywhere, introduce a
helper, ms_tearfree_is_active_on_crtc, to cover the TearFree state checks.
Suggested-by: Martin Roukala <martin.roukala@mupuf.org>
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
Check that the VT is owned and that the CRTC is on before exporting info to
Present stating that TearFree is available. Also, since `trf->buf[0].px` is
checked, the `ms->drmmode.tearfree_enable` check is redundant and can
therefore be removed.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
The event allocation for ms_do_pageflip is leaked on error because callers
of ms_do_pageflip have no way of knowing whether or not a page flip
succeeded for any CRTCs. If a page flip succeeded for at least one CRTC,
then it's not safe for the caller to free the event allocation, and the
allocation won't be leaked. The event allocation is only leaked when not a
single CRTC's page flip succeeded.
Since all callers of ms_do_pageflip allocate the event pointer, and all of
them intentionally leak the event allocation when ms_do_pageflip returns an
error, just free the event pointer inside ms_do_pageflip when a page flip
doesn't succeed for any CRTC.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
The CRTC pointer will soon be needed in the TearFree flip handlers, so pass
it in instead of passing in drmmode_tearfree_ptr.
No functional change.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
Rather than passing the reference CRTC's vblank pipe to ms_do_pageflip,
just pass the pointer to the reference CRTC directly instead. This is
clearer and more useful than the vblank pipe, since the vblank pipe is only
used to identify whether or not a given CRTC is the reference CRTC.
No functional change.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
This #ifdef is redundant since ms_do_pageflip is already enclosed within a
larger GLAMOR_HAS_GBM #ifdef.
No functional change.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
This moves lnx_platform.c to the shared directory and adds it to
the BSD build. This is needed for PRIME render offload.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Make sure info->active and info->vt_active are false after
dropping drm master.
Normally, this is done when pausing the first input device, so it
breaks when there are no input device at all.
Fixes: da9d012a9 ("xf86/logind: Fix drm_drop_master before vt_reldisp")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1387
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
The X server swapping code is a huge attack surface, much of this code
is untested and prone to security issues. The use-case of byte-swapped
clients is very niche, so let's disable this by default and allow it
only when the respective config option or commandline flag is given.
For Xorg, this adds the ServerFlag "AllowByteSwappedClients" "on".
For all DDX, this adds the commandline options +byteswappedclients and
-byteswappedclients to enable or disable, respectively.
Fixes#1201https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit 5145742fb6 accidentally bumped the videodrv ABI version from 26.0
to 26.6 in one go.
Change it back to 26.1 as per the documented process for minor additions.
Fixes: 5145742fb6 - randr: introduce rrCrtcGetInfo DDX function
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This allows rrCrtcGetInfo to override the values in the XRRCrtcGetInfo
reply. One use case is to allow Xwayland to return the current emulated
mode for the specific client instead of the global mode.
Signed-off-by: Minh Phan <phanquangminh217@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
If atomic modesetting is to be enabled in the configuration file, log
whether this is supported and eventually enabled or disabled.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
The modesetting driver has atomic modesetting disabled by default but
can be enabled (if supported) using a configuration option.
Add this option in the man page.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Martin Roukala <martin.roukala@mupuf.org>
This adds support for TearFree page flips to eliminate tearing without the
use of a compositor. It allocates two shadow buffers for each CRTC, a back
buffer and a front buffer, and uses damage tracking to minimize excessive
copying between buffers and skip unnecessary flips when the screen's
contents remain unchanged. It works on transformed screens too, such as
rotated and scaled CRTCs.
When PageFlip is enabled, TearFree won't force fullscreen DRI clients to
synchronize their page flips to the vblank interval.
TearFree is disabled by default.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
The DRM event queue in the kernel is quite small and can be easily
exhausted by DRI clients. When the event queue is full, that means nothing
can be queued onto it anymore, which can lead to incorrect presentation
times for DRI clients and failure when attempting to queue a page flip.
To make matters worse, once an event is placed onto the kernel's event
queue, there's no straightforward way to prematurely remove it from the
kernel's event queue in userspace, which means that aborting a sequence
number doesn't free up space in the event queue.
Since vblank events from DRI clients are the largest consumers of the
event queue, and since it's often easy to know the desired target MSC of
their vblank events without querying the kernel for a CRTC's current MSC,
we can coalesce vblank events occurring at the same MSC such that only one
of them is placed onto the kernel's event queue, instead of allowing
duplicate vblank events to pollute the event queue.
This is achieved by tracking the next kernel-queued event's MSC on a
per-CRTC basis and then running all of that CRTC's vblank event handlers
which have reached their target MSC when the queued MSC is signaled.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
do_queue_flip_on_crtc() is about to be used to flip buffers other than the
primary scanout (`ms->drmmode.fb_id`), so make it generic to accept any
frame buffer ID, as well as x and y coordinates in the frame buffer, to
flip on a given CRTC. Move the retry logic from queue_flip_on_crtc() into
it as well, so that it's robust for all callers.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Shadow buffers are about to be used for TearFree, so make the shadow buffer
helpers generic such that they can be used to create arbitrary per-CRTC
shadows aside from just the per-CRTC rotated buffer.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
xf86RotateCrtcRedisplay() is about to be used outside of xf86Rotate.c in
order to copy transformed pixmaps, so fix up its interface by specifying
the source drawable and destination pixmap rather than assuming the root
drawable and rotated pixmap, respectively. In addition, add an argument to
make xf86RotateCrtcRedisplay() not perform any transformations, which is an
indicator that it should only copy a transformed pixmap rather than
actually transform a pixmap.
These changes make it possible to use xf86RotateCrtcRedisplay() to not
only copy transformed pixmaps, but also actually transform pixmaps, making
it very useful outside of xf86Rotate.c.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
The current X server infrastructure sets modesetting driver as default driver
to handle PCI-hotplug of a GPU device. This prevents the respective DDX driver
(like AMDGPU DDX driver) to take control of the card.
This patch:
- Adds a few functions and fine-tunes the GPU hotplug infrastructure to allow
the DDX driver to be loaded, if it is configured in the X config file
options as "hotplug-driver".
- Scans and updates the PCI device list before adding the new GPU device
in platform, so that the association of the platform device and PCI device
is in place (dev->pdev).
- Adds documentation of this new option
An example usage in the config file would look like:
Section "OutputClass"
Identifier "AMDgpu"
MatchDriver "amdgpu"
Driver "amdgpu"
HotplugDriver "amdgpu"
EndSection
V2:
Fixed typo in commit message (Martin)
Added R-B from Adam.
Added ACK from Alex and Martin.
V3:
Added an output class based approach for finding the DDX driver (Aaron)
Rebase
V4:
Addressed review comment from Aaron:
GPU hot-plug handling driver's name to be read from the DDX config file options.
In this way only the DDX drivers interested in handling GPU hot-plug will be
picked and loaded, for others modesetting driver will be used as usual.
V5:
Addressed review comments from Aaron:
- X config option to be listed in CamelCase.
- Indentation fix at one place.
- Code readability related optimization.
V6:
Addressed review comments from Aaron:
- Squash the doc in the same patch
- Doc formatting changes
Cc: Alex Deucher <alexander.deucher@amd.com>
Suggested-by: Aaron Plattner aplattner@nvidia.com (v3)
Acked-by: Martin Roukala martin.roukala@mupuf.org(v1)
Acked-by: Alex Deucher alexander.deucher@amd.com (v1)
Reviewed-by: Adam Jackson ajax@redhat.com(v1)
Signed-off-by: Shashank Sharma shashank.sharma@amd.com
Current error:
ld: error: undefined symbol: xf86EnableIO
>>> referenced by xf86Configure.c
>>> libxorg_common.a.p/xf86Configure.c.o:(DoConfigure) in archive hw/xfree86/common/libxorg_common.a
>>> referenced by xf86Events.c
>>> libxorg_common.a.p/xf86Events.c.o:(xf86VTEnter) in archive hw/xfree86/common/libxorg_common.a
>>> referenced by xf86Init.c
>>> libxorg_common.a.p/xf86Init.c.o:(InitOutput) in archive hw/xfree86/common/libxorg_common.a
>>> referenced 1 more times
Changes check for trying modesetting driver from if defined(__linux__)
to use meson check for if we built the driver for this platform.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
I wanted to simplify the logic, and thought this is a good opportunity
to eliminate local diffs.
I don't want to list OSes without wsfb, because I understand that is a
netbsd/openbsd driver, and always have it as a fallback for us.
Additionally, I understand "fbdev" is linux-specific, so have the logic
match this intent.
../hw/xfree86/ddc/print_edid.c:511:20: error: format specifies type 'unsigned short' but the argument has type 'int' [-Werror,-Wformat]
det_mon->type - DS_VENDOR);
^~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Finishes the work started in commit cd0d4c1bb5
to remove checks for the variable that never varied from 0 after the code
to change it was removed by commit 511c60bc73
in 2006 (xorg-server-1.2.0).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Fixes LGTM warning "This parameter of type drmModeModeInfo is 68 bytes -
consider passing a const pointer/reference instead."
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Correctness is ensured be checking md5sum result before and after the
commit (it's the same).
Fixes LGTM warning "Comparison is always false because numTimings <= 0."
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Makes the 4-byte cases match those for 1- & 2-byte handling,
moving the break from being unconditionally hit the first time
through the to loop to after the loop is done.
Fixes Solaris Studio compiler warnings:
"prim_ops.c", line 2626: warning: end-of-loop code not reached
"prim_ops.c", line 2692: warning: end-of-loop code not reached
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
switch_to() is only used from #ifdef HAS_USL_VTS code, place it inside
ifdefs to to avoid unused static warning and compile error on systems
without VT_ACTIVATE and VT_WAITACTIVE defines.
This fixes address sanitizer errors when running unit tests. The
additional copying may reduce performance by a small amount, but we
don't care about that because this driver is used for testing only.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Put in a workaround to accept devices of the kernel's hyperv_drm
driver. Makes Xorg work on HyperV Gen 1/2 with the DRM graphics
stack.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
If there is one platform device, which is not paused nor resumed,
systemd_logind_vtenter() will never get called.
This break suspend/resume, and switching to VT on system with Nvidia
proprietary driver.
This is a regression introduced by f5bd039633
So now call systemd_logind_vtenter() if there are no paused
platform devices.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1271
Fixes: f5bd0396 - xf86/logind: fix call systemd_logind_vtenter after receiving drm device resume
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is minor, but that error message says a wrong function name.
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Initially reported downstream in Gentoo. Manifests with errors like:
```
gnu/bin/ld: hw/xfree86/common/libxorg_common.a(xf86fbBus.c.o): in function `xf86ClaimFbSlot':
xf86fbBus.c:(.text+0x20): undefined reference to `sbusSlotClaimed'
/usr/lib/gcc/sparc-unknown-linux-gnu/11.2.0/../../../../sparc-unknown-linux-gnu/bin/ld: xf86fbBus.c:(.text+0x2c): undefined reference to `sbusSlotClaimed'
```
While we use the headers in meson.build, we don't reference xf86sbusBus.c
which defines the missing symbols like sbusSlotClaimed.
Bug: https://bugs.gentoo.org/828513
Signed-off-by: Sam James <sam@gentoo.org>
Add a new interface to _rrScrPriv to make it possible for the server to
delay answering a lease request, at the cost of blocking the client. This
is needed for implementing drm-lease-v1, as the Wayland protocol has no
defined time table for responding to lease requests.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
This was overlooked when converting the function to use libxcvt.
Bring back name initialization from old code.
This was causing a segfault in xf86LookupMode() if modes where
name is NULL are present the modePool list.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
When switching to VT, the ioctl DRM_DROP_MASTER must be done before
the ioctl VT_RELDISP. Otherwise the kernel can't change the modesetting
reliably, and this leads to the console not showing up in some cases, like
after unplugging a docking station with a DP or HDMI monitor.
Before doing the VT_RELDISP, send a dbus message to logind, to
pause the drm device, so logind will do the ioctl DRM_DROP_MASTER.
With this patch, it changes the order logind will send the resume
event, and drm will be sent last instead of first.
so there is a also fix to call systemd_logind_vtenter() at the right time.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
logind send the resume event for input devices and drm device,
in any order. if we call vt_enter before logind resume the drm device,
it leads to a driver error, because logind has not done the
DRM_IOCTL_SET_MASTER on it.
Keep the old workaround to make sure we call systemd_logind_vtenter at
least once if there are no platform device
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Quite a lot of applications currently expect the screen DPI exposed by
the X server to be 96 even when the real display DPI is different.
Additionally, currently Xwayland completely ignores any hardware
information and sets the DPI to 96. Accordingly the new behavior, even
if it fixes a bug, should not be enabled automatically to all users.
A better solution would be to make the default DPI stay as is and enable
the correct behavior with a command line option (maybe -dpi auto, or
similar). For now let's just revert the bug fix.
This reverts commit 05b3c681ea.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
SimpleDRM 'devices' are a fallback device, and do not have a busid
so they are getting skipped. This will allow simpledrm to work
with the modesetting driver
The "sync crtc" is the crtc used to drive the display timing of a
drawable under DRI2 and DRI3/Present. If a drawable intersects
multiple video outputs, then normally the crtc is chosen which has
the largest intersection area with the drawable.
If multiple outputs / crtc's have exacty the same intersection
area then the crtc chosen was simply the first one with maximum
intersection. Iow. the choice was random, depending on plugging
order of displays.
This adds the ability to choose a preferred output in such a tie
situation. The RandR output marked as "primary output" is chosen
on such a tie.
This new behaviour and its implementation is consistent with other
video ddx drivers. See amdgpu-ddx, ati-ddx and nouveau-ddx for
reference. This commit is a straightforward port from amdgpu-ddx.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
In a setup with both VRR capable and non-VRR capable displays,
it was so far inconsistent if the driver would allow use of
VRR support or not, as "is_connector_vrr_capable" was set to
whatever the capabilities of the last added drm output were.
Iow. the plugging order of monitors determined the outcome.
Fix this: Now if at least one display is VRR capable, the driver
will treat an X-Screen as capable for VRR, plugging order no
longer matters.
Tested with a dual-display setup with one VRR monitor and one
non-VRR monitor. This is also beneficial with the new Option
"AsyncFlipSecondaries".
When we are at it, also add some so far missing description of
the "VariableRefresh" driver option, copied from amdgpu-ddx.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
A lut size of 4096 slots has been verified to work correctly,
as tested with amdgpu-kms. Intel Tigerlake Gen12 hw has a very
large GAMMA_LUT size of 262145 slots, but also issues with its
current GAMMA_LUT implementation, as of Linux 5.14.
Therefore we keep GAMMA_LUT off for large lut's. This currently
excludes Intel Icelake, Tigerlake and later.
This can be overriden via the "UseGammaLUT" boolean xorg.conf option
to force use of GAMMA_LUT on or off.
See following link for the Tigerlake situation:
https://gitlab.freedesktop.org/drm/intel/-/issues/3916#note_1085315
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
This reverts commit 617f591fc4.
The problem described in that commit exists, but the two
preceeding commits with improvements to the servers RandR
code should avoid the mentioned problems while allowing the
use of GAMMA_LUT's instead of legacy gamma lut.
Use of legacy gamma lut's is not a good fix, because it will reduce
color output precision of gpu's with more than 1024 GAMMA_LUT
slots, e.g., AMD, ARM MALI and KOMEDA with 4096 slot luts,
and some Mediathek parts with 512 slot luts. On KOMEDA, legacy
lut's are completely unsupported by the kms driver, so gamma
correction gets disabled.
The situation is especially bad on Intel Icelake and later:
Use of legacy gamma tables will cause the kms driver to switch
to hardware legacy lut's with 256 slots, 8 bit wide, without
interpolation. This way color output precision is restricted to
8 bpc and any deep color / HDR output (10 bpc, fp16, fixed point 16)
becomes impossible. The latest Intel gen gpu's would have worse
color precision than parts which are more than 10 years old.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
The assumption in the upsampling code was that the crtc->gamma_size
size of the crtc's gamma table is a power of two. This is true for
almost all current driver + gpu combos at least on Linux, with typical
sizes of 256, 512, 1024 or 4096 slots.
However, Intel Gen-11 Icelake and later are outliers, as their gamma
table has 2^18 + 1 slots, very big and not a power of two!
Try to make upsampling behave at least reasonable: Replicate the
last gamma value to fill up remaining crtc->gamma_red/green/blue
slots, which would normally stay uninitialized. This is important,
because while the intel display driver does not actually use all
2^18+1 values passed as part of a GAMMA_LUT, it does need the
very last slot, which would not get initialized by the old code.
This should hopefully create reasonable behaviour with Icelake+
but is untested on the actual Intel hw due to lack of suitable
hw.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
If randrp->palette_size is zero, the memcpy() path can read past the
end of the randr_crtc's gammaRed/Green/Blue tables if the hw crtc's
gamma_size is greater than the randr_crtc's gammaSize.
Avoid this by clamping the to-be-copied size to the smaller of both
sizes.
Note that during regular server startup, the memcpy() path is only
taken initially twice, but then a suitable palette is created for
use during a session. Therefore during an actual running X-Session,
the xf86RandR12CrtcComputeGamma() will be used, which makes sure that
data is properly up- or down-sampled for mismatching source and
target crtc gamma sizes.
This should avoid reading past randr_crtc gamma memory for gpu's
with big crtc->gamma_size, e.g., AMD/MALI/KOMEDA 4096 slots, or
Intel Icelake and later with 262145 slots.
Tested against modesetting-ddx and amdgpu-ddx under screen color
depth 24 (8 bpc) and 30 (10 bpc) to make sure that clamping happens
properly.
This is an alternative fix for the one attempted in commit
617f591fc4.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Rotation is broken for all drm drivers not providing hardware rotation
support. Drivers that give direct access to vram and not needing dirty
updates still work but only by accident. The problem is caused by
modesetting not sending the correct fb_id to drmModeDirtyFB() and
passing the damage rects in the rotated state and not as the crtc
expects them. This patch takes care of both problems.
Signed-off-by: Patrik Jakobsson <pjakobsson@suse.de>
The Linux version of xf86EnableIO calls a helper function called hwEnableIO().
Except on Alpha, this function reads /proc/ioports looking for the 'keyboard'
and 'timer' ports, extracts the port ranges, and enables access to them. It does
this by reading 4 bytes from the string for the start port number and 4 bytes
for the last port number, passing those to atoi(). However, it doesn't add a
fifth byte for a NUL terminator, so some implementations of atoi() read past the
end of this string, triggering an AddressSanitizer error:
==1383==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff71fd5b74 at pc 0x7fe1be0de3e0 bp 0x7fff71fd5ae0 sp 0x7fff71fd5288
READ of size 5 at 0x7fff71fd5b74 thread T0
#0 0x7fe1be0de3df in __interceptor_atoi /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:520
#1 0x564971adcc45 in hwEnableIO ../hw/xfree86/os-support/linux/lnx_video.c:138
#2 0x564971adce87 in xf86EnableIO ../hw/xfree86/os-support/linux/lnx_video.c:174
#3 0x5649719f6a30 in InitOutput ../hw/xfree86/common/xf86Init.c:439
#4 0x564971585924 in dix_main ../dix/main.c:190
#5 0x564971b6246e in main ../dix/stubmain.c:34
#6 0x7fe1bdab6b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#7 0x564971490e9d in _start (/home/aaron/git/x/xserver/build.asan/hw/xfree86/Xorg+0xb2e9d)
Address 0x7fff71fd5b74 is located in stack of thread T0 at offset 100 in frame
#0 0x564971adc96a in hwEnableIO ../hw/xfree86/os-support/linux/lnx_video.c:118
This frame has 3 object(s):
[32, 40) 'n' (line 120)
[64, 72) 'buf' (line 122)
[96, 100) 'target' (line 122) <== Memory access at offset 100 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:520 in __interceptor_atoi
Shadow bytes around the buggy address:
0x10006e3f2b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006e3f2b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006e3f2b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006e3f2b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006e3f2b50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10006e3f2b60: 00 00 f1 f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2[04]f3
0x10006e3f2b70: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006e3f2b80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x10006e3f2b90: f1 f1 f8 f2 00 f2 f2 f2 f8 f3 f3 f3 00 00 00 00
0x10006e3f2ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
0x10006e3f2bb0: f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==1383==ABORTING
Fix this by NUL-terminating the string.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1193#note_1053306
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
GAMMA_LUT sizes other than 1024 cause a crash during startup if the memcpy()
calls in xf86RandR12CrtcSetGamma() read past the end of the legacy X11 /
XVidMode gamma ramp.
This is a problem on Intel ICL / GEN11 platforms because they report a GAMMA_LUT
size of 262145. Since it's not clear that the modesetting driver will generate a
proper gamma ramp at that size even if xf86RandR12CrtcSetGamma() is fixed, just
disable use of GAMMA_LUT for sizes other than 1024 for now. This will cause the
modesetting driver to disable the CTM property and fall back to the legacy gamma
LUT.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1193
Tested-by: Mark Herbert
Whenever an unredirected fullscreen window uses pageflipping for a
DRI3/Present PresentPixmap() operation and the X-Screen has more than
one active output, multiple crtc's need to execute pageflips. Only
after the last flip has completed can the PresentPixmap operation
as a whole complete.
If a sync_flip is requested for the present, then the current
implementation will synchronize each pageflip to the vblank of
its associated crtc. This provides tear-free image presentation
across all outputs, but introduces a different artifact, if not
all outputs run at the same refresh rate with perfect synchrony:
The slowest output throttles the presentation rate, and present
completion is delayed to flip completion of the "latest" output
to complete. This means degraded performance, e.g., a dual-display
setup with a 144 Hz monitor and a 60 Hz monitor will always be
throttled to at most 60 fps. It also means non-constant present
rate if refresh cycles drift against each other, creating complex
"beat patterns", tremors, stutters and periodic slowdowns - quite
irritating!
Such a scenario will be especially annoying if one uses multiple
outputs in "mirror mode" aka "clone mode". One output will usually
be the "production output" with the highest quality and fastest
display attached, whereas a secondary mirror output just has a
cheaper display for monitoring attached. Users care about perfect
and perfectly timed tear-free presentation on the "production output",
but cares less about quality on the secondary "mirror output". They
are willing to trade quality on secondary outputs away in exchange
for better presentation timing on the "production output".
One example use case for such production + monitoring displays are
neuroscience / medical science applications where one high quality
display device is used to present visual animations to test subjects
or patients in a fMRI scanner room (production display), whereas
an operator monitors the same visual animations from a control room
on a lower quality display. Presentation timing needs to be perfect,
and animations high-speed and tear-free for the production display,
whereas quality and timing don't matter for the monitoring display.
This commit gives users the option to choose such a trade-off as
opt-in:
It adds a new boolean option "AsyncFlipSecondaries" to the device section
of xorg.conf. If this option is specified as true, then DRI3 pageflip
behaviour changes as follows:
1. The "reference crtc" for a windows PresentPixmap operation does a
vblank synced flip, or a DRM_MODE_PAGE_FLIP_ASYNC non-synchronized
flip, as requested by the caller, just as in the past. Typically
flips will be requested to be vblank synchronized for tear-free
presentation. The "reference crtc" is the one chosen by the caller
to drive presentation timing (as specified by PresentPixmap()'s
"target_msc", "divisor", "remainder" parameters and implemented by
vblank events) and to deliver Present completion timestamps (msc
and ust) extracted from its pageflip completion event.
2. All other crtc's, which also page-flip in a multi-display configuration,
will try to flip with DRM_MODE_PAGE_FLIP_ASYNC, ie. immediately and
not synchronized to vblank. This allows the PresentPixmap operation
to complete with little delay compared to a single-display present,
especially if the different crtc's run at different video refresh
rates or their refresh cycles are not perfectly synchronized, but
drift against each other. The downside is potential tearing artifacts
on all outputs apart from the one of the "reference crtc".
Successfully tested on a AMD gpu with single-display, dual-display and
triple-display setups, and with single-X-Screen as well as dual-X-Screen
"ZaphodHeads" configurations.
Please consider merging this commit for the upcoming server 1.21 branch.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
When using DRI3+Present with PRIME render offload, sometimes there is
a mismatch between the stride of the to-be-presented Pixmap and the
frontbuffer. The current code would reject a pageflip present in this
case if atomic modesetting is not enabled, ie. always, as atomic
modesetting is disabled by default due to brokeness in the current
modesetting-ddx.
Fullscreen presents without page flipping however trigger the copy
path as fallback, which causes not only unreliable presentation timing
and degraded performance, but also massive tearing artifacts due to
rendering to the framebuffer without any hardware sync to vblank.
Tearing is extra awful on modesetting-ddx because glamor afaics seems
to use drawing of a textured triangle strip for the copy implementation,
not a dedicated blitter engine. The rasterization pattern creates extra
awful tearing artifacts.
We can do better: According to a tip from Michel Daenzer (thanks!),
at least atomic modesetting capable kms drivers should be able to
reliably change scanout stride during a pageflip, even if atomic
modesetting is not actually enabled for the modesetting client.
This commit adds detection logic to find out if the underlying kms
driver is atomic_modeset_capable, and if so, it no longer rejects
page flip presents on mismatched stride between new Pixmap and
frontbuffer.
We (ab)use a call to drmSetClientCap(ms->fd, DRM_CLIENT_CAP_ATOMIC, 0);
for this purpose. The call itself has no practical effect, as it
requests disabling atomic mode, although atomic mode is disabled by
default. However, the return value of drmSetClientCap() tells us if the
underlying kms driver is atomic modesetting capable: An atomic driver
will return 0 for success. A legacy non-atomic driver will return a
non-zero error code, either -EINVAL for early atomic Linux versions
4.0 - 4.19 (or for non-atomic Linux 3.x and earlier), or -EOPNOTSUPP
for Linux 4.20 and later.
Testing on a MacBookPro 2017 with Intel Kabylake display server gpu +
AMD Polaris11 as prime renderoffload gpu, X-Server master + Mesa 21.0.3
show improvement from unbearable tearing to perfect, despite a stride
mismatch between display gpu and Pixmap of 11776 Bytes vs. 11520
Bytes. That this is correct behaviour was also confirmed by comparing the
behaviour and .check_flip implementation of the patched modesetting-ddx
against the current intel-ddx SNA Present implementation.
Please consider merging this patch before the server-1.21 branch point.
This patch could also be cherry-picked into the server 1.20 branch to
fix the same limitation.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
A misplaced error check can cause this failure scenario, and does
so reliably as tested on Ubuntu 21.04 with KDE Plasma 5 desktop
within the first few seconds of login session startup, rendering
VRR under modesetting-ddx unusable:
1. Some X11 client application changes some window property.
2. ms_change_property() is called as part of the property change
handling call chain (client->requestVector[X_ChangeProperty]).
It removes itself temporarily from the call chain - or so it
thinks, hooking up saved_change_property instead.
3. ret = saved_change_property(client) is called and fails
temporarily for some non-critical reason.
4. The misplaced error check returns early (error abort), without
first restoring ms_change_property() as initial X_ChangeProperty
handler in the call chain again.
-> Now ms_change_property() has removed itself permanently from the
property handler call chain for the remainder of the X session
and VRR property changes on windows are no longer handled, ie.
VRR no longer gets enabled/disabled in response to window VRR
property changes.
Place the error check at the proper place, just as it is correctly
done by amdgpu-ddx, and in modesetting-ddx ms_delete_property()
function.
Verified to fix VRR handling with an AMD gpu under KDE desktop
session.
Please consider merging before branching the server 1.21 branch.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
The xf86CVTMode() was implemented in a standalone source file because it
was being used for both the xfree86 API and the standalone cvt utility.
Now that the cvt utility is removed (as part of libxcvt) we can move the
small xf86CVTMode() function with the rest of the xf86Modes sources.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1142
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The cvt utility is now replaced by the standalone version found in
libxcvt, no need to build the one in xfree86 anymore.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1142
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Replace the local implementation of the VESA CVT standard timing
modelines generator with the one from libxct to avoid code duplication.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1142
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
If there is an explicit configuration, assign the RandR provider
of the GPUDevice to the screen it was specified for.
If there is no configuration (default case) the screen number is
still 0 so it doesn't change behaviour.
The result is e.g:
# DISPLAY=:0.2 xrandr --listproviders
Providers: number : 2
Provider 0: id: 0xd2 cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 0 name:modesetting
Provider 1: id: 0xfd cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 0 name:Intel
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
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>
Austin Shafer
Peter Grehan
Gleb Popov
Niclas Zeising
Aaron Dill
Sultan Alsawaf
Alan Coopersmith
Austin Shafer
Jocelyn Falempe
Peter Hutterer
Olivier Fourdan
Minh Phan
Jeremy Huddleston Sequoia
Shashank Sharma
pkubaj
coypu@sdf.org
Konstantin Kharlamov
Brian Ruthven
Claes Nästén
Povilas Kanapickas
Thomas Zimmermann
Andrea Monaco
Sam James
Matthieu Herrb
Xaver Hugl
Dave Airlie
nerdopolis
Matthieu Herrb
Jon Turney
nerdopolis
Mario Kleiner
Patrik Jakobsson
Aaron Plattner
Zoltán Böszörményi
Łukasz Spintzyk
Zoltán Böszörményi
Daniel Strnad
Lukasz Spintzyk
Mazlan, Hazwan Arif
luporl
Pascal VITOUX
Jacob Cherry
Julien Cristau
Prabhu Sundararaj
Kishore Kadiyala
Martin Peres
Michel Dänzer
Uday Kiran Pichika
Ignacio Casal Quinteiro
Alex Goins
Jose Maria Casanova Crespo
Martin Weber
Aaron Ma
Jan Beich
Tobias Stoeckmann
Michael Stapelberg
Yuriy Vasilev
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
Adam Richter
Michael Biebl
Andy Ritger
A. Wilcox
Michel Dänzer
Maya Rashish
Ilia Mirkin
Lyude Paul
Eric Anholt
rpm-build
Michal Srb
Julien Isorce
Jim Qu
Takashi Iwai
Stefan Agner
Michał Górny
Bas Nieuwenhuizen
Roman Gilg
Anuj Phogat
Louis-Francis Ratté-Boulianne
Thomas Klausner
Daniel Stone