xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2023-12-27T12:40:38Zhttps://gitlab.freedesktop.org/xorg/app/xinput/-/issues/15ambiguity with master device naming2023-12-27T12:40:38ZJesus Zen Droïdambiguity with master device naming```
$ xinput create-master Test
$ xinput reattach "Wacom One by Wacom S Pen stylus" Test
unable to find device 'Test'
# master must be set explicitly, but we already know it's a pointer (it was
# attached correctly to "Virtual core poin...```
$ xinput create-master Test
$ xinput reattach "Wacom One by Wacom S Pen stylus" Test
unable to find device 'Test'
# master must be set explicitly, but we already know it's a pointer (it was
# attached correctly to "Virtual core pointer" in the first place) ; so far
# this is just a minor nuisance
$ xinput reattach "Wacom One by Wacom S Pen stylus" "Test pointer"
# the problem becomes obvious when _removing_ a master:
$ xinput remove-master Test
unable to find device 'Test'
$ xinput remove-master "Test pointer"
# now, xinput removed _both_ "Test pointer" and "Test keyboard"
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1602Corrupt characters in Xorg.0.log2023-12-03T17:16:36ZJonnyCorrupt characters in Xorg.0.logOpening Xorg.0.log my editor reports corrupted characters
There is a vulnerability risk, as xorg is not checking the data is valid, could become a more serious risk, if they connect an HDMI device with invalid characters, that somehow is...Opening Xorg.0.log my editor reports corrupted characters
There is a vulnerability risk, as xorg is not checking the data is valid, could become a more serious risk, if they connect an HDMI device with invalid characters, that somehow is made into an overflow RCE
X.Org version: 1.21.1.7
30 29 3A 20 20 4D 43 36 4A 4E 81 31 35 36 57 46 31 0A 5B 20 20
0): MC6JN�156WF1.[
The 0x81 in the middle, is corrupt
Could xorg filter messages, to check they contain only valid characters?
I appreciate that it is probably coming from the monitor,
[ 29.328] ABI class: X.Org ANSI C Emulation, version 0.4
[ 29.785] (II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) HD Graphics 4000 (IVB GT2)
[ 29.785] (II) modeset(0): glamor initialized
[ 29.785] (==) modeset(0): VariableRefresh: disabled
[ 29.785] (==) modeset(0): AsyncFlipSecondaries: disabled
[ 29.785] (II) modeset(0): Output LVDS-1 has no monitor section
[ 29.799] (II) modeset(0): Output VGA-1 has no monitor section
[ 29.826] (II) modeset(0): Output HDMI-1 has no monitor section
[ 29.932] (II) modeset(0): Output DP-1 has no monitor section
[ 29.933] (II) modeset(0): EDID for output LVDS-1
[ 29.933] (II) modeset(0): Manufacturer: LGD Model: 2d9 Serial#: 0
[ 29.933] (II) modeset(0): Year: 2010 Week: 0
[ 29.933] (II) modeset(0): EDID Version: 1.4
[ 29.933] (II) modeset(0): Digital Display Input
[ 29.933] (II) modeset(0): 6 bits per channel
[ 29.933] (II) modeset(0): Digital interface is undefined
[ 29.933] (II) modeset(0): Max Image Size [cm]: horiz.: 34 vert.: 19
[ 29.933] (II) modeset(0): Gamma: 2.20
[ 29.933] (II) modeset(0): No DPMS capabilities specified
[ 29.933] (II) modeset(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
[ 29.933] (II) modeset(0): First detailed timing is preferred mode
[ 29.933] (II) modeset(0): Preferred mode is native pixel format and refresh rate
[ 29.933] (II) modeset(0): redX: 0.617 redY: 0.349 greenX: 0.313 greenY: 0.595
[ 29.933] (II) modeset(0): blueX: 0.151 blueY: 0.056 whiteX: 0.313 whiteY: 0.329
[ 29.933] (II) modeset(0): Manufacturer's mask: 0
[ 29.933] (II) modeset(0): Supported detailed timing:
[ 29.933] (II) modeset(0): clock: 139.5 MHz Image Size: 344 x 194 mm
[ 29.933] (II) modeset(0): h_active: 1920 h_sync: 1968 h_sync_end 2000 h_blank_end 2096 h_border: 0
[ 29.933] (II) modeset(0): v_active: 1080 v_sync: 1083 v_sync_end 1088 v_blanking: 1111 v_border: 0
[ 29.933] (II) modeset(0): Supported detailed timing:
[ 29.933] (II) modeset(0): clock: 93.0 MHz Image Size: 344 x 194 mm
[ 29.933] (II) modeset(0): h_active: 1920 h_sync: 1968 h_sync_end 2000 h_blank_end 2096 h_border: 0
[ 29.933] (II) modeset(0): v_active: 1080 v_sync: 1083 v_sync_end 1088 v_blanking: 1111 v_border: 0
[ 29.933] (II) modeset(0): MC6JN�156WF1
[ 29.933] (II) modeset(0): Unknown vendor-specific block 0
[ 29.933] (II) modeset(0): EDID (in hex):
[ 29.933] (II) modeset(0): 00ffffffffffff0030e4d90200000000
[ 29.933] (II) modeset(0): 00140104902213780a15d59e59509826
[ 29.933] (II) modeset(0): 0e505400000001010101010101010101
[ 29.933] (II) modeset(0): 0101010101017e3680b070381f403020
[ 29.934] (II) modeset(0): 350058c210000018542480b070381f40
[ 29.934] (II) modeset(0): 3020350058c210000018000000fe004d
[ 29.934] (II) modeset(0): 43364a4e813135365746310a00000000
[ 29.934] (II) modeset(0): 000041319e0000000002010a20200030
[ 29.934] (II) modeset(0): Printing probed modes for output LVDS-1
[ 29.934] (II) modeset(0): Modeline "1920x1080"x59.9 139.50 1920 1968 2000 2096 1080 1083 1088 1111 -hsync -vsync (66.6 kHz eP)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/200Add compose seq's for ASCII symbols absent from Cyrillic layouts to ru_RU2023-12-09T15:01:25ZKelly RoadkillAdd compose seq's for ASCII symbols absent from Cyrillic layouts to ru_RU### Intro ###
[JCUKEN (ЙЦУКЕН)](https://en.wikipedia.org/wiki/JCUKEN) layout and its derivatives is a de-facto standard for many Cyrillic scripts (Bashkir, Tatar, Belarusian, Kazakh, Russian, Tajik, Ukrainian, Yakut, etc.) and is the on...### Intro ###
[JCUKEN (ЙЦУКЕН)](https://en.wikipedia.org/wiki/JCUKEN) layout and its derivatives is a de-facto standard for many Cyrillic scripts (Bashkir, Tatar, Belarusian, Kazakh, Russian, Tajik, Ukrainian, Yakut, etc.) and is the only one printed on mass-produced Cyrillic keyboards (in the form of QWERTY/ЙЦУКЕН pair) and, like QWERTY, it has a number of flaws. One of the very annoying ones is that most of the punctuation marks were moved from their QWERTY positions to uppercase number row to make space for 33+ Cyrillic letters, and ``~`@#$^&[]{}|'<>`` were removed altogether. This is a major PITA for programmers, scientists, tech writers and translators who type in two or more languages (one has to `Alt+Shift, Shift+4, Alt+Shift` to type `$`). A number of projects try to fix this, including alt layouts, AHK scripts, custom XCompose maps, etc. ([examples below](#existing-attempts-at-fixing-this)), but no simple solution available OOTB yet.
![JCUKEN.svg](/uploads/f5a4628b4244a1aade7faeb40f2126ba/JCUKEN.svg.png)
### Proposal ###
Add sequences like
<Multi_key> <colon> <space> : "^" asciicircum # CIRCUMFLEX ACCENT
and maybe also
<Multi_key> <space> <colon> : "^" asciicircum # CIRCUMFLEX ACCENT
to `ru_RU.UTF-8/Compose` (and possibly other languages with JCUKEN-based layouts) for all the missing characters, so that they can be entered using the same keys as in QWERTY. The `<Multi_key> <symbol> <space>` and `<Multi_key> <space> <symbol>` pattern is established in [Spacing versions of accents](https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/nls/en_US.UTF-8/Compose.pre?ref_type=heads#L5) section of `en_US` and is not used anywhere else.
Complete file: [ru_RU.UTF-8_Compose.pre](/uploads/7234e05f59dbba3242a72dbf15350a03/ru_RU.UTF-8_Compose.pre)
### Advantages ###
- Doesn't require inventing and memorizing many sequences — the keys are the same as in QWERTY, only prefixed with `Compose` (and trailing `space` is typed naturally).
- Uses existing `Compose` key approach and tries to follow established patterns.
- Doesn't require dedicated modifier keys.
- Completely non-invasive, doesn't break existing UX.
- Doesn't touch `en_US`.
### Drawbacks ###
A couple of proposed sequences, namely
<Multi_key> <quotedbl> <space> : "@" at # COMMERCIAL AT
<Multi_key> <semicolon> <space> : "$" dollar # DOLLAR SIGN
override ones in `en_US`:
<Multi_key> <quotedbl> <space> : "¨" diaeresis # DIAERESIS
<Multi_key> <semicolon> <space> : "˛" ogonek # OGONEK
While unfortunate, this is not critical, as spacing diaeresis is available in other sequences, and ogonek is not used in Cyrillic. As this proposal only covers Cyrillic layout(s) without touching `en_US`, these conflicts may be considered minor.
### Alternative approaches ###
- Use a "switch layout while pressed" modifier (`grp:switch` and other `...switch` options in `xkb-options`). Convenient, but requires a dedicated mod key, and JCUKEN is crowded already. Same is for custom `AltGr` layer. Definitely not something to impose upon users by default. By contrast, `Compose` can be mapped to an existing key in a "tap for `Compose`, hold for `Modifier`" manner.
- Use a dead key like `<dead_somekey> <quotedbl>`. Requires some dead key to be set up to a non-standard behavior, so not an option. (Side note: it would be nice to have `dead_latin` and `dead_cyrillic`, similar to `dead_greek`).
- Add compose sequences in style of the ones in [Characters that may be difficult to access](https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/nls/en_US.UTF-8/Compose.pre?ref_type=heads#L59) section of `en_US`. While this proposal fits there nicely, it requires inventing new sequences of look-alike chars, which seems challenging, given the overall limited repertoire of symbols in JCUKEN (`.,"-_?!();:/\=+%*№`). More importantly, it requires users to learn a number of different sequences. This proposal, instead, uses a unified pattern, and the chars are printed on keycaps, nothing to memorize.
- Add sequences as proposed, but with shorter/simpler patterns, like `<Multi_key> <quotedbl> <quotedbl>` or `<Multi_key> <quotedbl>`. Both, especially the latter, override too many things in `en_US`, compared to a couple minor ones in the proposal. It seems that other possible sequences are similarly either too conflicting, or too complex to type/memorize.
- Input method - likely an overkill.
- Non-JCUKEN layout as default for Cyrillic scripts. Probably the best in long-term, but extremely invasive (and incompatible with kbd legends).
### Existing attempts at dealing with this ###
- <https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/symbols/ru?ref_type=heads#L1062>
- <https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/symbols/ru?ref_type=heads#L1234>
- <https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/symbols/ru?ref_type=heads#L1258>
- <https://ilyabirman.ru/typography-layout/>
- <https://tonsky.livejournal.com/318571.html>
- <https://github.com/braindefender/universal-layout>
- <https://habr.com/ru/articles/99042/>
- <https://github.com/uqqu/qPhyx>https://gitlab.freedesktop.org/xorg/xserver/-/issues/1601Random crashing, Bus error at address 0x7f638349e6c02024-03-17T14:13:28ZDianaRandom crashing, Bus error at address 0x7f638349e6c0Xorg, rarely, randomly crashes on me when using the dGPU, 6800M, seemingly no reason, no bug report templates or troubleshooting steps so heres what i think could be relevant.
No errors errors logged dmesg. Can't use Wayland until KDE g...Xorg, rarely, randomly crashes on me when using the dGPU, 6800M, seemingly no reason, no bug report templates or troubleshooting steps so heres what i think could be relevant.
No errors errors logged dmesg. Can't use Wayland until KDE gets it together. I have gotten crashes with both the modesetting driver and xorg amdgpu driver, and with and without VRR+TearFree/ The server does not recover or restart, and a VT switch does not work, and the machine seemingly must be hard rebooted. I have tried `Option "AccelMethod" "none"`, but that introduced various issues across nearly every graphical app and was essentially unusable.
`inxi -GSC -xx`
```
System:
Host: Hostname Kernel: 6.1.64-1-lts arch: x86_64 bits: 64 compiler: gcc
v: 13.2.1 Desktop: KDE Plasma v: 5.27.9 tk: Qt v: 5.15.11 wm: kwin_x11
dm: SDDM Distro: Arch Linux
CPU:
Info: 8-core model: AMD Ryzen 9 5980HX with Radeon Graphics bits: 64
type: MT MCP arch: Zen 3 rev: 0 cache: L1: 512 KiB L2: 4 MiB L3: 16 MiB
Speed (MHz): avg: 1552 high: 3300 min/max: 1200/5024 boost: enabled cores:
1: 1200 2: 3300 3: 1200 4: 1200 5: 1198 6: 1198 7: 1396 8: 3300 9: 1200
10: 1197 11: 2078 12: 1530 13: 1200 14: 1236 15: 1200 16: 1200
bogomips: 105445
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT]
vendor: ASUSTeK driver: amdgpu v: kernel arch: RDNA-2 pcie: speed: 16 GT/s
lanes: 16 ports: active: none empty: DP-1 bus-ID: 03:00.0
chip-ID: 1002:73df
Device-2: AMD Cezanne [Radeon Vega Series / Radeon Mobile Series]
vendor: ASUSTeK driver: amdgpu v: kernel arch: GCN-5 pcie: speed: 8 GT/s
lanes: 16 ports: active: eDP-1 empty: HDMI-A-1 bus-ID: 08:00.0
chip-ID: 1002:1638 temp: 49.0 C
Display: x11 server: X.Org v: 21.1.9 with: Xwayland v: 23.2.2
compositor: kwin_x11 driver: X: loaded: amdgpu dri: radeonsi gpu: amdgpu
display-ID: :0 screens: 1
Screen-1: 0 s-res: 2560x1440 s-dpi: 120
Monitor-1: eDP-1 mapped: eDP model: ChiMei InnoLux 0x1540 res: 2560x1440
dpi: 189 diag: 394mm (15.5")
API: EGL v: 1.5 platforms: device: 0 drv: radeonsi device: 1 drv: radeonsi
device: 2 drv: swrast gbm: drv: kms_swrast surfaceless: drv: radeonsi x11:
drv: radeonsi inactive: wayland
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 23.2.1-arch1.2
glx-v: 1.4 direct-render: yes renderer: AMD Radeon Graphics (renoir LLVM
16.0.6 DRM 3.49 6.1.64-1-lts) device-ID: 1002:1638
API: Vulkan v: 1.3.269 surfaces: xcb,xlib device: 0 type: discrete-gpu
driver: mesa radv device-ID: 1002:73df device: 1 type: integrated-gpu
driver: mesa radv device-ID: 1002:1638
```
[Xorg.0.log.old-2023-11-29T15_35_24](/uploads/802edef5bb1b18cbd3279277e2ed56d0/Xorg.0.log.old-2023-11-29T15_35_24)
[Xorg.0.log.old-2023-11-29T15_35_24-dmesg.log](/uploads/0604c61bf2bcc6b50876a5bfd24ce892/Xorg.0.log.old-2023-11-29T15_35_24-dmesg.log)
```
[ 943.215] (EE)
[ 943.215] (EE) Backtrace:
[ 943.215] (EE) 0: /usr/lib/Xorg (dri3_send_open_reply+0xdd) [0x5581fcc7540d]
[ 943.216] (EE) 1: /usr/lib/libc.so.6 (__sigaction+0x50) [0x7f63d8179710]
[ 943.216] (EE) 2: /usr/lib/libc.so.6 (__nss_database_lookup+0xc87) [0x7f63d82933b7]
[ 943.225] (EE) 3: /usr/lib/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0x5b89a) [0x7f63d512635a]
[ 943.226] (EE) 4: /usr/lib/dri/radeonsi_dri.so (nouveau_drm_screen_create+0x27f76c) [0x7f63d5baa8bc]
[ 943.226] (EE) 5: /usr/lib/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0xca99e) [0x7f63d519545e]
[ 943.226] (EE) 6: /usr/lib/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0x86a8d) [0x7f63d515154d]
[ 943.226] (EE) 7: /usr/lib/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0x87f7d) [0x7f63d5152a3d]
[ 943.226] (EE) 8: /usr/lib/dri/radeonsi_dri.so (__driDriverGetExtensions_d3d12+0x8806c) [0x7f63d5152b2c]
[ 943.227] (EE) 9: /usr/lib/xorg/modules/libglamoregl.so (glamor_pixmap_exchange_fbos+0x3ff2) [0x7f63d728b822]
[ 943.227] (EE) 10: /usr/lib/xorg/modules/libglamoregl.so (glamor_finish+0x1baa) [0x7f63d727375a]
[ 943.227] (EE) 11: /usr/lib/xorg/modules/libglamoregl.so (glamor_finish+0x22dd) [0x7f63d7273e8d]
[ 943.227] (EE) 12: /usr/lib/Xorg (miCopyRegion+0x96) [0x5581fcb64566]
[ 943.227] (EE) 13: /usr/lib/Xorg (miDoCopy+0x4a6) [0x5581fcb67446]
[ 943.227] (EE) 14: /usr/lib/xorg/modules/libglamoregl.so (glamor_copy_window+0x1d8) [0x7f63d726c2b8]
[ 943.227] (EE) 15: /usr/lib/Xorg (RRXineramaExtensionInit+0x1917) [0x5581fcbe79b7]
[ 943.228] (EE) 16: /usr/lib/Xorg (ShmRegisterFbFuncs+0x6cd) [0x5581fcc044dd]
[ 943.228] (EE) 17: /usr/lib/Xorg (SProcXkbDispatch+0x28ab) [0x5581fcb58fae]
[ 943.228] (EE) 18: /usr/lib/libc.so.6 (__libc_init_first+0x90) [0x7f63d8162cd0]
[ 943.228] (EE) 19: /usr/lib/libc.so.6 (__libc_start_main+0x8a) [0x7f63d8162d8a]
[ 943.228] (EE) 20: /usr/lib/Xorg (_start+0x25) [0x5581fcb59565]
[ 943.228] (EE)
[ 943.228] (EE) Bus error at address 0x7f638349e6c0
[ 943.228] (EE)
Fatal server error:
[ 943.228] (EE) Caught signal 7 (Bus error). Server aborting
[ 943.228] (EE)
[ 943.228] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
```
`/etc/X11/xorg.conf.d/20-amdgpu.conf` (this is the only xorg configuration file)
```
Section "Device"
Identifier "AMD iGPU"
BusID "PCI:8:0:0"
Driver "amdgpu"
Option "TearFree" "true"
Option "VariableRefresh" "true"
EndSection
Section "Device"
Identifier "AMD dGPU"
BusID "PCI:3:0:0"
EndSection
```https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/issues/227XOrg uses LLVM instead of Intel DRI driver2023-11-22T13:07:38ZNéstor AmigoXOrg uses LLVM instead of Intel DRI driverAs described here:
[Ubuntu MATE community thread about this bug](https://ubuntu-mate.community/t/my-intel-laptop-does-not-use-3d-acceleration-it-only-has-llvm/26853)
My Ubuntu MATE 22.04 LTS has recently started to use LLVM driver, so ...As described here:
[Ubuntu MATE community thread about this bug](https://ubuntu-mate.community/t/my-intel-laptop-does-not-use-3d-acceleration-it-only-has-llvm/26853)
My Ubuntu MATE 22.04 LTS has recently started to use LLVM driver, so I loose 3D hardware acceleration. I would be happy to try every command that you advise me to be able to revert to Intel driver. Thank you!https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/199XInitThreads crashes from libX11-1.8.72023-11-24T06:58:52ZLeshy-YAXInitThreads crashes from libX11-1.8.7Godot 4.X (engine, editor as well as released apps) and other applications crash with libX11-1.8.7 (or later). Downgrading to libX11-1.8.4 seems to workaround the problem. Tested on Fedora 38, 39, also reported on Ubuntu 23.04.
Reported...Godot 4.X (engine, editor as well as released apps) and other applications crash with libX11-1.8.7 (or later). Downgrading to libX11-1.8.4 seems to workaround the problem. Tested on Fedora 38, 39, also reported on Ubuntu 23.04.
Reported to impact Rust Desk as well as mentioned here:
- https://github.com/rustdesk/rustdesk/issues/6477
- https://github.com/rustdesk/rustdesk/discussions/5862
```
[xcb] Unknown sequence number while processing queue
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
godot.linuxbsd.editor.x86_64: xcb_io.c:278: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
```
Reported at: https://github.com/godotengine/godot/issues/75308
This is quite a serious problem. Preventing all (new and old) Godot based apps from running on systems with libX11-1.8.7 or later. Because Fedora 39 and other similarly recent distros don't support earlier versions of libX11 any more, this prevents a lot of apps from running on many Linux systems.
Probably regression of: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/170 based on Godot report: https://github.com/godotengine/godot/issues/69352https://gitlab.freedesktop.org/xorg/xserver/-/issues/1600Mouse can go off-screen when using multiple monitors2023-11-21T08:00:43ZŁukasz SpintzykMouse can go off-screen when using multiple monitorsThis was raised here:
https://github.com/ElectricRCAircraftGuy/bug_reports/issues/20
In three monitor setup:
1. Laptop builtin screen
2. DisplayLink display driven by evdi or udl driver
3. Non-displaylink display connected via USB-C -> ...This was raised here:
https://github.com/ElectricRCAircraftGuy/bug_reports/issues/20
In three monitor setup:
1. Laptop builtin screen
2. DisplayLink display driven by evdi or udl driver
3. Non-displaylink display connected via USB-C -> HDMI adapter (or HDMI monitor connected to HDMI laptop output)
After setting layout like in the attached picture:
![3displays_layout](/uploads/e5380447fdd3dcd32b970641dd17173c/3displays_layout.png)
Mouse go off-screen into the yellow-marked area.
This is not happening in homogeneous layout where displays 2 and 3 are both DisplayLink only or non-displaylink.
OS: Ubuntu 22.04
Machine Dell Latitude 5570, HP EliteBook 840 G7
XServer version 1.21.1.4https://gitlab.freedesktop.org/xorg/xserver/-/issues/1599GTK3 combo boxes don't work with touchscreen2023-12-07T00:44:16ZJakkojahau@rocketmail.comGTK3 combo boxes don't work with touchscreenThere are several drop-down lists in Xfce and MATE that don't work when using a touchscreen.
![GTK_combo_box_screenshot](/uploads/00f5ea04998cbc159c6742abd46c13fa/GTK_combo_box_screenshot.png)
The list opens when touching but closes wh...There are several drop-down lists in Xfce and MATE that don't work when using a touchscreen.
![GTK_combo_box_screenshot](/uploads/00f5ea04998cbc159c6742abd46c13fa/GTK_combo_box_screenshot.png)
The list opens when touching but closes when removing the finger. Therefore no list item can be chosen. Also touching and trying to slide to a list item doesn't work in most cases, the list doesn't interact. Some examples of those:
- Xfce desktop settings
- Xfce display settings
- NetworkManager Applet -> Connect to Hidden Wi-Fi Network... -> Wi-Fi security (both Xfce and MATE)
In some cases touching and sliding to a list item works. However, the expected behavior "first touch to open the list, second touch to select an item" doesn't work there either. Example:
- Xfce panel settings
These drop-down lists are called combo boxes in GTK (GtkComboBox widget).
I tried gtk3-demo and gtk4-demo.
- In gtk3-demo combo boxes of type "Items with icons" and "String IDs" don't work with touchscreen, as described above. Whereas type "Where are we?" and "Editable" work.
- In gtk4-demo combo boxes all four types work.
- (Although types "Items with icons" and "String IDs" stop working when trying to select an item for a second time. I think this is not related to the issue report here, in the terminal there is a GTK warning saying "Broken account of active state widget").
For the issue reported here I'm not sure if it's an xserver issue or a GTK issue. Though it reminded me of xserver issue #1255 on GTK menu widget, which was fixed by MR !866.
I'm on distributon postmarketOS edge (based on Alpine Linux edge) using device samsung-serranove (armv7). I also tried Linux Mint 21 (based on Ubuntu 22.04 LTS Jammy Jellyfish) with live USB (packages not updated) on a amd64 laptop with thouchscreen, the behavior was the same.
On postmarketOS I'm on the following software versions:
- xfce4: 4.18 (or mate-desktop: 1.26.1)
- xorg-server: 21.1.9
- gtk+3.0: 3.24.38
- gtk4.0: 4.12.3
Let me know what kind of logs or tests I can provide to clarify the issue.https://gitlab.freedesktop.org/xorg/app/xprop/-/issues/4xprop.c:1291:10: error: expected identifier or ‘(’ before ‘true’2024-02-11T07:19:52Zjeff cliffxprop.c:1291:10: error: expected identifier or ‘(’ before ‘true’(Yay more fallout from C23! see previous one: https://gitlab.freedesktop.org/xorg/lib/libxt/-/issues/20 )
When I compile with -std=gnu2x I get the following
CC xprop.o
xprop.c: In function ‘Handle_Question_Mark’:
xprop.c:1291:1...(Yay more fallout from C23! see previous one: https://gitlab.freedesktop.org/xorg/lib/libxt/-/issues/20 )
When I compile with -std=gnu2x I get the following
CC xprop.o
xprop.c: In function ‘Handle_Question_Mark’:
xprop.c:1291:10: error: expected identifier or ‘(’ before ‘true’
1291 | long true;
| ^~~~
xprop.c:1293:49: error: lvalue required as unary ‘&’ operand
1293 | dformat = Scan_Exp(dformat, thunks, format, &true);
| ^
make[2]: *** [Makefile:507: xprop.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/sources/blfs/xorg-apps/xprop-1.2.6'
when i use the default std i do not.
what is happening in xprop.c is that the newly as of C23 reserved word 'true' is being defined again, and that isn't working because it's not an identifier.
the good news: this variable 'true' is just in the local function Handle_Question_Mark () although it *is* used as a boolean value
so realistically there's going to be 2 ways of solving this depending on the taste of you, the maintainer
option 1) the easy way
simply rename the value 'true' to a non-reserved word, like 't' like the fix in the previous case
the following patch does this
```
--- xprop-1.2.6/xprop.c 2022-12-03 16:32:26.000000000 -0600
+++ xprop-fixed/xprop.c 2023-11-13 18:51:00.409900543 -0600
@@ -1288,15 +1288,15 @@
static const char *
Handle_Question_Mark (const char *dformat, thunk *thunks, const char *format)
{
- long true;
+ long t;
- dformat = Scan_Exp(dformat, thunks, format, &true);
+ dformat = Scan_Exp(dformat, thunks, format, &t);
if (*dformat != '(')
Fatal_Error("Bad conditional: '(' expected: %s.", dformat);
++dformat;
- if (!true)
+ if (!t)
dformat = Skip_Past_Right_Paren(dformat);
return dformat;
```
option 2) do the same *and* also change Scan_Exp (and all of its callers both inside and outside of this program) to use C booleans *if* it's
being compiled with C23 or above. Really Scan_Exp "returns" two values, one set of data and one boolean.
ok so option 2 has a snag that suggests an option 3, but let's get to the patch first:
this changes the Scan_Exp function to actually use a boolean if booleans are supported, and the above.
```
--- xprop-1.2.6/xprop.c 2022-12-03 16:32:26.000000000 -0600
+++ xprop-fixed/xprop.c 2023-11-13 19:07:52.545823882 -0600
@@ -1258,10 +1258,14 @@
return string;
}
+#if __STDC_VERSION__ >= 202311L
+static const char *
+Scan_Exp (const char *string, thunk *thunks, const char *format, boolean *value)
+#else
static const char *
Scan_Exp (const char *string, thunk *thunks, const char *format, long *value)
+#endif
{
- long temp;
if (string[0] == '(') {
string = Scan_Exp(++string, thunks, format, value);
@@ -1277,6 +1281,12 @@
string = Scan_Term(string, thunks, format, value);
+ #if __STDC_VERSION__ >= 202311L
+ boolean temp;
+ #else
+ long temp;
+ #endif
+
if (string[0] == '=') {
string = Scan_Exp(++string, thunks, format, &temp);
*value = *value == temp;
@@ -1285,18 +1295,23 @@
return string;
}
+
static const char *
Handle_Question_Mark (const char *dformat, thunk *thunks, const char *format)
{
- long true;
-
- dformat = Scan_Exp(dformat, thunks, format, &true);
+ #if __STDC_VERSION__ >= 202311L
+ boolean t;
+ #else
+ long t;
+ #endif
+
+ dformat = Scan_Exp(dformat, thunks, format, &t);
if (*dformat != '(')
Fatal_Error("Bad conditional: '(' expected: %s.", dformat);
++dformat;
- if (!true)
+ if (!t)
dformat = Skip_Past_Right_Paren(dformat);
return dformat;
```
BUT apparently this isn't *C90* kosher now. I don't know if anyone cares about C90 but for the hell of it, i have googled some ideas of how to fix that . . .
```
--- xprop-1.2.6/xprop.c 2022-12-03 16:32:26.000000000 -0600
+++ xprop-fixed/xprop.c 2023-11-13 19:15:33.082789000 -0600
@@ -1258,10 +1258,22 @@
return string;
}
+#if __STDC_VERSION__ >= 202311L
+static const char *
+Scan_Exp (const char *string, thunk *thunks, const char *format, boolean *value)
+#else
static const char *
Scan_Exp (const char *string, thunk *thunks, const char *format, long *value)
+#endif
{
+
+ #if __STDC_VERSION__ >= 202311L
+ boolean temp;
+ #else
long temp;
+ #endif
+
+
if (string[0] == '(') {
string = Scan_Exp(++string, thunks, format, value);
@@ -1277,6 +1289,8 @@
string = Scan_Term(string, thunks, format, value);
+
+
if (string[0] == '=') {
string = Scan_Exp(++string, thunks, format, &temp);
*value = *value == temp;
@@ -1285,18 +1299,23 @@
return string;
}
+
static const char *
Handle_Question_Mark (const char *dformat, thunk *thunks, const char *format)
{
- long true;
-
- dformat = Scan_Exp(dformat, thunks, format, &true);
+ #if __STDC_VERSION__ >= 202311L
+ boolean t;
+ #else
+ long t;
+ #endif
+
+ dformat = Scan_Exp(dformat, thunks, format, &t);
if (*dformat != '(')
Fatal_Error("Bad conditional: '(' expected: %s.", dformat);
++dformat;
- if (!true)
+ if (!t)
dformat = Skip_Past_Right_Paren(dformat);
return dformat;
```
ie apparently C90 is picky about where variable declarations are in the function. thanks to https://stackoverflow.com/questions/13291353/iso-c90-forbids-mixed-declarations-and-code-in-c for helping with that one.
anyway that last patch is probably best unless someone is expecting ABI stability of Scan_Exp for some reasonhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1596Driver "modesetting" can't set screen, report error -222023-11-09T22:43:34ZAndrew RandrianasuluDriver "modesetting" can't set screen, report error -22so, hw first:
```
inxi -Gxxx
Graphics:
Device-1: NVIDIA GK208B [GeForce GT 710] vendor: Micro-Star MSI
driver: nouveau v: kernel bus-ID: 01:00.0 chip-ID: 10de:128b class-ID: 0300
Display: server: X.Org 1.21.1.99 driver: loaded:...so, hw first:
```
inxi -Gxxx
Graphics:
Device-1: NVIDIA GK208B [GeForce GT 710] vendor: Micro-Star MSI
driver: nouveau v: kernel bus-ID: 01:00.0 chip-ID: 10de:128b class-ID: 0300
Display: server: X.Org 1.21.1.99 driver: loaded: nouveau
resolution: 1440x900~60Hz s-dpi: 96
OpenGL: renderer: NV106 v: 4.3 Mesa 24.0.0-devel (git-aba837ef71)
direct render: Yes
```
for some reason I can't use "modesetting" DDX while nouveau DDX works
[Xorg.0.log](/uploads/639c2a68dc81b35d21fd22d107b5e3e5/Xorg.0.log)
working loghttps://gitlab.freedesktop.org/xorg/lib/libxpm/-/issues/5pixmap(1) fails to build with libxpm 3.5.172023-11-17T09:37:41ZMichal Suchánekpixmap(1) fails to build with libxpm 3.5.17The pixmap tool uses the RgbName API which is no longer exported in libxpm 3.5.17
```
[ 10s] rm -f pixmap
[ 10s] gcc -o pixmap -O2 -Wall -fno-strict-aliasing -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -...The pixmap tool uses the RgbName API which is no longer exported in libxpm 3.5.17
```
[ 10s] rm -f pixmap
[ 10s] gcc -o pixmap -O2 -Wall -fno-strict-aliasing -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -g -DPIC -fPIC -L/usr/lib64 PixEdit.o Pixmap.o Dialog.o -L/net/koala/lib/sun4 -lXpm -LSelFile -lXgnu -lXaw -lXmu -lXt -lSM -lICE -lXpm -lXext -lX11 -lm
[ 11s] SelFile/Path.c: In function 'SFreplaceText.isra':
[ 11s] SelFile/Path.c:182:24: warning: '__builtin_strncat' specified bound depends on the length of the source argument [-Wstringop-overflow=]
[ 11s] 182 | (void) strncat(SFcurrentPath, str, len - 1);
[ 11s] | ^
[ 11s] SelFile/Path.c:178:15: note: length computed here
[ 11s] 178 | len = strlen(str);
[ 11s] | ^
[ 12s] /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: /tmp/ccoigPgu.ltrans1.ltrans.o: in function `PWUpdateColorInTable':
[ 12s] /home/abuild/rpmbuild/BUILD/pixmap/Pixmap.c:1726: undefined reference to `xpmGetRgbName'
[ 12s] /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/pixmap/Pixmap.c:1707: undefined reference to `xpmGetRgbName'
[ 12s] /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: /tmp/ccoigPgu.ltrans1.ltrans.o: in function `Initialize.lto_priv.0':
[ 12s] /home/abuild/rpmbuild/BUILD/pixmap/Pixmap.c:1146: undefined reference to `xpmReadRgbNames'
[ 12s] collect2: error: ld returned 1 exit status
[ 12s] make: *** [Makefile:1073: pixmap] Error 1
[ 12s] error: Bad exit status from /var/tmp/rpm-tmp.nhGVvc (%build)
```
It is not clear to me how access to this color information would be obtained without reimplementing the rgb utility functions in the application. That does not sound desirable.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1595Xwayland failing to set viewport and _XWAYLAND_RANDR_EMU_MONITOR_RECTS2023-11-10T16:12:07ZneofeoXwayland failing to set viewport and _XWAYLAND_RANDR_EMU_MONITOR_RECTSHi, I am trying to find a solution to mutter not being able to scale 640x480 wine games with xwayland properly. I am on mantic, with fairly latest packages, but for sure not the absolute latest xwayland release. Although, this is what gn...Hi, I am trying to find a solution to mutter not being able to scale 640x480 wine games with xwayland properly. I am on mantic, with fairly latest packages, but for sure not the absolute latest xwayland release. Although, this is what gnome mutter devs where able to find out. They basically claim that xwayland seems the culprit here.
Link to the issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/3131
What the dev said there:
Sebastian Keller
@skeller
The way this is supposed to work is that XWayland detects when an X11 application tries to change the resolution of the monitor and then sets up a Wayland viewport that scales the window accordingly. This does not seem to happen for those applications.
Running env WINEDEBUG=+x11drv wine ./CLAW.EXE 2>&1 | grep apply_display_settings gives:
0114:trace:x11drv:apply_display_settings handler:XRandR 1.4 changing L"\\\\.\\DISPLAY1" to position:(0,0) resolution:640x480 frequency:59Hz depth:8bits orientation:0.
So wine attempts to change the resolution, but XWayland does not set up a viewport. It does not set the _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on the window either. That might mean that some of the heuristics used to detect these fullscreen + resolution changes are no longer working, possibly due to changes on the mutter side (maybe the frames client). Now it would be good to know if this is an issue on the XWayland side or on the mutter side. Does this work on other Wayland compositors?https://gitlab.freedesktop.org/xorg/xserver/-/issues/1594RFE: Support for libdecor with rootless Xwayland for X11 applications2023-11-07T08:20:02ZNeal Gompa (ニール・ゴンパ)RFE: Support for libdecor with rootless Xwayland for X11 applicationsWhen Xwayland gained support for libdecor in !901, it was only for the X server window itself in rootful mode. Given that server-side decorations are not mandatory, it would be very useful if rootless Xwayland would wrap X11 applications...When Xwayland gained support for libdecor in !901, it was only for the X server window itself in rootful mode. Given that server-side decorations are not mandatory, it would be very useful if rootless Xwayland would wrap X11 applications with libdecor if the host compositor does not advertise support for SSDs.
This would make it easier for desktops/window managers to port to Wayland while still supporting X11 applications in their environments, because all they need to do is write plugins for libdecor instead of having to do work at the compositor level. And if they want to implement SSDs, then it would transparently support them too.https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/73libxcb-1.16 broke numbered unix DISPLAY sockets2023-10-29T22:05:17ZTaylor Campbelllibxcb-1.16 broke numbered unix DISPLAY socketsPreviously, with DISPLAY set to `unix:0`, libxcb up through version 1.15 would connect to display 0 using only local unix sockets in `/tmp/.X11-unix`:
```
$ echo $DISPLAY
unix:0
$ glxinfo -B
name of display: unix:0
display: unix:0 scre...Previously, with DISPLAY set to `unix:0`, libxcb up through version 1.15 would connect to display 0 using only local unix sockets in `/tmp/.X11-unix`:
```
$ echo $DISPLAY
unix:0
$ glxinfo -B
name of display: unix:0
display: unix:0 screen: 0
...
```
ktrace confirms that it is connecting to `/tmp/.X11-unix/X0`.
But libxcb 1.16 broke this:
```
$ echo $DISPLAY
unix:0
$ glxinfo -B
Error: unable to open display unix:0
$
```
ktrace reveals that it is trying to stat the file `0` (relative to working directory) and failing because it doesn't exist, instead of trying to connect to `/tmp/.X11-unix/X0` as it should.
I haven't tested any local changes to libxcb, but I suspect this commit is the culprit: https://gitlab.freedesktop.org/xorg/lib/libxcb/-/commit/095255531b90f0b442e6ca41fb3752a058562d07https://gitlab.freedesktop.org/xorg/driver/xf86-video-qxl/-/issues/17Driver always sets pScreen->DestroyPixmap to NULL during teardown2023-10-27T01:28:49ZPeter HuttererDriver always sets pScreen->DestroyPixmap to NULL during teardownIn `uxa_close_screen()` qxl tries to restore the various wrapped screen functions, including `DestroyPixmap`.
```
pScreen->DestroyPixmap = uxa_screen->SavedDestroyPixmap;
```
But `SavedDestroyPixmap` is never assigned from the origina...In `uxa_close_screen()` qxl tries to restore the various wrapped screen functions, including `DestroyPixmap`.
```
pScreen->DestroyPixmap = uxa_screen->SavedDestroyPixmap;
```
But `SavedDestroyPixmap` is never assigned from the original function, so we always set it to NULL here. If this code is ever called [^1] it will lead to segfault during pixmap cleanup.
---
[^1]: right now it isn't because of a buggy shortcut in the X server, see https://gitlab.freedesktop.org/xorg/xserver/-/commit/d348ab06aae21c153ecbc3511aeafc8ab66d8303https://gitlab.freedesktop.org/xorg/xserver/-/issues/1593Q965 ID 8086:2992 with modesetting DIX GPU HANG2024-01-09T04:54:48ZFelix Miatamrmazda@earthlink.netQ965 ID 8086:2992 with modesetting DIX GPU HANG[ 270.310368] i915 0000:00:02.0: [drm] GPU HANG: ecode 4:1:9fe7fbfd, in Xorg [474]
[ 270.352125] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
[ 270.454936] i915 0000:00:02.0: [drm] Xorg[474] context reset due ...[ 270.310368] i915 0000:00:02.0: [drm] GPU HANG: ecode 4:1:9fe7fbfd, in Xorg [474]
[ 270.352125] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
[ 270.454936] i915 0000:00:02.0: [drm] Xorg[474] context reset due to GPU hang
[ 270.481002] i915 0000:00:02.0: [drm] Setting output timings on SDVOB failed
[ 296.165343] i915 0000:00:02.0: [drm] GPU HANG: ecode 4:1:9fe7fbfd, in Xorg [474]
[ 296.203298] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
[ 296.306253] i915 0000:00:02.0: [drm] Xorg[474] context reset due to GPU hang
[ 296.332394] i915 0000:00:02.0: [drm] Setting output timings on SDVOB failed
Downstream bug reported in June:
https://bugzilla.opensuse.org/show_bug.cgi?id=1212696
Occurs on:
# inxi -C --vs
inxi 3.3.30-00 (2023-09-25)
CPU:
Info: dual core model: Intel Core2 6700 bits: 64 type: MCP cache: L2: 4 MiB
Speed (MHz): avg: 1595 min/max: N/A cores: 1: 1595 2: 1595
# inxi -GSaz --hostname
System:
Host: gx745 Kernel: 6.1.0-13-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 12.2.0 clocksource: tsc available: hpet,acpi_pm parameters: ro
root=LABEL=13debian ipv6.disable=1 net.ifnames=0 plymouth.enable=0
noresume consoleblank=0
Desktop: Trinity v: R14.1.0 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0
vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux 12 (bookworm)
Graphics:
Device-1: Intel 82Q963/Q965 Integrated Graphics vendor: Dell driver: i915
v: kernel arch: Gen-4 process: Intel 65n built: 2006-07 ports:
active: DVI-D-1,VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:2992
class-ID: 0300
Display: x11 server: X.Org v: 1.21.1.7 driver: X: loaded: modesetting
dri: crocus gpu: i915 display-ID: :0 screens: 1
Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
s-diag: 803mm (31.62")
Monitor-1: DVI-D-1 pos: right model: NEC EA243WM serial: <filter>
built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 640x480
Monitor-2: VGA-1 pos: primary,left model: Dell P2213 serial: <filter>
built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
max: 1680x1050 min: 720x400
API: EGL v: 1.5 hw: drv: intel crocus platforms: device: 0 drv: crocus
device: 1 drv: swrast gbm: drv: crocus surfaceless: drv: crocus x11:
drv: crocus inactive: wayland
API: OpenGL v: 2.1 vendor: intel mesa v: 22.3.6 glx-v: 1.4 es-v: 2.0
direct-render: yes renderer: Mesa Intel 965Q (BW) device-ID: 8086:2992
memory: 375 MiB unified: yes
#
and on
# inxi -GSaz
System:
Kernel: 6.5.8-lp155.3.g51baea8-default arch: x86_64 bits: 64 compiler: gcc
v: 11.3.0 clocksource: tsc available: hpet,acpi_pm
parameters: root=LABEL=10s155 ipv6.disable=1 net.ifnames=0 noresume
consoleblank=0
Desktop: KDE v: 3.5.10 tk: Qt v: 3.3.8c info: kicker wm: kwin vt: 7 dm:
1: KDM 2: XDM Distro: openSUSE Leap 15.5
Graphics:
Device-1: Intel 82Q963/Q965 Integrated Graphics vendor: Dell driver: i915
v: kernel arch: Gen-4 process: Intel 65n built: 2006-07 ports:
active: DVI-D-1,VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:2992
class-ID: 0300
Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: modesetting
dri: crocus gpu: i915 display-ID: :0 screens: 1
Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
s-diag: 803mm (31.62")
Monitor-1: DVI-D-1 pos: primary,left model: NEC EA243WM serial: <filter>
built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 640x480
Monitor-2: VGA-1 pos: right model: Dell P2213 serial: <filter> built: 2012
res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2 size: 473x296mm (18.62x11.65")
diag: 558mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400
API: EGL v: 1.5 hw: drv: intel crocus platforms: device: 0 drv: crocus
device: 1 drv: swrast gbm: drv: crocus surfaceless: drv: crocus x11:
drv: crocus inactive: wayland
API: OpenGL v: 4.5 compat-v: 2.1 vendor: intel mesa v: 22.3.5 glx-v: 1.4
direct-render: yes renderer: Mesa Intel 965Q (BW) device-ID: 8086:2992
memory: 375 MiB unified: yes
#
but apparently does not on same PC in:
# inxi -GS
System:
Host: gx745 Kernel: 6.5.6-1-default arch: x86_64 bits: 64
Desktop: KDE Plasma v: 5.27.8 Distro: openSUSE Tumbleweed 20231020
Graphics:
Device-1: Intel 82Q963/Q965 Integrated Graphics driver: i915 v: kernel
Display: x11 server: X.Org v: 21.1.8 with: Xwayland v: 23.2.1 driver: X:
loaded: modesetting unloaded: fbdev,vesa dri: crocus gpu: i915 resolution:
1: 1920x1200~60Hz 2: 1680x1050~60Hz
API: EGL v: 1.5 drivers: crocus,swrast
platforms: gbm,x11,surfaceless,device
API: OpenGL v: 4.5 compat-v: 2.1 vendor: intel mesa v: 23.2.1
renderer: Mesa Intel 965Q (BW)
#
Full dmesg from Debian 12 without drm.debug=0x1e log_buf_len=5M[dmesg-gx745-deb12-newbug-0M.txt](/uploads/f1f849eae49a5c435c3b5d400b94f558/dmesg-gx745-deb12-newbug-0M.txt)
Full dmesg from Debian 12 with drm.debug=0x1e log_buf_len=5M[dmesg-gx745-deb12-newbug-5M.txt](/uploads/fb1ee9598adf376e18b2ae601d4e37f9/dmesg-gx745-deb12-newbug-5M.txt)https://gitlab.freedesktop.org/xorg/lib/libxkbfile/-/issues/10CapsLock and Right Alt don't shift keyboard levels anymore2023-10-22T14:48:40ZAlexander PrähauserCapsLock and Right Alt don't shift keyboard levels anymorePlease note that I'm filing this xorg issue here because I don't know the exact project I am supposed to file it under. I am using a modification of the German Neo layout and just updated my pc this morning, and after the update I could ...Please note that I'm filing this xorg issue here because I don't know the exact project I am supposed to file it under. I am using a modification of the German Neo layout and just updated my pc this morning, and after the update I could not access the upper levels of my keyboard, which are normally reached with CapsLock and Right Alt. I tested this with my own layout, but also the Koy and Neo layout. I also tried using the standard German and English layouts. With the English, CapsLock didn't work, whereas with the standard German one it shifted to a level where it produces the letter æ when the AC01 is pressed.
I tried replacing the `/usr/share/X11/xkb/symbols` folder with a backup, then replacing the `/usr/share/X11/xkb/` folder, and both times it didn't change the situation. Replacing the entire X11 folder worked though, so I assume the error is not in xkb but somewhere else in `/usr/share/X11`.
I'm not sure what information is useful to you, so here is everything I know. My system is Arch. I encountered the bug while using StumpWM, which runs on X11, but it persisted when I switched to Gnome on Wayland. Here are all packages on my Computer that have `xorg`, `xkb` or `x11` in them, as listed by pacman, which I think means their version numbers are the ones as it installed them last, not as they are in my manually replaced X11 folder:
```
[alex@Archlaptop /]$ sudo pacman -Qe | grep xorg
xorg-fonts-encodings 1.0.7-1
xorg-fonts-misc 1.0.4-1
xorg-mkfontscale 1.2.2-1
xorg-server 21.1.8-2
xorg-server-common 21.1.8-2
xorg-setxkbmap 1.3.4-1
xorg-xev 1.2.5-1
xorg-xhost 1.0.9-1
xorg-xinput 1.6.4-1
xorg-xkbcomp 1.4.6-1
xorg-xkbutils 1.0.5-1
xorg-xmodmap 1.0.11-1
xorg-xprop 1.2.6-1
xorg-xrdb 1.2.2-1
xorg-xset 1.2.5-1
xorg-xwayland 23.2.1-1
xorgproto 2023.2-1
[alex@Archlaptop /]$ sudo pacman -Qe | grep xkb
libxkbcommon 1.6.0-1
libxkbcommon-x11 1.6.0-1
libxkbfile 1.1.2-1
xorg-setxkbmap 1.3.4-1
xorg-xkbcomp 1.4.6-1
xorg-xkbutils 1.0.5-1
[alex@Archlaptop /]$ sudo pacman -Qe | grep X11
[alex@Archlaptop /]$ sudo pacman -Qe | grep x11
libx11 1.8.7-1
libxkbcommon-x11 1.6.0-1
```
The output of xmodmap is as follows
```
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):
shift Shift_L (0xb), Shift_R (0x3e)
lock Shift_L (0x32)
control Control_L (0xe), Control_R (0x69)
mod1 Alt_L (0x40), Alt_L (0xcc), Meta_L (0xcd)
mod2
mod3 ISO_Level5_Shift (0xcb)
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c)
```
After I replaced the new X11 folder with the old one, this table changed back to:
```
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x31), Shift_R (0x3e)
lock Shift_L (0x32)
control Control_L (0xe), Control_R (0x69)
mod1 Alt_L (0x40), Alt_L (0xcc), Meta_L (0xcd)
mod2 Hyper_L (0xa)
mod3 ISO_Level5_Shift (0xcb)
mod4 Super_L (0xf), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c)
```
showkey signaled the keycode 58 when I pressed CapsLock. This stayed consistent. Please tell me any other information you need.https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/71Rootless X server crashes 60 seconds after start2024-02-25T17:38:24ZRoman ŽilkaRootless X server crashes 60 seconds after startAfter a switch from lxdm and running X as `root` to sddm and a rootless X server there is ~50% probability of the X server crashing exactly 60 seconds after start. By "crash" I mean unexpected termination, the X process terminates with a...After a switch from lxdm and running X as `root` to sddm and a rootless X server there is ~50% probability of the X server crashing exactly 60 seconds after start. By "crash" I mean unexpected termination, the X process terminates with a success. There is nothing in [Xorg.0.log](/uploads/5fddf3fa641f4e44fe363ce3aa11826b/Xorg.0.log) or kernel log. Sometimes I get
```
(WW) AMDGPU(0): flip queue failed: Invalid argument
(WW) AMDGPU(0): Page flip failed: Broken pipe
```
or
```
(WW) AMDGPU(0): flip queue failed: Invalid argument
(WW) AMDGPU(0): Page flip failed: Invalid argument
```
when X is finishing, but the emission of this message isn't correlated with the unexpected crash. It's just the only thing that's out of place that I can see.
The DM executes X as `/usr/bin/X -nolisten tcp -background none -seat seat0 -noreset -keeptty -novtswitch -verbose 3 -auth /run/user/1000/xauth_ardJzu -displayfd 13 vt4`. [X-crash-strace](/uploads/905049d50968d26c3529b7ceac3e081c/X-crash-strace) [X-crash-ltrace](/uploads/68f9654d20aa65d56684cfbf5b1b2cb2/X-crash-ltrace) of the last few seconds of the process.
RX 6500 XT [lspci-nnvv](/uploads/9bd455c12868321b44f561f4c3a63fcb/lspci-nnvv), 1x FreeSync LCD over DP. Kernel 6.1.57 custom [config](/uploads/749bfaa751869731ebfca988f4222357/config) [dmesg](/uploads/bceb40f77d44b6a0056a684e96ed149c/dmesg), x86_64, Gentoo, gcc 13.2.1 20230826, xorg-server 21.1.8, xf86-video-amdgpu 23.0.0, linux-firmware 20230919, sddm 0.20.0.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1591Custom keyboard layouts appear only after physically pressing a key.2023-12-11T13:43:18ZAnton GolubevCustom keyboard layouts appear only after physically pressing a key.To switch to another layout, I added a file `/etc/X11/xorg.conf.d/00-keyboard.conf` with the following content:
```
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "ru,us"...To switch to another layout, I added a file `/etc/X11/xorg.conf.d/00-keyboard.conf` with the following content:
```
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "ru,us"
Option "XkbModel" "pc104"
Option "XkbOptions" "grp:caps_toggle"
EndSection
```
Everything works fine, except for a small thing - before you physically press any key, some request to the X server returns the presence of only one keyboard layout - "us". And the same request, after pressing a key, returns two layouts - “ru,us”.
This request is used in the login manager, so the widget for switching layouts after loading shows only one layout, and after you touch the keyboard, it begins to show two layouts.
Or, if you connect via ssh , call the command
```
setxkbmap -option -layout ru,us -option grp:caps_toggle
```
Then two layouts become visible.
The call I mentioned to get the layouts is:
```
xcb_xkb_get_names(m_conn, XCB_XKB_ID_USE_CORE_KBD, XCB_XKB_NAME_DETAIL_GROUP_NAMES | XCB_XKB_NAME_DETAIL_SYMBOLS);
```
Apparently, the parameters of the master keyboard are requested here.
I did some research, the default layout of the master keyboard, "Virtual core keyboard", is hard-coded via
```
XkbInitRules(&set, rules, "pc105", "us", NULL, NULL);
```
And don't update anymore. Further, when initializing devices, xkb options are loaded into all slave keyboards, inside the `MergeInputClasses` function, but are not transferred to the master keyboard. After any key is pressed, when processing event, inside the `UpdateFromMaster` function, due to the fact that the lastSlave in the master keyboard is 0 yet, a new event of type `ET_DeviceChanged` is generated, as a result of which xkb options are copied to the master keyboard.
Thus, after at least one keypress, the layout settings specified in xorg.conf end up in the master keyboard.
Is this expected behavior? Maybe I need to use a different request to the X server to get the layouts?
I noticed that `setxkbmap -print` shows the correct `ru,us` layouts from the very beginning.
But it retrieves xkb values from the `XKB_RULES_NAMES` property, via function `XkbRF_GetNamesProp`. I also noticed that similar problem exists in KDE5 on X.org, if you enter a session without pressing the keyboard, for example using a fingerprint reader. (does not reproduce on all available computers and I haven't looked into it in detail).
UPDATE 23-12-11:
I found that if I just run `setxkbmap` (without arguments), it fixes the problem. That is, rmlvo, located in `_XKB_RULES_NAMES`, is placed in the "Virtual Core Keyboard" device. Because `XkbRF_GetNamesProp` is run first and the data is read, and then `XkbGetKeyboardByName` is called and this causes that data to be written to the Core Keyboard. It seems that this is indeed a Xorg bug.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1590xwayland crash in xwl_present_cleanup2023-11-17T09:45:52ZLionel Landwerlinxwayland crash in xwl_present_cleanupI just got ths crash on 22.1.8 :
```
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_...I just got ths crash on 22.1.8 :
```
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007f0d1a43c3b6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007f0d1a42287c in __GI_abort () at ./stdlib/abort.c:79
#5 0x000055d83233e390 in OsAbort () at ../os/utils.c:1353
#6 0x000055d832349cbf in AbortServer () at ../os/log.c:879
#7 FatalError (f=<optimized out>) at ../os/log.c:1017
#8 0x000055d83233c5c1 in OsSigHandler (unused=<optimized out>, sip=<optimized out>, signo=11) at ../os/osinit.c:156
#9 OsSigHandler (signo=11, sip=<optimized out>, unused=<optimized out>) at ../os/osinit.c:110
#10 <signal handler called>
#11 xwl_present_cleanup (window=0x55d83490ec70) at ../hw/xwayland/xwayland-present.c:373
#12 xwl_destroy_window (window=0x55d83490ec70) at ../hw/xwayland/xwayland-window.c:869
#13 0x000055d8322b340e in compDestroyWindow (pWin=0x55d83490ec70) at ../composite/compwindow.c:620
#14 0x000055d8322c50f4 in damageDestroyWindow (pWindow=0x55d83490ec70) at ../miext/damage/damage.c:1590
#15 0x000055d8322af6fd in DbeDestroyWindow (pWin=0x55d83490ec70) at ../dbe/dbe.c:1326
#16 0x000055d8322a8e39 in FreeWindowResources (pWin=pWin@entry=0x55d83490ec70) at ../dix/window.c:1018
#17 0x000055d8322a909e in DeleteWindow (value=0x55d83490ec70, wid=50331651) at ../dix/window.c:1086
#18 0x000055d8322a1942 in doFreeResource (res=0x55d834298780, skip=skip@entry=0) at ../dix/resource.c:888
#19 0x000055d8322a23ed in FreeClientResources (client=0x55d8347bd940) at ../dix/resource.c:1154
#20 0x000055d83227e5b6 in FreeClientResources (client=0x55d8347bd940) at ../dix/resource.c:1126
#21 CloseDownClient (client=<optimized out>) at ../dix/dispatch.c:3546
#22 0x000055d83233db62 in ospoll_wait (ospoll=0x55d8332bfe90, timeout=<optimized out>) at ../os/ospoll.c:657
#23 0x000055d83227ef59 in WaitForSomething (are_ready=0) at ../os/WaitFor.c:208
#24 Dispatch () at ../dix/dispatch.c:492
#25 0x000055d83220c5d9 in dix_main (envp=<optimized out>, argv=<optimized out>, argc=<optimized out>) at ../dix/main.c:271
#26 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../dix/stubmain.c:34
```