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 allow users to disable this if they don't
need it, using either a config option or commandline flag.
For Xorg, this adds the ServerFlag "AllowByteSwappedClients" "off".
For all DDX, this adds the commandline options +byteswappedclients and
-byteswappedclients to enable or disable, respectively.
Fixes#1201
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
(cherry picked from commit 412777664a)
(cherry picked from commit af5cd5acc9012e527ee869f8e98bf6c2e9a02ca4)
Backport to server-21.1-branch modified to keep byte-swapping enabled
by default but easy to disable by users or admins (or even by distros
shipping an xorg.conf.d fragment in their packages).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1440>
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>
---
(cherry picked from ed11c4d443)
Reported-by: "Sergiy" <Black_N@ukr.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1319>
Potentially, the pointer to the mode name could be unset, this can
occur with the xf86-video-nv DDX, in that case there isnt much we can do
except check if the next mode is any better.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
---
(cherry picked from db3aa4e03b)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1309>
The cursor in DIX is actually split in two parts, the cursor itself and
the cursor bits, each with their own devPrivates.
The cursor itself includes the cursor bits, meaning that the cursor bits
devPrivates in within structure of the cursor.
Both Xephyr and Xwayland were using the private key for the cursor bits
to store the data for the cursor, and when using XSELINUX which comes
with its own special devPrivates, the data stored in that cursor bits'
devPrivates would interfere with the XSELINUX devPrivates data and the
SELINUX security ID would point to some other unrelated data, causing a
crash in the XSELINUX code when trying to (re)use the security ID.
CVE-2024-0409
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 2ef0f1116c)
After a change for the xserver to automatically determine the seat
based on the XDG_SEAT variable, xephyr stopped working. This was
because of an old feature where xephyr used to handle evdev
directly. This was dropped some time ago, and now this check is
not needed
(cherry picked from commit 4c03b67d33)
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>
(cherry picked from commit 7d2014e7d5)
This brings the change for e1fdc856ae into meson based builds
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit b00cf4aef8)
../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>
(cherry picked from commit 199b8c0853)
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>
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>
(cherry picked from commit 6c1a1fcc4b)
With the new numbering scheme, XORG_VERISON_SNAP doesn't mean
a pre-release version anymore.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
(cherry picked from commit 4de9666b6d)
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>
(cherry picked from commit 35af1299e7)
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>
(cherry picked from commit da9d012a9c)
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>
(cherry picked from commit f5bd039633)
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
(cherry picked from commit b9218fadf3)
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>
(cherry picked from commit 4b75e65766)
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>
(cherry picked from commit 017ce26337)
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>
(cherry picked from commit 66e5a5bb12)
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>
(cherry picked from commit 545fa90cbf)
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>
(cherry picked from commit 7326e131df)
Peter Hutterer
Matthieu Herrb
Yusuf Khan
Olivier Fourdan
nerdopolis
Jeremy Huddleston Sequoia
John D Pell
Povilas Kanapickas
Jocelyn Falempe
Sam James
Dave Airlie
Matthieu Herrb
Jon Turney
nerdopolis
Mario Kleiner