After update, when I try to accent a letter in my keyboard layout (Latvian (tilde)) using Level3 Latch dead key, I do not get the accented symbol, instead I get the dead key and the unaccented symbol. Holding the dead key outputs dead key and accented symbol. Using Level3 Shift key works as expected (hold the key when writing symbol). Reproducible: Always Steps to Reproduce: 1. Press tilde/grave (`) 2. Press symbol to accent (a) Actual Results: Symbols `a appear. Expected Results: Accented symbol ā should appear Additional Information: Holding the tilde/grave instead of just pressing writes out `ā. Similar issue https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2040450 workaround adding ibus variables to /env/environment worked for non-electron based apps (e.g. Firefox), but remained broken for electron based (e.g. Discord). I chose component based on the bug report, I hope it's correct. This happens only on my desktop PC, but not on my laptop. I've attached dnf list of the laptop before rebooting after updating through Discover and after updating. I updated the devices at the same time, so desktop PC would've been on the same version or a bit newer while it was working.
Created attachment 2131751 [details] Package versions before update
Created attachment 2131752 [details] Package versions after update
I assume this would be an ibus issue.
Made a tentative patch.
I have the same new issue on Latvian Apostrophe layout. And I also had and still have the old issue which OP linked to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2040450 I had previously reported it to KDE https://bugs.kde.org/show_bug.cgi?id=513571 but it didn't gain any traction there. So it is now possible to type ('so) and get ('šō) while it should be (šo)
FEDORA-2026-e6f48632aa (ibus-1.5.34~rc1-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-e6f48632aa
FEDORA-2026-e6f48632aa has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-e6f48632aa` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-e6f48632aa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I wanted to try to test, so I set up a fresh VM, but same as on laptop, everything worked fine. However, I noticed that Virtual Keyboard differed - on VM it was Mailiit, on my PC it was Plasma Keyboard. I haven't checked my laptop yet, but I will try to tomorrow. Results were: None - works correctly on both VM and PC Mailiit - works correctly on both VM and PC IBus Wayland - has the issue on both VM and PC Plasma Keyboard - has the issue on PC, doesn't exist in VM. I checked my btrfs snapshot for Fedora 42 and a day ago (before I played with this) the config in ~/.config/kwinrc was: [Wayland] EnablePrimarySelection=false VirtualKeyboardEnabled=true After unsetting/setting the Virtual Keyboard in current system it changed to: [Wayland] EnablePrimarySelection=false InputMethod[$e]=/usr/share/applications/com.github.maliit.keyboard.desktop VirtualKeyboardEnabled=true Maybe the defaults somehow changed, or the config is also in a different file - let me know what I'd need to check. I'll try to set up a Fedora 44 VM soon to check this update.
@Askolds Sorry, I should ask you which virtual keyboard you used. I fixed your issue in IBus side since IBus also has the similar issue. When you go to systemsettings -> "Input & Output" -> "Keyboard" -> "Virtual Keyboard", and click the "IBus Wayland" icon "Apply" button. And then you will enable IBus instead of Maliit. You can enable the XKB with ibus-setup -> "Input Method" -> "Add" button and "Latvian" -> "Latvian (tilde)" I fixed your issue between ibus-1.5.34~beta1-1.fc44 and ibus-1.5.34~rc1-1.fc44. If you wish to fix Maliit keyboard, could you please file it again for Maliit?
No worries! I understood that this issue was ibus specific after choosing IBus Wayland in the Virtual Keyboard. I was writing that with Mailiit there were no issues, only ibus and plasma - does Plasma Keyboard use ibus underneath, since the issue is identical? I've checked my laptop and both IBus Wayland and Plasma Keyboard work fine on it (latest Fedora 43 updates), but not on my PC (also latest Fedora 43 updates). I've also installed Fedora 44 in the VM and confirmed the issue persists without your patch. After applying the patch, the issue doesn't change for Plasma Keyboard (I'm sure it's not within the patch's scope anyways), but becomes different with IBus Wayland: Pressing the accent key (tilde/grave in my case), then symbol, the symbol appears (not the accented symbol); Holding the accent key, then symbol, the accented symbol appears. It seems like the same issue, just the tilde/grave is not being outputted. I'll also report this in the bodhi link without mentioning the Plasma Keyboard as it doesn't seem relevant in this case.
@Askolds: You're right. Seems there was a timing issue or I had kept pressing TLDE key. Now I think your original issue might be in KDE since it can be reproduced without ibus. If you run systemsettings -> "Input & Keyboard" -> "Keyboard" and enable "Layouts", you will notice the setting does not show "Latvian(tilde)" but "Latvian(dvorak)" and I guess KDE does not implement "Latvian(tilde)" yet. Whiie we can enable the session layout to modify /etc/vconsole.conf and /etc/X11/xorg.conf.d/00-keyboard.conf I'm fixing this issue in IBus side to update xkb_state however the change effects other key typings and thinking the integration after the Fedora 44 GA and I delete this bug from the bodhi update at the moment. I will provide the copr repo later for the test purpose. We need to decide whether the tiny fix is reverted not to output the dead keys with ibus-1.5.34~rc1 or not for Fedora 44 GA.
What do you mean by not showing "Latvian(tilde)" but "Latvian(dvorak)"? For me I see a lot of layouts - Latvian with nothing, (apostrophe), (tilde) (Dvorak) and many more. Am I looking in the wrong place? I've always had the Layouts enabled, as sometimes it's convenient to switch to English with no dead keys. I'm not sure if there are any other layouts that use the latch key except Latvian, where I think most people use apostrofs (which is also affected by this bug) or default Alt key (not affected), so I do not think this issue is very high severity, and has workaround by switching Virtual Keyboard. I do not know if the last paragraph is addressed to me or other people, but as far as I'm concerned, with the tiny fix is slightly more usable than without it, so it's fine to revert or keep it - if it fixes something else, perfectly okay to keep it.
Working on another patch.
I made the COPR repo with the latest patch: https://copr.fedorainfracloud.org/coprs/fujiwara/test/ @Askolds: It would be great if you could test it. Now it supports the different layout between the session and user layouts. E.g. you could configure "US" keymap for the default session layout and "LV(tilde)" keymap with ibus-setup. Currently the Wayland protocol can detect the switching XKG group layouts likes "grp:toggle" but cannot the clicking keyboard icon in the KDE panel and that way does not work with IBus at present and I will report the issue to KDE later. (In reply to Askolds from comment #13) > What do you mean by not showing "Latvian(tilde)" but "Latvian(dvorak)"? > For me I see a lot of layouts - Latvian with nothing, (apostrophe), (tilde) > (Dvorak) and many more. Am I looking in the wrong place? I've always had the > Layouts enabled, as sometimes it's convenient to switch to English with no > dead keys. Seems my issue is a UI issue of the systemsettings. Right, clicking the "Latvian" flag icon shows all variants but typing the language work in the search box sometimes didn't show all variants and I was confused by it. But I think the original issue reported by you is caused by KDE while I'm fixing the issue in the IBus side. > I'm not sure if there are any other layouts that use the latch key except > Latvian, where I think most people use apostrofs (which is also affected by > this bug) or default Alt key (not affected), so I do not think this issue is > very high severity, and has workaround by switching Virtual Keyboard. I agree with the high severity but it's not an IBus regression. My plan is the IBus update after Fedora 44 GA. > I do not know if the last paragraph is addressed to me or other people, but > as far as I'm concerned, with the tiny fix is slightly more usable than > without it, so it's fine to revert or keep it - if it fixes something else, > perfectly okay to keep it. OK, the tiny fix not to output tilde char will be kept for Fedora 44 GA until we find any regression with the change.
Thank you for your work! I installed your patch in the Fedora 44 VM, added ibus-setup Input Method Latvian (tilde). When I first switch and type, it works perfectly, however there are issues: Caps lock seems to get stuck (after toggling it once, it can no longer be disabled - toolbar shows when it's enabled/disabled correctly), If at any point I press (doesn't need to be while typing/focused text box) - Left/Right CTRL, - Left Alt (Right, which is used for accents, not affected), - Left Meta (Right not affected) accents stop working, and it just outputs ` + symbol. I think I tried all keys on standard 104 key keyboard and these seem to be the only ones.
Copr packages fixed my issue with tilde (used for verbatim text markup) after today's set of Fedora updates. Thanks!
I updated the COPR repo with the latest patch: https://copr.fedorainfracloud.org/coprs/fujiwara/test/ - Fix latch key with shift in cause it used by compose - Support use-system-keyboard-layout to use the session layout with ibus-setup @Askolds: > Caps lock seems to get stuck (after toggling it once, it can no longer be disabled I couldn't reproduce your issue with both case of (system keymap lv, ibus keymap lv) and (system keymap us, ibus keymap lv). When I type CapsLock, a, b, c, CapsLock, d, "ABCd" is output correctly with ibus-1.5.34~rc1-4.1 in COPR. But it would be good for you to try ibus-1.5.34~rc2-1.1 in COPR. I reported clicking KDE icon issue for multiple layouts to KDE: https://bugs.kde.org/show_bug.cgi?id=518371 So switching XKB layouts with the XKB option keys works but you need to restart ibus if you switch XKB layouts with clicking KDE keyboard icon.
The Caps lock issue seemed to be fixed when I booted up the machine, so maybe just a case of needing another reboot (I did one after updates). Accents work correctly now when I set both layouts (KDE and ibus) to latvian (tilde), but not when KDE is set to something else (e.g. en(us) - though I'm not sure if this counts as a bug. Also, after changing layouts many times and ibus restarts, this mismatched layout issue seemed to disappear. When I enable "Use system keyboard layout" in ibus preferences, both with "ibus restart" and without it, accents only work with quick succession of the symbol key after the accent key (tilde). I'm not sure if this is the correct command, but the KDE keyboard icon might just not set the XKB layout correctly (command run with latvian layout in KDE icon): setxkbmap -query | grep layout WARNING: Running setxkbmap against an Xwayland server layout: us The ibus icon shows latvian layout though, or rather the layout I had set it to.
> but not when KDE is set to something else (e.g. en(us) - though I'm not sure if this counts as a bug. Also, after changing layouts many times and ibus restarts, this mismatched layout issue seemed to disappear. As I noted, now IBus supports such a situation. I'd ask you to describe your issue with detail. IBus now works with the latch keys in case that you set "lv(tilde)" for IBus keymap and "us" for the session keymap. Do you mean your issue happens only when you switch layouts many times? I assume you switch the layouts of the IBus keymaps with Super-space key, I.e. configuring multiple keymaps with ibus-setup -> "Input Method" seciton. > When I enable "Use system keyboard layout" in ibus preferences, It means to use the session keymap forcibly and IBus won't set any keymaps so your issue cann be reproduced until your issue will be fixed in KDE side. So the new feature does not enhance your issue. I'm not sure whether KDE(kwin_wayland) or each application should fix your issue in fact.