Какие для Вас самые важные недостатки X-сервера и/или протокола X11?

vsync в разных формах это когда новый кадр накладывается не поверх существующего, а в отдельный буфер.

Ну да, если у тебя пришла синхронизация, а кадр ещё не готов, и он почему-то отправляется на экран, будет тиринг. Если кадр формируется и по мере формирования отправляется готовым — не будет.

Производительность тут не причём. Отсутствие тиринга можно сделать даже на двух FPS.

Проблема иксов в том, что этот протокол изначально асинхронный и композиторы и V-sync для него это костыль, добавленный сильно позднее.

Где и какими технологиями проходит барьер безопасности между штатной программой и нештатной?

Через xdg-desktop-portal. Там у порталов есть штатный механизм.

Например, в гноме есть штатная программа для записи скринкастов, активируется комбинацией клавиш ctrl+alt+shift+r. Естественно, поскольку это штатная программа, для её активации никаких разрешений не надо.

OBS или chrome через xdg-desktop-portal запрашивает видеопоток, который всё та же штатная программа для записи отдаёт через pipewire.

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

Нет. Если у тебя нет вертикальной синхронизации, то у тебя всё равно 1/60 секунды на мониторе будет висеть повреждённый кадр, будь у тебя хоть 1000FPS.

и он почему-то отправляется на экран, будет тиринг.

Кадр не отправится, вместо него уйдёт старый кадр повторно. Как уже сказали выше - это не тиринг, это фризы.

Проблема иксов в том, что этот протокол изначально асинхронный и композиторы и V-sync для него это костыль, добавленный сильно позднее.

Отлично, теперь известна причина почему галочка vsync в х-композиторах не всегда работает. Но она работает в достаточном числе случаев чтобы тиринг стал незначительной проблемой по сравнению с прочими преимуществами.

Кадр не отправится, вместо него уйдёт старый кадр повторно.

Если есть композитор.

FPS-то тут причём? Ты рассказывал, что тиринг — это когда производительности не хватает.

Вот только это будет разрыв между моментами анимации со смещением в 1/1000 секунды что в 99,9999% случаев будет соответствовать долям пикселя. А мы ведь видим не саму границу склейки двух разных кадров, мы видим смещение объекта между двумя моментами анимации.

Вот только это будет разрыв между моментами анимации со смещением в 1/1000 секунды что в 99,9999% случаев будет соответствовать долям пикселя.

Нет, это будет смещение, которое должно быть за 1/60 секунды. Ведь все кадры, которые не успели отобразиться на мониторе, просто ушли вникуда.

На спокойных киношках, без экшона, конечно будет незаметно. На экшн-игрушках, да на соответствующем кино — ещё как.

Ну так поэтому и придумали тестовые видео, чтобы можно было точно сказать — есть эффект, или нет его.

Если есть композитор.

Так он всегда есть. Если ты его отключил то глупо жаловаться что утебя отключилась vsync, композитная прозрачность и эффекты. Аналогично если ты восппользовался новой функцией TearOn в вайланде.

FPS-то тут причём? Ты рассказывал, что...

протокол изначально асинхронный и композиторы и V-sync для него это костыль, добавленный сильно позднее.

Я, как обычный пользователь, заметил одну любопытную вещь: тиринг возникает только когда цпу захлёбывается, причём жестоко. Разумеется с этим будет связана просадка фпс, но как ты выше объяснил - дело в хреновой реализации vsync, которая не всегда успевает сделать как надо.

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

Вы так говорите, как будто вяленный всего этого не делает - там гораздо хуже. Если в иксах у подавляющего большинства фич есть единая реализация, то в вяленде ты по сути пишешь свой дисплейный сервер с нуля и фигачишь адовую фрагментацию. С некоторыми вещами, вроде композиторов и менеджеров окон - тут сложно агрегировать функционал, потому что у каждой DE свои требования к менеджеру окон и даже к композитору. Есть правда композиторы, которые будут работать на любом менеджере окон вроде picom, но тут всё равно иногда упираешься в то, что у DE должен быть свой композитор заточенный под функционал этого DE.

