LINUX.ORG.RU

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

 


1

4

Поскольку любители «закапывать устаревшее» не очень хорошо понимают, зачем лучше иметь работающую альтернативу, скажу прямо — для надежности.

Поскольку у меня самого продвинутого железа типа экрана в 4к и пр. нету, я решил спросить посетителей ЛОРа, что им наиболее мешает жить с текущей реализацией X-сервера.

Возможно по выявлению самого неприятного мета-бага (пишите в ответах версию х сервера и ДЕ/wm, и прочие подробности, желательно со ссылками на баги в багтрекерах) удастся собрать деньги на оплату (а скорее - также частичное дообучение) работы C developer(s).

Но сначала давайте попробуем определится, что же конкретно не работает. Одним из первых я поставил HDR потому что на phoronix кто-то утверждал, что поддержка hdr потребует-таки переписывания или обхода значительной части Х протокола. Проблема в том, что я где-то читал что абстрактные пиксели в Х могут быть и 16 бит на канал, и к тому же рабочие станции SGI (mips) явно умели в 10 бит на канал, а работали там собственная реализация X, glx, да OpenGL (ещё 1.2 или около того). Ссылки надо заново искать, но я это сделаю :)

edit: https://marc.info/?l=freedesktop-xorg-devel&m=148338322225159&w=2

вот тут обсуждение HDR (в 2016-ом) еще есть пдф-ка с XDC 2017 про Deep color.

DPI stuff https://www.mail-archive.com/xorg-devel@lists.x.org/msg57714.html

SGI hardware (10/12 bits per component) http://www.sgidepot.co.uk/ir_techreport.html

  1. Всё устраивает 222 (48%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. Тиринг 117 (25%)

    ************************************************************************************************************************************************************************

  3. Сложности работы двух мониторов с разным dpi или частотой обновления 108 (23%)

    ***********************************************************************************************************************************************************

  4. Неплавность анимаций или ввода 84 (18%)

    *************************************************************************************************************************

  5. Устаревшая кодовая база, с которой сложно работать 76 (16%)

    *************************************************************************************************************

  6. Дробное масштабирование 70 (15%)

    ****************************************************************************************************

  7. Задержка (latency) в несколько кадров 64 (14%)

    ********************************************************************************************

  8. Поддержка HDR (high dynamic range, 10bit/channel or more) 59 (13%)

    *************************************************************************************

  9. Изоляция приложений 47 (10%)

    *******************************************************************

  10. Поддержка переменной частоты развертки (vrr) 43 (9%)

    *************************************************************

  11. Невозможность (?) сохранить состояние сессии при обрыве 32 (7%)

    **********************************************

  12. Отсутствие поддержки новых версий GL в протоколе glx 32 (7%)

    **********************************************

  13. Автоподключение внешнего GPU 31 (7%)

    ********************************************

  14. Мультикасание, трансформация координат ввода 24 (5%)

    **********************************

  15. Отсутствие поддержки множества слоёв (поверхностей) видеовывода 19 (4%)

    ***************************

  16. Другое 14 (3%)

    ********************

  17. Нестандартные устройства ввода (указать какие) 6 (1%)

    ********

Всего голосов: 1048, всего проголосовавших: 461

★★★★★

Проверено: hobbit ()
Последнее исправление: Andrew-R (всего исправлений: 8)

Ответ на: комментарий от Rootlexx

И всё таки в динамичных и интерактивных штуках вроде шутера лучше иметь тиринг, а в плавных и спокойных - фризы и лаги.

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

Оказывается, отсутствие тиринга — это фича, которая существует только в определённых комбинациях DE и настроек. Чем Wayland хуже, у него удалённый доступ тоже существует в определённых комбинациях DE и настроек?

  1. Я не вчитывался в тред, но из того, что я видел, таких комбинаций там больше одной. Для вейланда такая комбинация ровно одна, если говорить про RDP.
  2. Я ничего не говорил насчёт тиринга вообще. Я говорил только о тех фичах/проблемах, которые интересны/важны лично мне. И RDP тут фактически в пролёте.

Причём, заметь, поддержка RDP/Spice/VNC/Whatever в KDE/wlroots в перспективе возможна. В иксы уже никто ничего не добавляет, они совершенны.

А тут уже пошло какое-то сравнение тёплого с мягким. В иксах RDP не часть протокола, RDP-сервер строится лишь поверх него. И его разработка, кстати говоря, вовсе не заморожена. И да, «в перспективе возможна» и «есть и работает», это довольно разные вещи.

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

Дык, о чём и речь. А потом ты ещё и оборудование поменяешь. А потом ещё и DE захочешь поменять. И всё опять разваливается и надо настраивать по-новой.

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

Я не вчитывался в тред, но из того, что я видел, таких комбинаций там больше одной. Для вейланда такая комбинация ровно одна, если говорить про RDP.

Пока да.

Я ничего не говорил насчёт тиринга вообще. Я говорил только о тех фичах/проблемах, которые интересны/важны лично мне. И RDP тут фактически в пролёте.

Да. Я же не говорю, что ты не прав. Лично тебе не подходит Wayland — ну и бог тебе в помощь, мне не жалко. Лично мне не подходит X.

В иксах RDP не часть протокола

В Wayland, внезапно, тоже.

Aceler ★★★★★
()
Ответ на: комментарий от Forum0888
  • Сделать API для нормального переключения раскладок клавиатуры, чтобы без вот этого всего балагана.

  • Сделать композитор обязательным компонентом иксов (но тогда иксы перестанут быть иксами). Это решит кучу проблем и с тирингом, и с восстановлением разрешения после выхода полноэкранных приложений, и с управлением CSD приложениями, и с трансляцией отдельных окон  — в общем, много с чем. Появится состояние окна, упростится написание тулкитов и приложений.

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

В общем, по-любому X12 получается, несовместимый с X11. Концепция «у нас нет состояния окна, приложение рисует окно» немного устарела.

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

Концепция «у нас нет состояния окна, приложение рисует окно» немного устарела.

Наверное это был правильный подход для слабых компьютеров.

Разработчики QT ИМХО правильно поступили при разработке GUI.
Многое взяли из архитектуры GUI Windows и добавили свое.

Forum0888
()
Ответ на: комментарий от kirill_rrr

И всё таки в динамичных и интерактивных штуках вроде шутера лучше иметь тиринг

Вы видео глянули? На это же смотреть невозможно!

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

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

Немного сарказма.
API что поддерживает «древние» клавиатуры?
Например терминальных комплексов у которых клавиатура даже функциональных клавиш не имеет.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 2)

