Present calls drmmode_set_mode_major() as part of ms_present_unflip(),
which leads to a crash due to the recursive attempt to force present to
unflip when it already is.
Fix it by simply skipping the forced present unflip when present itself is
unflipping. This also speeds up drmmmode_prepare_modeset() when present
isn't even flipping to begin with.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1791
Fixes: 899c87af1f ("modesetting: unflip before any setcrtc() calls")
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1793>
With this, X servers don't have to parse this option separately,
and can just use it after including dix-config.h
Linux kdrive servers (currently Xfbdev only) now support logging.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
In the `doListFontsAndAliases` function in dixfonts.c, when a font alias
is encountered (`err == FontNameAlias`) as a result of
`list_next_font_or_alias` call, the code allocates memory for
`resolved` variable (`resolvedlen + 1` bytes) for storing target font
name. In this case, if the `malloc(resolvedlen + 1)` call fails,
`resolved` remains NULL.
Later, when check (`else if (err == FontNameAlias)`) is TRUE, the code
uses `memcpy` to copy nullable `resolved` into `tmp_pattern` without
checking if `resolved` is NULL, so there is a potential null ptr
dereference.
This commit replaces `malloc` with `XNFalloc` for allocating memory for
`resolved`. `XNFalloc` will internally check result of `malloc` and stop
program execution if allocation was failed, preventing potential NULL
dereferencing.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2114>
Free nested allocations when initialization fails.
Several code paths returned early on error without releasing
memory owned by embedded structures, leading to leaks.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2125>
the license notice comes from these files:
- dix/registry.c
- Xext/xselinuxint.h
- Xext/xselinux_label.c
- Xext/xselinux_hooks.c
- Xext/xselinux_ext.c
- Xext/xselinux.h
- Xext/xacestr.h
- Xext/xace.h
- Xext/xace.c
while this is not like the standard `Copyright (C)` lines I think it
still belongs to the license, even if just to make it more clearly
separate from the MIT license above
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2098>
This is needed by radeonsi to support multi plane modifier when
using modesetting DDX.
xserver reject any multi plane buffer (in DRI3PixmapFromBuffers)
without the dmabuf_capable debug option. It's OK for single plane
buffer as xserver will fallback to DRI3BufferFromPixmap path.
amdgpu DDX does not expose DRI3PixmapFromBuffers, mesa just use
the single plane path anyway, so amdgpu DDX does not have this
problem.
Reviewed-by: Sultan Alsawaf <sultan@kerneltoast.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2091>
A key type that has no level names is legit. Before this commit,
`XkbCopyKeymap` would make such level inconsistent by setting its
number of levels to 0 while keeping its map entries. It suffices
to clear the names array.
Fixed by copying the level count from the source type.
WARNING: this will trigger an error in `XkbGetNames`, which worked
before this commit only by chance.
This is fixed in the next commit (squashed with this one).
------------------------------------------------------------------
xkb: Fix serialization of key type without level names
Before this commit the count of key type level names was wrongly set
in `XkbGetNames`: for key type without names, it was set to the level
count, while it should be 0:
- `XkbComputeGetNamesReplySize()` does not account key type without
level names;
- `XkbSendNames()` does not write any level entry for key types without
level names.
This causes a mismatch offset while parsing the response and its
processing would ultimately fail.
Fixed by setting the correct level name count: 0 if there is no level
name, else the number of levels.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2082>
Use intel ddx only on pre-gen4 hw, newer ones will fall back to modesetting.
Instead of defaulting to the Intel driver for all Intel hardware, only
default it for older hardware for which it has shown to be better for.
Note that Debian/Fedora and their derivatives, as well as the yocto project
have been carrying this patch for many years:
192254841aee515e44b0
so this simply aligns xserver upstream with Linux distributions.
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Co-authored-by: Balló György <ballogyor@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1887>
When validating the size passed to SetScreenSize, the CRTC mode size
needs to be applied the full CRTC transform, otherwise the check may
bogusly fail.
Do a full transform on the CRTC mode size when checking the
SetScreenSize request size instead of the current code that only
manually handles rotation.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1971>
This fix use after free when a pluggable gpu screen (such as displaylink)
was set as primary screen and unpluged.
gdb backtrace:
```
0 OssigHandler (signo=11, sip=0x7fff2e0a50f0, unused=0x7fff2e0a4fc0) at ../../../../os/osinit.c:138
1 <signal handler called>
2 rrGetscreenResources (client=0x3195160, query=0) at ../../../../randr/rrscreen.c:577
3 0x0000000000562bae in ProcRRGetscreenResourcesCurrent (client=0x3195160) at ../../../../randr/rrscreen.c:652
4 OxOOOOB0000054de63 in ProcRRDispatch (client=0x3195160) at ../../../../randr/randr.c:717
5 0x00000000004322c6 in Dispatch () at ../../../../dix/dispatch.c:485
6 0x0900900990443139 in dix_main (argc=12, argv=0x7fff2e0a5f78, envp=0x7fff2e0a5fe0) at ../../../../dix/main.c:276
7 0X0000000000421d9a in main (argc=12, argv=0x7fff2e0a5f78, envp=0x7fff2e0a5fe0) at ../../../../dix/stubmain.c:34
```
Signed-off-by: hongao <hongao@uniontech.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1553>
The previous change is not enough, as WM_KILLFOCUS can apparently be
sent to the window losing focus after WM_ACTIVATE has been sent to
the window gaining focus.
Try using WM_SETFOCUS instead, as that has the correct ordering and seems
more logical.
The test "!pWin || !pWin->overrideRedirect" is confusingly written: It's
true if:
(a) pWin is NULL (= X window doesn't exist, shouldn't happen), or
(b) pWin->overrideRedirect is FALSE
i.e. the intended effect is "don't give focus to override redirect windows"
There seem to be some cases where this still isn't quite correct: A
reproduction isn't known, but it seems to be related to minimizing a
maximized Windows window, and having window activation move to a
maximized X window beneath it.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/736>
In the multiwindow WM, we need to cancel the X input focus if the
Windows input focus has gone to the desktop, or another application's
window.
We could maybe avoid some unneeded work by not doing this if the
WM_KILLFOCUS wParam is another window owned by us, which is immediately
going to be given the X input focus.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/736>
Use the new xorg-sdk build type instead of building a complete Xserver,
to compile our drivers against.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header isn't actually included by any drivers (not even the sun* ones),
neither does it have any _X_EXPORT'ed symbols, nor structs that a driver
could use. Not relevant at all for proprietary Nvidia drivers, because their
cards never worked on Sbus.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The practical use case is just installing Xorg SDK headers for driver build,
but not having to actually compile anything.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's always present (and wont go away), so no need to ifdef on it.
Still keeping the symbols, until we're sure no drivers still depending
on it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
