-
0ed7b122
by nerdopolis
at 2021-11-23T13:01:55-08:00
xfree86: On Linux, while only seat0 can have TTYs, don't assmume all seat0s have TTYs
(cherry picked from commit b8c12aac651d626c5120e6e8e18b42e7528caf43)
-
6834f977
by Jocelyn Falempe
at 2021-12-03T00:46:11+00:00
xf86/logind: fix call systemd_logind_vtenter after receiving drm device resume
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 f5bd039633fa8360a10bd2aabb0111571f6275b0)
-
8eb1396d
by Jocelyn Falempe
at 2021-12-03T00:46:11+00:00
xf86/logind: Fix drm_drop_master before vt_reldisp
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 da9d012a9c760896941769d4127e3cfb1a7a9f03)
-
6f11b3c8
by Dave Airlie
at 2021-12-03T03:10:06+02:00
dri2: add crocus to the list of va_gl users
(cherry picked from commit a7b0a7fabd137183cc42a5edb15697e354c4450c)
-
49444ce9
by Povilas Kanapickas
at 2021-12-03T03:10:06+02:00
Revert "hw/xfree86: Propagate physical dimensions from DRM connector"
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 05b3c681ea2f478c0cb941c2f8279919cf78de6d.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit 35af1299e73483eaf93d913a960e1d1738bc7de6)
-
2c6989f8
by Peter Hutterer
at 2021-12-04T18:05:29+02:00
xkb: fix XkbSetMap check for the keytypes count
The previous if/else condition resulted in us always setting the key
type count to the current number of key types. Split this up correctly.
Regression introduced in de940e06f8733d87bbb857aef85d830053442cfe
Fixes #1249
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit be16bd8543f80ad2933ec9c37f082617c7084165)
-
101791f8
by Jonathan Gray
at 2021-12-04T18:05:29+02:00
glamor: fix free of uninitialised pointers
Attempting to run fvwm on a x61/965gm with xserver 1.21.1 with the
modesetting driver on OpenBSD/amd64 would cause the xserver to
reliably crash.
I tracked this down to the free() calls introduced in
2906ee5e4a722138cccb3265a615da7705a52589
(d1ca47e1242b51c79cec7287f52c36c8e494706b in branch).
clang also warns about this:
glamor_program.c:296:13: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:290:9: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:288:9: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:277:13: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:296:13: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:290:9: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:288:9: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
glamor_program.c:277:13: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 2906ee5e4 ("glamor: Fix leak in glamor_build_program()")
(cherry picked from commit 5ac6319776b13f96a2b336da4b35237618a5b001)
-
7caf29ca
by Povilas Kanapickas
at 2021-12-04T18:05:29+02:00
meson: Correctly set DDXOSVERRORF and DDXBEFORERESET on xwin
This worked with autotools, but not meson build system.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit 04c93b98e9e4593aa2e6701bb08f5e27c3544d8a)
-
fc2eb7e8
by Matt Turner
at 2021-12-10T00:55:35-05:00
test: #undef NDEBUG so assert is not compiled away
(cherry picked from commit d189102c783653a10931051175de24277a157331)
-
a39218d9
by Matthieu Herrb
at 2021-12-15T10:41:17+02:00
remove the PRE_RELEASE message.
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 4de9666b6d3c86660d728ddfc13d88700e5ff20d)
-
a82d523e
by Povilas Kanapickas
at 2021-12-15T10:41:18+02:00
record: Fix out of bounds access in SwapCreateRegister()
ZDI-CAN-14952, CVE-2021-4011
This vulnerability was discovered and the fix was suggested by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit e56f61c79fc3cee26d83cda0f84ae56d5979f768)
-
6f09e7d3
by Povilas Kanapickas
at 2021-12-15T10:41:19+02:00
xfixes: Fix out of bounds access in *ProcXFixesCreatePointerBarrier()
ZDI-CAN-14950, CVE-2021-4009
This vulnerability was discovered and the fix was suggested by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit b5196750099ae6ae582e1f46bd0a6dad29550e02)
-
7209982d
by Povilas Kanapickas
at 2021-12-15T10:41:20+02:00
Xext: Fix out of bounds access in SProcScreenSaverSuspend()
ZDI-CAN-14951, CVE-2021-4010
This vulnerability was discovered and the fix was suggested by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit 6c4c53010772e3cb4cb8acd54950c8eec9c00d21)
-
0b67785c
by Povilas Kanapickas
at 2021-12-15T10:41:21+02:00
render: Fix out of bounds access in SProcRenderCompositeGlyphs()
ZDI-CAN-14192, CVE-2021-4008
This vulnerability was discovered and the fix was suggested by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit ebce7e2d80e7c80e1dda60f2f0bc886f1106ba60)
-
9fe29910
by Sam James
at 2021-12-15T10:41:22+02:00
hw/xfree86: fix sbus build for SPARC
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 6c1a1fcc4bff90546ebc954f428c6df97005ea50)
-
9852b293
by Povilas Kanapickas
at 2021-12-15T15:46:09+02:00
xserver 21.1.2
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
-
b27eaa72
by nerdopolis
at 2021-12-19T12:44:51+02:00
os: Try to discover the current seat with the XDG_SEAT var first
(cherry picked from commit ca1dfdc9aa4b548de624d3a9af5147a998ba3d79)
-
8223a9d6
by Matthieu Herrb
at 2021-12-19T23:33:28+02:00
Convert more funcs to use InternalEvent.
This fixes a crash when a DeviceEvent struct converted to
InteralEvent was beeing copied as InternalEvent (and thus
causing out of bounds reads) in ActivateGrabNoDelivery()
in events.c: 3876 *grabinfo->sync.event = *real_event;
Possible fix for https://gitlab.freedesktop.org/xorg/xserver/-/issues/1253
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
(cherry picked from commit 5b8817a019845e1066c373022133985a0e2d718f)
-
fec0e250
by Jocelyn Falempe
at 2021-12-20T17:09:17+01:00
xf86/logind: Fix compilation error when built without logind/platform bus
This was introduced by commit 8eb1396d
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1269
Fixes: da9d012a9 - xf86/logind: Fix drm_drop_master before vt_reldisp
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
-
66890ca5
by Jocelyn Falempe
at 2021-12-20T17:09:19+01:00
xf86/logind: fix missing call to vtenter if the platform device is not paused
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 f5bd039633fa83
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>
-
001feb66
by Adam Jackson
at 2022-01-01T14:46:19+02:00
glx/dri: Filter out fbconfigs that don't have a supported pixmap format
For depth 30 in particular it's not uncommon for the DDX to not have
a configured pixmap format. Since the client expects to back both
GLXPixmaps and GLXPbuffers with X Pixmaps, trying to use an x2rgb10
fbconfig would fail along various paths to CreatePixmap. Filter these
fbconfigs out so the client can't ask for something that we know won't
work.
(cherry picked from commit f6c070a1ac05801c52ae60efb7dc4b3142653b7d)
-
85397cc2
by Povilas Kanapickas
at 2022-01-03T00:23:30+02:00
xserver 21.1.3
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>