Интересный опрос.

Проголосовал: [x] Изоляция приложений [x] Другое

Другое: буфер обмена опустошается при закрытии программы, из которого в него было что-то скопированно.

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

Сделать композитор обязательным компонентом иксов

Мне, как человеку, не используещему композитный менеджер, эта идея кажется исключительно вредной. Все проблемы полноэкранных приложений мог бы решить https://keithp.com/x-ideas/pseudo-root/. А CSD это изначально дегенератская идея, пусть страдают дальше.

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

буфер обмена опустошается при закрытии программы, из которого в него было что-то скопированно

Кстати да, бесячая штука. Решается менеджерами клипборда, но не понятно, почему сервер не может сделать это сам, так как количество буферов все равно фиксировано

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

Еще бесят веб-макаки, которые думают, что поменять у текста фон - это все равно, что сделать его выделенным. И те, которые блокируют вставку средней кнопкой в свои формы.

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

И всё таки в динамичных и интерактивных штуках вроде шутера лучше иметь тиринг, а в плавных и спокойных - фризы и лаги.

Лучше иметь Freesync монитор, где тиринг просто невозможен даже с выключенным V-Sync. По сути Freesync решает обе проблемы: и тиринг и задержки от V-Sync.

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

Лучше иметь Freesync монитор, где тиринг просто невозможен даже с выключенным V-Sync.

Возможен, freesync сам по себе не убирает тиринг. Он решает проблему с задержкой при vsync-е.

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

Возможен, freesync сам по себе не убирает тиринг. Он решает проблему с задержкой при vsync-е.

При включенном freesync у тебя экран сам подстраивается под FPS окна, какой тут может быть тиринг? В каком случае?

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

При включенном freesync у тебя экран сам подстраивается под FPS окна, какой тут может быть тиринг? В каком случае?

