LINUX.ORG.RU

Ubuntu 20.04.2 Лаг при переключении раскладки клавиатуры

 , , , ,


1

1

На это жаловались на форуме уже: Ubuntu 20.04 LTS куча проблем с клавиатурой но как я понял решения так автор и не нашел. В интернетах так же всплывает, но так же не нашел ответа как это решить-то.

Сабж: при переключении раскладки с русского на английский или обратно на секунду система пролагивает, съедая первые пару букв, что невероятно раздражает. Что в поиске, что в текстовых редакторах, что в переписке.

На федоре эта дурость была только под иксами, и то на шифт-альте: на вин+пробел было нормально. На убунте топика это и в вейленде и на вин-пробел тоже. Причем ввиду задействования вин-кнопки это пролагивание приводит к открытию обзора приложений.

Решил ли кто эту проблему все-таки?

P.S.> советы менять дистрибутивы можете отправить в спортлото, я не от прекрасной жизни этим пользуюсь.

Ответ на: комментарий от papin-aziat

Увы, много проблем по запросу keyboard layout switching delay / freeze , раньше считал что проблема libxinput, но в вяленом у меня тоже самое. В упор не знаю что теперь делать, ибо когда компьютер думает дольше чем я напечатаю 3-4 символа – очень раздражает, увы. Могу скринкаст что ли сделать

JAkutenshi ★★ ()

Поставь gnome-tweaks и там в «Клавиатура и мышь»->«Дополнительные параметры раскладки» выруби все настройки касающиеся раскладки. Т.е. поставь дефолт.

pon4ik ★★★★★ ()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от pon4ik

Странно, я в двух источниках чуть раньше находил эту рекомендацию(в том числе на лорчике) - мне помогло, переключается мгновенно.

Это помогает частично, начинает тормозить не так дико. Проблемы с тормозами при переключении раскладки последние лет 6 - ibus и/или gnome. Местами тормозил ibus, местами гном, а еще есть проблемы у самой связки ibus+gnome.

Тот же баг с тормозами связки ibus+gnome висит года три в багтрэкере убунты и с полгода в трэкере гномшелла. Репортил его кто-то из разработчиков убунты. Баг с тормозами при переключении раскладки висит в баг трекере гномшела год.

Скорее всего тормоза при переключении раскладки - один баг. А доп. тормоза из-за нестандартного хоткея - еще один сверху.

altwazar ★★ ()
Ответ на: комментарий от altwazar

А ты можешь это как-то зафиксировать, в виде видео или ещё как? По идее, что бы такие баги закрывались нужно готовить виртуалку и шаги воспроизведения, а то непонятно как воспроизводить.

pon4ik ★★★★★ ()

В моём случае эта проблема вылечилась переходом на wayland.

Также рабочим решением был скрипт переключения раскладки и создание на него кастомного шотката. Минус в том, что нельзя на него поставить стандартный win space, но зато задержки между переключением нет.

vlzvoice ()
Ответ на: комментарий от pon4ik

А ты можешь это как-то зафиксировать, в виде видео или ещё как?

Могу, но не вижу в этом смысла, эти баги уже зафиксированы и есть в баг трэкире.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1154

https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1766503

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3125

Тормозящее переключение раскладки фиксируется где-то с 2013 года. Тогда я просто сносил ibus, так как ради cjk всё равно приходится ставить fcitx, а для ввода en/ru ibus не нужен.

altwazar ★★ ()

У меня были Ubuntu 16.04, 19.10 и 20.04, никогда такого не наблюдал. Компы разные Intel+ASUS, asrock a300 и ноут asus. Но я вообще не ставлю кастомных расширений на ubuntu-gnome и переключаюсь дефолтным super+space.

P.S. Создай нового пользователя, чтоб с чистым home, и попробуй там, может что-то накручено каким-нибудь твик тулом или расширением.

Aber ★★★★ ()
Ответ на: комментарий от JAkutenshi

Ради интереса какой-нибудь лайв-сд с нормальным гномом попробуй. Может на уровне железа(+гном, разумеется) проблемы, ибо многие с таким не сталкиваются, представляешь какой вой бы стоял, если бы это было у всех :-)

papin-aziat ★★★ ()
Ответ на: комментарий от Aber

P.S. Создай нового пользователя, чтоб с чистым home, и попробуй там, может что-то накручено каким-нибудь твик тулом или расширением.

Проблема в убунтах, центосях, федорах, арчах, елементари без модификаций гнома/циннамона/пантеона или системы в целом. Там несколько накладывающихся друг на друга багов поверх тормозного ibus-а.

Можно не тратить время на перебор настроек и ос.

altwazar ★★ ()
Ответ на: комментарий от pon4ik

Так сколько миллисекунд лаг-то?

С win+super под иксами на мощной машине в большинстве случаев лаг не заметен, другие приложения не тормозят и раскладка не переключается в середине слова.

С caps - может доходить до нескольких секунд (от нагрузки машины зависит), в это время не только раскладка тормозит, но вся система.

Задержка явно больше, чем выдает «time ibus engine xkb:us::eng» и cpu загружен тоже дольше (что в багтрэкере тоже описывали). Хотя 130 мс для переключения раскладки уже должно быть достаточно для наблюдения лага и переключения раскладки на символ позже.

Делаешь переключение раскладки на caps, запускаешь htop, жмакаешь постоянно капс и эффект для системы покруче запуска cpuburn.

