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.

[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

2. Comment the following line

modifier_map Mod3 { Scroll_Lock };

3. 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.