Gala: Layout change stutter

[Djaler]

I ran into something strange. When I change keyboard layout (by shortcut or using indicator), all system freeze for a half of second.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[donadigo]

Confirming that, mostly visible when using the Alt+Shift shortcut and while moving a window with a mouse.

[donadigo]

I've tried removing the gala code that handles this, but the issue seems to still persist - might not be a gala issue.

[cassidyjames]

@Djaler was this an issue in Loki, or is it a regression in Juno?

[Djaler]

@cassidyjames I didn't remember this on Loki. So looks like this is regression

[panoskouf]

It does not stutter for me, but if I type fast, first letter I type is of previous layout so it just takes half a sec to activate without preventing you from typing.

[cassidyjames]

@donadigo is it possible that you're just seeing the Mutter behavior of holding the shift key when moving a window? I'm not seeing any other type of stutter or lag when switching layouts here.

[Djaler]

@cassidyjames why you change the label?
The issue is still there. This is not about Shift. This is about layout change. I can reproduce it even by changing layout in keyboard indicator

[cassidyjames]

@Djaler we thought we were able to reproduce it based on @donadigo and my investigation. Otherwise we're not able to reproduce it here. What layouts are you using? Can you record a screencast to demonstrate it?

We just don't have enough information right now.

[Djaler]

I am using english and russian layouts.
There are screencast https://youtu.be/9FW1evushkA

[panoskouf]

maybe I can also be of help

this is me typing, just changing the layout while typing fast
languages: english, greek
Ι change the layout with custom shortcut: alt + space (no shift)

ελementary ελεμενταρι εlementary ελεμενταρι εlementary

if I change the layout and then wait half a sec before I start typing everything is as expected

[Djaler]

@cassidyjames can you check my screencast?

[cassidyjames]

@Djaler I saw it. It looks like an extremely brief stutter, possibly due to graphics drivers or something. It don't think Gala has anything to do with this whatsoever.

[Djaler]

@cassidyjames I checked this on Nvidia drivers and the issue still here

[Djaler]

Also, I really have no idea how graphic driver can affect layout change.
More info: the issue exists with any layout change shortcut

[marcelogdeandrade]

I have this issue aswell on a XPS 13 without Nvidia graphic cards, only a integrated intel graphics card.

Changing from PT-BR to US is slower than changing from US to PT-BR.

[marcelogdeandrade]

I believe this is an issue with Gnome and Xorg.

Everytime elementary deals with keyboard layout, it justs calls org.gnome.desktop.input-sources.

There are multiple threads about this issue when using Gnome and Xorg without elementary.

1
2
3
4

[kotborealis]

I have the same issue. I use RU and US layouts, switching from US to RU is almost fine, but RU to US has ~1 second lag.

I'm using fresh install of Juno on Asus ux310u.

I also believe that this was an issue in Loki and that I've managed to find some kind of a workaround, but now I can't find a way to fix it :(

[Djaler]

@cassidyjames maybe this shouldb't be "Incomplete" now?

[marcelogdeandrade]

I have a possible temporary solution.

I can't guarantee it will work, but it helped a lot for me, I'm using US and PT-BR layouts.

1. Open your keyboard layout file for your language, in my case:

sudo nano /usr/share/X11/xkb/symbols/br

1. Comment the following line

modifier_map Mod3 { Scroll_Lock };

1. Logout and Login again.

I saw this solution here

[kotborealis]

@marcelogdeandrade I'm glad it worked for you, but there's no such line in file for RU layout 😞

Thanks for answer anyway 👍

[jacob1237]

The same issue on Acer Swift 3 SF315-52G. The same layouts in the system: RU and EN(US). I can also confirm that switching from RU -> US produces a bigger delay than US -> RU.

Had no such issues in Loki

[cassidyjames]

@Djaler we still have no idea what is causing the issue, which component is the culprit, or if it's even something we can address.

[Djaler]

@cassidyjames so maybe move this to os?

[marcelogdeandrade]

@cassidyjames What about a "priority" label so more people can try to figure it out?

For people that use two keyboard layouts, this is a deal breaker, it becomes almost impossible to write a document using two layouts.

[panoskouf]

no such line for greek layout as marcelogdeandrade suggested either. I also did not have this issue on Loki, thinking about changing os :(

[nikitati]

Same issue on Juno release version. Did not experience this on Loki though. Delay seems to be most noticeable when switching between layouts that use different alphabets (e.g. EN <-> RU). Switching between Latin-based layouts (e.g. EN <-> CZ) seems OK to me.
Typing in multiple layouts is almost unbearable now.
I've found a lot of similar reports coming from Ubuntu users, so maybe this problem comes from there.

[can3p]

I did a quick test and it doesn't seem to be on gala side. If you try to add logging to the KeyboardManager you will see that once handle_modifiers_accelerator_activated function is executed, the whole layout change takes less than 100ms, but for some reason there is a noticeable delay between pressing keyboard shortcut and this code being run. From my understanding this signal comes from libmutter, so it's a next place to go after

[jacob1237]

The funny thing is that while switching between the languages, the Xorg process listed in top may take up to 60% of CPU time.

[can3p]

@jacob1237 good catch! Now I see that too. When I look at the processes in htop, Xorg process takes easily 20-50% of CPU during the switch

[marcelogdeandrade]

I believe this is an issue external to eOS.

Adding to the other 4 links I pointed, there's this one.

He describes exactly the problem we're having here on Ubuntu 18.04 with Gnome and Xorg.

[can3p]

I did a couple of more experiments with keymaps. Looks like inefficiency sits there. If you edit keymap file, completely remove section for the layout that is selected in your settings, layout switch happens almost immediately, without any effect of course.

How to test:
1) For the sake of experiment make two layouts - english and russian phonetic. switch layout to verify that it's slow
2) Completely remove section starting from xkbsymbols "phonetic" in /usr/share/X11/xkb/symbols/ru
3) Reload keymap with setxkbmap -layout ru
4) Test switching once again. It should be near instant to ru now

What I fail to understand is that it doesn't seem to depend on contents of the section, it can have literally no mappings defined and layout change is still slow

[yamnikov-oleg]

I've found a workaround which works for me. I can switch layouts using gsettings set org.gnome.desktop.input-sources current X command: for some reason the delay doesn't occur this way.

Here is a script which listens to the shortcuts and switches layouts itself using the above command: https://github.com/yamnikov-oleg/switch-layout

I'm not familiar with Gnome internals, so this is the best I can do. I hope, it will work for somebody else too.

[panoskouf]

@yamnikov-oleg this script works perfectly for me, thank you

[santileortiz]

Is there a difference if the OS is installed in an SSD?

[agrrh]

@santileortiz I'm using eOS with SSD and can confirm issue persists in this case.

Thanks, @yamnikov-oleg , I'm using workaround you proposed. Still looking forward for correct fix, of course.

[kotborealis]

@yamnikov-oleg Thanks! Works perfectly.

[marcelogdeandrade]

Are there any downsides using this command?

If it solves the issue, maybe changing keyboard shortcut to this command on plug-keyboard project could be a solution.

[santileortiz]

The thing is Gala is already using this GSettings key, look: https://github.com/elementary/gala/blob/be16d4a0cbdd7aa2058a14ca8370000d38c0c83a/src/KeyboardManager.vala#L49

I don't understand how that command is different from https://github.com/elementary/gala/blob/be16d4a0cbdd7aa2058a14ca8370000d38c0c83a/src/KeyboardManager.vala#L60

[santileortiz]

I think the problem is that Mutter's modifiers_accelerator_activated signal grabs the keyboard focus, and only returns it back to the application in the signal handler, here:
https://github.com/elementary/gala/blob/be16d4a0cbdd7aa2058a14ca8370000d38c0c83a/src/KeyboardManager.vala#L62