altwazar ★★ ()
Ответ на: комментарий от pon4ik

А чем плохо то? Вроде всё под пальцами, не?

С win+super две серьезные проблемы:

  1. Win используется как клавиша модификатор, но на её отдельное нажатие все кому не лень вешают функцию типа поиска приложений, открытия меню «Пуск» и т.п.

  2. Win расположена в блоке клавиш модификаторов, по центру между шифтом, альтом, контролом. Из-за этого высокая вероятность мисклика по этой клавише, что было бы совершенно не страшно, если бы на её отдельное нажатие ничего бы не вешали. Это на столько часто вызывает проблемы, что на любую нормальную клавиатуру делают хоткей на отключение этой клавиши в прошивке.

  3. Положение и размеры win клавиши гуляет между раскладками клавиатур. Так как переключение раскладки быстро прописывается в мышечную память, то одновременная работа за ноутбуком/пк превращается в пытку.

Надо убрать хоткей по нажатию на win и переломать руки любителям менять левый блок клавиш ctr+win+alt. Был бы не плохой хоткей для переключения раскладки, но остается только мечтать.

altwazar ★★ ()
Ответ на: комментарий от pon4ik

Выглядит как-то так (виртуалка с убунтой):

https://disk.yandex.ru/i/Wb0MUaJM411Zrg - caps

https://disk.yandex.ru/i/shoOHMwWIb9QEg - win+space

Нажатие на win+space грузит систему раза в 3 меньше, чем на caps. Если убить ibus-daemon, то gnome-shell процесс меньше грузит систему, но производительность всё равно печальная. И это просто система без фоновой нагрузки.

Для сравнения: нажимая на капс пару раз в секунду можно поднять до 100% нагрузку на cpu в гноме. Нажимая на капс раз в 8 в секунду в другом DE на том же железе получишь нагрузку в 10-20% на cpu. При этом нагрузка от xorg процесса - 2-3%.

altwazar ★★ ()
Ответ на: комментарий от anonymous

Вот оно и тормозит как корова.

Может быть. Вспоминается эпичный баг с анимацией открытия окна на фуллскрин, когда они скриншот в js переменную писали и нажав F11 можно было за пару секунд все оперативную память выжрать на системе. Интересно, пофиксили его или нет.

altwazar ★★ ()
Ответ на: комментарий от altwazar

Вот у меня было ровно так, пока не вырубил в твиках все все галки на переключение раскладки. Пока не воспроизводилось либо я и правда не замечаю прост.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Если под ноутбуками ты понимаешь тут синкпады - то есть такой момент, однако, все мы знаем как он лечится конкретно для этой линейки.

На буках просто чаще всего там кнопки двигают. Вместо 1.25 делают размером с обычную кнопку, а позиция то под шифтом, то под «X».

altwazar ★★ ()
Ответ на: комментарий от pon4ik

Ща попримерялся, на самом деле, да похоже на то, что shift+alt ничем не хуже в качестве дефолта, даже чуть удобнее, т.к. хотя бы один ряд клавиш выше.

Ага, но с шифт+альт тоже нюансы - наличие хоткеев типа «X+Y» и «X+Y+n» в системе. Последние работать не будут.

У меня caps/shift+caps, но тут тоже нюанс - под виндой нормально не работает.

altwazar ★★ ()
Ответ на: комментарий от altwazar

У меня раньше был капс, но, потом я перешёл на 60% клавиатуру, и капс оказался нужнее для других вещей:)

Под виндой - я делал капс как переключалку, но с помощью какого-то 3rdparty софта конечно.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Под виндой - я делал капс как переключалку, но с помощью какого-то 3rdparty софта конечно.

Я автохоткеем делаю. Но сторонние переключатели не во всех приложениях работают.

Жаль выбор между 60% и tenkeyless не богатый. Подобную бы доску, только качеством повыше.

altwazar ★★ ()

Вроде как очень странное решение вышло: выставил в tweaks переключение на привычное shift-alt, wayland, в Language Support -> Keyboard input method system выбран none. Пока что лагов не заметил, стало намного комфортнее. Раньше именно shift-alt лагал и приходилось мучаться и переучиваться на win-space.

Вангую лаги из-за появляющегося оверлея с переключающимися языками, если зажать win-space. (набирая это я понял, как приучился уже к этому переключению, эх, что за морока..)

JAkutenshi ★★ ()

вообще, меня в последнее время начали бесить лаги везде - в kde при вводе, в хроме при вводе или при кликании элементы не нажимают, либо курсор с первого раза не перескакивает. 32 Gb RAM 3200/ Ryzen 3800X / Adata800 ЧЯДНТ

darkenshvein ★★★★★ ()

А кто-нибудь знает, можно как-то вообще снести управление раскладкой в гноме?

В cinnamon у меня раскладка определяется через setxkbmap, правда иногда глючит. Гном на команду не реагирует.

another ★★★★★ ()
Ответ на: комментарий от JAkutenshi

Вангую лаги из-за появляющегося оверлея с переключающимися языками, если зажать win-space.

С оверлеем нагрузка от gnome-shell больше.

С ibus нагрузка от gnome-shell больше.

С альт-шифтом нагрузка от xorg больше.

На вейленде нагрузки от xorg нет.

Не удивлюсь, если там 3-4 косяка с тормозами друг на друга накладываются. Может хоть с переходом на вейленд проблема частично отпадет.

altwazar ★★ ()