xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2024-01-30T01:34:01Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1611Disabling a master keyboard leads to segfaults2024-01-30T01:34:01ZPeter HuttererDisabling a master keyboard leads to segfaultsFound by @adamdruppe in !1223, copy-pasting from [my comment there](https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1223#note_2211401):
I've confirmed this with Xwayland which at least makes it quite easy to debug. But it d...Found by @adamdruppe in !1223, copy-pasting from [my comment there](https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1223#note_2211401):
I've confirmed this with Xwayland which at least makes it quite easy to debug. But it does open a can of worms. The underlying cause is:
* master devices work in pairs, when you create one the keyboard is paired with the pointer
* when you disable the pointer, it also disables the keyboard
* when you re-enable the pointer it didn't re-enable the keyboard so the pointer wasn't paired with anything.
And much of the code assumes that both master devices are enabled, there are not enough checks for any of the `GetMaster(dev, MASTER_KEYBOARD)` or `GetMaster(dev, MASTER_POINTER)` calls. From a quick review of git grep:
* `xinput disable "foo pointer"` followed by `xinput remove-master "foo pointer"` -> crash in `remove_master()`
* `XIPassiveGrabDevice()` uses that as the modifier device, probably causing crashes during grabbing
* `EnableDevice()` when the XKB state is pushed down
* Looks like screen crossing may crash if the keyboard was enabled but the pointer isn't
* another possible crash in `CheckPassiveGrab`
* possible in `SetInputFocus()`
* if you set the ClientPointer to the new master pointer, pretty much anything that relies on `PickKeyboard()` may now return NULL which is probably untested.
* xkb's `ProcessPointerEvent` seems to have at least one null deref on button release
Those are just the immediate ones I found with a simple git grep, there are likely more hidden ones.
I don't think they can all be fixed, I think a better fix here would be to force-enable the master keyboard when the pointer is enabled, same way as we currently force-disable it when the pointer is disabled.
Reproducer, assuming device 6 is a pointer device (it will be in Xwayland):
```
xinput float 6
xinput create-master "foo"
xinput reattach 6 "foo pointer"
xinput disable "foo pointer" # disables foo keyboard too
xinput enable "foo pointer" # foo keyboard is still disabled
# Now crash with either
xinput reattach 6 "foo pointer"
xinput remove-master "foo pointer"
```https://gitlab.freedesktop.org/xorg/app/xrandr/-/issues/71Screen does not re-dimension following resizing of physical display (in virtu...2023-12-17T17:55:26ZApteryksScreen does not re-dimension following resizing of physical display (in virtual environment)Hi,
Testing with xrandr 1.5.2, the following does *NOT* work to resize the display:
```
$ xrandr --output "Virtual-1" --auto
$ xrandr --output "Virtual-1" --display :0 --auto
$ DISPLAY=:0 xrandr --output "Virtual-1" --auto
$ DISPLAY...Hi,
Testing with xrandr 1.5.2, the following does *NOT* work to resize the display:
```
$ xrandr --output "Virtual-1" --auto
$ xrandr --output "Virtual-1" --display :0 --auto
$ DISPLAY=:0 xrandr --output "Virtual-1" --auto
$ DISPLAY=:0 xrandr --output "Virtual-1" --display :0 --auto
```
What works is this:
```
xrandr -s 0
```
Why is this so? Is there a way to have the above but effected only for an output and a display (--output and --display) ?https://gitlab.freedesktop.org/xorg/xserver/-/issues/1610Random crash [0x558b3b144ed9]2024-02-19T07:33:36ZStephane YRandom crash [0x558b3b144ed9]Xorg crashed and then I arrived on a black screen with a blinking white cursor.
I am using Debian x64 stable (up to date).
The GPU is included into the processor "Intel 13500".
[Xorg.0.log.old](/uploads/f79dc2ad81fd856beed39f85df9e1daf...Xorg crashed and then I arrived on a black screen with a blinking white cursor.
I am using Debian x64 stable (up to date).
The GPU is included into the processor "Intel 13500".
[Xorg.0.log.old](/uploads/f79dc2ad81fd856beed39f85df9e1daf/Xorg.0.log.old)
Hope it helps...https://gitlab.freedesktop.org/xorg/xserver/-/issues/1609RFC: Backport GL ES patches to xserver 21.12024-03-26T13:42:55ZKonstantinRFC: Backport GL ES patches to xserver 21.1@ofourdan @daenzer @whot
What do you think about backporting
!1007, !1158, !1164, !914 (with !1200 included), !1156, !1157 and !1163?
This can leads for functional desktop on Xorg, not only on Xwayland)
If you agree, I will do a PR w...@ofourdan @daenzer @whot
What do you think about backporting
!1007, !1158, !1164, !914 (with !1200 included), !1156, !1157 and !1163?
This can leads for functional desktop on Xorg, not only on Xwayland)
If you agree, I will do a PR with backporting (I have a local branch ready).https://gitlab.freedesktop.org/xorg/xserver/-/issues/1608UBSAN test failures2023-12-14T06:07:48ZSam JamesUBSAN test failuresThere's two batches of failures when building `server-21.1-branch` at commit 15e2409776014b41c77f7da7aeb9520613994d27 with `-fsanitize=undefined`. The errors look the same on master at 0c1a93d319558fe3ab2d94f51d174b4f93810afd though.
Th...There's two batches of failures when building `server-21.1-branch` at commit 15e2409776014b41c77f7da7aeb9520613994d27 with `-fsanitize=undefined`. The errors look the same on master at 0c1a93d319558fe3ab2d94f51d174b4f93810afd though.
The first are function pointer mismatches vs prototypes (https://maskray.me/blog/2022-12-18-control-flow-integrity#fsanitizefunction, needs Clang 17):
```
==================================== 3/6 =====================================
test: xserver / sync
start time: 06:03:51
duration: 0.20s
result: exit status 1
command: MALLOC_PERTURB_=21 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 /home/sam/git/xserver/build/test/simple-xinit test/sync/sync -- hw/vfb/Xvfb
----------------------------------- stderr -----------------------------------
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
../dix/devices.c:1466:5: runtime error: call to function NoopDDA through pointer to incorrect function type 'void (*)(struct _DeviceIntRec *, PtrCtrl *)'
/home/sam/git/xserver/build/../dix/dixutils.c:360:1: note: NoopDDA defined here
#0 0x55d549f30405 in InitPtrFeedbackClassDeviceStruct /home/sam/git/xserver/build/../dix/devices.c:1466:5
#1 0x55d549f2ab04 in CorePointerProc /home/sam/git/xserver/build/../dix/devices.c:670:14
#2 0x55d549f2a494 in ActivateDevice /home/sam/git/xserver/build/../dix/devices.c:573:11
#3 0x55d549f2b6d8 in InitCoreDevices /home/sam/git/xserver/build/../dix/devices.c:718:14
#4 0x55d549f7b654 in dix_main /home/sam/git/xserver/build/../dix/main.c:245:9
#5 0x7f37c6e6024d (/usr/lib64/libc.so.6+0x2424d)
#6 0x7f37c6e60308 in __libc_start_main (/usr/lib64/libc.so.6+0x24308)
#7 0x55d549d8a6c4 in _start (/home/sam/git/xserver/build/hw/vfb/Xvfb+0x6da6c4)
==================================== 4/6 =====================================
test: xserver / request-length
start time: 06:03:51
duration: 0.22s
result: exit status 1
command: MALLOC_PERTURB_=221 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 /home/sam/git/xserver/build/test/simple-xinit test/bigreq/request-length -- hw/vfb/Xvfb
----------------------------------- stderr -----------------------------------
../dix/devices.c:1466:5: runtime error: call to function NoopDDA through pointer to incorrect function type 'void (*)(struct _DeviceIntRec *, PtrCtrl *)'
/home/sam/git/xserver/build/../dix/dixutils.c:360:1: note: NoopDDA defined here
#0 0x56108d132405 in InitPtrFeedbackClassDeviceStruct /home/sam/git/xserver/build/../dix/devices.c:1466:5
#1 0x56108d12cb04 in CorePointerProc /home/sam/git/xserver/build/../dix/devices.c:670:14
#2 0x56108d12c494 in ActivateDevice /home/sam/git/xserver/build/../dix/devices.c:573:11
#3 0x56108d12d6d8 in InitCoreDevices /home/sam/git/xserver/build/../dix/devices.c:718:14
#4 0x56108d17d654 in dix_main /home/sam/git/xserver/build/../dix/main.c:245:9
#5 0x7f605b64a24d (/usr/lib64/libc.so.6+0x2424d)
#6 0x7f605b64a308 in __libc_start_main (/usr/lib64/libc.so.6+0x24308)
#7 0x56108cf8c6c4 in _start (/home/sam/git/xserver/build/hw/vfb/Xvfb+0x6da6c4)
==================================== 5/6 =====================================
test: xserver / damage-primitives
start time: 06:03:51
duration: 0.21s
result: exit status 1
command: ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MALLOC_PERTURB_=248 /home/sam/git/xserver/build/test/simple-xinit test/damage/damage-primitives -- hw/vfb/Xvfb
----------------------------------- stderr -----------------------------------
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
../dix/devices.c:1466:5: runtime error: call to function NoopDDA through pointer to incorrect function type 'void (*)(struct _DeviceIntRec *, PtrCtrl *)'
/home/sam/git/xserver/build/../dix/dixutils.c:360:1: note: NoopDDA defined here
#0 0x55f792018405 in InitPtrFeedbackClassDeviceStruct /home/sam/git/xserver/build/../dix/devices.c:1466:5
#1 0x55f792012b04 in CorePointerProc /home/sam/git/xserver/build/../dix/devices.c:670:14
#2 0x55f792012494 in ActivateDevice /home/sam/git/xserver/build/../dix/devices.c:573:11
#3 0x55f7920136d8 in InitCoreDevices /home/sam/git/xserver/build/../dix/devices.c:718:14
#4 0x55f792063654 in dix_main /home/sam/git/xserver/build/../dix/main.c:245:9
#5 0x7f81c605524d (/usr/lib64/libc.so.6+0x2424d)
#6 0x7f81c6055308 in __libc_start_main (/usr/lib64/libc.so.6+0x24308)
#7 0x55f791e726c4 in _start (/home/sam/git/xserver/build/hw/vfb/Xvfb+0x6da6c4)
```
The second is more straightforward and seems to be also the cause of a test failure (in the same test) when compiling with `-O3`:
```
==================================== 6/6 =====================================
test: xserver / unit
start time: 06:03:51
duration: 0.24s
result: exit status 1
command: ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MALLOC_PERTURB_=150 /home/sam/git/xserver/build/test/tests
[...]
(EE) -1073741824
../test/signal-logging.c:318:15: runtime error: left shift of 1073741824 by 1 places cannot be represented in type 'int'
#0 0x558f4c209c90 in logging_format /home/sam/git/xserver/build/../test/signal-logging.c:318:15
#1 0x558f4c208e57 in signal_logging_test /home/sam/git/xserver/build/../test/signal-logging.c:406:5
#2 0x558f4c20c94b in run_test_in_child /home/sam/git/xserver/build/../test/tests-common.c:31:14
#3 0x558f4c20ca1a in main /home/sam/git/xserver/build/../test/tests.c:15:5
#4 0x7f9b4e56c24d (/usr/lib64/libc.so.6+0x2424d)
#5 0x7f9b4e56c308 in __libc_start_main (/usr/lib64/libc.so.6+0x24308)
#6 0x558f4c1bc6c4 in _start (/home/sam/git/xserver/build/test/tests+0x78a6c4)
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1607UB in miZeroLine referencing one-before-array2024-03-02T04:21:53ZSam JamesUB in miZeroLine referencing one-before-arrayI was building xorg-server with `-fsanitize=undefined` for an unrelated issue when I hit a GCC ICE (reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012).
Anyway, while analysing that, we found that while GCC obviously should...I was building xorg-server with `-fsanitize=undefined` for an unrelated issue when I hit a GCC ICE (reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012).
Anyway, while analysing that, we found that while GCC obviously shouldn't ICE, the code in mizerline.c (miZeroLine) appears wrong and references one _before_ the allocated memory from `xallocarray`.
The reduced version from the GCC bug demonstrates the problem:
```c
typedef __SIZE_TYPE__ size_t;
extern void *reallocarray(void *__ptr, size_t __nmemb, size_t __size)
__attribute__((__alloc_size__(2, 3)));
void miZeroLine(int npt, int Nspans, int list_len, int ady) {
int *pwidthInit, *widths;
pwidthInit = reallocarray(0, (list_len), (sizeof(int)));
widths = pwidthInit - 1;
while (--npt > 0)
{
if (ady + 1 > Nspans)
widths = pwidthInit - 1;
++*widths;
++widths;
}
}
```
At https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/mi/mizerline.c#L100, we have:
```c
void
miZeroLine(DrawablePtr pDraw, GCPtr pGC, int mode, /* Origin or Previous */
int npt, /* number of points */
DDXPointPtr pptInit)
{
/* ... */
pspanInit = xallocarray(list_len, sizeof(DDXPointRec));
pwidthInit = xallocarray(list_len, sizeof(int));
/* ... */
spans = pspanInit - 1;
widths = pwidthInit - 1;
/* ... */
while (length--) {
MI_OUTPUT_POINT(x, y); /* macro when expanded refernces `spans` and `widths`
e += e1;
if (e >= 0) {
y += signdy;
e += e3;
}
x += signdx;
}
/* ... */
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1606Flickering mouse cursor on X11 session2023-12-17T19:59:13ZSam FisherFlickering mouse cursor on X11 sessionPlatform: Raspberry Pi 5
OS: RPIOS (debian derivative) with KDE Plasma on top of it.
Wayland brings a whole lot of issues so i default to X11. However, "unlike RPI 4", on RPI 5, if you boot to an X11 session (instead of wayland), mouse...Platform: Raspberry Pi 5
OS: RPIOS (debian derivative) with KDE Plasma on top of it.
Wayland brings a whole lot of issues so i default to X11. However, "unlike RPI 4", on RPI 5, if you boot to an X11 session (instead of wayland), mouse cursor constantly flickers. And on some occasions it even becomes invisible unless you move the mouse. If i disable kwin compositor (shift+alt F12) the issue goes away. But when the compositor is disabled, screen tearing is introduced.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1605XWayland: provide options to set title and app_id of rootful window2023-12-11T17:04:43ZS. ChauveauXWayland: provide options to set title and app_id of rootful windowUnless I missed something, in the XWayland rootful window, the title and the app_id are hard-coded to `Xwayland on :$DISPLAY` and `org.freedesktop.Xwayland`. This is slightly annoying when using a compositor such as Sway that relies on r...Unless I missed something, in the XWayland rootful window, the title and the app_id are hard-coded to `Xwayland on :$DISPLAY` and `org.freedesktop.Xwayland`. This is slightly annoying when using a compositor such as Sway that relies on rules matching those two properties to control the behavior of new windows (e.g. floating vs tiling, sticky, ...).
Xephyr provides an option `-title` to set the windows title and `-name` to set the `WM_CLASS` (the equivalent of app_id for X11 clients).
Similarly, Xephyr provides a `-resizeable` options when the window geometry is explicitly given with `-screen`. This is the default behavior in XWayland rootful but a `-no-resize` or `-not-resizeable` option would be welcome to prevent resizing.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1604XWayland: rootfull, lost keyboard focus after hiding the cursor2024-03-18T23:37:47ZS. ChauveauXWayland: rootfull, lost keyboard focus after hiding the cursorSway has an option to automatically hide the mouse cursor after a timeout or when typing on the keyboard.
I noticed that when using XWayland in rootfull mode, the underlying X11 client is losing focus every time the mouse becomes hidden....Sway has an option to automatically hide the mouse cursor after a timeout or when typing on the keyboard.
I noticed that when using XWayland in rootfull mode, the underlying X11 client is losing focus every time the mouse becomes hidden.
The mouse must be moved to get the focus back.
Native wayland clients and XWayland clients in rootless mode do not have this behavior. Xephyr (running via Xwayland) is not affected either.
**System information:**
- XWayland 23.2.2-1
- Sway 1.8.1
- Debian Testing (trixie)
**Steps to reproduce:**
- Start Sway or a compositor with the ability to hide the cursor. In Sway, a 5s timeout can be set with
``swaymsg "seat * hide_cursor 5000"``
- Start a terminal in XWayland in rootfull mode
``export DISPLAY=:20 ; Xwayland $DISPLAY -geometry 1200x800 & sleep 1 ; xterm ``
- Move the mouse cursor to give focus to the terminal in the rootfull XWayland window.
- Wait for 5s until the mouse cursor disappears.
- Start typing. Nothing happens.
- Move the mouse to bring the cursor back. The keyboard should be functional again.
Expected behavior: The keyboard should remain functional when the mouse cursor is hidden.https://gitlab.freedesktop.org/xorg/util/imake/-/issues/3Build failure with stricter C compilers (e.g. GCC 14)2024-01-08T18:55:52ZSam JamesBuild failure with stricter C compilers (e.g. GCC 14)Modern C compilers are becoming stricter with a variety of changes over the last year or so.
GCC 14 in particular (to be released in ~April 2024) fails to build imake-1.0.9 like:
```
imake.c: In function ‘doit’:
imake.c:803:29: error: p...Modern C compilers are becoming stricter with a variety of changes over the last year or so.
GCC 14 in particular (to be released in ~April 2024) fails to build imake-1.0.9 like:
```
imake.c: In function ‘doit’:
imake.c:803:29: error: passing argument 2 of ‘execvp’ from incompatible pointer type [-Wincompatible-pointer-types]
803 | execvp(cmd, argv);
| ^~~~
| |
| const char **
In file included from imake.c:172:
/usr/include/unistd.h:599:52: note: expected ‘char * const*’ but argument is of type ‘const char **’
599 | extern int execvp (const char *__file, char *const __argv[])
| ~~~~~~~~~~~~^~~~~~~~
```
This can be emulated with `-Werror=incompatible-pointer-types -Werror=implicit -Werror=int-conversion` on an older GCC or Clang.https://gitlab.freedesktop.org/xorg/lib/libxcb-errors/-/issues/31.0.1: test suite is failing in `contents:: :depth: 2`unit2023-12-12T20:18:08ZTomasz Kłoczko1.0.1: test suite is failing in `contents:: :depth: 2`unit```plaintext
+ cd xcb-util-errors-1.0.1
+ xvfb-run -a /usr/bin/make -O -j48 V=1 VERBOSE=1 check
/usr/bin/make tests/test
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
/usr/bin/gcc -DPACKAGE_NAME=\"xcb...```plaintext
+ cd xcb-util-errors-1.0.1
+ xvfb-run -a /usr/bin/make -O -j48 V=1 VERBOSE=1 check
/usr/bin/make tests/test
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
/usr/bin/gcc -DPACKAGE_NAME=\"xcb-util-errors\" -DPACKAGE_TARNAME=\"xcb-util-errors\" -DPACKAGE_VERSION=\"1.0.1\" -DPACKAGE_STRING=\"xcb-util-errors\ 1.0.1\" -DPACKAGE_BUGREPORT=\"https://gitlab.freedesktop.org/xorg/lib/libxcb-errors/-/issues\" -DPACKAGE_URL=\"\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DSTDC_HEADERS=1 -D_ALL_SOURCE=1 -D_DARWIN_C_SOURCE=1 -D_GNU_SOURCE=1 -D_HPUX_ALT_XOPEN_SOCKET_API=1 -D_NETBSD_SOURCE=1 -D_OPENBSD_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D__STDC_WANT_IEC_60559_ATTRIBS_EXT__=1 -D__STDC_WANT_IEC_60559_BFP_EXT__=1 -D__STDC_WANT_IEC_60559_DFP_EXT__=1 -D__STDC_WANT_IEC_60559_FUNCS_EXT__=1 -D__STDC_WANT_IEC_60559_TYPES_EXT__=1 -D__STDC_WANT_LIB_EXT2__=1 -D__STDC_WANT_MATH_SPEC_FUNCS__=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -DPACKAGE=\"xcb-util-errors\" -DVERSION=\"1.0.1\" -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE_VERSION_MAJOR=1 -DPACKAGE_VERSION_MINOR=0 -DPACKAGE_VERSION_PATCHLEVEL=1 -I. -I./src/ -fno-strict-aliasing -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -c -o tests/test-test.o `test -f 'tests/test.c' || echo './'`tests/test.c
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
/bin/sh ./libtool --tag=CC --mode=link /usr/bin/gcc -fno-strict-aliasing -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -Wl,--gc-sections -Wl,--as-needed -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,--build-id=sha1 -o tests/test tests/test-test.o libxcb-errors.la -lxcb
libtool: link: /usr/bin/gcc -fno-strict-aliasing -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -Wl,--gc-sections -Wl,--as-needed -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,--build-id=sha1 -o tests/.libs/test tests/test-test.o ./.libs/libxcb-errors.so -lxcb
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
/usr/bin/make check-TESTS
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
FAIL: tests/test
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
=============================================
xcb-util-errors 1.0.1: ./test-suite.log
=============================================
# TOTAL: 1
# PASS: 0
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: tests/test
================
For xge event (131, 27): Expected (null), got GesturePinchBegin
For xcb xge wire event 27: Expected (null), got GesturePinchBegin
FAIL tests/test (exit status: 1)
============================================================================
Testsuite summary for xcb-util-errors 1.0.1
============================================================================
# TOTAL: 1
# PASS: 0
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to https://gitlab.freedesktop.org/xorg/lib/libxcb-errors/-/issues
============================================================================
make[2]: *** [Makefile:912: test-suite.log] Error 1
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
make[1]: *** [Makefile:1020: check-TESTS] Error 2
make: *** [Makefile:1234: check-am] Error 2
```https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/202Process blocked in XReply2024-01-16T02:20:29Zzf wProcess blocked in XReplyHere I encountered a problem
The program was blocked in XReply, below was the gdb stack trace
![image.png](/uploads/c53ae7f41d477f06af70ddffb3ee7dd1/image.png)or other case was below
![291e1243f0d9c6eb9a9fc9a67e69d38a.png](/uploads/e3...Here I encountered a problem
The program was blocked in XReply, below was the gdb stack trace
![image.png](/uploads/c53ae7f41d477f06af70ddffb3ee7dd1/image.png)or other case was below
![291e1243f0d9c6eb9a9fc9a67e69d38a.png](/uploads/e3dffdd4dce6ba665e72a7df679f8b1f/291e1243f0d9c6eb9a9fc9a67e69d38a.png)both them was blocked and the program was trapped into white-screen status
I trace the log of x-protol via xtrace, it shows the program send the getinputfocus request twice because of the Xreply think it was an error
![image.png](/uploads/32af2017ef82ee35d211508209af4fcd/image.png)firstly i think it was deadlock, but there is no other thread lock the same addresshttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1603Rootless X server terminates 60 seconds after start2024-02-26T18:26:43ZRoman ŽilkaRootless X server terminates 60 seconds after startAfter a switch from lxdm and running X as `root` to sddm and a rootless X server there is ~10% probability of the server terminating exactly 60 seconds after start. I have to `sleep 60` each time I log in before proceeding with desktop l...After a switch from lxdm and running X as `root` to sddm and a rootless X server there is ~10% probability of the server terminating exactly 60 seconds after start. I have to `sleep 60` each time I log in before proceeding with desktop launch. There is nothing in [Xorg.0.log](/uploads/01ccc9101c0c5ae96e12c9d50a8f4f77/Xorg.0.log) or kernel log. Sometimes I get
```
(WW) AMDGPU(0): flip queue failed: Invalid argument
(WW) AMDGPU(0): Page flip failed: Broken pipe
```
or
```
(WW) AMDGPU(0): flip queue failed: Invalid argument
(WW) AMDGPU(0): Page flip failed: Invalid argument
```
when X is finishing, but the emission of this message isn't correlated with the unexpected exit. On xorg-server 21.1.8 X would terminate ~50% of the time, the update to 21.1.9 significantly reduced the frequency, which leads me to move the issue from xf86-video-amdgpu here.
The DM executes X as `/usr/bin/X -nolisten tcp -background none -seat seat0 -noreset -keeptty -novtswitch -verbose 3 -auth /run/user/1000/xauth_ardJzu -displayfd 13 vt4`. [X-crash-strace](/uploads/35b42984d0345ebb002be3f9165a3041/X-crash-strace) [X-crash-ltrace](/uploads/99c74d5908154ff2704bf66eed6206f0/X-crash-ltrace) of the last few seconds of the process lifetime (21.1.8, no WM running).
RX 6500 XT [lspci-nnvv](/uploads/4825fa45a1dcc333998a23042221a11e/lspci-nnvv), 1x FreeSync LCD over DP. Kernel 6.1.57 custom [config](/uploads/97c970773e41b43877e50ffb3b06878f/config) [dmesg](/uploads/2b6827e0f9f98ef5a1e112c575c917d6/dmesg), x86_64, Gentoo, gcc 13.2.1, xorg-server 21.1.9, xf86-video-amdgpu 23.0.0, linux-firmware 20231030, sddm 0.20.0.https://gitlab.freedesktop.org/xorg/app/xkbutils/-/issues/2Build failure with stricter C compilers (e.g. GCC 14)2024-02-03T20:38:38ZSam JamesBuild failure with stricter C compilers (e.g. GCC 14)Modern C compilers are becoming stricter with a variety of changes over the last year or so.
GCC 14 in particular (to be released in ~April 2024) fails to build xkbutils-1.0.5 like:
```
xkbwatch.c:92:34: error: passing argument 7 of ‘Xt...Modern C compilers are becoming stricter with a variety of changes over the last year or so.
GCC 14 in particular (to be released in ~April 2024) fails to build xkbutils-1.0.5 like:
```
xkbwatch.c:92:34: error: passing argument 7 of ‘XtOpenApplication’ from incompatible pointer type [-Wincompatible-pointer-types]
92 | fallback_resources,
| ^~~~~~~~~~~~~~~~~~
| |
| char **
In file included from xkbwatch.c:31:
/usr/include/X11/Intrinsic.h:1473:5: note: expected ‘const char **’ but argument is of type ‘char **’
1473 | String* /* fallback_resources */,
| ^~~~~~~ ^
```
Originally reported downstream in Gentoo at https://bugs.gentoo.org/919190.
This can be emulated with `-Werror=incompatible-pointer-types -Werror=implicit -Werror=int-conversion` on an older GCC or Clang.https://gitlab.freedesktop.org/xorg/app/xdm/-/issues/15Build failure with stricter C compilers (e.g. GCC 14)2024-03-25T20:14:46ZSam JamesBuild failure with stricter C compilers (e.g. GCC 14)Modern C compilers are becoming stricter with a variety of changes over the last year or so.
GCC 14 in particular (to be released in ~April 2024) fails to build xdm-1.1.14 like:
```
chooser.c: In function ‘RebuildTable’:
chooser.c:280:2...Modern C compilers are becoming stricter with a variety of changes over the last year or so.
GCC 14 in particular (to be released in ~April 2024) fails to build xdm-1.1.14 like:
```
chooser.c: In function ‘RebuildTable’:
chooser.c:280:26: error: passing argument 2 of ‘XawListChange’ from incompatible pointer type [-Wincompatible-pointer-types]
280 | XawListChange (list, newTable, size, 0, TRUE);
| ^~~~~~~~
| |
| char **
In file included from chooser.c:59:
/usr/include/X11/Xaw/List.h:170:27: note: expected ‘const char **’ but argument is of type ‘char **’
170 | _Xconst char **list,
| ^ ^
```
Originally reported downstream in Gentoo at https://bugs.gentoo.org/919207.
This can be emulated with `-Werror=incompatible-pointer-types -Werror=implicit -Werror=int-conversion` on an older GCC or Clang.https://gitlab.freedesktop.org/xorg/app/xlsfonts/-/issues/1Build failure with stricter C compilers (e.g. GCC 14)2024-03-02T00:55:06ZSam JamesBuild failure with stricter C compilers (e.g. GCC 14)Modern C compilers are becoming stricter with a variety of changes over the last year or so.
GCC 14 in particular (to be released in ~April 2024) fails to build xlsfonts-1.0.7 like:
```
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -W...Modern C compilers are becoming stricter with a variety of changes over the last year or so.
GCC 14 in particular (to be released in ~April 2024) fails to build xlsfonts-1.0.7 like:
```
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wlogical-op -Wimplicit -Wnonnull -Winit-self -Wmain -Wmissing-braces -Wsequence-point -Wreturn-type -Wtrigraphs -Warray-bounds -Wwrite-strings -Waddress -Wint-to-pointer-cast -Wpointer-to-int-cast -fno-strict-aliasing -O3 -pipe -march=native -fno-diagnostics-color -c -o xlsfonts.o xlsfonts.c
xlsfonts.c: In function ‘get_list’:
xlsfonts.c:204:23: error: assignment to ‘char **’ from incompatible pointer type ‘const char **’ [-Wincompatible-pointer-types]
204 | fonts = &pattern;
| ^
```
Originally reported downstream in Gentoo at https://bugs.gentoo.org/919204.
This can be emulated with `-Werror=incompatible-pointer-types -Werror=implicit -Werror=int-conversion` on an older GCC or Clang.https://gitlab.freedesktop.org/xorg/lib/libxpm/-/issues/6How to determine number of bits per color channel in XPM3 file2023-12-07T19:37:36ZRobert DodierHow to determine number of bits per color channel in XPM3 fileI'm working on extending a parser for XPM3 files and I think I need to figure out how many bits per color channel are in the color table specification. It appears that most XPM3 files (among the ones I've seen on a couple of Ubuntu insta...I'm working on extending a parser for XPM3 files and I think I need to figure out how many bits per color channel are in the color table specification. It appears that most XPM3 files (among the ones I've seen on a couple of Ubuntu installations, at any rate) assume 8 bits per color channel, so 24 bits per color and therefore 6 hexadecimal digits per color. However, there are a few which assume 16 bits per color channel, 48 bits per color, and 12 hexadecimal digits per color. Aside from inspecting the hexadecimal strings, is there any way to know how many bits per channel are assumed?
A related point for which I believe I know the answer. Whatever the number of bits in the XPM3 file, how many bits per channel are allowed in the libXpm source code? I believe the number is just 8, since it appears that each color channel in XpmColor is represented by a C `char`.
I looked at the source code for libXpm (thank you to all the contributors, I appreciate it) but I was unable to puzzle it out. Documentation which I was able to find (such as xpm.ps.gz in the libXpm project) didn't seem to address the question. Thanks for any light you can shed on this problem.
PS. In case anyone is wondering, I'm working in a language (Common Lisp) for which a parser for XPM3 does not yet exist from what I can tell.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/201Sole compose sequence in en_US with postfix <cedilla>, anomaly?2023-12-04T21:54:20ZKelly RoadkillSole compose sequence in en_US with postfix <cedilla>, anomaly?[This](https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/nls/en_US.UTF-8/Compose.pre?ref_type=heads#L915) is the only sequence in `en_US.UTF-8` with `<Multi_key> <letter> <cedilla>` pattern (or with postfix `<cedilla>` at all)...[This](https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/nls/en_US.UTF-8/Compose.pre?ref_type=heads#L915) is the only sequence in `en_US.UTF-8` with `<Multi_key> <letter> <cedilla>` pattern (or with postfix `<cedilla>` at all):
> \<Multi_key\> \<s\> \<cedilla\> : "ş" U015F # LATIN SMALL LETTER S WITH CEDILLA
Other letters in the block have `<cedilla>` in the prefix position only.
Is this an anomaly?https://gitlab.freedesktop.org/xorg/app/xinput/-/issues/15ambiguity with master device naming2023-12-27T12:40:38ZJesus Zen Droïdambiguity with master device naming```
$ xinput create-master Test
$ xinput reattach "Wacom One by Wacom S Pen stylus" Test
unable to find device 'Test'
# master must be set explicitly, but we already know it's a pointer (it was
# attached correctly to "Virtual core poin...```
$ xinput create-master Test
$ xinput reattach "Wacom One by Wacom S Pen stylus" Test
unable to find device 'Test'
# master must be set explicitly, but we already know it's a pointer (it was
# attached correctly to "Virtual core pointer" in the first place) ; so far
# this is just a minor nuisance
$ xinput reattach "Wacom One by Wacom S Pen stylus" "Test pointer"
# the problem becomes obvious when _removing_ a master:
$ xinput remove-master Test
unable to find device 'Test'
$ xinput remove-master "Test pointer"
# now, xinput removed _both_ "Test pointer" and "Test keyboard"
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1602Corrupt characters in Xorg.0.log2023-12-03T17:16:36ZJonnyCorrupt characters in Xorg.0.logOpening Xorg.0.log my editor reports corrupted characters
There is a vulnerability risk, as xorg is not checking the data is valid, could become a more serious risk, if they connect an HDMI device with invalid characters, that somehow is...Opening Xorg.0.log my editor reports corrupted characters
There is a vulnerability risk, as xorg is not checking the data is valid, could become a more serious risk, if they connect an HDMI device with invalid characters, that somehow is made into an overflow RCE
X.Org version: 1.21.1.7
30 29 3A 20 20 4D 43 36 4A 4E 81 31 35 36 57 46 31 0A 5B 20 20
0): MC6JN�156WF1.[
The 0x81 in the middle, is corrupt
Could xorg filter messages, to check they contain only valid characters?
I appreciate that it is probably coming from the monitor,
[ 29.328] ABI class: X.Org ANSI C Emulation, version 0.4
[ 29.785] (II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) HD Graphics 4000 (IVB GT2)
[ 29.785] (II) modeset(0): glamor initialized
[ 29.785] (==) modeset(0): VariableRefresh: disabled
[ 29.785] (==) modeset(0): AsyncFlipSecondaries: disabled
[ 29.785] (II) modeset(0): Output LVDS-1 has no monitor section
[ 29.799] (II) modeset(0): Output VGA-1 has no monitor section
[ 29.826] (II) modeset(0): Output HDMI-1 has no monitor section
[ 29.932] (II) modeset(0): Output DP-1 has no monitor section
[ 29.933] (II) modeset(0): EDID for output LVDS-1
[ 29.933] (II) modeset(0): Manufacturer: LGD Model: 2d9 Serial#: 0
[ 29.933] (II) modeset(0): Year: 2010 Week: 0
[ 29.933] (II) modeset(0): EDID Version: 1.4
[ 29.933] (II) modeset(0): Digital Display Input
[ 29.933] (II) modeset(0): 6 bits per channel
[ 29.933] (II) modeset(0): Digital interface is undefined
[ 29.933] (II) modeset(0): Max Image Size [cm]: horiz.: 34 vert.: 19
[ 29.933] (II) modeset(0): Gamma: 2.20
[ 29.933] (II) modeset(0): No DPMS capabilities specified
[ 29.933] (II) modeset(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
[ 29.933] (II) modeset(0): First detailed timing is preferred mode
[ 29.933] (II) modeset(0): Preferred mode is native pixel format and refresh rate
[ 29.933] (II) modeset(0): redX: 0.617 redY: 0.349 greenX: 0.313 greenY: 0.595
[ 29.933] (II) modeset(0): blueX: 0.151 blueY: 0.056 whiteX: 0.313 whiteY: 0.329
[ 29.933] (II) modeset(0): Manufacturer's mask: 0
[ 29.933] (II) modeset(0): Supported detailed timing:
[ 29.933] (II) modeset(0): clock: 139.5 MHz Image Size: 344 x 194 mm
[ 29.933] (II) modeset(0): h_active: 1920 h_sync: 1968 h_sync_end 2000 h_blank_end 2096 h_border: 0
[ 29.933] (II) modeset(0): v_active: 1080 v_sync: 1083 v_sync_end 1088 v_blanking: 1111 v_border: 0
[ 29.933] (II) modeset(0): Supported detailed timing:
[ 29.933] (II) modeset(0): clock: 93.0 MHz Image Size: 344 x 194 mm
[ 29.933] (II) modeset(0): h_active: 1920 h_sync: 1968 h_sync_end 2000 h_blank_end 2096 h_border: 0
[ 29.933] (II) modeset(0): v_active: 1080 v_sync: 1083 v_sync_end 1088 v_blanking: 1111 v_border: 0
[ 29.933] (II) modeset(0): MC6JN�156WF1
[ 29.933] (II) modeset(0): Unknown vendor-specific block 0
[ 29.933] (II) modeset(0): EDID (in hex):
[ 29.933] (II) modeset(0): 00ffffffffffff0030e4d90200000000
[ 29.933] (II) modeset(0): 00140104902213780a15d59e59509826
[ 29.933] (II) modeset(0): 0e505400000001010101010101010101
[ 29.933] (II) modeset(0): 0101010101017e3680b070381f403020
[ 29.934] (II) modeset(0): 350058c210000018542480b070381f40
[ 29.934] (II) modeset(0): 3020350058c210000018000000fe004d
[ 29.934] (II) modeset(0): 43364a4e813135365746310a00000000
[ 29.934] (II) modeset(0): 000041319e0000000002010a20200030
[ 29.934] (II) modeset(0): Printing probed modes for output LVDS-1
[ 29.934] (II) modeset(0): Modeline "1920x1080"x59.9 139.50 1920 1968 2000 2096 1080 1083 1088 1111 -hsync -vsync (66.6 kHz eP)