Если шапка протолкнёт эту альфу в продакшен, тонна опенсорсных программистов будет также заботливо укладывать костыли для поддержки Wayland. Только есть понимание, что количество костылей существенно снизится, поскольку протокол не имеет врождённых заморочек иксов.

Как раз это и заморочка вейланда, потому что в иксах есть минимальный набор фич, чтобы написать свой композитор и менеджер окон и так далее, а в вяленде нужно постоянно изобретать велосипед. Потом до людей начало доходить и был изобретён wlroots с его 30к строк кода, но это по умолчанию не подразумевалось вялендом. К тому же GNOME, KDE и многие другие его не юзают - а это уже фрагментация из коробки.

если их в избытке то проблема исчезает.

Становится менее заметной, но не исчезает. Когда у тебя 120-240 кадров он заметен и порой попадает в одно и то же место экрана и это выглядит как артефакт шириной в пару пикселей.

Просто проблема будет называться не «тиринг» а «лаги и фризы».

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

Например, в гноме есть штатная программа для записи скринкастов, активируется комбинацией клавиш ctrl+alt+shift+r. Естественно, поскольку это штатная программа, для её активации никаких разрешений не надо.

Да, но можно ли ей пользоваться? Вызывать не ctrl+alt+shift+r, а значком в меню? Выбрать область видеозавата и настроить кодек? Указать место для сохранения? Привязать удобные хоткеи? А чтобы она ещё и не выглядела как говно?

Нет, это будет смещение, которое должно быть за 1/60 секунды.

Нет, это будет смещение в 1/1000 секунды. Кадры ,не успевшие уйти на монитор просто не ушли на монитор, но в буфере композитора то они сменяются с 1000фпс. И рваться будет не 1-й и 17-й кадры а 16-й и 17-й.

Так он всегда есть.

Ну так у тебя и не будет тиринга в интерфейсе. Я вроде нигде и не отрицал.

Кстати, фраза «композитор всегда есть» — не верна, в lxqt он не всегда есть, а уж в IceWM тайловых WM и подавно.

Но. В выводе mpv при использовании некоторых бекендов — тиринг будет, потому что там ради повышения скорости слегка насрали на буферизацию и синхронизацию.

Я, как обычный пользователь, заметил одну любопытную вещь: тиринг возникает только когда цпу захлёбывается, причём жестоко.

Может быть.

то в вяленде ты по сути пишешь свой дисплейный сервер с нуля и фигачишь адовую фрагментацию.

Вообще-то не обязан, но разработчики выбрали этот путь. Кто знает, почему?

но это по умолчанию не подразумевалось вялендом

Кто сказал?

К тому же GNOME, KDE и многие другие его не юзают - а это уже фрагментация из коробки.

Так это же прекрасно. Если Gnome превратится в спагетти с плохим кодом — его можно будет спокойно закопать. А вот с едиными иксами такой фокус не пройдёт.

Да, но можно ли ей пользоваться?

Разрешаю.

Я уже понял, что Wayland плохой, потому что тебе гном не нравится.

А, ну ок.

но разработчики выбрали этот путь. Кто знает, почему?

Мне кажется потому что красношапки взяли курс на интерфейсный фашизм и реализацию всего максимально несовместимым с конкурентми. Из за этого никаких объединений не получилось, Шаттлворд не доделал Мир а КДЕ были вынуждены догонять со своим колхозом. Если бы красношапки изначально взяли Weston и не мешал бы всем другим - был бы единый и работоспособный W-сервер на замену Х-серверу.

Wayland плохой, потому что тебе гном не нравится.

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

Ты предлагаешь грузить CPU(GPU) time отрисовкой 1000 кадров в секунду вместо 60 только для того, чтобы не было тиринга? Да и то, он всё равно будет если два соседних кадра достаточно отличаются.

Впрочем сам я тиринга не видел.

Так он всегда есть. Если ты его отключил то глупо жаловаться что утебя отключилась vsync, композитная прозрачность и эффекты.

Не говори за всех. Во всяких гномопомойках может и так, но никаких дефолтных композиторов в иксах нет. По мне так эти прозрачности и прочие эффекты не нужны.

Нет, он мне доказывал, что тиринг больше заметен на низкой FPS, чем на высокой. Я думаю, он прав.

