xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2023-09-02T12:04:34Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1568X server crash2023-09-02T12:04:34ZlindevelX server crashHalf a week ago I moved my OS to QEMU/KVM, enabled passthrough for GPU, mouse and keyboard, so far it's all worked fine. But today, while playing the game, the X server stopped displaying the picture and instead I see a terminal with a ...Half a week ago I moved my OS to QEMU/KVM, enabled passthrough for GPU, mouse and keyboard, so far it's all worked fine. But today, while playing the game, the X server stopped displaying the picture and instead I see a terminal with a systemd boot log identical to vt1, and the sound looped. However, the Xorg process and all X server clients continue to run.
My OS: Arch Linux
X Server version: 1.21.1.8
DE: Xfce
X server log:
```
[167959.752] (EE)
[167959.752] (EE) Backtrace:
[167959.753] (EE) 0: /usr/lib/Xorg (dri3_send_open_reply+0xdd) [0x55b5cb91b4bd]
[167959.753] (EE) 1: /usr/lib/libc.so.6 (__sigaction+0x50) [0x7fca4edccab0]
[167959.754] (EE) 2: /usr/lib/libc.so.6 (pthread_key_delete+0x14c) [0x7fca4ee1c26c]
[167959.754] (EE) 3: /usr/lib/libc.so.6 (gsignal+0x18) [0x7fca4edcca08]
[167959.754] (EE) 4: /usr/lib/libc.so.6 (abort+0xd7) [0x7fca4edb5538]
[167959.755] (EE) 5: /usr/lib/libc.so.6 (abort+0xe7a) [0x7fca4edb62db]
[167959.755] (EE) 6: /usr/lib/libc.so.6 (timer_settime+0x2d7) [0x7fca4ee261b7]
[167959.755] (EE) 7: /usr/lib/libc.so.6 (__default_morecore+0x1ccc) [0x7fca4ee2972c]
[167959.755] (EE) 8: /usr/lib/libc.so.6 (__libc_calloc+0xd8) [0x7fca4ee2b608]
[167959.755] (EE) 9: /usr/lib/Xorg (present_event_notify+0x1b3e) [0x55b5cb8a1dde]
[167959.755] (EE) 10: /usr/lib/Xorg (present_event_notify+0xae5) [0x55b5cb8a0d85]
[167959.755] (EE) 11: /usr/lib/Xorg (SProcXkbDispatch+0x2801) [0x55b5cb7feeae]
[167959.756] (EE) 12: /usr/lib/libc.so.6 (__libc_init_first+0x90) [0x7fca4edb6850]
[167959.756] (EE) 13: /usr/lib/libc.so.6 (__libc_start_main+0x8a) [0x7fca4edb690a]
[167959.756] (EE) 14: /usr/lib/Xorg (_start+0x25) [0x55b5cb7ff465]
[167959.756] (EE)
[167959.756] (EE)
Fatal server error:
[167959.756] (EE) Caught signal 6 (Aborted). Server aborting
[167959.756] (EE)
[167959.756] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[167959.756] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[167959.756] (EE)
[167959.757] (II) AIGLX: Suspending AIGLX clients for VT switch
[167959.819] (EE) Server terminated with error (1). Closing log file.
```https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/194configure script reports stray, confusing "yes"2023-08-20T17:13:10ZG. Branden Robinsonconfigure script reports stray, confusing "yes"The `configure` script produced from `configure.ac` in Git HEAD produces puzzling output.
```
checking for strcasecmp... yes
checking for strlcpy... no
checking if run-time linking is supported... checking for library containing dlopen....The `configure` script produced from `configure.ac` in Git HEAD produces puzzling output.
```
checking for strcasecmp... yes
checking for strlcpy... no
checking if run-time linking is supported... checking for library containing dlopen... -ldl
checking for dlfcn.h... (cached) yes
yes
checking if loadable i18n module support should be enabled... no
checking if loadable Xcursor library support should be enabled... yes
checking for sys/filio.h... no
checking for sys/select.h... yes
```
The text of Autoconf `CHECKING` and `RESULT` messages should not be nested.
Here's a patch.
```
diff --git a/configure.ac b/configure.ac
index 045dbb87..17a8ebce 100644
--- a/configure.ac
+++ b/configure.ac
@@ -98,7 +98,6 @@ m4_pattern_forbid([^XTRANS_CONNECTION_FLAGS$])
XTRANS_CONNECTION_FLAGS
# Check for dlopen
-AC_MSG_CHECKING([if run-time linking is supported])
AC_SEARCH_LIBS(dlopen,[dl svld])
if test "x$ac_cv_search_dlopen" = xno; then
AC_SEARCH_LIBS(shl_load,[dld])
@@ -111,6 +110,7 @@ else
AC_DEFINE(HAVE_DLOPEN,1,[Use dlopen to load shared libraries])
AC_CHECK_HEADERS([dlfcn.h])
fi
+AC_MSG_CHECKING([if run-time linking is supported])
if test "x$ac_cv_header_dlfcn_h" = xyes -o "x$ac_cv_header_dl_h" = xyes; then
HAVE_LOADABLE_MODULES=yes
else
```
Here's the result, having used `autogen.sh` to regenerate the `configure` script.
```
checking for strcasecmp... yes
checking for strlcpy... no
checking for library containing dlopen... -ldl
checking for dlfcn.h... (cached) yes
checking if run-time linking is supported... yes
checking if loadable i18n module support should be enabled... no
checking if loadable Xcursor library support should be enabled... yes
checking for sys/filio.h... no
checking for sys/select.h... yes
checking for sys/ioctl.h... yes
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1567Xorg and Xwayland2023-08-01T23:37:33Zqian yeXorg and XwaylandHi,May I ask if Xwayland will replace xorg server in the future, and if Xwayland uses xprotoHi,May I ask if Xwayland will replace xorg server in the future, and if Xwayland uses xprotohttps://gitlab.freedesktop.org/xorg/app/xrandr/-/issues/69xrandr: Configure crtc 0 failed2023-07-24T12:27:44ZAjita Chavanxrandr: Configure crtc 0 failedHi all,
I am getting same error as I am trying to implement custom size on display. My actual display driver supports 960x480. The size I want is 960x288.
root@imx8mmevk:~# xrandr -q
Screen 0: minimum 16 x 16, current 960 x 480, maximu...Hi all,
I am getting same error as I am trying to implement custom size on display. My actual display driver supports 960x480. The size I want is 960x288.
root@imx8mmevk:~# xrandr -q
Screen 0: minimum 16 x 16, current 960 x 480, maximum 32767 x 32767
XWAYLAND0 connected 960x480+0+0 left (normal left inverted right x axis y axis) 0mm x 0mm
480x960 59.53*+
960x288_60.00 58.94
root@imx8mmevk:~# xrandr --auto --output XWAYLAND0 --mode 960x288_60.00 --primary --verbose
crtc 0: disable
screen 0: 288x960 76x254 mm 96.00dpi
crtc 0: 960x288_60.00 58.94 +0+0 "XWAYLAND0"
xrandr: Configure crtc 0 failed
crtc 0: disable
screen 0: revert
crtc 0: revert
can someone help me with this?
Thanks,
Ajitahttps://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/69display crashes on thin images2023-07-25T16:19:43Zthesourcerer8display crashes on thin imagesI have filed an issue against ImageMagick:
https://github.com/ImageMagick/ImageMagick/issues/6509
When I try to display the attached image ![output](/uploads/19de7e45c18a1c5429e06bc25af0d6f5/output.png), display crashes, the stacktrace ...I have filed an issue against ImageMagick:
https://github.com/ImageMagick/ImageMagick/issues/6509
When I try to display the attached image ![output](/uploads/19de7e45c18a1c5429e06bc25af0d6f5/output.png), display crashes, the stacktrace indicates an endless recursive loop inside the PutSubImage function:
```
#5954 0x00007ffff72e4c7a in PutSubImage (dpy=0x555555571d90, d=71305664, gc=0x5555555bda50, image=0x555555629c50, req_xoffset=, req_yoffset=, x=0, y=0, req_width=2096928,
req_height=1, dest_bits_per_pixel=32, dest_scanline_pad=32) at ../../src/PutImage.c:920
#5955 0x00007ffff72e4c7a in PutSubImage (dpy=0x555555571d90, d=71305664, gc=0x5555555bda50, image=0x555555629c50, req_xoffset=, req_yoffset=, x=0, y=0, req_width=2096928,
req_height=1, dest_bits_per_pixel=32, dest_scanline_pad=32) at ../../src/PutImage.c:920
#5956 0x00007ffff72e4c7a in PutSubImage (dpy=0x555555571d90, d=71305664, gc=0x5555555bda50, image=0x555555629c50, req_xoffset=, req_yoffset=, x=0, y=0, req_width=2096928,
req_height=1, dest_bits_per_pixel=32, dest_scanline_pad=32) at ../../src/PutImage.c:920
#5957 0x00007ffff72e4c7a in PutSubImage (dpy=0x555555571d90, d=71305664, gc=0x5555555bda50, image=0x555555629c50, req_xoffset=, req_yoffset=, x=0, y=0, req_width=2096928,
req_height=1, dest_bits_per_pixel=32, dest_scanline_pad=32) at ../../src/PutImage.c:920![output](/uploads/d30cfe1555a9b2bd1c066460c2e6b47f/output.png)
```
I guess that the problem is that due to the very wide and thing image (138240 x 16) display wants to scale it down for a thumbnail to the screensize, divides the height by some bigger factor, which then gets rounded down to 0 pixel, and then Xlib/libxcb crashes trying to resize or display the 0 pixel height image.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1566In the Decent Sampler app under a Wayland session clicks on control elements ...2023-07-21T23:34:06ZMikhail GavrilovIn the Decent Sampler app under a Wayland session clicks on control elements works through timePreviously here: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1566
In the Decent Sampler app under a Wayland session clicks on control elements works through time.
Under X11 session all clicks on control elements works immedi...Previously here: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1566
In the Decent Sampler app under a Wayland session clicks on control elements works through time.
Under X11 session all clicks on control elements works immediately.
I can't judge what is blame here. Maybe Xwayland server, maybe Decent Sampler itself.
But be better if look into this and reach your verdict.
I suppose user should not see the difference between Wayland and X11 sessions.
Steps To Reproduce:
1. Download https://www.decentsamples.com/product/decent-sampler-plugin/ and extract Decent Sampler v1.8.12 Linux (x86_64 - Static build)
2. Enter in GNOME Wayland session
3. Lauch Decent Sampler
4. Click on "FILE..." or "Options" button several times
Demonstration:
| Wayland | X11 |
| ------ | ------ |
| ![Screencast_from_2023-07-20_03-11-21](/uploads/e1024a54c860f382ff5a97b39d0fa796/Screencast_from_2023-07-20_03-11-21.webm) | ![Screencast_from_2023-07-20_03-09-50](/uploads/dd245591671c30c7e0752b4efce61bab/Screencast_from_2023-07-20_03-09-50.webm) |https://gitlab.freedesktop.org/xorg/xserver/-/issues/1565Xwayland Regression with !11312023-07-27T14:52:11ZOlivier FourdanXwayland Regression with !1131This is a spin off #1564 as more regression is observed following !1131.
1. Open `xterm`
1. <kbd>Shift</kbd> + RMB to select the "Enormous" font
1. Move the window around
This is what I see:
![VID_20230719_161801](/uploads/5a950b9e2ec...This is a spin off #1564 as more regression is observed following !1131.
1. Open `xterm`
1. <kbd>Shift</kbd> + RMB to select the "Enormous" font
1. Move the window around
This is what I see:
![VID_20230719_161801](/uploads/5a950b9e2ece512420228c642edb8778/VID_20230719_161801.mp4)https://gitlab.freedesktop.org/xorg/xserver/-/issues/1564Xwayland: GLAMOR regression in the master branch2023-07-27T14:52:11ZOlivier FourdanXwayland: GLAMOR regression in the master branchLooks like xorg/xserver!1131 may have introduced a small rendering regression.
It is hard to spot, but I can reproduce with `xterm`, the vertical line separating the scroll bar from the text widget, it appears as if it has uninitialized...Looks like xorg/xserver!1131 may have introduced a small rendering regression.
It is hard to spot, but I can reproduce with `xterm`, the vertical line separating the scroll bar from the text widget, it appears as if it has uninitialized pixels.
That line appears white in the screenshot, but in reality, it looks like random pixels.
Actual result:
![Screenshot_from_2023-07-18_15-57-07](/uploads/93c44bb46255a7f6d1ac67dd4fefe349/Screenshot_from_2023-07-18_15-57-07.png)
Expected result:
![Screenshot_from_2023-07-18_15-58-13](/uploads/66cf4c704be61d06eb6c3c6fe818f345/Screenshot_from_2023-07-18_15-58-13.png)
To reproduce, I am attaching my [.Xresources](/uploads/49232cdd6ce44b27fd332c0c195c7058/.Xresources) for `xterm`.https://gitlab.freedesktop.org/xorg/lib/libxcb-cursor/-/issues/11ERROR: AddressSanitizer: heap-buffer-overflow: load_cursor.c2023-07-13T21:02:37ZithinkappsERROR: AddressSanitizer: heap-buffer-overflow: load_cursor.cWhen building a Qt 6.6.0 Beta 1 example program (calculatorform.pro) using fsanitize and running on a Linux Mint VM:
```
System:
Kernel: 5.15.0-76-generic x86_64 bits: 64 compiler: gcc v: 11.3.0 Desktop: Cinnamon 5.6.8
tk: GTK 3.2...When building a Qt 6.6.0 Beta 1 example program (calculatorform.pro) using fsanitize and running on a Linux Mint VM:
```
System:
Kernel: 5.15.0-76-generic x86_64 bits: 64 compiler: gcc v: 11.3.0 Desktop: Cinnamon 5.6.8
tk: GTK 3.24.33 wm: muffin dm: LightDM Distro: Linux Mint 21.1 Vera base: Ubuntu 22.04 jammy
Machine:
Type: Virtualbox System:
```
I got a heap buffer overflow error reported.
As this did not say where the memory was allocated I built a copy of xcb-util-cursor-0.1.1 locally with fsanitize enabled using the following configure:
```
./configure CFLAGS="-O0 -g -fsanitize=address -fno-omit-frame-pointer" CPPFLAGS="-O0 -g -fsanitize=address -fno-omit-frame-pointer" LDFLAGS="-g -fsanitize=address"
```
Then I received the following error from AddressSanitizer:
```
=================================================================
==18997==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6030001fe505 at pc 0x7f35c910d88c bp 0x7ffcbb1e8680 sp 0x7ffcbb1e8670
WRITE of size 1 at 0x6030001fe505 thread T0
#0 0x7f35c910d88b in _XcursorThemeInherits /home/peter/Develop/LINUX/BUILDS0/xcb-util-cursor-0.1.1/cursor/load_cursor.c:107
#1 0x7f35c910df30 in open_cursor_file /home/peter/Develop/LINUX/BUILDS0/xcb-util-cursor-0.1.1/cursor/load_cursor.c:165
#2 0x7f35c910e36c in xcb_cursor_load_cursor /home/peter/Develop/LINUX/BUILDS0/xcb-util-cursor-0.1.1/cursor/load_cursor.c:204
#3 0x7f35c918b5d8 in QXcbCursor::createFontCursor(int) /home/qt/work/qt/qtbase/src/plugins/platforms/xcb/qxcbcursor.cpp:493
#4 0x7f35c918bd32 in QXcbCursor::changeCursor(QCursor*, QWindow*) /home/qt/work/qt/qtbase/src/plugins/platforms/xcb/qxcbcursor.cpp:327
#5 0x7f35c918bd32 in QXcbCursor::changeCursor(QCursor*, QWindow*) /home/qt/work/qt/qtbase/src/plugins/platforms/xcb/qxcbcursor.cpp:306
#6 0x7f35cf94f6cc in QWindowPrivate::applyCursor() /home/qt/work/qt/qtbase/src/gui/kernel/qwindow.cpp:3035
#7 0x7f35cf953ef6 in QWindowPrivate::setCursor(QCursor const*) /home/qt/work/qt/qtbase/src/gui/kernel/qwindow.cpp:3016
#8 0x7f35d02be070 in applyCursor /home/qt/work/qt/qtbase/src/widgets/kernel/qwidget.cpp:5012
#9 0x7f35d02be070 in qt_qpa_set_cursor(QWidget*, bool) /home/qt/work/qt/qtbase/src/widgets/kernel/qwidget.cpp:5050
#10 0x7f35d02c77c1 in qt_qpa_set_cursor(QWidget*, bool) /home/qt/work/qt/qtbase/src/widgets/kernel/qwidget.cpp:5023
#11 0x7f35d02c77c1 in QWidgetPrivate::show_sys() /home/qt/work/qt/qtbase/src/widgets/kernel/qwidget.cpp:8177
#12 0x7f35d02cfbea in QWidgetPrivate::show_helper() /home/qt/work/qt/qtbase/src/widgets/kernel/qwidget.cpp:8103
#13 0x7f35d02d2542 in QWidgetPrivate::setVisible(bool) /home/qt/work/qt/qtbase/src/widgets/kernel/qwidget.cpp:8399
#14 0x559c33290462 in main ../calculatorform/main.cpp:12
#15 0x7f35ceac7d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#16 0x7f35ceac7e3f in __libc_start_main_impl ../csu/libc-start.c:392
#17 0x559c332878e4 in _start (/home/peter/QtCom/Examples/Qt-6.5.1/designer/build-calculatorform-Desktop_Qt_6_6_0_GCC_64bit-Debug/calculatorform+0x58e4)
0x6030001fe505 is located 0 bytes to the right of 21-byte region [0x6030001fe4f0,0x6030001fe505)
allocated by thread T0 here:
#0 0x7f35d08e4867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f35c910d5ae in _XcursorThemeInherits /home/peter/Develop/LINUX/BUILDS0/xcb-util-cursor-0.1.1/cursor/load_cursor.c:92
#2 0x7f35c910df30 in open_cursor_file /home/peter/Develop/LINUX/BUILDS0/xcb-util-cursor-0.1.1/cursor/load_cursor.c:165
#3 0x7f35c910e36c in xcb_cursor_load_cursor /home/peter/Develop/LINUX/BUILDS0/xcb-util-cursor-0.1.1/cursor/load_cursor.c:204
#4 0x7f35c918b5d8 in QXcbCursor::createFontCursor(int) /home/qt/work/qt/qtbase/src/plugins/platforms/xcb/qxcbcursor.cpp:493
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/peter/Develop/LINUX/BUILDS0/xcb-util-cursor-0.1.1/cursor/load_cursor.c:107 in _XcursorThemeInherits
Shadow bytes around the buggy address:
0x0c0680037c50: fd fd fd fa fa fa 00 00 04 fa fa fa fd fd fd fa
0x0c0680037c60: fa fa 00 00 04 fa fa fa 00 00 04 fa fa fa fd fd
0x0c0680037c70: fd fa fa fa fd fd fd fa fa fa 00 00 00 fa fa fa
0x0c0680037c80: 00 00 00 00 fa fa 00 00 00 fa fa fa 00 00 00 fa
0x0c0680037c90: fa fa fd fd fd fd fa fa 00 00 00 01 fa fa 00 00
=>0x0c0680037ca0:[05]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0680037cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0680037cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0680037cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0680037ce0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0680037cf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==18997==ABORTING
```
Looking at the source code for the buffer overflow memory allocation and how it is used it seems that in the following line:
```
result = malloc (strlen (l));
```
Not enough memory is allocated and the size of the memory allocated should be: ```strlen(l) + 1```.
Hence causing the memory buffer overflow at: ```load_cursor.c:107```
The function that is being called:
```
static char *
_XcursorThemeInherits (const char *full)
```
points to a file: ```"/usr/share/icons/default/index.theme"```
And the content of that file on my machine is:
```
[Icon Theme]
Name=Bibata-Modern-Classic
Inherits=Bibata-Modern-Classic
```
I hope this helps you confirm and fix the issue.
NB: Looking at your latest source code under git (git://anongit.freedesktop.org/git/xcb/util-cursor) the error line in question seems to be still there.
Regards
PeterAlan CoopersmithAlan Coopersmithhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/191Xwayland crash when calling XPutImage with large image sizes2023-07-03T10:43:11ZAmini AllightXwayland crash when calling XPutImage with large image sizesHopefully this is the right category for this.
I've discovered what I think is a bug that only manifests when running an X server via Xwayland. A simplified version of the code that causes the issue:
```c
int width = ...;
int height = ...Hopefully this is the right category for this.
I've discovered what I think is a bug that only manifests when running an X server via Xwayland. A simplified version of the code that causes the issue:
```c
int width = ...;
int height = ...;
unsigned char* data = malloc(width * height * 4);
memset(data, 0, width * height * 4);
XImage* ximage = XCreateImage(
display,
DefaultVisual(display, DefaultScreen(display)),
32,
ZPixmap,
0,
data,
width, height,
32,
0
);
Pixmap pixmap = XCreatePixmap(
display,
window,
width, height,
32
);
GC gc = XCreateGC(display, pixmap, 0, 0);
XPutImage(
display,
pixmap,
gc,
ximage,
0, 0,
0, 0,
width, height
);
XInternAtom(display, "WM_DELETE_WINDOW", 0);
```
- If `width` and `height` are 128 or lower, this code executes fine.
- If `width` and `height` is 256 or 512, a segmentation fault will be triggered when calling `XPutImage`.
- If `width` and `height` are 1024 or higher, `XPutImage` will succeed but the call to `XInternAtom` will fail with the following error, causing the program to exit immediately:
```
XIO: fatal IO error 14 (Bad address) on X server ":0"
```
- Non-power of two sizes and non-square images were not tested.
- The same code works fine when a normal X server is running.
The full code where I originally discovered the error can be found in my project [here](https://gitlab.com/amini-allight/lambdamod/-/blob/c3631e4e9eb1e3b8f780b9e0cc26c1781da6a6ea/src/client/platform/window_x11.cpp), around line 169.
- Removing the `XPutImage` line causes the program to run normally.
- Removing the `XInternAtom` line (and the lines that depend upon it) just delays the crash until cursor pixmap initialization further down the same function.
- Removing cursor initialization further delays the crash until `vkCreateXlibSurfaceKHR` elsewhere in the program.
System Information:
- `xorg-xwayland` version 23.1.2-1
- `xorg-server-common` version 21.1.8-1
- `sway` wayland compositor version 1:1.8.1-1
- Arch Linux 6.3.9-arch1-1
- AMD graphicshttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1561Xwayland crash when calling XPutImage with large image sizes2023-07-03T10:43:12ZAmini AllightXwayland crash when calling XPutImage with large image sizesHopefully this is the right category for this.
I've discovered what I think is a bug that only manifests when running an X server via Xwayland. A simplified version of the code that causes the issue:
```c
int width = ...;
int height = ...Hopefully this is the right category for this.
I've discovered what I think is a bug that only manifests when running an X server via Xwayland. A simplified version of the code that causes the issue:
```c
int width = ...;
int height = ...;
unsigned char* data = malloc(width * height * 4);
memset(data, 0, width * height * 4);
XImage* ximage = XCreateImage(
display,
DefaultVisual(display, DefaultScreen(display)),
32,
ZPixmap,
0,
data,
width, height,
32,
0
);
Pixmap pixmap = XCreatePixmap(
display,
window,
width, height,
32
);
GC gc = XCreateGC(display, pixmap, 0, 0);
XPutImage(
display,
pixmap,
gc,
ximage,
0, 0,
0, 0,
width, height
);
XInternAtom(display, "WM_DELETE_WINDOW", 0);
```
- If `width` and `height` are 128 or lower, this code executes fine.
- If `width` and `height` is 256 or 512, a segmentation fault will be triggered when calling `XPutImage`.
- If `width` and `height` are 1024 or higher, `XPutImage` will succeed but the call to `XInternAtom` will fail with the following error, causing the program to exit immediately:
```
XIO: fatal IO error 14 (Bad address) on X server ":0"
```
- Non-power of two sizes and non-square images were not tested.
- The same code works fine when a normal X server is running.
The full code where I originally discovered the error can be found in my project [here](https://gitlab.com/amini-allight/lambdamod/-/blob/c3631e4e9eb1e3b8f780b9e0cc26c1781da6a6ea/src/client/platform/window_x11.cpp), around line 169.
- Removing the `XPutImage` line causes the program to run normally.
- Removing the `XInternAtom` line (and the lines that depend upon it) just delays the crash until cursor pixmap initialization further down the same function.
- Removing cursor initialization further delays the crash until `vkCreateXlibSurfaceKHR` elsewhere in the program.
System Information:
- `xorg-xwayland` version 23.1.2-1
- `xorg-server-common` version 21.1.8-1
- `sway` wayland compositor version 1:1.8.1-1
- Arch Linux 6.3.9-arch1-1
- AMD graphicshttps://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/60libinput NULL pointer dereference in is_libinput_device crashes X on udev-reload2023-07-12T16:43:11ZArthur Huilletlibinput NULL pointer dereference in is_libinput_device crashes X on udev-reloadThis Lenovo P14s laptop will see a crash in X when upgrading some packages on Archlinux, with the following signature:
```
#9 0x00007f692465bab0 in <signal handler called> () at /usr/lib/libc.so.6
#10 0x00007f69214f3e8c in is_libinput_d...This Lenovo P14s laptop will see a crash in X when upgrading some packages on Archlinux, with the following signature:
```
#9 0x00007f692465bab0 in <signal handler called> () at /usr/lib/libc.so.6
#10 0x00007f69214f3e8c in is_libinput_device (pInfo=0x0) at /usr/src/debug/xf86-input-libinput/xf86-input-libinput-1.3.0/src/xf86libinput.c:1479
#11 swap_registered_device (pInfo=0x55bbebcf7600) at /usr/src/debug/xf86-input-libinput/xf86-input-libinput-1.3.0/src/xf86libinput.c:1500
#12 xf86libinput_destroy (dev=<optimized out>) at /usr/src/debug/xf86-input-libinput/xf86-input-libinput-1.3.0/src/xf86libinput.c:1526
#13 xf86libinput_device_control (dev=<optimized out>, mode=<optimized out>) at /usr/src/debug/xf86-input-libinput/xf86-input-libinput-1.3.0/src/xf86libinput.c:1552
#14 0x000055bbeaeb31d8 in CloseDevice (dev=0x55bbebd7fcb0) at ../xorg-server-21.1.8/dix/devices.c:971
#15 0x000055bbeaeb35e1 in RemoveDevice (dev=0x55bbebd7fcb0, sendevent=<optimized out>) at ../xorg-server-21.1.8/dix/devices.c:1186
#16 0x000055bbeafc47e9 in DeleteInputDeviceRequest (pDev=0x55bbebd7fcb0) at ../xorg-server-21.1.8/hw/xfree86/common/xf86Xinput.c:1142
#17 0x000055bbeb019467 in remove_device (backend=0x55bbeb0495a4 "udev", dev=0x55bbebd7fcb0) at ../xorg-server-21.1.8/config/config.c:91
#18 remove_devices (backend=0x55bbeb0495a4 "udev", config_info=0x55bbebf23ef0 "udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2/event2") at ../xorg-server-21.1.8/config/config.c:103
#19 device_removed (device=<optimized out>) at ../xorg-server-21.1.8/config/udev.c:347
#20 0x000055bbeb0196d8 in socket_handler (fd=<optimized out>, ready=<optimized out>, data=<optimized out>) at ../xorg-server-21.1.8/config/udev.c:374
#21 0x000055bbeaf968c2 in ospoll_wait (ospoll=0x55bbeb46e540, timeout=<optimized out>) at ../xorg-server-21.1.8/os/ospoll.c:657
#22 0x000055bbeaf91ec9 in WaitForSomething (are_ready=<optimized out>) at ../xorg-server-21.1.8/os/WaitFor.c:208
#23 0x000055bbeae8136f in Dispatch () at ../xorg-server-21.1.8/dix/dispatch.c:492
#24 dix_main (envp=<optimized out>, argv=0x7ffc91871a28, argc=7) at ../xorg-server-21.1.8/dix/main.c:272
#25 main (argc=7, argv=0x7ffc91871a28, envp=<optimized out>) at ../xorg-server-21.1.8/dix/stubmain.c:34
```
What triggers the reproduction is:
/usr/share/libalpm/scripts/systemd-hook udev-reload
which happens as part of the upgrade process
Please let me know what information I can provide to help debug this. It seems that is_libinput_device should never get a NULL argument and swap_registered_device seems fishy in its loop, but I am not sure what to do.https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/59Custom accel profile is off; 64 point limit is not enough2023-06-30T05:13:54ZfluentpwnCustom accel profile is off; 64 point limit is not enoughHello!
I'm using the latest commit(as of now) version of xf86-input-libinput, and version 1.23.0 of libinput from Void Linux repos
I'm using this set of points:
```
0 0.33340726500000001 0.3338405692357222 0.33469227511481264 0.33602423...Hello!
I'm using the latest commit(as of now) version of xf86-input-libinput, and version 1.23.0 of libinput from Void Linux repos
I'm using this set of points:
```
0 0.33340726500000001 0.3338405692357222 0.33469227511481264 0.33602423529212044 0.33788526825125625 0.34031646478095684 0.34335368546258149 0.3470289683474484 0.35137141188017096 0.35640777004766655 0.362162875056948 0.36865994969574106 0.3759208455159172 0.383966229121328 0.39281573095571304 0.40248806625492656 0.41300113486247925 0.42437210467986219 0.4366174822305311 0.4497531729260415 0.46379453299497309 0.47875641458332391 0.49465320520373685 0.51149886246401699 0.52930694481870832 0.54809063894442778 0.56786278422869985 0.58863589477502465 0.61042217925799636 0.63323355890718247 0.65708168385405186 0.68197794804012313 0.70793350285493939 0.73363941176470582 0.75788000000000011 0.78077388888888899 0.80243027027027025 0.82294684210526314 0.84241128205128213 0.86090250000000013 0.87849170731707305 0.8952433333333335 0.9112158139534885 0.92646227272727277 0.94103111111111115 0.95496652173913044 0.96830893617021274 0.98109541666666666 0.99335999999999991 1.005134 1.0164462745098042 1.0273234615384617 1.0377901886792453 1.0478692592592593 1.0575818181818182 1.0669474999999999 1.0759845614035088 1.0847099999999998 1.093139661016949 1.1012883333333334 1.109169836065574 1.1167970967741936 1.1241822222222222 1.1313365625 1.1382707692307692 1.1449948484848484 1.1515182089552238 1.1578497058823529 1.1639976811594204 1.1699700000000002 1.1757740845070423 1.1814169444444445 1.186905205479452 1.1922451351351351 1.1974426666666667 1.2025034210526315 1.2074327272727272 1.2122356410256412 1.2169169620253166 1.2214812500000001
```
1. 80 points error out:
The limit of 64 is not enough if you're doing more complex mouse accel - setting sens for each possible unit on 1600 dpi(like I'm doing) is impossible.
2. Way off:
Using these points cut off to 64 (up to 1.1313365625 including) and step of 1, it is really off - somehow when you move the mouse slower it gets further than when you're moving it faster.
I am probably doing something really wrong here, but I have no idea what.
Here is what the curve looks like, for reference:
![image](/uploads/d2021a22a97bc3f54fd0a37c510f30c4/image.png)
CC @Yinonhttps://gitlab.freedesktop.org/xorg/app/xedit/-/issues/1Xedit crashes with a corrupted lisp.lsp file2024-03-10T19:51:03ZGJDuckXedit crashes with a corrupted lisp.lsp fileTested with the latest xedit (1.2.3) build from source.
To reproduce, replace /usr/local/lib/X11/xedit/lisp/lisp.lsp with the attached version, then run xedit.
Appears to be a NULL pointer dereference.
[lisp.lsp](/uploads/32cabf054b61...Tested with the latest xedit (1.2.3) build from source.
To reproduce, replace /usr/local/lib/X11/xedit/lisp/lisp.lsp with the attached version, then run xedit.
Appears to be a NULL pointer dereference.
[lisp.lsp](/uploads/32cabf054b61d368702f23053ffaa984/lisp.lsp)https://gitlab.freedesktop.org/xorg/xserver/-/issues/1558AutoRepeat setting wrong repeat rate2023-11-02T01:20:45ZJoey HoltzmanAutoRepeat setting wrong repeat rateThe "AutoRepeat" rate for a keyboard sets the wrong repeat rate. For example, if I have `Option "AutoRepeat" "150 40"`, this sets the delay rate to 150 (correct) and the repeat rate to 25. I can verify this by viewing the output of `xset...The "AutoRepeat" rate for a keyboard sets the wrong repeat rate. For example, if I have `Option "AutoRepeat" "150 40"`, this sets the delay rate to 150 (correct) and the repeat rate to 25. I can verify this by viewing the output of `xset q`: `auto repeat delay: 150 repeat rate: 25`.
Here is the log output, which shows the correct numbers:
```
[ 15968.600] (**) Option "xkb_options" "caps:none"
[ 15968.601] (**) Option "AutoRepeat" "150 40"
[ 15968.601] (**) AutoRepeat: 150 40
```
Here is my `/etc/X11/xorg.conf.d/99-keyboard.conf`:
```
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbOptions" "caps:none"
Option "AutoRepeat" "150 40"
EndSection
```
Another configuration could possibly be affecting this, but it is strange that it every time I change the repeat rate, the actual repeat rate set is different (ex. using 50 instead of 40 changes the actual repeat rate to 20).
I'd be happy to submit a fix for this if I figure out what is going on.https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/58tablet left-handed setting does not apply correctly2023-06-11T23:55:52ZPeter Hutterertablet left-handed setting does not apply correctlyFedora 38, `xorg-x11-server-Xorg-1.20.14-23.fc38.x86_64` and `xorg-x11-drv-libinput-1.3.0-1.fc38.x86_64` and `mutter-44.1-1.fc38.x86_64` does not handle the tablet left-handed setting correctly. See also @jigpu's comment in [mutter#562](...Fedora 38, `xorg-x11-server-Xorg-1.20.14-23.fc38.x86_64` and `xorg-x11-drv-libinput-1.3.0-1.fc38.x86_64` and `mutter-44.1-1.fc38.x86_64` does not handle the tablet left-handed setting correctly. See also @jigpu's comment in [mutter#562](https://gitlab.gnome.org/GNOME/mutter/-/issues/562#note_1747735).
Tested locally with a PTH-660, the left-handed setting appears in the GNOME control center but does not toggle for all devices.
- `Wacom Intuos Pro M Pen` this is the parent device and it does **not** have a left-handed setting
- `Wacom Intuos Pro M Pen Pen (0x12345678)` this is the actual pen when in proximity and it does **not** have a left-handed setting
- `Wacom Intous Pro M Finger` this is the touch device and it has a left-handed setting but that remains on zero
- `Wacom Intuos Pro M Pad` the pad, has a left-handed setting that is toggledhttps://gitlab.freedesktop.org/xorg/app/xdm/-/issues/13Variable/Conditional USE_SYSTEMD_DAEMON is not being set properly.2024-02-11T16:56:59ZAlisson BrunoVariable/Conditional USE_SYSTEMD_DAEMON is not being set properly.The `Autotool` is generating an inconsistent `Makefile`, where it does
not remove the `Type=notify` and `NotifyAccess=all` bits from the
systemd unit file (`xdm.service.in`).
The reason is that it tries to `auto` identify if the `...The `Autotool` is generating an inconsistent `Makefile`, where it does
not remove the `Type=notify` and `NotifyAccess=all` bits from the
systemd unit file (`xdm.service.in`).
The reason is that it tries to `auto` identify if the `libsystemd` is
present in the system, thus setting its default value to `auto`.
Resulting in the `AM_CONDITIONAL` at the [line](https://gitlab.freedesktop.org/xorg/app/xdm/-/blob/master/configure.ac#L206) always evaluating to true.
(`xauto` != `xno`)
Because the systemd unit file has the `Type=notify`, Systemd keeps
killing the XDM service due to timeout. The timeout occurs because it
never notifies `systemd` with a call to `sd_notify`.
I've created a patch that fixes it. I couldn't create a fork here so
I am submitting it here, let me know what am I missing to create a fork
and create a proper `Merge request.
[xdm-1.1.14-fix-with-systemd-daemon-option.patch](/uploads/33046e4d5984033daadbee0dffa093b9/xdm-1.1.14-fix-with-systemd-daemon-option.patch)https://gitlab.freedesktop.org/xorg/xserver/-/issues/1557Cursor incorrectly modified in GTK2 apps with Xwayland2023-06-13T07:40:39ZFabrice Belletfabrice@bellet.infoCursor incorrectly modified in GTK2 apps with XwaylandThe problem happens in Fedora 38, running Wayland (xorg-x11-server-Xwayland-22.1.9-2.fc38.x86_64). When using GTK2 applications, the cursor appears to be sometimes incorrectly modified.
See this example from gtk-demo which try to illus...The problem happens in Fedora 38, running Wayland (xorg-x11-server-Xwayland-22.1.9-2.fc38.x86_64). When using GTK2 applications, the cursor appears to be sometimes incorrectly modified.
See this example from gtk-demo which try to illustrate the problem:
[Screencast_from_2023-06-07_18-42-18](/uploads/b65ebfc3fbe4b2fdf1466f6c7bad03ef/Screencast_from_2023-06-07_18-42-18.webm)
When exiting from the dropdown menu area the cursor is reverted to what is was when entering in the application area (e-resize, w-resize, ...).
The bug is not systematic, and seems to depend on the order of these two calls to ``ChangeToCursor()`` (which is not always the same), when moving from the border of the window, to the interior of the application:
```
Breakpoint 2, ChangeToCursor (pDev=0x1a07dd0, cursor=0x1d45a10) at ../dix/events.c:936
936 SpritePtr pSprite = pDev->spriteInfo->sprite;
#0 ChangeToCursor (pDev=0x1a07dd0, cursor=0x1d45a10) at ../dix/events.c:936
#1 0x00000000004bdbc8 in PostNewCursor (pDev=0x1a07dd0) at ../dix/events.c:1003
#2 0x00000000004c2ac0 in CheckMotion (ev=0x7ffcd8200d30, pDev=0x1a07dd0) at ../dix/events.c:3226
#3 0x000000000057db33 in ProcessDeviceEvent (ev=0x7ffcd8200d30, device=0x1a07dd0) at ../Xi/exevents.c:1852
#4 0x000000000057e13d in ProcessOtherEvent (ev=0x7ffcd8200d30, device=0x1a07dd0) at ../Xi/exevents.c:2017
#5 0x00000000005c595a in ProcessPointerEvent (ev=0x7ffcd8200d30, mouse=0x1a07dd0) at ../xkb/xkbAccessX.c:756
#6 0x0000000000480d5a in mieqProcessDeviceEvent (dev=0x1be05b0, event=0x7ffcd8201970, screen=0x18c8480) at ../mi/mieq.c:508
#7 0x0000000000480f6f in mieqProcessInputEvents () at ../mi/mieq.c:563
#8 0x0000000000419a9c in ProcessInputEvents () at ../hw/xwayland/xwayland-input.c:3057
#9 0x00000000004a8f2a in Dispatch () at ../dix/dispatch.c:483
#10 0x00000000004b7438 in dix_main (argc=16, argv=0x7ffcd8202798, envp=0x7ffcd8202820) at ../dix/main.c:272
#11 0x0000000000432115 in main (argc=16, argv=0x7ffcd8202798, envp=0x7ffcd8202820) at ../dix/stubmain.c:34
```
and
```
Breakpoint 2, ChangeToCursor (pDev=0x1a07dd0, cursor=0x1d2ad80) at ../dix/events.c:936
936 SpritePtr pSprite = pDev->spriteInfo->sprite;
#0 ChangeToCursor (pDev=0x1a07dd0, cursor=0x1d2ad80) at ../dix/events.c:936
#1 0x00000000004bdbc8 in PostNewCursor (pDev=0x1a07dd0) at ../dix/events.c:1003
#2 0x00000000004c3624 in WindowHasNewCursor (pWin=0x1d45db0) at ../dix/events.c:3505
#3 0x00000000004f9753 in ChangeWindowDeviceCursor (pWin=0x1d45db0, pDev=0x1a07dd0, pCursor=0x0) at ../dix/window.c:3526
#4 0x000000000058e0d4 in ProcXIChangeCursor (client=0x1c4e520) at ../Xi/xichangecursor.c:105
#5 0x0000000000581ae4 in ProcIDispatch (client=0x1c4e520) at ../Xi/extinit.c:390
#6 0x00000000004a9113 in Dispatch () at ../dix/dispatch.c:546
#7 0x00000000004b7438 in dix_main (argc=16, argv=0x7ffcd8202798, envp=0x7ffcd8202820) at ../dix/main.c:272
#8 0x0000000000432115 in main (argc=16, argv=0x7ffcd8202798, envp=0x7ffcd8202820) at ../dix/stubmain.c:34
```
In this order, the bug happens.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1556X11 apps crash causes Xwayland to stuck at 100% cpu2023-06-25T15:55:18Zkorialo kfdX11 apps crash causes Xwayland to stuck at 100% cpuWhen I have both my browser (chromium based) and media player open at the same time, closing the browser sends the session to a total freeze both are configured to run as X11 apps, in a wayland session.
```
lspci -v | grep VGA
00:02.0 VG...When I have both my browser (chromium based) and media player open at the same time, closing the browser sends the session to a total freeze both are configured to run as X11 apps, in a wayland session.
```
lspci -v | grep VGA
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05) (prog-if 00 [VGA controller])
01:00.0 VGA compatible controller: NVIDIA Corporation GA104M [GeForce RTX 3080 Mobile / Max-Q 8GB/16GB] (rev a1) (prog-if 00 [VGA controller])
```
```
Xwayland -version
The X.Org Foundation Xwayland Version 21.1.99 (12101099)
X Protocol Version 11, Revision 0
```
Stack trace:[gdb2.txt](/uploads/e351b1a7626cb2ef91fe9f97cc066a13/gdb2.txt)https://gitlab.freedesktop.org/xorg/xserver/-/issues/1555Deprecating fd.o Patchwork patch tracking2023-06-07T14:59:12ZDragoon AethisDeprecating fd.o Patchwork patch trackingHello, I'm currently cleaning up the [fd.o Patchwork](https://patchwork.freedesktop.org/) and marking some projects in there as deprecated and moved elsewhere. It looks like the X.org mailing list has some minimal activity every now and ...Hello, I'm currently cleaning up the [fd.o Patchwork](https://patchwork.freedesktop.org/) and marking some projects in there as deprecated and moved elsewhere. It looks like the X.org mailing list has some minimal activity every now and then, but most development now happens on GitLab. May I mark the X.org project as moved here as well?