I don't know if there is a way to avoid Mutter/Gala grabbing the keyboard.

Maybe the python script is faster because pynput doesn't grab the keyboard focus, but I'm not sure.

[jacob1237]

I've found a workaround which works for me. I can switch layouts using gsettings set org.gnome.desktop.input-sources current X command: for some reason the delay doesn't occur this way.

Here is a script which listens to the shortcuts and switches layouts itself using the above command: https://github.com/yamnikov-oleg/switch-layout

I'm not familiar with Gnome internals, so this is the best I can do. I hope, it will work for somebody else too.

Have tried it and unfortunately it doesn't work. Still typing the first symbol of the word with the previous layout.

Damn GNOME. I think the Elementary project must сonsider the possibility to move away from the GNOME dependencies, including Mutter and Clutter. There are a lot of issues with these libraries.

Slow rendering performance, laggy animations and now the keyboard issues.

[santileortiz]

Yeah, the python script didn't work for me either. I've been testing another way to upload keymaps different to what Clutter does. I would like to get some feedback on this https://github.com/santileortiz/keymap_tests .

It needs more testing because I tried it several times, and it became slow again for no reason (I didn't recompile or anything) then a reboot fixed it. I would like to know if this happens to someone other than me. If it doesn't, then I can port this to Vala and make a PR for Gala.

Note that this is not a workaround, it's a very specific case (the text entry must be focused, only toggles between us and br, uses TAB to toggle), but if it works it can be implemented in Gala.

[adminko]

Have same problem. Fresh installed Juno 5.0 delay after changing layout from UA to EN or RU to EN

[unameisfine]

Another observation. When the "Alt + Shift" combination is selected, for some reason, the "Shift + Shift" combination also works. And both Shifts works fast.

[jacob1237]

Another observation. When the "Alt + Shift" combination is selected, for some reason, the "Shift + Shift" combination also works. And both Shifts works fast.

Nice observation! I tried LShift + RShift and there is no delay anymore! So looks like we just need to trace the callstack, understand what happens and replicate the same behavior for Shift + Alt (and the others).

[santileortiz]

I can confirm that when selecting Alt+Shift, both shifts will also switch layouts. Although it feels faster, it's not instant for me, it still takes some time. I'm testing changing us to br, which layouts are you switching between?

[jacob1237]

I can confirm that when selecting Alt+Shift, both shifts will also switch layouts. Although it feels faster, it's not instant for me, it still takes some time. I'm testing changing us to br, which layouts are you switching between?

Mine is us -> ru. What is your CPU and memory? Mine is i7 8550u + 16Gb, probably I don't feel the delay because of the CPU, not sure. Anyway, with both solutions I'm getting up to 60% CPU usage by Xorg under the top output, but Shift + Shift swtiches the layout almost instantly.

[santileortiz]

Switching between us and ru is faster, I have an i7-6700HQ with 16 Gb of RAM, do you have an SSD? because I don't. Can you try us and br? because that one takes almost 2 seconds for me.

[kotborealis]

I also can confirm that LShift+RShift (while Alt+Shift is selected) switches layout without any issues.

[jacob1237]

Switching between us and ru is faster, I have an i7-6700HQ with 16 Gb of RAM, do you have an SSD? because I don't. Can you try us and br? because that one takes almost 2 seconds for me.

OMG! I have an SSD and switching between br and us is EXTREMELY slow, unlinke ru and us. So I can confirm that. That's a nonsense. This is really unusable.

[santileortiz]

yeah, to anyone that finds a workaround, please test it with us and br as that is the worst case I've found, it takes anywhere from 2 to 5 seconds for me. The only way I've found to fix it is by directly uploading a precompiled keymap to X11.

[marcelogdeandrade]

I have a possible temporary solution.

I can't guarantee it will work, but it helped a lot for me, I'm using US and PT-BR layouts.

1. Open your keyboard layout file for your language, in my case:

sudo nano /usr/share/X11/xkb/symbols/br

1. Comment the following line

modifier_map Mod3 { Scroll_Lock };

1. Logout and Login again.

I saw this solution here

This solution helped me with us and br.

[fogone]

Maybe this comment in /usr/share/X11/xkb/symbols/ru can explain something:
// eng: Bug notice: One has to set lv5:rwin_switch_lock or one of the other level 5 locks for the caps switch to work!

[Djaler]

I found this comment https://bugs.launchpad.net/ubuntu/+bug/1388770/comments/4
Is this true for us?
Also, there are another comment https://bugs.launchpad.net/ubuntu/+bug/1388770/comments/8

[mirkinoid]

That's happening for me too. I have an i5 + 16Gb RAM and while switching layouts the lag is about 0.5 sec. Also noticed that lightdm gives up to 40-50% cpu load during the switch

[ghost]

After switch keyboard layout - delay .5 sec and i hear a sound like a push backspace in an empty text box

[PROteinBY]

Have the same problem. US to RU works fine, but vice versa doesn't (delay ~0.5 sec). Does anybody work on investigating it?

[santileortiz]

@Djaler Regarding the change of the file I don't think that's the case for elementary, because from this thread the issue seems to affect equally people on SSDs and spinning hard drives. About the other comment, I don't understand what they mean by "console command".

I have an attempt at fixing it here https://github.com/elementary/gala/tree/faster-keymap-upload but I haven't had time to test it, it looks like just compiling and replacing Gala, doesn't work. I still need to try installing it and rebooting, and see if that works.

[sakralbar]

I've found a workaround which works for me. I can switch layouts using gsettings set org.gnome.desktop.input-sources current X command: for some reason the delay doesn't occur this way.

Here is a script which listens to the shortcuts and switches layouts itself using the above command: https://github.com/yamnikov-oleg/switch-layout

I'm not familiar with Gnome internals, so this is the best I can do. I hope, it will work for somebody else too.

This work for me. RU and US layout.

[drequivalent]

@danrabbit Why?

The bug is still happening, and it really-really-really-really gets my goat!

That's not good user experience!

It was okay on Loki! It's new with Juno!

[genoapp]

I have this problem too

[peteruithoven]

Could people thumbs up the solutions that worked for them? And thumbs down the ones that didn't. That way I can hide the confirmation comments that don't really add anything.

[devkornev]

Is there a way to make a switch layout for each window separately? This will reduce problems during slow switching.

[jacob1237]

After the latest update, the things got even worse. RU-US layout is almost unusable. It takes about 3 seconds to switch.

[hotsezus]

Tried script by @yamnikov-oleg and it is not working for me. BUT after installing this with command sudo apt-get install --install-recommends linux-generic-hwe-18.04 xserver-xorg-hwe-18.04 it works fine and switches without delay on my A6-9220 powered laptop.

[o-alquimista]

The same stutter can be seen when changing the volume with FN (function keys) + VolumeUp/Down on GNOME on Xorg. Perhaps these things are all connected.

This workaround worked for me since I use layouts US and PT-BR.

A fix for Xorg would be nice right now, but eventually elementary will switch to Wayland and this bug will be gone.

[CssHammer]

https://github.com/yamnikov-oleg/switch-layout works perfectly even without packages @AlexDerbenew mentioned above for me.

[santileortiz]

I've been noticing some things about this bug. I think my previous theory that the slowness came from the keyboard layout compiler is not correct. I'm now pretty sure the issue comes from the code that listens for this modifier-only keybindings. But I still don't know where this is implemented, Mutter?, maybe Clutter?.

@CssHammer as you say the python script works fine for you, have you tried switching between us and br (Portuguese (Brazil))?.

Also, this new theory has given me an idea for people saying @yamnikov-oleg 's script doesn't work: Have you disabled layout switching from elementary's settings? (set the Switch Layout option to Disabed). If you didn't disable this, and you tried to set up the same keybindings in the python script as the ones set up in the settings panel, the code that looks up these keybindings will still run and freeze things.

[santileortiz]

The reason I think the layout compiler is not the slow part, is because I have an application that makes a grab of the keyboard, this means events should go just to my application. While the grab was active pressing the layout change keybinding caused the stutter, but the layout didn't change. Which means the layout compiler didn't run.

[CssHammer]

@santileortiz I use English, Russian and Ukrainian layouts, works fine

[mkswebdev]

... after installing this with command sudo apt-get install --install-recommends linux-generic-hwe-18.04 xserver-xorg-hwe-18.04 it works fine ...

For my computer, this caused problems. When I unlock computer, desktop eOS Juno all time crashed. Caution! To restore it helped:
sudo apt install xserver-xorg-core xserver-xorg

[Khomyak-sibiryak]

I was unable to configure switching using setxkbmap, X configuration files and localectl. Although, if in the terminal you use setxkbmap us, the switch works. The problem is that there is no possibility to use the buttons I need for this command (shift, caps). Therefore, I must use the standard switching method.
Perhaps this is somehow related.

[parqo]

This is an awful bug. And i think gnome settings causes that problem.

[vladmelnikov]

any progress on this ?

[bill88t]

elementary os hera still has this... I'm a new elementary os user, and this bug is driving me nuts. I'm on latest everything languages el-gr and en-us and the issue was there all along..

[younyokel]

That is so sad to know that this problem still appears after... _666 days... really?_

Also, this one really helped me. If you test gsettings set org.gnome.desktop.input-sources current (0 or 1) and then the default Alt + Shift it really feels faster.

[keynslug]

Just wanted to chime in.

I had been experiencing same issue on vanilla GNOME desktop environment until 3.34 release came out. After upgrading the stutter gone almost entirely. So there's that.

[dagolinuxoid]

confirmed on elementary os 5.1 Hera
changing layout via keyboard (I use Alt + Shift | but the same situation with a different biding)
us to ru - seems fast
ru to us - slow (slight but noticeable delay)

changing layout via drop down menu
indication changes fast in both directions

[hotsezus]

Nobody cares if layout switch has lags :)
It's always better for team to do something nobody cares about :)
Do not get me wrong - i love elementary os, i'm donating and contributing into project but this thread disappoints me