Насколько я знаю ни в какую версию малины не ставился i7 6700HQ.

Я там выше показывал наличие тиринга в полноэкранном видео у меня. Разумеется, в 100500 потоков одновременно с этим я ничего не собирал. Так что ваша теория хромает.

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

Наверно они посмотрели на него, ужаснулись общему «качеству» и решили сделать своё. Только вот проблема была не в реализации а в спецификации, поэтому получился такой же хлам.

Да просто штаная гномоутилита убогая потому что писалась дегенератами. Её нельзя использовать, с ней можно только страдать.

И что же вас в ней не устраивает?

Это когда плеер обязан выдавать 30, но отрисовать успел только 27, а 3 просто отбросил. И выглядит это ровно аналогично «Будет откладывание отображения кадра до окончания его отрисовки.» - весьма некрасиво. Меня это раздражает не меньше чем тиринг, а вас?

Если эти 3 распределены равномерно, то скорее всего, я даже не замечу. Если же одномоментно, то уж лучше микролаги, чем картинка, на которой треть одного кадра, треть другого, и ещё треть третьего.

Я, как обычный пользователь, заметил одну любопытную вещь: тиринг возникает только когда цпу захлёбывается, причём жестоко.

Вам записать видео тиринга на уже упомянутом i7 6700HQ при небольшой нагрузке на ЦПУ, или на слово поверите?

Смотри, как каждый DE создаёт свою переключалку раскладки

Что-то, мне кажется, ты тут погорячился. И про композитор, - хотя я и не вполне понимаю, что это такое в экосистеме X11, - тоже сомнительно.

Да, моя попытка съехать на KDE/Wayland/Nvidia с целью проверить, есть ли жизнь на Марсе, а заодно посмотреть, что можно сделать с тем, что один монитор HiDPI, а второй, вспомогательный - даже не full hd. И, вроде, всё сразу заработало, включая, к моему удивлению, переключение на китайский, но с масштабированием картинки - явные проблемы и «мыло» на основном мониторе. По итогу вернулся на X11.

А как подобные конфигурации живут у других?

прямой связи нет. сгруппы это просто концепция, а системд уже реализация, которая ее использует. это разные вещи.

Что-то, мне кажется, ты тут погорячился.

В гноме своя, в KDE своя, в XFCE своя. Функционально XFCE-шная переключалка такое себе. В LXQt своя и тоже довольно примитивная. В некоторых средах есть вомзожность выкинуть штатные и остаться на иксовой. Это не считая всяких самостоятельных переключалок типа fcitx. Вообще, переключение раскладок это боль, потому что штатные возможности X довольно убоги, вместо этого предполагается использовать внешний API, и тут уже кто во что горазд.

И про композитор,

Kwin — композитор, mutter — композитор, xfwm — композитор. В mate можно использовать композитинг metacity, можно поставить compiz. Есть универсальный композитор compton, это типа wlroots для wayland.

По-моему, композитор с нуля не изобретали только в lxqt (взяв kwin) и Cinnamon/Pantheon (взяв mutter).

Сколько я композиторов назвал? :-)

Можно и без системд. Крайний раз вообще настраивал себе ограничения для группы процессов через mkdir и echo

Это был вопрос на тему «ядро не должно ни с чем интегрироваться».

Должно. cgroups пилят для поддержки systemd, containerd, lxd и прочих приложений.

Можно. У нас тут кое-где кое-кто ещё сидит на центось 7 и там libcgroup :-)

А к чему эта реплика?

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

А, ну если смысл твоего посыла был в этом — то соглашусь.

Эмм… KDE-шная - это просто интерфейс для настройки xkb + индикатор, умеющий по клику на него сформировать ISO_NextGroup. Остальные, кроме Гнома, устроены примерно так же, по сути не отличаясь от xxkb, выполненной в технике соответствующего фреймворка. В минимально самодостаточном cli-варианте - 210 строк кода, включая лицензию, юзэйдж и разбор параметров cli

Гномовская реализация, как я её помню, ещё загружала раскладки самостоятельно при каждом переключении. ЕМНИП, для того, чтобы обойти XKB-шные ограничения на 4 группы и модификаторы. (Ей-же-ей, лучше бы сделали fcitx частью поставки и помогали его допилить).

