xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2023-09-21T12:11:03Zhttps://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/issues/226PCI ID list out of date2023-09-21T12:11:03ZDavid OberPCI ID list out of date The file i915_pciids.h has not been updated since Tiger Lake and I have users getting unknown device ID when running un the Alderlake 770 chip They also expect to still be running using xorg with Raptor Lake The file i915_pciids.h has not been updated since Tiger Lake and I have users getting unknown device ID when running un the Alderlake 770 chip They also expect to still be running using xorg with Raptor Lakehttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1573Key release events wake up monitors in DPMS standby2023-08-19T10:03:40ZChris BainbridgeKey release events wake up monitors in DPMS standby(this issue may not be filed against the right project - I don't know exactly which code wakes the monitors back up)
- hold shift
- run `xset dpms force standby`
- release shift after a second
- monitors go to standby but then immediate...(this issue may not be filed against the right project - I don't know exactly which code wakes the monitors back up)
- hold shift
- run `xset dpms force standby`
- release shift after a second
- monitors go to standby but then immediately wake back up
This has been a problem for years, and developers appear to workaround it by adding something like "sleep 1" before running a screen locker (e.g. see the xflock4 commit at https://gitlab.xfce.org/xfce/xfce4-session/-/issues/178 ).
I wonder if it would be possible to fix the root cause by waking up on key press events as usual, but just ignoring key **release** events?https://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/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/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/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/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/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/1563xwayland rootful: Use a better default size without a geometry specified2023-07-27T08:01:32ZOlivier Fourdanxwayland rootful: Use a better default size without a geometry specifiedThe following discussion from !1133 should be addressed:
- [ ] @jadahl started a [discussion](https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1133#note_2004598): (+4 comments)
> If you want even better default, listen...The following discussion from !1133 should be addressed:
- [ ] @jadahl started a [discussion](https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1133#note_2004598): (+4 comments)
> If you want even better default, listen to `xdg_toplevel.configure_bounds()` and e.g. do 50% of the bounds. 640x480 will be ridiculously tiny on a 4K monitor.
Something similar would be useful for fullscreen as well.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1562pop up does not get focus2023-07-16T19:29:30ZTsahi Asherpop up does not get focusSetup:
Windows 11
wsl ubuntu 22.04
windows xserver - xming (vcxsrv) 1.20.14.0 with the following parameters
<XLaunch WindowMode="MultiWindow" ClientMode="NoClient" LocalClient="False" Display="-1" LocalProgram="xcalc" RemoteProgram="xter...Setup:
Windows 11
wsl ubuntu 22.04
windows xserver - xming (vcxsrv) 1.20.14.0 with the following parameters
<XLaunch WindowMode="MultiWindow" ClientMode="NoClient" LocalClient="False" Display="-1" LocalProgram="xcalc" RemoteProgram="xterm" RemotePassword="" PrivateKey="" RemoteHost="" RemoteUser="" XDMCPHost="" XDMCPBroadcast="False" XDMCPIndirect="False" Clipboard="True" ClipboardPrimary="True" ExtraParams="" Wgl="False" DisableAC="False" XDMCPTerminate="False"/>
problem:
When i use an app some popup windows do not get focused, I have no way to make any button of the popup work, not with the mouse and not with the keyboard, not any button in the popup, but also not main windows buttons (close maximize etc), i also can not drag and move the windows. Attached are two examples from the freeview app. The "load surface overlay" is a pop up that is responding, the "configure overlay" pop up is the one that i can not get to work.
![load](/uploads/f0b658608adf4f78b1925272a1993185/load.jpg)
![configure](/uploads/62fbff1772977e7972815e70e195b691/configure.jpg)
If this is not the right forum, i am sorry, please tell me where i can post this problem.https://gitlab.freedesktop.org/xorg/app/xkbprint/-/issues/3Make DEBUG builds useful2023-07-13T13:49:43ZJohn DrinkwaterMake DEBUG builds usefulThere are sections of xkbprint.c that contain `#ifdef DEBUG` that don’t appear to enable debugging features, and that add an entry `-I` to usage that doesn’t appear to exist.There are sections of xkbprint.c that contain `#ifdef DEBUG` that don’t appear to enable debugging features, and that add an entry `-I` to usage that doesn’t appear to exist.https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/70Segfault on suspend, unplug dock, resume2023-09-07T07:38:05ZChris BainbridgeSegfault on suspend, unplug dock, resumeRegarding merge request !85
Following on from drm/amd bug reports https://gitlab.freedesktop.org/drm/amd/-/issues/2375#note_1987516
I tracked the Xorg driver crash down to a null pointer dereference.
I am not familiar with the Xorg a...Regarding merge request !85
Following on from drm/amd bug reports https://gitlab.freedesktop.org/drm/amd/-/issues/2375#note_1987516
I tracked the Xorg driver crash down to a null pointer dereference.
I am not familiar with the Xorg amdgpu code so this may not be the correct way to go about it, and this may not be the only possible segfault. I ran gdb attached to Xorg and could see that, after the external monitors were disconnected and resume done, `drmmode_set_mode` was still iterating over data structures for the disconnected external monitors, and attempts to dereference a NULL pointer. The call to `drmmode_set_mode` appears to be attempting to change the mode on one of those disconnected monitors.
The crash happens randomly on resume, but I found one (mostly) reproducible test case, which is:
* plug dock in with 3 external monitors
* close laptop lid (laptop display goes off)
* suspend using XFCE command (I think there is something timing sensitive here - a simple `systemctl suspend` does not trigger it)
* unplug USB dock
* resume by opening laptop lid
The patch fixes this test case. The gdb backtrace was:
```
#0 0x00007f2029565e82 in drmmode_set_mode
(crtc=crtc@entry=0x55a0c7610390, fb=fb@entry=0x55a0c86d7410, mode=mode@entry=0x55a0c76103a8, x=x@entry=0, y=y@entry=0) at drmmode_display.c:1267
#1 0x00007f20295663f6 in drmmode_set_mode_major
(crtc=0x55a0c7610390, mode=0x55a0c76103a8, rotation=<optimized out>, x=<optimized out>, y=<optimized out>) at drmmode_display.c:1371
#2 0x00007f202955ff8a in AMDGPUUnblank (pScrn=pScrn@entry=0x55a0c740a8e0) at amdgpu_kms.c:1823
#3 0x00007f2029560047 in AMDGPUSaveScreen_KMS (pScreen=<optimized out>, mode=1) at amdgpu_kms.c:1905
#4 0x000055a0c643803c in dixSaveScreens ()
#5 0x000055a0c64b9ab5 in ()
#6 0x000055a0c64b9b35 in ()
#7 0x000055a0c6407734 in ()
#8 0x000055a0c640b6cc in ()
#9 0x00007f2029e4618a in __libc_start_call_main
(main=main@entry=0x55a0c63f4b40, argc=argc@entry=10, argv=argv@entry=0x7fffb7cefbf8)
at ../sysdeps/nptl/libc_start_call_main.h:58
#10 0x00007f2029e46245 in __libc_start_main_impl
(main=0x55a0c63f4b40, argc=10, argv=0x7fffb7cefbf8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffb7cefbe8) at ../csu/libc-start.c:381
#11 0x000055a0c63f4b71 in _start ()
```
This crash is specific to the amdgpu driver. The modesetting driver does not crash under the same test case on the same hardware.https://gitlab.freedesktop.org/xorg/app/xedit/-/issues/2Quit action triggered immidiatly when running in Xwayland2023-07-02T23:21:31Zyuki joouQuit action triggered immidiatly when running in XwaylandTrying to use xedit through Xwayland triggers the Quit action immediately on startup. Digging a bit in with a debugger, I can see the following stacktrace when adding a breakpoint on the QuitAction function in commads.c
```
(gdb) bt
#0 ...Trying to use xedit through Xwayland triggers the Quit action immediately on startup. Digging a bit in with a debugger, I can see the following stacktrace when adding a breakpoint on the QuitAction function in commads.c
```
(gdb) bt
#0 QuitAction (w=0x555555636320, event=0x7fffffffbb70, params=0x0, num_params=0x7ffff7eeb2f0) at commands.c:100
#1 0x00007ffff7ecbc8f in ?? () from /usr/lib/libXt.so.6
#2 0x00007ffff7ecbf1e in ?? () from /usr/lib/libXt.so.6
#3 0x00007ffff7ecc753 in _XtTranslateEvent () from /usr/lib/libXt.so.6
#4 0x00007ffff7ea38a4 in XtDispatchEventToWidget () from /usr/lib/libXt.so.6
#5 0x00007ffff7eac944 in ?? () from /usr/lib/libXt.so.6
#6 0x00007ffff7ea4ac2 in XtDispatchEvent () from /usr/lib/libXt.so.6
#7 0x00007ffff7eb08c2 in XtAppProcessEvent () from /usr/lib/libXt.so.6
#8 0x00007ffff7ea533a in XtAppMainLoop () from /usr/lib/libXt.so.6
#9 0x00005555555776cc in main (argc=1, argv=0x7fffffffdf18) at xedit.c:333
```
This makes the program unusable, because this immediately kills it.
This was tested on ArchLinux, using the labwc compositorhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1560Flickering after screen rotation2023-07-03T08:10:59Zgreen-green-avkFlickering after screen rotation<https://github.com/green-green-avk/AnotherTerm/issues/41#issuecomment-1613507617>
Flickering after screen rotation...
* **Borken**: Debian `xwayland (2:22.1.9-1)` (`The X.Org Foundation Xwayland Version 22.1.9 (12201009)`)
* **Ok**: D...<https://github.com/green-green-avk/AnotherTerm/issues/41#issuecomment-1613507617>
Flickering after screen rotation...
* **Borken**: Debian `xwayland (2:22.1.9-1)` (`The X.Org Foundation Xwayland Version 22.1.9 (12201009)`)
* **Ok**: Debian `xwayland (2:1.20.11-1+deb11u6)`
It tries to use old buffers each time after screen size changes:
<https://gitlab.freedesktop.org/-/snippets/7651#LC96>
```
[ 103004.732] -> wl_shm@4.create_pool(new id wl_shm_pool@23, fd 10, 9054720)
[ 103004.787] -> wl_shm_pool@23.create_buffer(new id wl_buffer@21, 0, 1080, 2096, 4320, 1)
[ 103004.809] -> wl_shm_pool@23.destroy()
```
<https://gitlab.freedesktop.org/-/snippets/7651#LC191>
```
[ 105296.196] wl_output@5.geometry(0, 0, 143, 64, 1, "Lindon inc.", "Palantir v1", 0)
[ 105296.591] wl_output@5.mode(3, 2181, 995, 60000)
[ 105296.701] wl_output@5.done()
```
<https://gitlab.freedesktop.org/-/snippets/7651#LC224>
```
[ 106975.484] -> wl_shm@4.create_pool(new id wl_shm_pool@20, fd 10, 8680380)
[ 106975.553] -> wl_shm_pool@20.create_buffer(new id wl_buffer@22, 0, 2181, 995, 8724, 1)
[ 106975.570] -> wl_shm_pool@20.destroy()
```
<https://gitlab.freedesktop.org/-/snippets/7651#LC387>
```
[ 107738.231] wl_display@1.delete_id(20)
[ 107738.417] wl_pointer@17.frame()
[ 107738.548] wl_callback@20.done(106)
[ 107746.446] -> wl_surface@10.attach(wl_buffer@22, 0, 0)
[ 107746.652] -> wl_surface@10.damage_buffer(0, 0, 2175, 994)
[ 107746.759] -> wl_surface@10.frame(new id wl_callback@20)
[ 107746.860] -> wl_surface@10.commit()
[ 107748.698] wl_pointer@17.motion(579133439, 1871.86718750, 92.89453125)
[ 107748.907] wl_pointer@17.frame()
[ 107752.163] wl_buffer@21.release()
[ 107761.402] wl_pointer@17.motion(579133456, 1896.17578125, 81.51171875)
[ 107763.173] wl_pointer@17.frame()
[ 107776.670] wl_pointer@17.motion(579133472, 1925.40234375, 66.12890625)
[ 107777.237] wl_pointer@17.frame()
[ 107795.278] wl_pointer@17.motion(579133489, 1955.70703125, 52.90234375)
[ 107795.427] wl_pointer@17.frame()
[ 107810.895] wl_pointer@17.motion(579133506, 1982.62890625, 42.75000000)
[ 107811.062] wl_pointer@17.frame()
[ 107813.325] wl_display@1.delete_id(20)
[ 107813.407] wl_callback@20.done(107)
[ 107816.666] -> wl_surface@10.attach(wl_buffer@21, 0, 0)
[ 107816.792] -> wl_surface@10.damage_buffer(0, 0, 2175, 994)
[ 107816.835] -> wl_surface@10.frame(new id wl_callback@20)
[ 107816.864] -> wl_surface@10.commit()
[ 107824.405] wl_buffer@22.release()
[ 107825.966] wl_pointer@17.motion(579133522, 2010.16796875, 34.90234375)
[ 107828.897] wl_pointer@17.frame()
[ 107844.842] wl_pointer@17.motion(579133539, 2033.85546875, 27.05859375)
[ 107845.467] wl_pointer@17.frame()
[ 107859.590] wl_pointer@17.motion(579133556, 2053.85546875, 20.13671875)
[ 107859.962] wl_pointer@17.frame()
[ 107878.827] wl_pointer@17.motion(579133572, 2071.85546875, 13.36718750)
[ 107879.071] wl_pointer@17.frame()
[ 107887.907] wl_callback@20.done(108)
[ 107894.053] -> wl_surface@10.attach(wl_buffer@22, 0, 0)
[ 107894.137] -> wl_surface@10.damage_buffer(0, 0, 2175, 994)
[ 107894.173] -> wl_surface@10.frame(new id wl_callback@19)
[ 107894.204] -> wl_surface@10.commit()
[ 107894.838] wl_display@1.delete_id(20)
[ 107894.922] wl_pointer@17.motion(579133589, 2087.23828125, 6.75390625)
[ 107894.944] wl_pointer@17.frame()
[ 107902.884] wl_buffer@21.release()
[ 107917.503] wl_pointer@17.motion(579133606, 2099.39062500, -1.39453125)
[ 107917.574] wl_pointer@17.frame()
[ 107967.034] wl_callback@19.done(109)
[ 107970.540] -> wl_surface@10.attach(wl_buffer@21, 0, 0)
[ 107970.660] -> wl_surface@10.damage_buffer(0, 0, 2175, 994)
[ 107970.700] -> wl_surface@10.frame(new id wl_callback@20)
[ 107970.722] -> wl_surface@10.commit()
[ 107971.024] wl_display@1.delete_id(19)
[ 107974.618] wl_buffer@22.release()
[ 108023.124] wl_callback@20.done(110)
[ 108023.304] wl_display@1.delete_id(20)
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1559Touchsceen click discard after open nm-applet menu then click desktop2023-07-26T12:03:54Zpines liTouchsceen click discard after open nm-applet menu then click desktopenvironment description:
1. Debian 10, LXDE OpenBOX
2. xserver-xorg-core version: 2:1.20.4-1
3. touchscreen driver: gt9xx.c
4. hardware platform: rockchip rk3288 which is 32bit armhf, also reproduce under rk3399 which is 64bit ARCH64.
...environment description:
1. Debian 10, LXDE OpenBOX
2. xserver-xorg-core version: 2:1.20.4-1
3. touchscreen driver: gt9xx.c
4. hardware platform: rockchip rk3288 which is 32bit armhf, also reproduce under rk3399 which is 64bit ARCH64.
reproduce procedure:
1. Touch applets in "tray-zone" like nm-appet to active their menu.
2. Touch somewhere on desktop or taskbar except menu. menu will closed
3. Then [Start menu], and Desktiop ICON stop response touch click event. ( you may moving mouse pointer to there, but click not working )
4. This can be reproduce 100%
5. The window program opened already can respone touch click event correctly, also mini ICON in quick-start bar like chorme, PCmanFM can been active by touch click.
6. Tt will last until you moving some window, moving by what i mean is keep finger touch the title of a window program then moving a little bit to diffrence x,y position.
note:
1. this issue can be reproduced while switch to xfce4 and xfwm4 (another lightweight desktop)
which imply it's independant to window manager or desktop.
2. through xinput test-xi2 --root print output, touch begin/end event is correct while touch click bug happen.
3. Using program like NetworkManager nm-applet, bluetooth applet both have menu will trigger bug.
menu from APPs like Mousepad and Galculator also does. pcmanFM's menu(a filemanager of LXDE) doesn't have this issue.
they have difference style of menu while could been tell by look.
any idea might be useful is a welcome feedback.
attached within:
1. xinput print output.
2. desktop operate video record.
[touchscreen-applet-menu-bug](/uploads/69fadd6e901cc48a3ca164b6d629932c/touchscreen-applet-menu-bug.mp4)
[xinput-touchscreen-event.log](/uploads/44781d9a21823dfdf86a4713024629fb/xinput-touchscreen-event.log)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/190No Multi_key sequences for letters with macron below2023-06-21T14:50:01Zjmcwilliams403No Multi_key sequences for letters with macron belowLatin letters with macron below are used in the standard orthography of various Native American and Indigenous Australian languages, as well as the romanization of various Indian languages.
Letters which have precomposed Unicode characte...Latin letters with macron below are used in the standard orthography of various Native American and Indigenous Australian languages, as well as the romanization of various Indian languages.
Letters which have precomposed Unicode characters with macron below are mutually exclusive with letters with macron above.<br>
<br>
Existing atomic characters with macron above are as follows:<br>
`Āā`/`Ǣǣ`/`Ēē`/`Ḡḡ`/`Īī`/`Ōō`/`Ūū`/`Ȳȳ`<br>
Existing atomic characters with macron below are as follows:<br>
`Ḇḇ`/`Ḏḏ`/`ẖ`/`Ḵḵ`/`Ḻḻ`/`Ṉṉ`/`Ṟṟ`/`Ṯṯ`/`Ẕẕ`<br>
<br>
There do exist `Ḹḹ`/`Ṝṝ` but these also have a dot below which makes them still not overlap as it's no longer just an atomic character + macron. Otherwise, no letters are shared in common.<br>
<br>
I would like to suggest perhaps implementing sequences in the format of e.g. `<Multi_key> <underscore> <letter>` for letters with macron below as there are no Latin-script letters which would have conflicting sequences for both macron above and below in this format.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/189XmbTextListToTextProperty() can SEGV with invalid/corrupt locale data2023-06-19T03:37:23ZGJDuckXmbTextListToTextProperty() can SEGV with invalid/corrupt locale dataIt seems possible to crash Xlib with invalid/corrupt locale data.
Attached is an example and below are steps to reproduce. Tested on libX11-1.8.6 built from source:
1. Build libx11-1.8.6 from source
2. Replace nls/C/XLC_LOCALE...It seems possible to crash Xlib with invalid/corrupt locale data.
Attached is an example and below are steps to reproduce. Tested on libX11-1.8.6 built from source:
1. Build libx11-1.8.6 from source
2. Replace nls/C/XLC_LOCALE with attached version
3. Change directory into src/.libs/ and execute:
$ gdb -ex "set exec-wrapper env LC_ALL=C LD_LIBRARY_PATH=$PWD XLOCALEDIR=../../nls/" /usr/bin/xpdf.real
Appears to be a NULL pointer dereference.
[XLC_LOCALE](/uploads/e7839d09c5481289461671acb1d73661/XLC_LOCALE)