[drequivalent]

This is the single issue preventing me from using and recommending ElementaryOS to my peers.

I just can't use something that's slowly eating on my nerves basically.

[devkornev]

The next release based on 20.04 is coming soon. There is no point in fixing the problem. It will be available again in the new release. I'm thinking of switching to Ubuntu. I'm tired of waiting for basic functions to be fixed.

[cassidyjames]

To anyone commenting something to the effect of, "this is still an issue and I'm sad," yes, we get it. However, without a way to reliably reproduce the issue and understand what it causing it, it is difficult to fix. Since the issue is still open, it means we know it is still an issue. Commenting yet another "me too" comment here won't magically resolve it any faster, and neither will telling us that you're no longer using elementary OS.

The biggest help would be to try to understand that it is indeed code in Gala that is causing a stutter, and to help identify how to fix that code.

[devkornev]

You're crazy. 1.5 years do not fix this problem. Comfortable multilingual keyboard operation is a key functionality for many users.

[cassidyjames]

Welp, not gonna tolerate personal attacks here. My previous comment stands.

[cassidyjames]

A user reached out with this python script to work around the issue. While I don't think it's a permanent fix for elementary OS itself, perhaps it can be useful to users who are hitting this bug as a workaround, and perhaps it can be useful to figure out our own workaround/fix:

https://github.com/yamnikov-oleg/switch-layout