В общем, в упор не вижу здесь «своих реализаций».

Про композитинг, да, осознал разнообразие. Но, насколько я понимаю, эта часть делалась уже вдовесок к основному X11, поэтому и зоопарк.

Ну, я бы не привязывал разработку cgroups ни к одному из конкретных применений, включая systemd и контейнеры. Просто обобщенный способ управления ресурсами, выделенными на группу процессов.

Но, наверное, да, «тред не читай, сразу отвечай» получился.

Эмм… KDE-шная - это просто интерфейс для настройки xkb + индикатор, умеющий по клику на него сформировать ISO_NextGroup.

Не спорю. И ей для работы надо перехватывать глобальные комбинации клавиш, что приводит к соответствующим последствиям.

В общем, в упор не вижу здесь «своих реализаций».

Любая сторонняя переключалка будет лишь загружать или переключать раскладки в иксах. Как ты себе это представляешь иначе? И каждая такая сторонняя переключалка добавляет багов — пропадающие меню, перехват глобальных клавиш, индикация с чтением статуса индикации и прочее-прочее.

Там ещё веселье начинается, когда надо вводить иероглифы, или когда надо одновременно переключать аппаратную и экранную клавиатуры.

Ты можешь не считать оболочки за свои реализации, ОК. Костыли вместо использования возможностей самого X сервера — вот что важно :-)

И ей для работы надо перехватывать глобальные комбинации клавиш

Я ей не пользовался, но судя по

это просто интерфейс для настройки xkb + индикатор, умеющий по клику на него сформировать ISO_NextGroup.

никакие перехваты клавиш ей как раз не нужны. Ну, кроме клика мышкой по её окну.

никакие перехваты клавиш ей как раз не нужны. Ну, кроме клика мышкой по её окну.

В KDE единый способ переключения горячих клавиш, в том числе там настраиваются клавиши переключения раскладки. Соответственно, он перехватывает нажатия всех клавиш, и по нажатию комбинации переключения раскладки — дёргает xkb.

По крайней мере, так раньше было, может, что поменялось. У кого KDE, откройте меню и переключите раскладку. Что получилось?

Вообще-то не обязан, но разработчики выбрали этот путь. Кто знает, почему?

Чтобы монополизировать Linux desktop под себя. Фрагментированности нужно сопротивляться, чтобы не получить аналог рынка смартфонов с 9000 несовместимыми прошивками.

Кто сказал?

Потому что wlroots появился намного позже и это вообще 3rd party библиотека, которая по уму должна была быть частью проекта Wayland по-умолчанию.

Если Gnome превратится в спагетти с плохим кодом — его можно будет спокойно закопать. А вот с едиными иксами такой фокус не пройдёт.

Вот было бы плевать, но от GNOME библиотек зависит очень много софта. От того же GTK например.

которая по уму

Опять по уму. По чьему уму? Какие-то возможности должны были быть в версии 1.0, теперь вот библиотека по уму должна быть.

Претензия к Wayland «он сделан не так, как я себе представляю правильную разработку софта» — это очень интересно, конечно (нет).

но от GNOME библиотек зависит очень много софта. От того же GTK например.

Для запуска GTK софта под KDE не нужен mutter. Для запуска иксового софта под Gnome нужен Xorg.

... А ещё oss3

ты по сути пишешь свой дисплейный сервер с нуля и фигачишь адовую фрагментацию

И в итоге вся фрагментация сводится к неработающему в гноме spectacle. Вот и весь размер трагедии.

И ей для работы надо перехватывать глобальные комбинации клавиш, что приводит к соответствующим последствиям.

Ну, я бы назвал это «читать очередь входящих событий» и реагировать на тот самый ISO_NextGroup & Co, перерисовывая флажок. Перехват событий — это уже звучит заметно более интрузивно, хотя, возможно, не отличается по сути.

Последствия — ну, все как-то научились не блочить очередь и смирились с тем, что в обычном режиме все имеют возможность читать всё.

Любая сторонняя переключалка будет лишь загружать или переключать раскладки в иксах. Как ты себе это представляешь иначе?

