The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск wayland-protocols 1.18, opennews (??), 26-Июл-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


38. "Выпуск wayland-protocols 1.18"  +4 +/
Сообщение от Аноним84701 (ok), 26-Июл-19, 13:24 
> И только комментаторы опеннета смогли бы сразу выкатить готовый продуктъ™, поддерживающий
> сразу всё, от подключения кофеварки в качестве устройства ввода-вывода до межгалактической  прозрачности.

Учитывая, что:

- PRIMARY selection (это когда кроме привычного виндузячьего буфера обмена доступен буфер, данные в который копируется выделением, а извлекаются по умолчанию средней кнопкой мыши) в протокол включили менее года назад
- urgency hint, штатный метод приложений сообщить менеджеру окон о событии, требующем внимания пользователя, т.е. с настраиваемой и однообразной реакцией вместо "кто в лес, кто по дрова"
все еще "НЕ НУЖНО!"

хотя уже несколько лет как клятвенно заверяют "Почти совсем уже замена и готово!"
Не знаю, не знаю.

А ведь еще есть эпичное "назло маме отморожу уши", тьфу, "перекладываем все на клиента",
когда вместо централизованной обработки ввода и передачи готовых событий повтореного нажатия клавиши (key repeat)  теперь клиенту отсылаются события key up/down и пусть он там разруливает сам.
Результат закономерен:
если клиент чуть тормознет и не успеет вовремя обработать событие "key up", то вместа иксового (микро) лага будет веселое
https://bugzilla.redhat.com/show_bug.cgi?id=1579859
> 2018-05-18
> That is, the typing "hello" may result in "hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhello".
> Changed to GNOME on Xorg during the login process and no more issues with repeated keystrokes
>

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

48. "Выпуск wayland-protocols 1.18"  +1 +/
Сообщение от Аноним (46), 26-Июл-19, 16:22 
> PRIMARY selection (это когда кроме привычного виндузячьего буфера обмена доступен буфер, данные в который копируется выделением, а извлекаются по умолчанию средней кнопкой мыши) в протокол включили менее года назад

Что, правда? Включили-таки? Эдак, глядишь, и попробовать можно будет лет через несколько.

Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск wayland-protocols 1.18"  +3 +/
Сообщение от Аноним84701 (ok), 26-Июл-19, 16:42 
>> PRIMARY selection (это когда кроме привычного виндузячьего буфера обмена доступен буфер, данные в который копируется выделением, а извлекаются по умолчанию средней кнопкой мыши) в протокол включили менее года назад
> Что, правда? Включили-таки? Эдак, глядишь, и попробовать можно будет лет через несколько.

Правда-правда! Даже новость отдельная была:
https://www.opennet.ru/opennews/art.shtml?num=49598
>  Выпуск wayland-protocols 1.17 с поддержкой буфера обмена по средней кнопке мыши
> 13.11.2018 07:59
> В версии 1.7 представлено два новых нестабильных протокола:
> -  primary-selection - по аналогии с X11 обеспечивает работу первичного буфера обмена (primary selection), вставка информации из которого обычно осуществляется средней кнопкой мыши;
> -  linux-explicit-synchronization - специфичный для Linux механизм синхронизации буферов в привязке к поверхности.

Кстати да, интересная формулировка "специфичный для Linux механизм" – как будто в остальном оно совершенно платформонезависимо (ЕМНИП, libinput на который завязан wayland, портировали на бсд только после добавления поддержки evdev в ядро бсд).

Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск wayland-protocols 1.18"  –1 +/
Сообщение от Michael Shigorinemail (ok), 26-Июл-19, 21:28 
> https://bugzilla.redhat.com/show_bug.cgi?id=1579859

Год с лишним спустя Status: NEW...

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

87. "Выпуск wayland-protocols 1.18"  +1 +/
Сообщение от Аноним84701 (ok), 26-Июл-19, 23:25 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1579859
> Год с лишним спустя Status: NEW...

Я сам не копал достаточно глубоко для понимания всего процесса, но если верить отписавшемуся там же Peter Hutterer  (Senior Software Engineer @ RedHat)
> libinput doesn't do key repeats - it filters out the kernel repeats and only passes key down/up events on to the compositor. The key repeat you're seeing is the one triggered in the compositor (or Xorg but that's where this bug doesn't trigger) and is
> simply caused by gnome-shell being busy doing something else and thus not handling events as fast as it should.

и почитать апстрим-багрепорт https://bugzilla.gnome.org/show_bug.cgi?id=745032 (тоже "NEW" c 2015 года)
> we'll probably move libinput processing to its own thread (as
> is done on recent versions of Xorg
) where it can directly update the
> hardware cursor without waiting for main drawing loop. This would probably
> involve moving the libinput backend from clutter to mutter, and adding
> mutexes shared by the KMS code and libinput backend. Doing this will not
> affect latency issues related to clients receiving input events; that'll
> require much larger changes, such as splitting up the shell UI into a
> separate process.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру