You are not logged in.
Hey everyone
I'm experiencing a weird bug on GNOME where pressing the delete key in most software inputs the actual delete as an Unicode character ("", U+007F) instead of deleting the character to the right. Pressing the delete key again changes that character to the Arabic Letter Hamza ("ء", U+0621).
This behavior persists across most applications (all GNOME applications and others), but it's not occurring on Firefox, GIMP, and a couple more.
I'm not sure what component is causing this issue to properly file a bug. I have looked at recent changes in gnome-shell, ibus (which is integrated into Gnome) and glibc, as they could be related and were all upgraded this week. My searches were inconclusive though.
Troubleshooting Steps:
Created a new user to test if the issue persists (it does).
Tested in both Xorg and Wayland sessions (present on both).
Tried changing locales (tested it_IT, en_US). The issue only happened in the pt_BR locale; the others do not exhibit this behavior.
Has anyone else encountered this issue or have suggestions for further troubleshooting? Any help would be greatly appreciated! I'm lost.
# System Details Report
---
## Report details
- **Date generated:** 2024-08-09 19:13:14
## Hardware Information:
- **Hardware Model:** HP HP ProBook 630 G8 Notebook PC
- **Memory:** 24.0 GiB
- **Processor:** 11th Gen Intel® Core™ i7-1185G7 × 8
- **Graphics:** Intel® Xe Graphics (TGL GT2)
- **Disk Capacity:** 2.0 TB
## Software Information:
- **Firmware Version:** T72 Ver. 01.10.01
- **OS Name:** Arch Linux
- **OS Build:** rolling
- **OS Type:** 64-bit
- **GNOME Version:** 46
- **Windowing System:** Wayland
- **Kernel Version:** Linux 6.10.3-arch1-2
Thanks,
hdmj
Last edited by hdmj (2024-09-19 16:29:34)
Offline
ls /usr/share/X11/locale/pt_BR*/Compose
Try to add an
~/.XCompose
include "/usr/share/X11/locale/en_US.UTF-8/Compose"
Though gnome uses https://wiki.archlinux.org/title/IBus by default and I'm not sure how or where XCompose is incorporated there¹, https://wiki.archlinux.org/title/Xorg/K … ompose_key
You changed the locale, not the keyboard layout?
¹ Though https://github.com/ibus/ibus/issues/1793 somewhat suggests it is and libx11 was updated 2 days ago…
Online
`/usr/share/X11/locale/pt_BR.UTF-8/Compose` has the following contents:
# UTF-8 (Unicode) compose sequences
#
# Originally modified for Brazilian Portuguese
# by Gustavo Noronha Silva <kov@debian.org>.
# Transformed to an include file plus some overrides
# by Benno Schulenberg <bensberg@justemail.net>
# Use the sequences from en_US.UTF-8 as the basis:
include "/usr/share/X11/locale/en_US.UTF-8/Compose"
# Two nice additions -- maybe add to en_US.UTF8?
<Multi_key> <quotedbl> <backslash> : "〝" U301d # REVERSED DOUBLE PRIME QUOTATION MARK
<Multi_key> <quotedbl> <slash> : "〞" U301e # DOUBLE PRIME QUOTATION MARK
# Overriding C with acute:
<dead_acute> <C> : "Ç" Ccedilla # LATIN CAPITAL LETTER C WITH CEDILLA
<dead_acute> <c> : "ç" ccedilla # LATIN SMALL LETTER C WITH CEDILLA
# Overriding E with ogonek:
<Multi_key> <comma> <E> : "Ȩ" U0228 # LATIN CAPITAL LETTER E WITH CEDILLA
<Multi_key> <comma> <e> : "ȩ" U0229 # LATIN SMALL LETTER E WITH CEDILLA
# Overriding U with ogonek:
<Multi_key> <U> <comma> <E> : "Ḝ" U1E1C # LATIN CAPITAL LETTER E WITH CEDILLA AND BREVE
<Multi_key> <U> <comma> <e> : "ḝ" U1E1D # LATIN SMALL LETTER E WITH CEDILLA AND BREVE
# These two should probably go back into en_US.UTF8;
# they were most likely mistakenly dropped in June 2006:
<Multi_key> <acute> <U03D2> : "ϓ" U03D3 # GREEK UPSILON WITH ACUTE AND HOOK SYMBOL
<Multi_key> <apostrophe> <U03D2> : "ϓ" U03D3 # GREEK UPSILON WITH ACUTE AND HOOK SYMBOL
The include is there, and adding it to a ~/.XCompose didn't work, unfortunately.
And yes, I have changed the locale and it does work (stops the bug), but changing the keyboard layout has no effect.
Offline
adding it to a ~/.XCompose
The plan was to to get rid of the pt_BR specific composition, though that file doesn't even look overly suspicious and hasn't been touched upstream since a year.
Did you re-login/restart ibus after the change?
What (else) was in compromising update?
Did you try to downgrade any of the mentioned packages (and esp. ibus) resp. switch from ibus to XIM?
Online
salve!
also what you get for `xmodmap -pm`?
Last edited by gcb (2024-08-10 17:43:02)
Offline
adding it to a ~/.XCompose
The plan was to to get rid of the pt_BR specific composition, though that file doesn't even look overly suspicious and hasn't been touched upstream since a year.
Did you re-login/restart ibus after the change?What (else) was in compromising update?
Did you try to downgrade any of the mentioned packages (and esp. ibus) resp. switch from ibus to XIM?
As ibus is integrated in GNOME, I'm not sure it's possible to restart it directly (i think GNOME only uses libibus package now, ibus is not installed directly).
Anyway, I tried re-login and rebooting after the change, but it didn't work.
I tried downgrading a bunch of packages (libibus, glibc, gnome-shell, linux and some others) but that also didn't work. I'm not sure what others to test.
Below are the packages affected in the two upgrades before I've noticed the issue:
# 2024/07/22
linux-api-headers libxml2 mesa libproxy orc audacity perl automake fastfetch
firefox libassuan pinentry gnupg gpgme libnftnl libnl iproute2 libibus
libinstpatch libupnp linux pacman-mirrorlist python-astroid python-coverage
python-gobject python-jaraco.text python-tomlkit python-trove-classifiers
python-urllib3 sof-firmware sudo suitesparse timeshift errands
# 2024/08/04
glibc gcc-libs gtest abseil-cpp alsa-card-profiles argon2 libpipewire
libcamera-ipa lz4 readline bash libxcrypt keyutils systemd-libs
ca-certificates-mozilla curl libelf libcamera libsysprof-capture pipewire
pipewire-audio pipewire-session-manager pipewire-jack libxml2
gsettings-desktop-schemas libxtst cryptsetup dbus-broker dbus-broker-units
systemd mesa glib-networking gstreamer hidapi sdl2 gst-plugins-base-libs libva
gst-plugins-bad-libs audacity binutils cracklib libadwaita svt-av1 libavif
epiphany nss parted mpfr evince libtool tdb evolution-data-server fastfetch
libopenmpt libvpx firefox firefox-i18n-pt-br fluidsynth gcc git
gnome-bluetooth-3.0 gpm gst-libav gst-plugin-gtk libgme imagemagick
gst-plugins-bad gst-plugins-base gst-plugins-good gst-plugins-ugly gzip
iproute2 ldb libedataserverui4 libheif libnm libwbclient libxfont2 licenses
linux pcsclite wpa_supplicant networkmanager pangomm-2.48 pipewire-pulse
pulse-native-provider python-jaraco.context python-jaraco.functools
python-jaraco.text python-numpy python-pikepdf python-pylint
python-trove-classifiers smbclient systemd-sysvcompat xapp xmlsec yt-dlp
salve!
also what you get for `xmodmap -pm`?
Salve!
Had to install xorg-xmodmap. Here's the output:
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Control_R (0x69)
mod1 Alt_L (0x40), Alt_L (0xcc), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3 ISO_Level5_Shift (0xcb)
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c)
I'm continuing troubleshooting and will share any findings here. Thank you both for the help so far!
Offline
The big obvious one would have been libibus…
1st, pin ibus:
https://wiki.archlinux.org/title/Input_method#Xim
gtk3-demo # alternatively, if that doesn't exhibit the problem, gtk4-demo
export GTK_IM_MODULE=xim
export GDK_CORE_DEVICE_EVENTS=1 # probably not relevant
gtk3-demo # issue gone?
Otherwise see whether you can restore proper function w/ a global downgrade to a date before this showed up: https://wiki.archlinux.org/title/Arch_L … cific_date
Online
The big obvious one would have been libibus…
1st, pin ibus:
https://wiki.archlinux.org/title/Input_method#Ximgtk3-demo # alternatively, if that doesn't exhibit the problem, gtk4-demo export GTK_IM_MODULE=xim export GDK_CORE_DEVICE_EVENTS=1 # probably not relevant gtk3-demo # issue gone?
Otherwise see whether you can restore proper function w/ a global downgrade to a date before this showed up: https://wiki.archlinux.org/title/Arch_L … cific_date
Only gtk4-demo exhibits the issue, but setting the environment variable had no effect (re-login, restarted and all).
I had then tried downgrading the gtk4 package (though it wasn't upgraded recently), but nothing, unfortunately.
Anyway, that's interesting... I'm trying to investigate a bit further before going with the global downgrade. But might as well do that soon.
Offline
libadwaita …
Online
Same issue here. Other 3 Brazilians also confirmed, and one of them said to have found the same issue in Fedora.
Have you consider cross-posting this in GNOME Discourse?
Offline
Have you tried to downgrade libadwaita?
Online
Have you tried to downgrade libadwaita?
Just tried that, but nothing. I'll likely proceed with the global downgrade later today.
Same issue here. Other 3 Brazilians also confirmed, and one of them said to have found the same issue in Fedora.
Have you consider cross-posting this in GNOME Discourse?
Good to know that I'm not alone. Where have you seen this confirmation?
I was first trying to pinpoint which was the defected package so I haven't considered cross-posting yet. Has anyone reported that over there already? (or in any other place?)
Offline
Good to know that I'm not alone. Where have you seen this confirmation?
I was first trying to pinpoint which was the defected package so I haven't considered cross-posting yet. Has anyone reported that over there already? (or in any other place?)
I've been collecting info from Arch Linux Brasil and GNOME Brasil Telegram groups. Haven't talked about it in Fedora groups, but a couple users in both groups told me they had this issue in Fedora or that someone else had.
I haven't seen any other report of this except for this forum post.
What I've got so far:
- This seems to be happening only with Brazilian Portuguese keyboard layout, GNOME, GTK4 apps and libx11=1.8.10
- A user tested in Hyprland and it was ok; then tried GNOME found it
- GTK3 apps are not affected, like gedit or firefox; GTK4 are affect, like GNOME Console, GNOME Text Editor, Nautilus, etc.
- libx11 1.8.10 shipped a lot of compose sequences changes (see commits comparison between 1.8.9 and 1.8.10).
- I don't know if it affects GNOME on Xorg; I'm on Wayland and test with libx11 confirmed.
I tried the following:
1- Downgrade libx11: https://archive.archlinux.org/packages/ … kg.tar.zst
2- Create a new user (e.g. sudo useradd -m -g 1000 testuser)
3- Switch to the new user, open Console (or other GTK4 app) and it will works fine!
4- Go back and update libx11 back to version 1.8.10
5- Switch to the new user, nothing changed (still works)
6- Go back remove the user, clean its home folder
7- Redo steps 2 and 3, but now the Delete key bug happens
Thanks to Victor Matheus that "bisected" using Arch Linux Archive and found libx11 1.8.10 to be the version that for some reason triggers this issue.
Last edited by josephg (2024-08-14 00:20:27)
Offline
https://gitlab.freedesktop.org/xorg/lib … _1690_1709
It was added to the /usr/share/X11/locale/en_US.UTF-8/Compose
No idea whow or why that would impact pt_BR but only on gtk4, but try to revert that patch (ie. remove the <dead_hamza> lines from that file), make sure to re-login to avoid cached behavior.
Online
seth, I haven't tested and I will, but please notice that this bug happens (AFAIK) only with GNOME. So while this commit could be started this issue, the problem might be somewhere else that doesn't properly handle this update.
Just to mention that an user from OpenSUSE Tumbleweed confirmed to have the same issue in Nautilus.
Offline
seth, I haven't tested and I will, but please notice that this bug happens (AFAIK) only with GNOME. So while this commit could be started this issue, the problem might be somewhere else that doesn't properly handle this update.
I opened an issue in LibX11 so we can keep track of it, even if it's something GNOME needs to handle, since 1.8.10 merge caused it, it has to be looked there first.
No idea whow or why that would impact pt_BR but only on gtk4, but try to revert that patch (ie. remove the <dead_hamza> lines from that file), make sure to re-login to avoid cached behavior.
I was bisecting it and the issue persists even after a reboot, it's only "fixable" if you revert further up to commit 4f554119. Which doesn't make any sense and makes me believe either GNOME or something else builds up a cache somewhere.
Here's the link for the issue: https://gitlab.freedesktop.org/xorg/lib … issues/220
Please do post any finding there so it might help.
Offline
Reported in GNOME Discourse: https://discourse.gnome.org/t/delete-ke … cale/22875
Offline
gtk4 meatime saw a rebuild against the newer libx11, but libadwaita didn't - w/ the but apparently dependign on the binary structure of libx11 more than any actual upstream commit: if the gtk4 4.14.5-1 didn't fix this, you could try to also rebuild libadwaita
Online
Be advised that this merge request fixes the issue: https://gitlab.freedesktop.org/xorg/lib … quests/265
Offline
dead_hamza is used in Arabic layouts and this change will break these layouts.
While I wonder why arabic specific compositions need to exist in the US compose map (sounds like some cultural appropriation it also kinda conflicts with https://bbs.archlinux.org/viewtopic.php … 5#p2190725 and doesn't explain the *very*, like **incredibly narrow**, impact at all.
With https://gitlab.freedesktop.org/xorg/lib … te_2542782 and gnome traditionally operating on some copied keymaps, I wonder whether gtk internally uses a dated protocol definition here
(xorgproto 2024.1-2 is in the repos since April, Fools - both gtk4 and libadwaita should™ have long time build against it)
The main question is "why does gnome/ibus/whatever think that you pressed a dead hamster dead_hamza" (googling for that is probably not a good idea, hamza also seems to be a popular name…)
while read junk symbol value junk; do (($value & 0xfe8d == 0xfe8d)) 2>/dev/null && echo $symbol; done < /usr/include/X11/keysymdef.h
XK_VoidSymbol
XK_Delete
XK_KP_Enter
XK_KP_Begin
XK_KP_Delete
XK_KP_Equal
XK_KP_Subtract
XK_KP_Divide
XK_F2
XK_F16
XK_L6
XK_F18
XK_L8
XK_F32
XK_R12
XK_F34
XK_R14
XK_Hyper_L
XK_dead_hamza
XK_Pointer_Button5
XK_Pointer_DblClick1
XK_Pointer_Drag5
Right after the very special void symbol, XK_Delete is the first one to match the dead_hamza in a stupid byte comparism … or do you also get the same behavior w/ the Enter key on the keypad? Or F2?
Online
Hi folks! I was unable to follow up here in the past weeks, but thank you all for the help solving this puzzle.
Here's the link for the issue: https://gitlab.freedesktop.org/xorg/lib … issues/220
Be advised that this merge request fixes the issue: https://gitlab.freedesktop.org/xorg/lib … quests/265
For anyone following this, the merge request above was rejected in because the issue needed to be fixed in GTK.
Wismill shared insights here and here (though the proposed workaround didn't work for me).
therfc opened the GTK issue here: https://gitlab.gnome.org/GNOME/gtk/-/issues/6968 (Thank you twice! )
A fix should be coming soon as this commit was merged into GTK.
I'll keep this post updated.
Offline
At last, with gtk4 updating to 4.16.1 today, the issue is now resolved.
The following command and a reboot might be necessary though:
~ $ rm ~/.cache/gtk-4.0/compose/*
Thanks again, everyone
Offline