Например, когда «переключалка раскладки» ничего не загружает самостоятельно, то есть, работает как индикатор. А уж кто там загрузил или не загрузил xkb’шные раскладки и какой там переключатель и есть ли он вообще, её не интересует.

Есть и другая крайность — тот же fcitx, которому вообще не нужно грузить раскладки в xkb. У меня сейчас так и работает всё переключение: meta-space — переключение между группами «западные языки» и «восточные языки», и ctrl-shift — внутри групп, us-altgr/ruu и pinyin/rime. Как видишь, текст набрать могу, "Привет! ¡Hola! 你好！“.

или когда надо одновременно переключать аппаратную и экранную клавиатуры.

Переключать одновременно (ок, почти одновременно) экранную и аппаратную клавиатуру — выше уже приводил ссылку на XkbSwitch. Парни из Kodi просто не умеют в программирование X11

Претензия к Wayland «он сделан не так, как я себе представляю правильную разработку софта» — это очень интересно, конечно (нет).

Именно так, у вейланда самый мудацкий дизайн из всех возможных. Причём сделано это намеренно во вред обычным пользователям и разработчикам мелких DE.

Для запуска GTK софта под KDE не нужен mutter.

Во-первых, тут сразу начинается проблема с темами. Раньше Qt умел поддерживать GTK2 темы, но потом вышел GTK3 и поддержку сломали напрочь. Теперь приложения на Qt и GTK3 выглядят по разному. Про libadwaita даже говорить не хочу - это нахардкоженное убожество. Второе - это CSD в GTK, тут будет страдать любой оконный менеджер.

и по нажатию комбинации переключения раскладки — дёргает xkb.

Конечно же, нет.

Он формирует, грубо говоря, параметры для setxkbmap, а потом просто отслеживает ISO_*Group.

Похожее на то, о чём ты пишешь, делала гномовская раскладка. Чтобы, хе-хе, можно было на alt-space повесить раскладку, чтобы как в правослбогомерзком MacOSX было. Ну и снять ограничение в 4 группы max, но кому оно мешало, честно :-) Всё равно все на dead keys себе диакритику вешали :-)

Перехват событий — это уже звучит заметно более интрузивно, хотя, возможно, не отличается по сути.

Это приводит к глюкам при открытых меню. Или комбинации вообще не работают, или меню закрывается вместо требуемого поведения. О чём, в общем-то, мы и вели речь.

Например, когда «переключалка раскладки» ничего не загружает самостоятельно, то есть, работает как индикатор.

Но это же редкость. Какой-нибудь IceWM так работает, не спорю, но не Gnome/KDE/XFCE. Потому что и раскладок всего четыре, и по другим причинам

Переключать одновременно (ок, почти одновременно) экранную и аппаратную клавиатуру — выше уже приводил ссылку на XkbSwitch.

И как там на счёт иероглифов? XkbSwitch берёт раскладки из иксов, не так ли?

Он формирует, грубо говоря, параметры для setxkbmap

ОК, результат тот же?

Во-первых, тут сразу начинается проблема с темами. Раньше Qt умел поддерживать GTK2 темы, но потом вышел GTK3 и поддержку сломали напрочь. Теперь приложения на Qt и GTK3 выглядят по разному. Про libadwaita даже говорить не хочу - это нахардкоженное убожество. Второе - это CSD в GTK, тут будет страдать любой оконный менеджер.

А Wayland тут при том, что?

Насколько я помню своё общение с гномошелом - при нажатии PriScr вообще не появлялось никаких утилит, просто картинка возникала в какой то захардкоженой папке. Это очень по гномовски, но вообще невменяемый подход.

GTK3 тоже не очень умеет использовать возможности X-ов по полной. Форк GTK3 хотят запилить по другой причине. Из-за того, что разрабы GTK часто ломают обратную совместимость. Вот те, кто не рад этому, и пытаются сделать GTK3 LTS, так сказать. Но, то, что происходит с Qt последнее время(развивается быстро тулкит, а старые версии разрабы долго не поддерживают(СПО вариант, для фанатов коммерческой версии Qt как раз есть вариант EOL-версии тулкита). Неужели и Qt будут форкать? Может проще синхронизировать разработку ПО с разработкой тулкита?