xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2023-10-19T11:05:59Zhttps://gitlab.freedesktop.org/xorg/util/makedepend/-/issues/6Problem with same-file detection in inc_path()2023-10-19T11:05:59ZHagbard CelineProblem with same-file detection in inc_path()I am working in a non-POSIX environment, and had to do several changes to the path handling to get to the point where I could discover this. But I'm quite sure the original code behaves the same at the point in question in the following ...I am working in a non-POSIX environment, and had to do several changes to the path handling to get to the point where I could discover this. But I'm quite sure the original code behaves the same at the point in question in the following issue. Please excuse me if I'm wrong.
The behavior I observe rewritten in POSIX terms: Relative to my current directory i got a source file ./myoprg/myprog.c. myprog.c includes two files that are referenced relative to my current directory with:
`#include "../otherdir/include1.h"`
`#include "../otherdir/include2.h"`
The file ../otherdir/include1.h includes ../otherdir/include1.h but referenced relative to its own location:
`#include "include2.h"`
When the parser finds the include2.h the second time it trips up in inc_path().
At line 337 in include.c, it will compare the strings "ip-\>i_incstring" (include2.h), from the first time it was included in include1.h, and "include" (../otherdir/include2.h) and decide they are different files.
If I change it to compare "ip-\>i_file" and "include" it will see they are the same file and behave as documented.https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/568Nouveau spits a lots of error in kernel logs & Xorg randomly hangs2023-10-16T20:13:26ZSébastien PicavetNouveau spits a lots of error in kernel logs & Xorg randomly hangsHi,
I create an issue about two things (but probably linked).
Since august, I got a lot of error in my logs:
```
ct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: magic set 1:
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: ...Hi,
I create an issue about two things (but probably linked).
Since august, I got a lot of error in my logs:
```
ct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: magic set 1:
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900409904: dc0b0005
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900409908: f73d8ad8
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x090040990c: 40000430
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900409910: 8ad80000
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: TRAP_TEXTURE - TP1: 00000003 [ FAULT]
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: 00200000 [] ch 10 [001eefa000 plasmashell[2502]] subc 3 class 8297 mthd 15e0 data 00000000
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: fb: trapped read at f73d8ad800 on channel 10 [1eefa000 plasmashell[2502]] engine 00 [PGRAPH] client 0a [TEXTURE] subclient 00 [] reason 00000000 [PT_NOT_PRESENT]
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: magic set 0:
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900408904: d429160f
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900408908: 353dad8f
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x090040890c: 40000430
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900408910: ad8f0000
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: TRAP_TEXTURE - TP0: 00000003 [ FAULT]
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: magic set 1:
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900409904: d429290f
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900409908: 353dad8f
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x090040990c: 40000430
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900409910: ad8f0000
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: TRAP_TEXTURE - TP1: 00000003 [ FAULT]
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: 00200000 [] ch 10 [001eefa000 plasmashell[2502]] subc 3 class 8297 mthd 15e0 data 00000000
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: magic set 0:
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900408904: d428000f
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900408908: 353dad8f
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x090040890c: 40000430
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900408910: ad8f0000
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: TRAP_TEXTURE - TP0: 00000003 [ FAULT]
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: magic set 1:
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900409904: d428280f
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900409908: 353dad8f
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x090040990c: 40000430
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: \x0900409910: ad8f0000
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: TRAP_TEXTURE - TP1: 00000003 [ FAULT]
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: gr: 00200000 [] ch 10 [001eefa000 plasmashell[2502]] subc 3 class 8297 mthd 15e0 data 00000000
Oct 11 22:07:36 fixe kernel: nouveau 0000:02:00.0: fb: trapped read at 353dad8f00 on channel 10 [1eefa000 plasmashell[2502]] engine 00 [PGRAPH] client 0a [TEXTURE] subclient 00 [] reason 00000000 [PT_NOT_PRESENT]
```
First, I tought it was a harware issue (my motherboard died few weeks after). But now, I changed it and also the graphic cards (changed due to next issues which I thought it was linked) and the issue is still here.
It is worst:
* I have also random hangs (no reaction keyboard/Ctrl+Alt+XXX). I do not remember if I had this issue before motherboard crash.
* I have also random loss of pixels (like the screenshot), this was not the case before motherboard crash.
So it does not look a hardware issue.
Versions:
* xorg => 21.1.8 (installed before 15th July 2023);
* xf86-video-nouveau => 1.0.17 (since 2th April 2023);
* various 6.1.x kernels => 6.1.53 in September (from 6.1.46) and 6.1.41 (from 6.1.38).
Let me know if I can help more…https://gitlab.freedesktop.org/xorg/lib/libxfont/-/issues/14Allow to configure pkgconfigdir2023-10-16T19:24:49ZMarcel TelkaAllow to configure pkgconfigdirI propose the following patch so users can configure the location of installed pkgconfig file(s).
```plaintext
--- libXfont2-2.0.6/Makefile.am.orig
+++ libXfont2-2.0.6/Makefile.am
@@ -43,7 +43,6 @@
src/FreeType/ftfuncs.h \...I propose the following patch so users can configure the location of installed pkgconfig file(s).
```plaintext
--- libXfont2-2.0.6/Makefile.am.orig
+++ libXfont2-2.0.6/Makefile.am
@@ -43,7 +43,6 @@
src/FreeType/ftfuncs.h \
src/util/replace.h
-pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = xfont2.pc
lib_LTLIBRARIES = libXfont2.la
--- libXfont2-2.0.6/configure.ac.orig
+++ libXfont2-2.0.6/configure.ac
@@ -65,6 +65,7 @@
# If the first PKG_CHECK_MODULES appears inside a conditional, pkg-config
# must first be located explicitly.
PKG_PROG_PKG_CONFIG
+PKG_INSTALLDIR
#
# select libraries to include
```https://gitlab.freedesktop.org/xorg/util/makedepend/-/issues/5Symbolic link detection in remove_dotdot() broken.2023-10-15T22:02:39ZHagbard CelineSymbolic link detection in remove_dotdot() broken.On line 106 in include.c "`newpath" is passed as argument to issymbolic(). But "newpath" is never updated during the while loop, so the same value of "/\0" or "\0" will be used in every iteration of the loop.`On line 106 in include.c "`newpath" is passed as argument to issymbolic(). But "newpath" is never updated during the while loop, so the same value of "/\0" or "\0" will be used in every iteration of the loop.`https://gitlab.freedesktop.org/xorg/app/xdm/-/issues/14Maybe logic flaw causing concurrency issue with startup and signal handling2023-10-15T14:45:46Zhalfdog meMaybe logic flaw causing concurrency issue with startup and signal handling**Observation:**
In Debian Bullseye/Bookworm virtual machines with single CPU, xdm, cron, logrotate installed, xdm fails with about 10% rate on startup. System logs show, that xdm startup and logrotate startup were activated by systemd ...**Observation:**
In Debian Bullseye/Bookworm virtual machines with single CPU, xdm, cron, logrotate installed, xdm fails with about 10% rate on startup. System logs show, that xdm startup and logrotate startup were activated by systemd at the same time. xdm seems to have created a pid file and touched xdm.log when logrotate moves xdm.log away and sends SIGUSR2 to trigger logrotation.
Logrotate does:
```
postrotate
if [ -r /var/run/xdm.pid ]; then \
kill -s USR2 $(cat /var/run/xdm.pid); \
fi
endscript
```
Systemd reports:
```
Oct 15 11:45:12 localhost systemd[1]: xdm.service: Main process exited, code=killed, status=12/USR2
Oct 15 11:45:12 localhost systemd[1]: xdm.service: Failed with result 'signal'.
```
**Hypothetical cause:**
According to
https://gitlab.freedesktop.org/xorg/app/xdm/-/blob/master/xdm/dm.c?ref_type=heads
main function
```
159 if ((oldpid = StorePid ()))
```
creates the pid but the signal handler is only installed later on in
```
246 StartDisplays ();
```
via calling StartServer and StartServerOnce.
Therefore logrotate may send the signal after the pidfile is ready but before the signal handler was setup correctly.
Due to the nature of the issue, the concurrency problem is a little tricky to debug. Can therefore someone with xdm design knowledge confirm, that my interpretation of the xdm code and reasoning is correct and signal handler setup is really done after pid file writing?
```https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/567nouveau system lockup: `fifo: write fault at 00025c0000 engine 15 [PCE0] clie...2023-10-13T08:54:09ZPaul Menzelnouveau system lockup: `fifo: write fault at 00025c0000 engine 15 [PCE0] client 01 [PCOPY0] reason 02 [PAGE_NOT_PRESENT] on channel 1 [003fc73000 DRM]`On a Dell Precision T7610 with
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108GL [Quadro 600] [10de:0df8] (rev a1)
and Linux 5.15.131, xf86-video-nouveau 1.0.17, Mesa 22.1.7, Firefox 118.0.2, RStudio 2022.02.3+49...On a Dell Precision T7610 with
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108GL [Quadro 600] [10de:0df8] (rev a1)
and Linux 5.15.131, xf86-video-nouveau 1.0.17, Mesa 22.1.7, Firefox 118.0.2, RStudio 2022.02.3+492 and Xfce 4.18, a user reports a freeze of their desktop environment. One window after another becomes unresponsive. The logs contain:
2023-10-12T14:13:34.509078+02:00 narnia kernel: [173073.183817] nouveau 0000:03:00.0: fifo: write fault at 00025c0000 engine 15 [PCE0] client 01 [PCOPY0] reason 02 [PAGE_NOT_PRESENT] on channel 1 [003fc73000 DRM]
2023-10-12T14:13:34.509106+02:00 narnia kernel: [173073.184801] nouveau 0000:03:00.0: fifo: ce0 engine fault on channel 1, recovering...
2023-10-12T14:13:34.515090+02:00 narnia kernel: [173073.206370] nouveau 0000:03:00.0: DRM: channel 1 killed!
[Linux 5.15.131 messages](/uploads/d66c0f2511b50bcb54ba49fe84f736e7/20231012--narnia--linux-5.15.131.txt)https://gitlab.freedesktop.org/xorg/driver/xf86-video-fbdev/-/issues/11Does fbdev support fb nodes that only support 24bppp ?2023-10-05T21:28:18Zravi chandra sadineniDoes fbdev support fb nodes that only support 24bppp ?We have a device that only supports 24bpp. does fbdev driver support 24bppp ? If so what does the conf file for that look like ?
Looking at the code, `FBDevPreInit()` seems to be forcing fbpp to 32 even when the hardware says it only...We have a device that only supports 24bpp. does fbdev driver support 24bppp ? If so what does the conf file for that look like ?
Looking at the code, `FBDevPreInit()` seems to be forcing fbpp to 32 even when the hardware says it only supports 24bpp: https://gitlab.freedesktop.org/xorg/driver/xf86-video-fbdev/-/blob/master/src/fbdev.c?ref_type=heads#L495. Am I understanding this correct ?https://gitlab.freedesktop.org/xorg/xserver/-/issues/1588May xwayland.pc be installed into /usr/share/pkgconfig?2023-10-05T16:24:32ZfundawangMay xwayland.pc be installed into /usr/share/pkgconfig?Currently, `xwayland.pc` looks like:
```
prefix=/usr
includedir=${prefix}/include
exec_prefix=${prefix}
xwayland=/usr/bin/Xwayland
have_glamor=true
have_eglstream=true
have_initfd=true
have_listenfd=true
have_verbose=true
have_terminate...Currently, `xwayland.pc` looks like:
```
prefix=/usr
includedir=${prefix}/include
exec_prefix=${prefix}
xwayland=/usr/bin/Xwayland
have_glamor=true
have_eglstream=true
have_initfd=true
have_listenfd=true
have_verbose=true
have_terminate_delay=true
have_no_touch_pointer_emulation=true
have_force_xrandr_emulation=true
have_geometry=true
have_fullscreen=true
have_host_grab=true
have_decorate=true
have_byteswappedclients=true
Name: Xwayland
Description: X Server for Wayland
Version: 23.2.1
Cflags: -I${includedir}
```
It does not contain any arch-dependent code, such as `$libdir`. Is it feasible installing it into `/usr/share/pkgconfig` rather than `/usr/lib64/pkgconfig` dir?https://gitlab.freedesktop.org/xorg/app/xman/-/issues/2Inconsistent number of column positions2023-10-04T21:06:56ZgldrkInconsistent number of column positionsCertain man programs (man-db) query their controlling terminal for the number of columns to format the output for. In the case of xman, this is whatever controlling terminal it happened to inherit from its parent process. This value is...Certain man programs (man-db) query their controlling terminal for the number of columns to format the output for. In the case of xman, this is whatever controlling terminal it happened to inherit from its parent process. This value is of no relevance to a graphical application and can confusingly change over time outside xman’s control.
I can think of two ways to get around this:
1. Get rid of the controlling terminal in man’s process environment. This would require replacing `system` with a `fork`-`setsid`-`exec` sequence at a minimum. There is a `setsid` command on some systems which is non-portable. As a side effect, this would prevent child processes from receiving SIGHUP when the terminal is detached, as well as job control signals (or these would have to be manually forwarded).
2. Export the COLUMNS environment variable, which is [supposed to override](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03) automatic detection. This raises the question of the number of columns to specify. This could be:
1. Some fixed value, such as 80.
2. An X resource value.
3. Calculated from xman’s window size.
![screenshot](/uploads/1ee10f03d917b7f4a1cb5e5b73339ae7/screenshot.png){height=500px}https://gitlab.freedesktop.org/xorg/xserver/-/issues/1585Unexpected periodic core dumps from Xwayland2023-09-27T06:34:51ZMahaer MahmudUnexpected periodic core dumps from XwaylandXwayland gives unexpected core dumps in the home directory every once in a while. They always follow the format `core.[process ID]`. This has been happening for several months now, and I do not know what is causing them. There are no not...Xwayland gives unexpected core dumps in the home directory every once in a while. They always follow the format `core.[process ID]`. This has been happening for several months now, and I do not know what is causing them. There are no noticeable program crashes which may lead to the creation of these files.
When I run `gdb` and then `bt full` on one of these dumps, I get this as a result (I have installed debugging symbols for the Void package `xorg-xserver-wayland`):
```
#0 __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
tid = 2002
ret = 0
pd = <optimized out>
old_mask = {__val = {119}}
ret = <optimized out>
#1 0x00007fb26759577f in __pthread_kill_internal (signo=6,
threadid=<optimized out>) at pthread_kill.c:78
No locals.
#2 0x00007fb2675491a2 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#3 0x00007fb267533477 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20},
sa_mask = {__val = {94572039212631, 171515904, 94572064759248,
94572074350896, 140404214872879, 9, 7, 0, 7, 0, 94572039188127,
94572039518208, 2, 94572074350720, 94570884890624,
94572039517664}}, sa_flags = -116976128, sa_restorer = 0x0}
#4 0x0000560344cd8e8c in OsAbort () at ../os/utils.c:1363
No locals.
#5 0x0000560344cd913f in AbortServer () at ../os/log.c:879
No locals.
#6 FatalError (f=<optimized out>) at ../os/log.c:1017
args = {{gp_offset = 8, fp_offset = 48,
overflow_arg_area = 0x7ffd544cf820,
reg_save_area = 0x7ffd544cf760}}
args2 = {{gp_offset = 8, fp_offset = 48,
overflow_arg_area = 0x7ffd544cf820,
reg_save_area = 0x7ffd544cf760}}
beenhere = 1
#7 0x0000560344bae7a8 in InitOutput (screen_info=<optimized out>,
argv=0x7ffd544cfa58, argc=17) at ../hw/xwayland/xwayland.c:429
depths = {1, 4, 8, 15, 16, 24, 32}
bpp = {1, 8, 8, 16, 16, 32, 32}
i = <optimized out>
depths = <optimized out>
bpp = <optimized out>
i = <optimized out>
#8 dix_main (envp=<optimized out>, argv=<optimized out>, argc=<optimized out>)
at ../dix/main.c:189
i = <optimized out>
alwaysCheckForInput = {0, 1}
i = <optimized out>
alwaysCheckForInput = <optimized out>
pScreen = <optimized out>
pScreen = <optimized out>
remember_it = <optimized out>
pScreen = <optimized out>
#9 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>)
at ../dix/stubmain.c:34
No locals.
```
Here are my system details as reported by `neofetch`:
```
__.;=====;.__ mayhair@cobalt
_.=+==++=++=+=+===;. --------------
-=+++=+===+=+=+++++=_ OS: Void Linux x86_64
. -=:`` `--==+=++==. Host: HP Spectre x360 Convertible 14-ea0xxx
_vi, ` --+=++++: Kernel: 6.5.5_1
.uvnvi. _._ -==+==+. Uptime: 31 mins
.vvnvnI` .;==|==;. :|=||=|. Packages: 1660 (xbps-query), 36 (flatpak)
+QmQQmpvvnv; _yYsyQQWUUQQQm #QmQ#:QQQWUV$QQm. Shell: bash 5.2.15
-QQWQWpvvowZ?.wQQQE==<QWWQ/QWQW.QQWW(: jQWQE Resolution: 3000x2000
-$QQQQmmU' jQQQ@+=<QWQQ)mQQQ.mQQQC+;jWQQ@' DE: GNOME 44.2
-$WQ8YnI: QWQQwgQQWV`mWQQ.jQWQQgyyWW@! WM: Mutter
-1vvnvv. `~+++` ++|+++ WM Theme: Adwaita
+vnvnnv, `-|=== Theme: Adwaita-dark [GTK2/3]
+vnvnvns. . :=- Icons: Adwaita [GTK2/3]
-Invnvvnsi..___..=sv=. ` Terminal: gnome-terminal
+Invnvnvnnnnnnnnvvnn;. CPU: 11th Gen Intel i7-1165G7 (8) @ 4.700GHz
~|Invnvnvvnvvvnnv}+` GPU: Intel TigerLake-LP GT2 [Iris Xe Graphics]
-~|{*l}*|~ Memory: 3737MiB / 15642MiB
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1584XWayland crashes attempting to change video modes on the primary GPU from PRI...2023-09-25T09:03:36ZChristopher SnowhillXWayland crashes attempting to change video modes on the primary GPU from PRIME gameI am running the unusual configuration of an AMD RX 480 8GB as a primary GPU, and an Intel Arc A770 FE 16GB as a secondary GPU. I was running A Hat In Time on the Arc card, using `DRI_PRIME=1`. XWayland was SIGABRT'd when I attempted to ...I am running the unusual configuration of an AMD RX 480 8GB as a primary GPU, and an Intel Arc A770 FE 16GB as a secondary GPU. I was running A Hat In Time on the Arc card, using `DRI_PRIME=1`. XWayland was SIGABRT'd when I attempted to change the video mode of the game.
```
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: amdgpu: The CS has been rejected (-22).
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE)
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) Backtrace:
Sep 24 00:17:37 mrgency kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to process the buffer list -22!
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 0: Xwayland (0x5555cea6d000+0x16a4e3) [0x5555cebd74e3]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 1: Xwayland (0x5555cea6d000+0x16ac74) [0x5555cebd7c74]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 2: /usr/lib/libc.so.6 (0x7f2d90200000+0x3e710) [0x7f2d9023e710]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 3: /usr/lib/libc.so.6 (0x7f2d90200000+0x8e83c) [0x7f2d9028e83c]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 4: /usr/lib/libc.so.6 (raise+0x18) [0x7f2d9023e668]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 5: /usr/lib/libc.so.6 (abort+0xd7) [0x7f2d902264b8]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 6: /usr/lib/dri/radeonsi_dri.so (0x7f2d8c400000+0xab4e77) [0x7f2d8ceb4e77]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 7: /usr/lib/dri/radeonsi_dri.so (0x7f2d8c400000+0xab8373) [0x7f2d8ceb8373]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 8: /usr/lib/dri/radeonsi_dri.so (0x7f2d8c400000+0x120e3c) [0x7f2d8c520e3c]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 9: /usr/lib/dri/radeonsi_dri.so (0x7f2d8c400000+0x143f5c) [0x7f2d8c543f5c]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 10: /usr/lib/libc.so.6 (0x7f2d90200000+0x8c9eb) [0x7f2d9028c9eb]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) 11: /usr/lib/libc.so.6 (0x7f2d90200000+0x110dfc) [0x7f2d90310dfc]
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE)
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE)
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: Fatal server error:
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE) Caught signal 6 (Aborted). Server aborting
Sep 24 00:17:37 mrgency wayland-session_wayfire.desktop[6263]: (EE)
Sep 24 00:17:37 mrgency systemd[1]: Started Process Core Dump (PID 236414/UID 0).
Sep 24 00:17:38 mrgency systemd-coredump[236415]: Process 6263 (Xwayland) of user 1000 dumped core.
Stack trace of thread 6350:
#0 0x00007f2d9028e83c n/a (libc.so.6 + 0x8e83c)
#1 0x00007f2d9023e668 raise (libc.so.6 + 0x3e668)
#2 0x00007f2d902264b8 abort (libc.so.6 + 0x264b8)
#3 0x00005555cebd738d OsAbort (Xwayland + 0x16a38d)
#4 0x00005555cebd776d AbortServer (Xwayland + 0x16a76d)
#5 0x00005555cebd7cd0 OsSigHandler (Xwayland + 0x16acd0)
#6 0x00007f2d9023e710 n/a (libc.so.6 + 0x3e710)
#7 0x00007f2d9028e83c n/a (libc.so.6 + 0x8e83c)
#8 0x00007f2d9023e668 raise (libc.so.6 + 0x3e668)
#9 0x00007f2d902264b8 abort (libc.so.6 + 0x264b8)
#10 0x00007f2d8ceb4e77 amdgpu_ctx_set_sw_reset_status (radeonsi_dri.so + 0xab4e77)
#11 0x00007f2d8ceb8373 amdgpu_cs_submit_ib (radeonsi_dri.so + 0xab8373)
#12 0x00007f2d8c520e3c util_queue_thread_func (radeonsi_dri.so + 0x120e3c)
#13 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#14 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#15 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 6390:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 6394:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 6264:
#0 0x00007f2d9030359f __poll (libc.so.6 + 0x10359f)
#1 0x00007f2d8f5f44b8 poll (libEGL_mesa.so.0 + 0x1f44b8)
#2 0x00007f2d8f5f46e3 _ZN8perfetto4base16ThreadTaskRunner13RunTaskThreadESt8functionIFvPNS0_14UnixTaskRunnerEEE (libEGL_mesa.so.0 + 0x1f46e3)
#3 0x00007f2d8f61c945 _ZSt13__invoke_implIvMN8perfetto4base16ThreadTaskRunnerEFvSt8functionIFvPNS1_14UnixTaskRunnerEEEEPS2_JS7_EET_St21__invoke_memfun_derefOT0_OT1_DpOT2_ (libEGL_mesa.so.0 + 0x21c945)
#4 0x00007f2d8f0e1943 execute_native_thread_routine (libstdc++.so.6 + 0xe1943)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 7111:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 7133:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 6393:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 6389:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 6263:
#0 0x00007f2d9030ed6d syscall (libc.so.6 + 0x10ed6d)
#1 0x00007f2d8c5186c7 sys_futex (radeonsi_dri.so + 0x1186c7)
#2 0x00007f2d8c5209e8 do_futex_fence_wait (radeonsi_dri.so + 0x1209e8)
#3 0x00007f2d8ce95df9 si_flush_all_queues (radeonsi_dri.so + 0xa95df9)
#4 0x00007f2d8cc09a03 tc_flush (radeonsi_dri.so + 0x809a03)
#5 0x00007f2d8c6da4a3 st_flush (radeonsi_dri.so + 0x2da4a3)
#6 0x00007f2d8c6da628 st_glFlush (radeonsi_dri.so + 0x2da628)
#7 0x00005555ceac0104 glamor_flush (Xwayland + 0x53104)
#8 0x00005555ceb15624 BlockHandler (Xwayland + 0xa8624)
#9 0x00005555cea9e3a8 dix_main (Xwayland + 0x313a8)
#10 0x00007f2d90227cd0 n/a (libc.so.6 + 0x27cd0)
#11 0x00007f2d90227d8a __libc_start_main (libc.so.6 + 0x27d8a)
#12 0x00005555cea9fd85 _start (Xwayland + 0x32d85)
Stack trace of thread 6351:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 6464:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 7105:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 7110:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 7109:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 7130:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
Stack trace of thread 7116:
#0 0x00007f2d902894ae n/a (libc.so.6 + 0x894ae)
#1 0x00007f2d9028bd40 pthread_cond_wait (libc.so.6 + 0x8bd40)
#2 0x00007f2d8c54402e cnd_wait (radeonsi_dri.so + 0x14402e)
#3 0x00007f2d8c520d7c util_queue_thread_func (radeonsi_dri.so + 0x120d7c)
#4 0x00007f2d8c543f5c impl_thrd_routine (radeonsi_dri.so + 0x143f5c)
#5 0x00007f2d9028c9eb n/a (libc.so.6 + 0x8c9eb)
#6 0x00007f2d90310dfc n/a (libc.so.6 + 0x110dfc)
ELF object binary architecture: AMD x86-64
```
Possibly the PRIME subsystem didn't like the sudden buffer resolution change? Maybe this is a kernel bug? Or is it a userspace bug? A Mesa bug?https://gitlab.freedesktop.org/xorg/xserver/-/issues/1581Moving from xf86-video-ati to xf86-video-modesetting with multiple GPU's and...2023-09-22T11:47:37ZStuartMoving from xf86-video-ati to xf86-video-modesetting with multiple GPU's and MonitorsI have a setup with two (not recent) AMD graphics cards connected to two monitors.
I currently have an /etc/X11/xorg.conf (quite old) that uses the radeon (ati) driver which gives me two displays :0.0 and :0.1.
On display 0.0 I run a nor...I have a setup with two (not recent) AMD graphics cards connected to two monitors.
I currently have an /etc/X11/xorg.conf (quite old) that uses the radeon (ati) driver which gives me two displays :0.0 and :0.1.
On display 0.0 I run a normal X11 session using a display manager and I use it for normal desktop activites.
On display 0.1 I only run the X server and I use this display to present videos using mplayer.
I have recently updated the os on this machine to LFS/BLFS version 12.0 (Xorg-Server-21.1.8).
This version of LFS/BLFS only supports the modesetting driver, I have manually included the radeon (ati) driver to keep the system running.
However going forward I would, if possible, like to use the modesetting driver for this system.
So far I have discovered that it is not a simple matter of changing the driver type from radeon to modesetting (this just gives me a single :0 clone display).
I have read a number of documents (non describes exacly what I wish to do) which lead me to the concusion that it may be possible but the way forward is not clear to me.
So two questions:
1, Is it possible.
2, What is the simplest way forward.
Thankshttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/196Add compose sequences for all four Serbo-Croatian accents on Latin and Cyrill...2023-09-22T01:06:20ZIvan ZakharyaschevAdd compose sequences for all four Serbo-Croatian accents on Latin and Cyrillic letters (the missing ones)Serbo-Croatian uses either Latin or Cyrillic letters, and [four marks](https://en.wikipedia.org/wiki/Shtokavian#Accentuation) when one needs to show the accent (in a dictionary mostly): double grave, inverted breve, grave, acute. No matt...Serbo-Croatian uses either Latin or Cyrillic letters, and [four marks](https://en.wikipedia.org/wiki/Shtokavian#Accentuation) when one needs to show the accent (in a dictionary mostly): double grave, inverted breve, grave, acute. No matter what the base language is (perhaps, English), it would be convenient to be able to input these letters when editing a dictionary entry for a Serbo-Croatian word.
I believe there is currently no deficiency of compose sequences for putting a grave or acute mark on a Latin or Cyrillic letter.
As for double grave, there are [only sequences for Cyrillic letters](https://www.x.org/releases/current/doc/libX11/i18n/compose/en_US.UTF-8.html), but no corresponding ones for Latin letters:
```
Multi_key grave grave Cyrillic_a | "а̏" # CYRILLIC SMALL LETTER A WITH COMBINING DOUBLE GRAVE ACCENT |
Multi_key grave grave Cyrillic_A
Multi_key grave grave Cyrillic_ie
Multi_key grave grave Cyrillic_IE
Multi_key grave grave Cyrillic_i
Multi_key grave grave Cyrillic_I
Multi_key grave grave Cyrillic_o
Multi_key grave grave Cyrillic_O
Multi_key grave grave Cyrillic_u
Multi_key grave grave Cyrillic_U
Multi_key grave grave Cyrillic_er
Multi_key grave grave Cyrillic_ER
```
(Maybe also additionally all the accent marks combined with Cyrillic_el and Latin L would be useful for some Serbo-Croatian dialects that retained the syllabic L in words like *vlk* "wolf", such as [Timok-Prizren (Torlakian)](https://en.wikipedia.org/wiki/Shtokavian#Timok%E2%80%93Prizren_(Torlakian)).)
I suggest adding similar sequences for Latin A, E, I, O, U, R (and maybe L, together with all the other accents on L).
As for inverted breve, there are no such sequences either for Cyrillic or Latin letters now. I suggest inventing a key that would act as an inverted breve after the Compose key and adding sequences with it (for the listed vocalic letters, including R and maybe L). Perhaps, the key could be parenright (since parenleft is sometimes used for breve, though not for all these vocalic letters--there, u or b are used).
* * *
I think that the comments and sequences in <https://www.x.org/releases/current/doc/libX11/i18n/compose/sr_RS.UTF-8.html> miss that R (Cyrillic_er) should be accentable, too. Example: [cȓn / цр̑н](https://en.wiktionary.org/wiki/crn#Serbo-Croatian) "black". And maybe L (Cyrillic_el) in some dialects, which retain syllabic L (I mentioned this above); example: [vlk](https://en.wiktionary.org/wiki/vlk#Serbo-Croatian) "wolf".
And there, they implement the long falling accent as a circumflex, although as we can see in Wikipedia and other places, inverted breve is used for this. (Of course, if someone likes a circumflex, I don't think we should take away the possibility to do so, but we should also add the commonly used inverted breve to represent this accent. Well, I don't know, perhaps it'd be better to replace circumflex with inverted breve in these combinations for Serbian, since it's more correct, but I don't know what the actual wide-spread practice is, whether someone would prefer circumflex, and that would break the compatibility, but since this is limited just to Serbian, the compatibility problem might not be a real problem given that inverted breve is the correct mark.)https://gitlab.freedesktop.org/xorg/app/xrandr/-/issues/70Why is 1440x900 resolution missing from Ubuntu on Xorg environment, but not f...2023-09-17T07:33:21ZTomica KoracWhy is 1440x900 resolution missing from Ubuntu on Xorg environment, but not from Ubuntu environment (Wayland)?I run Ubuntu 22.10 on Dell XPS 13 2-in-1 2020. Its graphic card is Mesa Intel® Xe (TGL GT2). I noticed the following:
* When I log in to the default Ubuntu desktop environment (which is Wayland), I can choose the 1440x900 resolution (16...I run Ubuntu 22.10 on Dell XPS 13 2-in-1 2020. Its graphic card is Mesa Intel® Xe (TGL GT2). I noticed the following:
* When I log in to the default Ubuntu desktop environment (which is Wayland), I can choose the 1440x900 resolution (16x10 aspect ratio).
* When I log in to Ubuntu on Xorg desktop environment, the 1440x900 resolution is not offered as an option.
I see the same behaviour through both the GUI (Settings \> Display), and command line (xrandr). Also, the above resolution was available on Xorg in Ubuntu 22.04.
Why is this happenning? How can I re-enable 1440x900 resolution for the Xorg environment again?
If this is not the appropriate project to raise this issue, please direct me to the one that is.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1578Scrolling on some old style app (no support hi-res wheel scrolling) might ign...2023-12-20T21:00:15Zde tiamScrolling on some old style app (no support hi-res wheel scrolling) might ignore first scroll when direction is changedI just move issue from xorg/driver/xf86-input-libinput#61 to here
---
- Related issue: xorg/driver/xf86-input-libinput#5 #1339I just move issue from xorg/driver/xf86-input-libinput#61 to here
---
- Related issue: xorg/driver/xf86-input-libinput#5 #1339https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/72Fail to build libxcb-1.16 with some values of LC_CTYPE environment2024-02-22T06:09:50ZXi RuoyaoFail to build libxcb-1.16 with some values of LC_CTYPE environmentOriginally reported https://lists.linuxfromscratch.org/sympa/arc/blfs-support/2023-09/msg00019.html.
```
$ LANG=en_US.ISO-8859-1 make -j1
Making all in src
make[1]: Entering directory '/home/xry111/sources/xc/libxcb-1.16/src'
GEN ...Originally reported https://lists.linuxfromscratch.org/sympa/arc/blfs-support/2023-09/msg00019.html.
```
$ LANG=en_US.ISO-8859-1 make -j1
Making all in src
make[1]: Entering directory '/home/xry111/sources/xc/libxcb-1.16/src'
GEN composite.c
Traceback (most recent call last):
File "/home/xry111/sources/xc/libxcb-1.16/src/./c_client.py", line 3395, in <module>
module.generate()
File "//usr/lib/python3.11/site-packages/xcbgen/state.py", line 131, in generate
item.out(name)
File "/home/xry111/sources/xc/libxcb-1.16/src/./c_client.py", line 3212, in c_request
_man_request(self, name, void=not self.reply, aux=False)
File "/home/xry111/sources/xc/libxcb-1.16/src/./c_client.py", line 2676, in _man_request
f.write('%s \\- %s\n' % (func_name, brief))
UnicodeEncodeError: 'latin-1' codec can't encode character '\u201c' in position 68: ordinal not in range(256)
make[1]: *** [Makefile:1425: composite.c] Error 1
make[1]: Leaving directory '/home/xry111/sources/xc/libxcb-1.16/src'
make: *** [Makefile:799: all-recursive] Error 1
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1577DRM crash when connecting a screen while resuming from suspend2023-09-06T16:09:56ZThiago MacieiraDRM crash when connecting a screen while resuming from suspendBoth times the crash happened, this was the sequence of actions:
1. Suspend laptop with no external monitors connected
2. Plug USB-C cable with external monitor
3. Resume
Steps 2 and 3 do not have to be in that order; it's possible to c...Both times the crash happened, this was the sequence of actions:
1. Suspend laptop with no external monitors connected
2. Plug USB-C cable with external monitor
3. Resume
Steps 2 and 3 do not have to be in that order; it's possible to cause this by first resuming but then quickly attaching the USB-C cable before the screen comes up.
It does not happen 100% of the time: I have done the above without problems recently. Though they may have been different monitors / docks.
Xorg.log:
```
[ 60851.418] (II) modeset(0): Output DP-3-1 has no monitor section
[ 60851.421] (EE)
[ 60851.421] (EE) Backtrace:
[ 60851.421] (EE) 0: /usr/bin/Xorg.bin (xorg_backtrace+0x7e) [0x5618d751aaae]
[ 60851.421] (EE) 1: /usr/bin/Xorg.bin (0x5618d7344000+0x1df409) [0x5618d7523409]
[ 60851.421] (EE) 2: /lib64/libc.so.6 (0x7f95d5a00000+0x3f1b0) [0x7f95d5a3f1b0]
[ 60851.421] (EE) 3: /usr/lib64/xorg/modules/drivers/modesetting_drv.so (0x7f95d545f000+0xe2a0) [0x7f95d546d2a0]
[ 60851.421] (EE) 4: /usr/lib64/xorg/modules/drivers/modesetting_drv.so (0x7f95d545f000+0x14d00) [0x7f95d5473d00]
[ 60851.421] (EE) 5: /usr/bin/Xorg.bin (0x5618d7344000+0x1e2192) [0x5618d7526192]
[ 60851.421] (EE) 6: /usr/bin/Xorg.bin (WaitForSomething+0x1c9) [0x5618d751d4f9]
[ 60851.421] (EE) 7: /usr/bin/Xorg.bin (0x5618d7344000+0x4ceb8) [0x5618d7390eb8]
[ 60851.422] (EE) 8: /lib64/libc.so.6 (0x7f95d5a00000+0x281b0) [0x7f95d5a281b0]
[ 60851.422] (EE) 9: /lib64/libc.so.6 (__libc_start_main+0x8b) [0x7f95d5a28279]
[ 60851.422] (EE) 10: /usr/bin/Xorg.bin (_start+0x27) [0x5618d7391a15]
[ 60851.422] (EE)
[ 60851.422] (EE) Segmentation fault at address 0x0
```
Proper backtrace:
```
#9 0x00007f95d5a3f1b0 in <signal handler called> () at /lib64/libc.so.6
#10 0x00007f95d546d2a0 in drmmode_connector_check_vrr_capable (connector_id=<optimized out>, drm_fd=14)
at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:3159
#11 drmmode_output_init
(pScrn=pScrn@entry=0x5618d8106d40, drmmode=drmmode@entry=0x5618d8107928, mode_res=mode_res@entry=0x5618da96d0d0, num=num@entry=5, dynamic=dynamic@entry=1, crtcshift=crtcshift@entry=0) at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:3313
#12 0x00007f95d5473d00 in drmmode_update_kms_state (drmmode=0x5618d8107928)
at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:4067
#13 0x00005618d7526192 in ospoll_wait (ospoll=0x5618d80e3980, timeout=<optimized out>) at ../../os/ospoll.c:657
#14 0x00005618d751d4f9 in WaitForSomething (are_ready=<optimized out>) at ../../os/WaitFor.c:208
#15 0x00005618d7390eb8 in Dispatch () at ../../dix/dispatch.c:492
#16 dix_main (envp=<optimized out>, argv=0x7ffd5e809588, argc=<optimized out>) at ../../dix/main.c:276
#17 main (argc=<optimized out>, argv=0x7ffd5e809588, envp=<optimized out>) at ../../dix/stubmain.c:34
(gdb) f 10
#10 0x00007f95d546d2a0 in drmmode_connector_check_vrr_capable (connector_id=<optimized out>, drm_fd=14)
at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:3159
```
```
(gdb) f 10
#10 0x00007f95d546d2a0 in drmmode_connector_check_vrr_capable (connector_id=<optimized out>, drm_fd=14)
at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:3159
3159 for (i = 0; !found && i < props->count_props; ++i) {
(gdb) l
3156 props = drmModeObjectGetProperties(drm_fd, connector_id,
3157 DRM_MODE_OBJECT_CONNECTOR);
3158
3159 for (i = 0; !found && i < props->count_props; ++i) {
3160 drmModePropertyPtr drm_prop = drmModeGetProperty(drm_fd, props->props[i]);
(gdb) p props
$1 = (drmModeObjectPropertiesPtr) 0x0
(gdb) up
#11 drmmode_output_init (pScrn=pScrn@entry=0x5618d8106d40, drmmode=drmmode@entry=0x5618d8107928, mode_res=mode_res@entry=0x5618da96d0d0, num=num@entry=5,
dynamic=dynamic@entry=1, crtcshift=crtcshift@entry=0) at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:3313
(gdb) l
3312 ms->is_connector_vrr_capable |=
3313 drmmode_connector_check_vrr_capable(drmmode->fd,
3314 drmmode_output->output_id);
(gdb) p *ms
$6 = {fd = 14, fd_passed = 0, Chipset = 0, pEnt = 0x5618d8107bb0, noAccel = 0, CloseScreen = 0x5618d74305c0 <xf86CursorCloseScreen>,
CreateWindow = 0x5618d74e6380 <fbCreateWindow>, SaveGeneration = 4294967295, createScreenResources = 0x5618d7508ac0 <miCreateScreenResources>,
BlockHandler = 0x7f95d5433b60 <_glamor_block_handler>, SpriteFuncs = 0x5618d75b7c80 <miSpritePointerFuncs>, driver = 0x0, drmmode = {fd = 14, fb_id = 361,
mode_fb = 0x0, cpp = 4, kbpp = 32, scrn = 0x5618d8106d40, gbm = 0x5618d8122aa0, uevent_monitor = 0x5618d89befd0, uevent_handler = 0x5618d8bc4760,
event_context = {version = 0, vblank_handler = 0x0, page_flip_handler = 0x0, page_flip_handler2 = 0x0, sequence_handler = 0x0}, front_bo = {width = 3840,
height = 2400, dumb = 0x0, used_modifiers = 0, gbm = 0x5618da7807a0}, sw_cursor = 0, Options = 0x5618d811fd30, glamor = 1, shadow_enable = 0,
shadow_enable2 = 0, pageflip = 1, force_24_32 = 0, shadow_fb = 0x0, shadow_fb2 = 0x0, pixmapPrivateKeyRec = {offset = 152, size = 64, initialized = 1,
allocated = 0, type = PRIVATE_PIXMAP, next = 0x0}, spritePrivateKeyRec = {screenKey = {offset = 192, size = 0, initialized = 1, allocated = 0,
type = PRIVATE_SCREEN, next = 0x5618d75f0ac0 <miPointerScreenKeyRec>}}, vrrPrivateKeyRec = {offset = 0, size = 0, initialized = 0, allocated = 0,
type = PRIVATE_XSELINUX, next = 0x0}, sprites_visible = 0, reverse_prime_offload_mode = 0, is_secondary = 0, fbcon_pixmap = 0x0, dri2_flipping = 0,
present_flipping = 1, flip_bo_import_failed = 0, can_async_flip = 1, async_flip_secondaries = 0, dri2_enable = 1, present_enable = 1, vrr_prop_id = 24,
use_ctm = 0}, event_context = {version = 4, vblank_handler = 0x7f95d5469c00 <ms_drm_handler>, page_flip_handler = 0x7f95d5469c00 <ms_drm_handler>,
page_flip_handler2 = 0x0, sequence_handler = 0x7f95d5469c30 <ms_drm_sequence_handler_64bit>}, atomic_modeset_capable = 1, atomic_modeset = 0,
pending_modeset = 0, damage = 0x5618d8bc47f0, dirty_enabled = 1, cursor_width = 256, cursor_height = 256, has_queue_sequence = 1, tried_queue_sequence = 1,
kms_has_modifiers = 1, vrr_support = 0, flip_window = 0x5618d9323230, is_connector_vrr_capable = 0, connector_prop_id = 0, shadow = {Setup = 0x0, Add = 0x0,
Remove = 0x0, Update32to24 = 0x0, UpdatePacked = 0x0}, glamor = {back_pixmap_from_fd = 0x7f95d54317f0 <glamor_back_pixmap_from_fd>,
block_handler = 0x7f95d5433ae0 <glamor_block_handler>, clear_pixmap = 0x7f95d5433d40 <glamor_clear_pixmap>,
egl_create_textured_pixmap = 0x7f95d5431950 <glamor_egl_create_textured_pixmap>,
egl_create_textured_pixmap_from_gbm_bo = 0x7f95d54315a0 <glamor_egl_create_textured_pixmap_from_gbm_bo>,
egl_exchange_buffers = 0x7f95d5438c70 <glamor_egl_exchange_buffers>, egl_get_gbm_device = 0x7f95d542fe30 <glamor_egl_get_gbm_device>,
egl_init = 0x7f95d542feb0 <glamor_egl_init>, finish = 0x7f95d5435970 <glamor_finish>, gbm_bo_from_pixmap = 0x7f95d54391e0 <glamor_gbm_bo_from_pixmap>,
init = 0x7f95d5434690 <glamor_init>, name_from_pixmap = 0x7f95d54397a0 <glamor_name_from_pixmap>,
set_drawable_modifiers_func = 0x7f95d54358b0 <glamor_set_drawable_modifiers_func>,
shareable_fd_from_pixmap = 0x7f95d5439660 <glamor_shareable_fd_from_pixmap>,
supports_pixmap_import_export = 0x7f95d5435860 <glamor_supports_pixmap_import_export>, xv_init = 0x7f95d54303e0 <glamor_xv_init>,
egl_get_driver_name = 0x7f95d542fe60 <glamor_egl_get_driver_name>}}
(gdb) p name
$7 = "DP-3-1\000\000\b\000\000\000\025\000\000\000\000\000\000\000\000@\000\000\000\000\000\000\000@\000"
```https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/61scrolling on some old style app (no support hi-res wheel scrolling) might ign...2023-11-23T06:14:29Zde tiamscrolling on some old style app (no support hi-res wheel scrolling) might ignore first scroll when direction is changedFor example, Firefox without MOZ_USE_XINPUT2=1 env var, switch KDE virtual desktop by scroll mouse wheel on desktop, any x11 program that don't support hi-res wheel.
Like this issue:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/...For example, Firefox without MOZ_USE_XINPUT2=1 env var, switch KDE virtual desktop by scroll mouse wheel on desktop, any x11 program that don't support hi-res wheel.
Like this issue:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1339 <br>
but in KDE plasma x11 session
video (`libinput record` record normal input event, every time I scroll there a `REL_WHEEL` event. `xev` don't): <br>
![Video_2023-09-04_08-20-04](/uploads/a77bcce2cae20a43a4e30ef947d8731a/Video_2023-09-04_08-20-04.mp4)
on real app: <br>
![Video_2023-09-04_08-41-33](/uploads/fb7601035ee1d5a1c878c9f3a74268a8/Video_2023-09-04_08-41-33.mp4)
Mouse: Logitech G903 LS
And even on program support hi-res wheel, first scroll only have half long, maybe relate to #5 <br>
This issue won't happen on evdev or wayland.
<hr>
when I mess around try to find a solution, I found that if I change [this line](https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/blob/master/src/xf86libinput.c#L1853) to <br>`valuator_mask_set_double(mask, 3, value*2);`<br> the issue gone, though all hi-res wheel scroll are twice long now, and first hi-res wheel scroll still only have half longhttps://gitlab.freedesktop.org/xorg/app/xbacklight/-/issues/6Lock Minimum brightness to prevent screen turning off2023-09-02T08:55:31ZCelivalgLock Minimum brightness to prevent screen turning offXbacklight doesn't prevent the backlight from turning off, which some users have found a use for, but can sometimes require a ssh connection, a reboot, or blind typing on a terminal to fix if the keyboard keys haven't been linked to an x...Xbacklight doesn't prevent the backlight from turning off, which some users have found a use for, but can sometimes require a ssh connection, a reboot, or blind typing on a terminal to fix if the keyboard keys haven't been linked to an xbacklight call.
1rst solution:
A way to fix that would be an optional argument to keep the brightness value at a minimum of 1.
(`xcb_randr_query_output_property_valid_values` usually considers 0 as a valid value as far as I can tell, which in most cases, will turn off the backlight. I have not found a case where this is not true, but I am not 100% sure this is the case.)
This way, users that make use of the fact that xbacklight will turn off the screen won't see its behavior changed, but users with a need to keep the backlight on will have the option.
Problem:
One issue with that is that there is no guarantee that a value of 1 will keep the screen on, I have had a laptop whose lowest I could go before the backlight turned off was 40...
2nd solution:
An optional argument specifying the minimum value to set the brightness to.
Same behavior as before for users who don't need the limit.
Problem:
Different screens might have different turn-off and maximum values. As mentioned before, my old laptop turned off at 40, whereas from what I read on other issues, Toshiba Satellite L650D have a maximum backlight value of 7... I have not encountered a situation where xbacklight was capable of controlling multiple screens (either the screens I had didn't support the connected computer controlling the brightness or something else...) and I don't know how this would behave...
3rd solution:
An optional argument to specify the minimum brightness for each specific screen...
Problem:
This is starting to get pretty involved, and doesn't take into account the fact that a screen might change ports, and screen can't be reliably uniquely identified afaik (edid doesn't necessarily have all the info to uniquely identify a screen from what I've seen) Best we can do is specify the ports (eDP1 or DP-1, things like that) or maybe fingerprint the screens with the various info we have... But that's already way outside the scope of xbacklight...
So I don't have a one size fits all solution, which is why I haven't written the code myself, I simply don't know what to do with it...https://gitlab.freedesktop.org/xorg/xserver/-/issues/1576XWayland windows get stuck on drag when a tablet device is disconnected while...2023-10-07T22:58:53ZKodehawaXWayland windows get stuck on drag when a tablet device is disconnected while performing a drag event, inhibiting mouse clicks.If I'm dragging something with a tablet device inside of an XWayland window, and the tablet gets disconnected while dragging for whatever reason (discovered this because my feet met the cable), the dragging action does not get cancelled,...If I'm dragging something with a tablet device inside of an XWayland window, and the tablet gets disconnected while dragging for whatever reason (discovered this because my feet met the cable), the dragging action does not get cancelled, and it inhibits you from clicking anywhere on the window until you reconnect the tablet and move the cursor using the tablet device (or click with the pen), or restart XWayland.
Repro:
1. Start dragging text on an XWayland window using a tablet device
2. Disconnect the tablet device while dragging (do not stop dragging until its disconnected)
3. Moving the mouse will show you the drag contents without you clicking, and trying to right click anywhere in the window will be met with no response. Right clicking works, but if you right click and then left click, left click will still do nothing.
This cannot be reproduced on a Wayland client.
A video reproducing this issue:
![attached here](/uploads/9a7e709ea7f07ccf4cb971185acb10c5/20230901_131030.mp4)