xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2023-08-17T10:49:32Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1572xserver segmentation fault when setting HorizSync too high2023-08-17T10:49:32ZStefan B.xserver segmentation fault when setting HorizSync too highWith xerver 1.21.1.8 the Nvidia 340 drivers no longer work due ABI changes.
So the nv driver has to be used.
However, the nv driver only succeeds starting if HorizSync is set in xorg.conf.
To get FHD resolution, it has to be set >60, 68...With xerver 1.21.1.8 the Nvidia 340 drivers no longer work due ABI changes.
So the nv driver has to be used.
However, the nv driver only succeeds starting if HorizSync is set in xorg.conf.
To get FHD resolution, it has to be set >60, 68.
Now the problem is that, the higher one sets HorizSync, the higher is the chance that xserver exits due seg fault.
I guess this might be fixable easily...https://gitlab.freedesktop.org/xorg/xserver/-/issues/1571Additional information about test cases and logs2023-08-16T17:13:43ZWillian Douglas Ferrari MendonçaAdditional information about test cases and logsHello,
I hope this message finds you well. I am reaching out to the developers as I haven't been able to find an alternative channel for communication. If possible, could you kindly provide me with the contact information of the respons...Hello,
I hope this message finds you well. I am reaching out to the developers as I haven't been able to find an alternative channel for communication. If possible, could you kindly provide me with the contact information of the responsible developer in charge of the testing phase?
I am a researcher in the field of Software Engineering. We are currently developing a configurables system. We have already created a prioritization approach and are currently working on a test case selection approach. Our intention is to expand on this approach by combining other approaches, for example a approach of selection and prioritization.
In order to facilitate the validation of our approach, I am seeking additional insights regarding the Continuous Integration (CI) logs. Furthermore, if feasible, we would like to utilize this information to make informed decisions. For instance, in the provided example in this log:
1/77 xserver / modesetting symbol test OK 0.03s
2/77 xserver:xvfb / XTS OK 10.50s
3/77 xserver:xvfb / blend/Clear OK 1.43s
4/77 xserver:xvfb / blend/Src OK 1.43s
Within this code snippet, terms such as "modesetting symbol test," "XTS," "blend/Clear," and "blend/Src" are present. Although I have extensively studied the meson scripts, I have encountered difficulty in establishing the connection between these names and the corresponding files, suites, or test functions.
Any assistance you can provide would be greatly appreciated.
Thank you in advance for your help.
Best regards,https://gitlab.freedesktop.org/xorg/lib/libxt/-/issues/19src/Shell.c needs to include <process.h> on Windows for getpid()2023-08-15T00:01:05ZBilly O'Nealsrc/Shell.c needs to include <process.h> on Windows for getpid()This problem was first detected in https://github.com/microsoft/vcpkg/pull/33088
(I wanted to submit the 1 line change required here but it isn't clear to me the correct way to make such a contribution here, sorry!)This problem was first detected in https://github.com/microsoft/vcpkg/pull/33088
(I wanted to submit the 1 line change required here but it isn't clear to me the correct way to make such a contribution here, sorry!)Thomas E. DickeyThomas E. Dickeyhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1570DPMS state not updated when screen waked via VNC2023-08-11T20:51:40ZSean GreensladeDPMS state not updated when screen waked via VNCI'm working on an application that polls the DPMS state of a monitor, and I noticed that if the monitor goes to sleep and is then woken up via virtual inputs from a VNC session (using x11vnc), the DPMS state remains reported as "off".
`...I'm working on an application that polls the DPMS state of a monitor, and I noticed that if the monitor goes to sleep and is then woken up via virtual inputs from a VNC session (using x11vnc), the DPMS state remains reported as "off".
```
OS: Arch Linux
$ Xorg -version : 1.21.1.8
$ x11vnc -version : 0.9.16
VGA compatible controller: Intel Corporation Apollo Lake [HD Graphics 505]
kernel : 6.4.3-arch1-1
Using modesetting driver
```
Test workflow \#1 (expected behavior):
- \<Monitor is visibly off\>
- xset q | grep Monitor
- Monitor is Off
- \<tap the touchscreen\>
- \<Monitor is visibly on\>
- xset q | grep Monitor
- Monitor is On
Test workflow \#2 (unexpected behavior):
- \<Monitor is visibly off\>
- xset q | grep Monitor
- Monitor is Off
- \<click on window in VNC client\>
- \<Monitor is visibly on\>
- xset q | grep Monitor
- Monitor is Off
Please let me know if there's any additional information you need.https://gitlab.freedesktop.org/xorg/app/xinit/-/issues/22Raspberry pi start issues2023-08-11T20:57:14ZJonathanRaspberry pi start issuesI went to reboot my pi today and it got stuck in a boot loop (enter password goback to login...)
then i goto my shell (ctrl + alt + F2) and i try to start the desktop with `startx` but instead i got this
<details><summary>Error</summary>...I went to reboot my pi today and it got stuck in a boot loop (enter password goback to login...)
then i goto my shell (ctrl + alt + F2) and i try to start the desktop with `startx` but instead i got this
<details><summary>Error</summary>
```diff
jonathan@raspberrypi:" $ startx
xauth: unable to write authority file /tmp/serverauth.AzxNa65a0n-n
xauth: unable to write authority file /tmp/serverauth.AzxNa65a0n-n
xauth: unable to write authority file /tmp/serverauth.AzxNa65a0n-n
CEE)
Fatal server error:
(EE) Could not write pid to lock file in /tmp/.tX1-lock
(EE)
(EE)
Please consult the The X.0rg Foundation support
at http://wiki.x.org
for help.
(EE)
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
```
</details>https://gitlab.freedesktop.org/xorg/xserver/-/issues/1569Crash / freeze when switching between GUI desktop and tty on Artix, Arch and ...2023-08-04T21:52:32ZdvdCrash / freeze when switching between GUI desktop and tty on Artix, Arch and DevuanSwitching to a tty console results in an empty black screen perhaps 25% of the time, although you can get a sequence of it working or not. This freeze can usually be exited by pressing Fn + F10 (KB backlight) to cycle the keyboard backli...Switching to a tty console results in an empty black screen perhaps 25% of the time, although you can get a sequence of it working or not. This freeze can usually be exited by pressing Fn + F10 (KB backlight) to cycle the keyboard backlight to off, mid and full, then Fn + Insert (sleep) and after it has gone to sleep, press the power button to wake up and it returns to the expected state showing the tty. This is true for the current Zen kernel and LTS kernel, but it didn't happen with an older kernel. I tried updating the BIOS to the latest version and disabling all the performance options and virtualization support in the BIOS, forcing the CPU to 100% all the time with one core and thread, with no change. It is worse using the linux-git kernel and happens almost all the time.
First I tried the kernels available in the Artix archive, the problem started between these two versions:
Bad: linux-5.16.1.artix1-1-x86_64.pkg.tar.zst 16-Jan-2022 13:55
Good: linux-5.15.12.artix1-1-x86_64.pkg.tar.zst 30-Dec-2021 12:03
Then I tried the Arch archive:
Bad: linux-5.16.arch1-1-x86_64.pkg.tar.zst
Good: linux-5.15.13.arch1-1-x86_64.pkg.tar.zst
Then I bisected the kernel:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/8e07757bece6e81b0b0910358ebceca3032bc6c7%5E%21/#F0
It seemed this commit was where the problem started:
commit 8e07757bece6e81b0b0910358ebceca3032bc6c7 (HEAD)
Author: Shyam Prasad N <sprasad@microsoft.com>
Date: Mon Jul 19 10:03:38 2021 +0000
cifs: do not negotiate session if session already exists
Reverting the patch in linux-git did not fix the issue, but changed / improved it. It seemed there were a lot of changes in this section of code including the function in question, the file had even moved to fs/smb/client/connect.c from it's previous location. Unmodified linux-git would never recover by pressing sleep, it required a forced power off. With the reverted patch sleep then resume almost always worked but still it often went to a black screen when switching to a tty. On recovery this message can sometimes be seen on the tty and in syslog:
__common_interrupt: 0.55 No irq handler for vector
I also found on a Dell M4400 a possible variation of the problem, when switching from a tty back to the desktop, the desktop crashes back to the login tty, as I have startx and autologin set up it then restarts automatically although any previously open apps were forcibly terminated in the crash. This happens only about say one in 50 times so it is not so obvious. But on a Dell M4500, switching tty works normally.
There was a similar bug (fixed now) in December 2021 relating to xorg and xorg-server:
https://bbs.archlinux.org/viewtopic.php?id=272327
This does not seem to happen when I use either a 5.15.12 or 5.16.1 Artix kernel on the M4400, so it was not triggered by the exact same commit on there.
I added a printk to the commit revert to try and find out when this was getting called, as I had not found any sign of it using trace-cmd when switching to a tty. But the printk output never appears in dmesg or syslog, even after switching to a tty and freezing - or not. So it looks like this section of code is not used. I don't use any samba things and also did -Rs samba caja-share to remove the samba package and related items, which has not changed the situation either. I guess from this that some kind of buffer overflow / memory corruption / stack smashing type situation could be loading this part of the kernel code due to an error elsewhere, even though it is not being used in the normal course of events?
I installed Gnome desktop (which uses wayland) and gdm, starting the Mate desktop with gdm still has the problem, so it isn't xinitrc, but Gnome using Wayland is not affected, while Gnome using Xorg is, so it seems to be an Xorg bug, or at least Xorg related. Then I tried downgrading various xorg components to see if older versions behaved differently, but they didn't, and beyond a certain point it became difficult with an otherwise updated system due to changes in libxcvt and the switch in Artix away from eudev.
I went back as far as these versions with no change in behaviour:
xf86-input-evdev-2.10.6-2.1-x86_64.pkg.tar.zst
xf86-video-fbdev-0.5.0-2.1-x86_64.pkg.tar.zst
xorg-server-xephyr-1.20.13-3-x86_64.pkg.tar.zst
xf86-input-libinput-1.2.0-1-x86_64.pkg.tar.zst
'xf86-video-intel-1 2.99.917+916+g31486f40-1.1-x86_64.pkg.tar.zst'
xorg-server-xnest-1.20.13-3-x86_64.pkg.tar.zst
xf86-input-synaptics-1.9.1-2-x86_64.pkg.tar.zst
xorg-server-1.20.13-3-x86_64.pkg.tar.zst
xorg-server-xvfb-1.20.13-3-x86_64.pkg.tar.zst
xf86-input-vmmouse-13.1.0-5.1-x86_64.pkg.tar.zst
xorg-server-common-1.20.13-3-x86_64.pkg.tar.zst
xf86-video-dummy-0.3.8-4.1-x86_64.pkg.tar.zst
xorg-server-devel-1.20.13-3-x86_64.pkg.tar.zst
Arch Linux (with systemd) has exactly the same problem. Devuan Daedalus is slightly different - you can switch to another tty, but cannot then switch back to tty7 and the GUI display, either using ctrl alt f7 or chvt. Trying to do so results in the cursor on the tty you are on freezing and becoming unresponsive. But here you can switch back to the existing tty, say tty2, and continue as you were, it is just impossible to return to tty7 once you have left it. In the same way as Artix, using Gnome Wayland works normally but Gnome Xorg exhibits the bug. Switching to tty1 is still possible where GDM starts up though.
This is using a Dell E7470 Ultrabook, hw details:
System:
Kernel: 5.8.14-artix1-1 arch: x86_64 bits: 64 compiler: gcc v: 10.2.0
Desktop: MATE v: 1.27.0 Distro: Artix Linux base: Arch Linux
Machine:
Type: Laptop System: Dell product: Latitude E7470 v: N/A serial: <filter>
Mobo: Dell model: 0T6HHJ v: A00 serial: <filter> UEFI: Dell v: 1.36.3
date: 09/18/2022
Battery:
ID-1: BAT0 charge: 30.4 Wh (100.0%) condition: 30.4/55.0 Wh (55.2%)
volts: 8.6 min: 7.6 model: LGC-LGC3.65 DELL 242WD6C status: full
CPU:
Info: dual core model: Intel Core i7-6600U bits: 64 type: MT MCP
arch: Skylake rev: 3 cache: L1: 128 KiB L2: 512 KiB L3: 4 MiB
Speed (MHz): avg: 2645 high: 2882 min/max: 400/3400 cores: 1: 2808 2: 2882
3: 2550 4: 2340 bogomips: 22408
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
Graphics:
Device-1: Intel Skylake GT2 [HD Graphics 520] vendor: Dell Latitude E7470
driver: i915 v: kernel arch: Gen-9 bus-ID: 00:02.0
Display: server: X.Org v: 21.1.8 with: Xwayland v: 23.1.2 driver: X:
loaded: intel unloaded: fbdev,modesetting dri: i965 gpu: i915
resolution: 1920x1080~60Hz
API: OpenGL Message: Unable to show GL data. Required tool glxinfo
missing.
Network:
Device-1: Intel Wireless 8260 driver: iwlwifi v: kernel bus-ID: 01:00.0
IF: wlan0 state: down mac: <filter>
Drives:
Local Storage: total: 238.47 GiB used: 71.3 GiB (29.9%)
ID-1: /dev/nvme0n1 vendor: Western Digital model: PC SN720
SDAPNTW-256G-1016 size: 238.47 GiB temp: 40.9 C
Partition:
ID-1: / size: 120 GiB used: 71.07 GiB (59.2%) fs: btrfs dev: /dev/nvme0n1p6
ID-2: /boot size: 500 MiB used: 228.7 MiB (45.7%) fs: btrfs
dev: /dev/nvme0n1p2
ID-3: /boot/efi size: 299.4 MiB used: 292 KiB (0.1%) fs: vfat
dev: /dev/nvme0n1p1
ID-4: swap-1 size: 16 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p3
Info:
Processes: 199 Uptime: 11m Memory: available: 7.67 GiB
used: 680.6 MiB (8.7%) Init: OpenRC runlevel: default Compilers: gcc: 13.1.1
Packages: 707 Shell: Bash v: 5.1.16 inxi: 3.3.27
[]([oldkernelswitchingttynoproblemXorg.0.log.gz](/uploads/1012cd750a867af793f46f0753231c92/oldkernelswitchingttynoproblemXorg.0.log.gz)[example-of-ttyblackscreen-Xorg.0.log.gz](/uploads/415f9ec8713ae1c7c25a57c5b92a2ede/example-of-ttyblackscreen-Xorg.0.log.gz)[commitrevertpatch.diff.gz](/uploads/bf17cf034a7fd466df59fa224dcbc684/commitrevertpatch.diff.gz)https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/issues/23make a new release2023-08-17T10:12:51ZXaver Huglmake a new releaseWhile there aren't a lot of changes since the last release (91178913c25b19e0457cdf6d21e00e6a613823e2 and b016df100111b56d7c1a2c63ea6791b2287a83e4) seem to be the only actual protocol changes, I'd like to make use of 91178913c25b19e0457cd...While there aren't a lot of changes since the last release (91178913c25b19e0457cdf6d21e00e6a613823e2 and b016df100111b56d7c1a2c63ea6791b2287a83e4) seem to be the only actual protocol changes, I'd like to make use of 91178913c25b19e0457cdf6d21e00e6a613823e2 and with the current development speed it's unlikely a lot of changes will be added soon. So I think it would be appropriate to make a new release now.https://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/app/xclock/-/issues/425 hour, 26 hour2023-08-03T03:25:12ZAlex Remizoff25 hour, 26 hour```
xclock -digital -strftime '%a, %d %b, %Y-%m-%d %H:%M:%S' -update 1 -face 'Liberation Mono:size=72'
```
![photo_2023-08-03_06-23-06](/uploads/36c5e999cea2d5c8f98a7b65d77c639b/photo_2023-08-03_06-23-06.jpg)
![Снимок_экрана_2023-08-03...```
xclock -digital -strftime '%a, %d %b, %Y-%m-%d %H:%M:%S' -update 1 -face 'Liberation Mono:size=72'
```
![photo_2023-08-03_06-23-06](/uploads/36c5e999cea2d5c8f98a7b65d77c639b/photo_2023-08-03_06-23-06.jpg)
![Снимок_экрана_2023-08-03_06-24-20](/uploads/49bc9217b318a3ee0b0a9c85827e5529/Снимок_экрана_2023-08-03_06-24-20.png)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/195Still reachable bytes, is that unavoidable?2023-09-02T20:14:12ZHenrique N. LenglerStill reachable bytes, is that unavoidable?I am developing a program using Xlib, and by running it through valgrind it detects many bytes that are still reachable after execution.
I posted the details and a minimal example here: https://stackoverflow.com/questions/76808501/xlib...I am developing a program using Xlib, and by running it through valgrind it detects many bytes that are still reachable after execution.
I posted the details and a minimal example here: https://stackoverflow.com/questions/76808501/xlib-memory-leak-when-loading-specific-font-string
I am using LibX11 6.4.0.
I know still reachable bytes are not that much of a problem, but I think ideally programs must have a clean exit.
Is this inevitable?
Thanks,https://gitlab.freedesktop.org/xorg/app/xditview/-/issues/1pop-up menu doesn't work2023-07-29T18:49:42ZG. Branden Robinsonpop-up menu doesn't workMenu items in the pop-up menu (drawn over the Dvi widget) cannot be selected.
To reproduce:
1. Launch xditview.
2. Left-click on the main window (not in the menu or scroll bars).
3. Attempt to select an item.
This issue also affects gr...Menu items in the pop-up menu (drawn over the Dvi widget) cannot be selected.
To reproduce:
1. Launch xditview.
2. Left-click on the main window (not in the menu or scroll bars).
3. Attempt to select an item.
This issue also affects groff's gxditview client, which is how it came to my attention. However, it does not affect _all_ of our users, so I suspect a problem with one of the libraries.
Background (possibly tedious):
A. https://lists.gnu.org/archive/html/groff/2023-07/msg00138.html
B. https://lists.gnu.org/archive/html/groff/2023-07/msg00153.htmlhttps://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/app/xinit/-/issues/21xinit tries to use :0 every time.2023-07-29T15:40:54ZNobodyxinit tries to use :0 every time.I tried to start a second X server on my system, using startx, and it failed saying that Server :0 was already running. This is true, but there were may other available integeres.
I tracked down the issue to xinit, and created the foll...I tried to start a second X server on my system, using startx, and it failed saying that Server :0 was already running. This is true, but there were may other available integeres.
I tracked down the issue to xinit, and created the following patch, which works for me.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/193display crashes on thin images2023-07-25T16:20:01Zthesourcerer8display 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/af18ffa80855b1e165e8977524c7e431/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/af18ffa80855b1e165e8977524c7e431/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/6070967f4e7ff8cb465bac134935f531/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/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/lib/libx11/-/issues/192Switch Compose.pre files into a different source format2024-01-03T22:23:00ZPeter HuttererSwitch Compose.pre files into a different source formatMoving out the discussion here https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/224#note_2005803 so we can discuss this independently, copy-pasted from that thread:
@wismill:
> Relying on spaces is not robust. I would ad...Moving out the discussion here https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/224#note_2005803 so we can discuss this independently, copy-pasted from that thread:
@wismill:
> Relying on spaces is not robust. I would advocate for some prefix, such as `* `or `CJK: `; or surrounding with some brackets, such as: `<YUAN / WEN>`.
@whot:
> I should've thought of that yesterday but: the `Compose.pre` files are just source artifacts. If someone had the motivation we could switch those to e.g. YAML or TOML at which point both editing and checking it for correctness would be significantly simpler. And this way we can add extra comments at will for human consumption that don't need to be parsed.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)