Задача: у вас два окна, одно из которых обновляется с частотой 37 к/с, а другое — 41 к/с. Какая, по-вашему, должна быть частота обновления экрана в этом случае?

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

Задача: у вас два окна, одно из которых обновляется с частотой 37 к/с, а другое — 41 к/с. Какая, по-вашему, должна быть частота обновления экрана в этом случае?

Я говорил конкретно про игры, которые работают в fullscreen режиме.

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

Это решает проблему для полноэкранных приложений, но с окнами то это никак не поможет.

Ну да, для окон и V-Sync сойдёт.

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

При включенном freesync у тебя экран сам подстраивается под FPS окна, какой тут может быть тиринг?

Надо ограничить фпс, чтобы он не выходил за g/free-sync зону (обычно ставят кап на 2-3 кадра в секунды ниже частоты монитора). На винде еще встречал тиринг в играх с работающим freesync-ом, но без vsync-а (под линуксом с фрисинком я под вейлендом играю).

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

Я говорил конкретно про игры, которые работают в fullscreen режиме.

Ну т.е. это даже не половинчатое решение.

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

Ну т.е. это даже не половинчатое решение.

Это отличное решение. Просто не тиринг является проблемой, а задержка. freesync с ней хорошо справляется.

altwazar ★★★★
()

Противопоставление X.org и Wayland теряет актуальность. Потому что Wayland был «не то что иксы», «это вам не иксы» только пока оставался красивой сказкой, о том как всем будет здорово жить при коммунизме. По мере превращения из идеи в реально существующий и работающий продукт, Wayland всё больше напоминает … да-да, иксы! Уже и тиринг реализовали. Забавно смотреть, как фанаты Wayland сменили пластинку с «тиринга не должно быть никогда!» на «в иксах неправильный тиринг, вот разработчики Wayland его сделали как надо».

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

А если быф не падало то возможно работало бы и экран не рассыпался бы.

Когда то давно я гонял сталкер ЗП в вайне, там не работала мышка и рассыпались некоторые модели и текстуры. Есть в таких условиях смысл измерять фпс и проверять тиринг?

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

А если быф не падало то возможно работало бы и экран не рассыпался бы.

С помощью какой магии? Тиринг-то был как раз пока приложение работало.

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

Адов тиринг возник как раз перед тем, как картинка начала скакать метров по 10 или по полсекунды. Там явно полный звиздец в динамических сценах. Почти наверняка вылет был связан с этим.

Точнее наоборот, обычно если есть проблема с поддержкой видео, частенько перед вылетом начинается полный звиздец с производительностью, время скачет, кадры рассыпаются.

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

Что только не придумают, какие теории не выдвинут, лишь бы адовый тиринг защитить…

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

Заметная часть проблем иксов базируется на том, что это протокол без сохранения состояния. Композитор — это такая программа, которая сохраняет состояние окна. Это совершенно не обязательно OpenGL-монстр со спецэффектами, полупрозрачностью и системными требованиями как у Half-life Alyx. Это может быть и достаточно скромная по возможностям программа.

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

Скажи, поддерживают ли иксы без композитора трансляцию одного окна?

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

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

Я тебе по секрету скажу, что сейчас у меня невозможно сменить раскладку, не выбрав поле, в котором можно что-то напечатать. Нет (мигающего) курсора — нет смены раскладки. И ничо, как-то живу.

ЗЫ в вейланд-сеансе - всё то же самое. Только ещё почему-то Caps как altgr не всегда работает :-)

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

Кстати, а как в этих ваших wayland-ах правильно выставлять масштабирование на HiDPI-мониторах? А то я в KDE-шке попробовал на одном мониторе увеличить масштабирование в 150% и получил такое омерзительное мыло, что не в сказке сказать, ни пером описать.

В сеансе Plasma/X11 стоит глобальное масштабирование в 150% и выглядит всё, ну, предсказуемо.

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

Ну, очевидно, что используются не иксовые средства, а какие-то костыли. И в вейланде тоже. И эти костыли одинаково криво работают.

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

Не знаю, это в KDE что-то нахимичили. У меня в гноме приложения Wayland масштабируются отлично, приложения X11 линейно (ну то есть с мылом). В KDE может, всё линейно?

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

Не знаю, это в KDE что-то нахимичили.

Использую на разных машинах 115%, 150%, 200%. Никакого мыла нет, только шрифты лучше выглядят.

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

И внезапно, но архитектура графики винды не менялась со времён наверное NT4

В NT6 (виста) поменяли и весьма серьёзно, см. WDDM. Дальше в основном допиливали уже.

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

Не знаю что тут можно сделать, разве что приложение/сеанс перезапустить с новыми настройками. У меня только для стима вручную GTK_SCALE указан.

altwazar ★★★★
()

Основное, наверное, неплавность(даже старая sdl игра Legend of Edgar, мне показалось, что скроллится фон плавнее) и дробное масштабирование(на 4к 27" хочется 175%, а не 200. и без мыла чтобы). Хотя и HDR бы хотелось, тогда следующий монитор можно было бы с HDR брать(лет через 10).

Ещё проблемой иксов вижу переключение раскладок по нажатию, а не по отпусканию(да, как в венде), из-за этого нельзя нажать что-то вроде Alt-Shift-1 для какого-либо действия и не переключить раскладку при этом.

Перешел бы на Wayland, но с моей невидией там слишком много глюков пока что. Основной это промаргивание фона, не знаю как назвать по другому, но как будто окно или пол окна на мгновение(кадр?) становится прозрачным. Причем это и в Sway и в KDE и в браузере и в играх, т.е. проблема скорее всего невидивских драйверов.

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

Перешел бы на Wayland, но с моей невидией там слишком много глюков пока что. Основной это промаргивание фона, не знаю как назвать по другому, но как будто окно или пол окна на мгновение(кадр?) становится прозрачным.

Пробовал?

Как исправить мигание изображения и прочие глюки отрисовки на связке KDE Plasma + Wayland + Nvidia

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

По первому пункту, у меня всё довольно свежее, насколько оно свежее в Gentoo конечно. По второму варианту тоже вроде не моё, по крайней мере, если плазма ещё может там что-то делать прозрачным, то в Sway дефолтном вроде ничего прозрачного нет. А вот KWIN_USE_BUFFER_AGE это вот не пробовал, сегодня попробую. Единственно смущает, что это для KWIN, а проблема одинаковая и в кедах и в sway. Надо будет ещё weston попробовать, для чистоты эксперимента.

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

Хорошо, если изменения и дальше будут минимальными и не ломающими. Но, не факт. Как компашке, что пилит Qt, зарабатывать на LTS версиях, если они никому не нужны, потому что ничего не сломали?

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

Да, насколько я знаю переписали всё с нуля. Но это была новая реализация старых api, с небольшими дополнениями.

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

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

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

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

Xsgi? Еще были вcякие Accelerated X, но где их разработчики и код я не знаю …

Andrew-R ★★★★★
() автор топика
Ответ на: комментарий от mrjaggers

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

Жаль конечно, но вскрывает ту самую проблему что реально понимают как это все работает очень немногие, и увы с Вэйландом и прочим лет через 10-15 так же скорее всего будет (та же меса и drm subsystem поверх которой она работает тоже не hello world, разработчики nouveau подтвердят :/ )

Andrew-R ★★★★★
() автор топика
Ответ на: комментарий от Skullnet

есть еще такой тулкит как xfe, правда на нем мало чего написано. Ну или fltk. Переводить под них большие проекты наверное никто уже не будет, но глянуть что там и как устроено наверное попроще будет чем в современных больших тулкитофрэймворках.

к прелыдущему про пиксмапы - есть такое подозрение что их Х сервер, как и глифы, должен уметь кэшировать. И возможно часть тормозов - это перезагрузка пиксмапов из-за алгоритмов планировщика, который в glamor работает через OpenGL и может по ходу что-то теряет … Кстати да, вот еще - EXA делали именно с походом «выбросить все старое» и долго мучались с быстрой отрисовкой тех же глифов. Гламур …вроде как opengl-es использует но что-то мне подсказывает что ее в сновном пилили разработчики с толстыми десктопными дискретками, а потом … опять стало некому :). Т.е. архитектура ускорения внутри иксов тоже может играть свою роль.

Andrew-R ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.