Чем вам не нравится X11?

X11 не нравится разработчикам. Разработчикам тулкитов, и, самое главное, разработчикам самих иксов.

Враньё, разработчикам иксов он нравится, да вот только они все на пенсии. А в мейнтейнерах его официальной ветки сейчас какие-то засланцы из вайланда.

Какие рабочие задачи нельзя сделать из консоли?

Если речь про текстовый эмулятор терминала (Ctrl+Alt+F1), то copy/paste? Но в иксах copy/paste работает прекрасно.

Линупсоиды умудрились и консоль скатить в СГ.

Это ты еще не видел настоящего аппаратного терминала с принтером вместо дисплея ;)

Какие рабочие задачи нельзя сделать из консоли?

Выделять текст, копировать/вставить, нормальная прокрутка.

Да все устраивает, багов не вижу

разрабам игр вааще пофиг должно быть, они используют опенглы/вулканы/сдлы

Кто тебе сказал эту дичь ?

Даже эталонная 0ad, сюрпрайз сюрпрайз, требует libx11-dev для сборки. И это не считая gtk3\wxwidgets, которые так же перетянут половину иксов в качестве зависимостей.

И это логично. Банальное сокрытие рамки окна \ переход в полноэкранный режим ты чем собрался делать, опенглом ?)

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

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

Linux-разработчики даже графический тулкит подконтрольный им не смогли сделать

А Linux-разработчики — это кто такие?

н не умеет обеспечивать плавность картинки и анимаций 60/120 fps

умеет в отличие от, например, wayland который чуть что превращается в слайдшоу

не поддерживает нормальное подключение мониторов с разной герцовкой и DPI

man xrandr

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

пожалуй единственная серьёзная проблема - реализация монопольного ввода, что я уже упоминал здесь

Для какого-нибудь раритетного хлама или офисного ПК, этот X.Org может и подходит, почему нет. Но для современного десктопа – увольте.

То есть современный десктоп должен сидеть с чёрным одним из мониторов, который подключен к отдельному gpu, вместо того, чтобы шарить его как prime дисплей?

Корпорации которые породили и поддерживали X.Org в течении 20 лет, в скором времени его убьют, в этом даже не стоит сомневаться, ибо процесс уже начался. Просто потому что им сложно и дорого стало его поддерживать.

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

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

Покажи мне где архитектура лучше чем в иксах? В винде остановленное отладчиком окно никак сдвинуть нельзя!
В wayland за 10 лет не смогли завести совсем базовые фичи нормально, смотри начало треда. У него банально API для отрисовки 2д нет. И не надо затирать что этим должен заниматься opengl или vulkan, они не для этого, можешь просто взглянуть в /proc/.../maps для процесса, который использует opengl и убедиться, что это говно, а не решение. Опционально иметь возможность рисовать 2д через opengl клиенте хорошо, только форсировать это не надо.
Да, код иксов правда говно, только вот не надо говорить что wayland готов их заменить. Прошло 10 долбанных лет, wayland уже состоялся как узкоспециализированное говно для пользователей gnome и таким и останется

Потому что в линуксе нету такой банальной штуке как portable executable. Угадай как проще всего собрать игру чтобы работала под линуксами и при этом не собирать её отдельно под 100500 дистров, при этом не сожрав гигабайт-другой на flatpak?
Правильно, мать его, виндовый exe, который прекрасно работает на win32s, win9x/dos, winnt, wine и будет работаьь пока x86 не умрёт совсем
Потому что в линуксе решили - а давайте мы загрузчик ,so, реализацию сокетов поверх сисколов, аллокатор и другие никак не связанные с C системные вещи пихнём в glibc, а в glibc будем держать только одностороннюю совместимость. В итоге glibc хоть и гарантирует запуск всего старого софта, но чтобы собрать софт так чтобы он работал на большом спектре систем придётся собирать его со всеми зависимостями в старом glibc. И никто не делает никакого portable linux тулчейна чтобы разработчики игр могли под этот ваш линукс собирать портабельные игры.
Тем временем в винде для этого libc полностью отделён от системных API и ты можешь положить себе свою libc, opengl загрузит свою и никаких флетпаков не нужно.
Вот представь себе если бы портабельная программа всё содержимое system32 кроме drivers на windows тащила с собой? А мы тут в линуксах такой дичью занимаемся вообще-то теперь

Суть драммы, вот нашёлся баг в glibc в функции возведения в степень, вот и добавили новую `pow` с новой версией, нельзя же менять поведение старого софта? А то софт собранный под грёбанные RHEL6 будет работать чуть по другому. В итоге теперь при линковке с новым glibc весь софт тащит новую версию симвала. А тут очнёлся сисадми со своим любимым дебианом и у него софт не работает! И тут он, насмотревшийся на свой любимый докер изобретает... flatpak. ДАвайте все зависимости пихнём в контейнер.
Потом ой.. а у нас блоб невидии не загрузился, пихаем его тожа...
Потом на всех форумах когда i965 заменили на iris ой... у нас аппаратное декодирвоание видео отвалилось.
А оперативки тем временем наш хвалёный флетпак жрёт в 2 раза больше потому что мы грузим mesa llvm системный и из контейнера. А в дебиане мы ещё грущим библиотеки под все gpu сразу, а вдруг они пригодятся. И у нас одно запущенное gtk3 приложение с маленьким окошком выжирает аж 4 гига рамы, браво!

У него банально API для отрисовки 2д нет.

Так ведь API для отрисовки 2D в иксах настолько устарел, что его никто и не использует толком сейчас. Взять какой-нибудь Qt или Chrome с его Skia – все срут битмапами внутрь OpenGL или на худой конец какого-нибудь XCB. И накой, тогда, спрашивается, нужен этот 2D, и всякие там XRender’ы с трапезоидами, которые даже в KDE/KWin задепрекейтили?

Опционально иметь возможность рисовать 2д через opengl клиенте хорошо, только форсировать это не надо.

Сегодня, когда каждый чайник имеет GPU рядом с CPU, нет смысла это не форсировать. Это именно что должно стать дефолтом, а в случае неполадок – fallback на CPU-рендеринг. Собственно так какой-нибудь Qt сегодня и делает.

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

Рассуждая про PE ты почему-то забыло про WinAPI. В Windows он есть и до сих пор обновляется под потребности современного мира. Запустив программы на WinAPI из первой версии Windows 1985 года на современной «максимальной дисяточке» ты получишь современный gray-scale рендеринг шрифтов, правильную трансформацию координат и возможность отображения на HiDPI-дисплеях: https://baat.exlmoto.ru/~exl_lab/screens/old_winapi_apps_on_hidpi.png

Уровень обратной/прямой совместимости недостяжимый для иксовых копролитов. Вот именно что в UNIX’ах аналогом WinAPI должен был стать Xlib + Xaw, но он протух и его сегодня доело червиё.

Импотенция иксов – одна из корней той причины, про которую ты плачешься постом выше. Они должны были обеспечить нормальный общесистемный фундаментный API для графики и окон в Linux (и UNIX-системах), но вместо этого устарели и сгнили. И пользователи и разработчики прикладного софта теперь должны таскать свои приложения с условным «system32» который ты упомянул. Оборачиваться во всякие Flatpak’и и прочие Snap’ы, ибо иксы не смогли обеспечить нормальный API для всего для чего пытались они его обеспечить.

Да, код иксов правда говно

Вот и пусть он отправляется вслед за своими разработчиками на пенсию помойку и перестаёт засорять кодовую базу ядра Linux (sic!) убогими костылями по типу «если процесс начинается с заглавной буквы X то это запущен какой-то иксовый хлам, к которому нужно применить workaround».

То есть все аргументы это «а вэйланд тоже говно, только в профиль» и УМВР? Но первый не делает иксы лучше, чем они есть, а второй субъективен.

вам то какая разница, если работает

такой подход хорош на отлаженном сервере, а на десктопе когда в иксах просто законфижить стабильно работаующую систему трудно (не говоря даже об отсутствии её портабельности, под каждую gpu свой конфиг), да еще и это работает менее плавно, есть и другие косяки, то Wayland сам напрашивается

picom

тормозной, иногда отваливается, часто дропает кадры

простые вещи по типу маштабирования и стриминга экрана сделаны через Ж

стриминг экрана прекрасно работает по Pipewire, масштабирование экрана работает лучше иксов, шрифты просто прекрасно выглядят (хотя всегда юзал полный хинтинг)

шрифты просто прекрасно выглядят

Теперь уже и шрифты рендерить X11 мешает.

А Римскую империю не X11 развалил, часом?

Дайте мне аналог атомов и пропертей окон под вейландом + возможность репарентить окна, и мне будет похрен, что там за графический стек.

А если этого нет, то для меня как разработчика это говно, а не технология.

Импотенция иксов – одна из корней той причины, про которую ты плачешься постом выше. Они должны были обеспечить нормальный общесистемный фундаментный API для графики и окон в Linux (и UNIX-системах), но вместо этого устарели и сгнили.

И поэтому мы теперь должны радоваться еще большему говну? Зашибись логика.

имеем:

1. дисплей 141 dpi
2. полный хинтинг

в конфигах иксов прописываем dpi, в wayland вообще ничего не трогаем. Получаем шрифты в иксах хуже

Внимание вопрос. Каких боком дисплейный сервер относится к рендерингу шрифтов?

Отвечают знатоки из команды ЛОРа. Минута пошла.

хоть Поттеринга на них натравить

Поттеринг бы выкинул этот фрагментированный позор на помойку и изобрёл displayd. Было бы оверинженернуто так мощно, что не только бы показывало окна, но еще и ходило бы в магазин за продуктами. Ну зато работало бы адекватно поставленным задачам.

А Поттеринг пусть сидит себе в M$.

Работает человек:

https://www.opennet.ru/opennews/art.shtml?num=59099

Ну начну с основного - невозможность приложения сохранить работоспособность в случае отвала сессии. В wayland сейчас это пытаются исправить.

То есть пока для иксов спокойно себе сто лет существует xpra, в вяленом это только «пытаются исправить».

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

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

Не хотят.

В том числе и потому, что это только протокол с кучей независимых реализаций.

А X11 не протокол?

в один прекрасный день задумал перейти на i3

поставил i3

получил тиринг

прочитал, что чтобы избавиться от него, нужно либо поставить некий compton (что очень похоже на костыль. И после этого местные не прекращают орать про какие-то мифические костыли в вяленом, смешно просто), либо перейти на sway, в котором нет тиринга бай дизайн

перешел на sway

то что какие-то утилиты из него могут не работать в гноме - о боже, какая трагедия. Может они еще и в винде должны работать, или это другое?

Внимание вопрос. Каких боком дисплейный сервер относится к рендерингу шрифтов?

К огромному сожалению, наипрямейшим образом. Потому что «иксы» это не только дисплейный сервер но и весь тот ворох XCB-кода (очень недокументированного и дурно пахнущего) и Xlib-кода во всяких шрифтовых растеризаторах и фреймворках по типу Qt, GTK+ и пр.

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

Уровень обратной/прямой совместимости недостяжимый для иксовых копролитов.

Что ты черт побери такое несешь?

Пользователи «замечают разницу», потому что gtk4 работает по-разному под иксами и вяленым, с разными настройками. Всё.

Парсингом и рендерингом текста под линуксом занимается отдельный стек библиотек. Который генерирует битмапы. Которые потом ложатся в текстуру.

Знатоки не справились.

Как мне в Xlib/Xaw приложении 1984 года получить поддержку современных Gray-scale TTF шрифтов, HDR и HiDPI-матриц с правильной трансформацией координат и чтобы без мыла?

Пользователи «замечают разницу», потому что gtk4 работает по-разному под иксами и вяленым, с разными настройками.

Здесь пользователь замечает разницу в шрифтах у себя в KDE на Qt: Тем, кто не верит, что иксы портят картинку

весь тот ворох XCB-кода (очень недокументированного и дурно пахнущего) и Xlib-кода

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

Абсолютно одинаковое мыло. Без попиксельного сравнению рендеринга идентичного шрифта - ни о чем.

Я выше утверждал что в OpenGL и XCB херачат битмапы. А отрисовку XRender-примитивами (читай трапезоидами) использует только GTK/Cairo, от неё практически все отказались.

Итак, Qt херачит битмапы в opengl, поэтому под иксами ему барабашка из шкафа помешал рендерить шрифты. Всё правильно?

Итак, Qt херачит битмапы в opengl, поэтому под иксами ему барабашка из шкафа помешал рендерить шрифты. Всё правильно?

Неправильно.

Qt под X11 херачит битмапы в XCB.

Qt под Wayland херачит битмапы куда-то в QtWaylandPlatform, которые потом возможно улетают в OpenGL, или какой-нибудь там pixman, если нужна именно программная отрисовка.

И где-то в этом куске XCB-кала который Qt кормит битмапами – https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb у пользователей корёжутся шрифты и они после сравнения с Wayland-сессией бегут создавать темы и посты о том, что на иксах у них ШГ.

Разработчики Qt решили выпендриться и использовать XCB напрямую вместо Xlib, неосилили и получился криворукий результат. А виноват внезапно X11, а не разработчики Qt.

Это уже по ведомству дурки, извини.

Разработчики Qt решили выпендриться и использовать XCB напрямую вместо Xlib, неосилили и получился криворукий результат.

Если мне не изменяет память, современный Xlib сам давно переписан через XCB…

https://xcb.freedesktop.org/XlibXcb/

Правда в релизе иксов оно или нет, я не знаю.

В любом случае, XCB уже очень давно рекомендуется как современная и асинхронная замена Xlib самими разработчиками иксов, так что нельзя винить разработчиков Qt за их выбор.

А учитывая что документация (её фактическое отсутствие) XCB это полный кал, Qt-разработчиков можно лишь пожалеть. У Xlib хотя бы была вменяемая документация.

А виноват внезапно X11, а не разработчики Qt.

Считаешь что в устаревании реализаций кода XCB и Xlib back-end’ов и нежелания его поддерживать иксы никак не виноваты? Я так не считаю.

Так называемые «Иксы» – это не только священная корова – X11 и сервер окошек, но ещё и ворох Xlib и XCB реализаций разной степени корявости. И как раз-таки проблемы внутри проекта всех иксовой экосистемы, их организации, документации, кода и прочего сказываютс на конечном качестве прикладных приложений.

Под херово документированный XCB писать код сложно – на выходе получаем криво работающий растеризатор.

Дурка – недокментированность XCB, когда для того чтобы написать что-то с ним связанное, нужно буквально лезть в исходники Qt и других проектов и смотреть как у них это сделано.

Дурка – когда баги XCB и Xlib реализаций не фиксят десятилетиями, и пользователи на ЛОРе ноют про ШГ.

Дурка – пакеты xorg-server-bug865 в репозиториях.

Дурка – когда разработчик внедряет в ядро Linux (!) патч-костыль, который по первой букве X находит процесс Xorg и применяет к нему workaround, потому что лезть в код иксов никто не хочет.

Но сука, святая икс-корова, не виновата в своей дерьмовой «экосистеме» с расплодившимся зоопарком Xlib’ов и XCB’ов. Святую икс-корову трогать нельзя, её «диды» (на самом деле студентота MIT) лабали.

И это всё наплодили вот именно эти типы, что сейчас херачат вяленого. Поздравляю, линупс по уши в дерьме.

Что млять мешает навести во всём этом порядок еще 15 лет назад кроме импотенции разрабов?

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

Что млять мешает навести во всём этом порядок еще 15 лет назад кроме импотенции разрабов?

Лично моё мнение – мешает отсутствие благосклонного диктатора в лице человека, группы разработчиков или компании. Такого диктатора, который мог бы твёрдой рукой стандартизировать Linux-десктоп. Которого будут слушать и делать так, как скажет он. Мешает отсутствие скоординированности и предельный фанатизм разных лагерей. Вот в ядре есть лидеры в лице мейнтейнеров, в Linux-десктопе таких лидеров нет, либо же они не очень адекватны и витают в облаках – см. на разработчиков GNOME в Red Hat.

Первые попытки стандартизировать всё это в лице LSB, как видишь, оказались тоже импотентны. Иначе бы у нас был бы до сих пор Qt 3 и древний RPM/CPIO в Linux-системах, которые они там настандартизировали от балды.

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

А учитывая что десктоп (не только Linux’ый) становится очень нишевым в последнее время, то вообще не факт что порядок случится когда-либо.

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

Я радуюсь лишь тому, что сегодня наконец-то убивают иксовый кунсткамерный зоопарк со всеми его Xlib’ами, XCB’ами, четырмя подсистемами ввода, «Maybe nobody knows .. LOL» в man xorg.conf, пакетами патченных иксов в репах потому что апстрим не может, сука, расхаркодить говённый захардкоженный иксокод и сделать его конфигурируемым, ссут где-то там сломать очередной xroach, при это всякие xsnow вот уже 15 лет сломаны из-за композитинга и всем похрен.

Конечно плохо что Wayland до сих пор не предлагает X.Org паритетную по функциональности замену. И в первую очередь ограниченность реализаций Wayland’а касается политических амбиций разработчиков из Red Hat с их влажными фантазиями о том, что все должны преклоняться перед их великими революционными идеями – https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/

Разработчики Qt решили выпендриться и использовать XCB напрямую вместо Xlib

А как так вышло, что для того, чтобы просто кормить битмапами, надо ещё выбрать правильную билблиотеку?

Так пруфы-то будут? А то все так кинулись обсуждать фантазии EXL, будто он уже ссылки на код дал.

либо же они не очень адекватны и витают в облаках

Ну вот и где поводы для радости?

Я радуюсь лишь тому, что сегодня наконец-то убивают иксовый кунсткамерный зоопарк…

…и все надежды на стабильное API для прикладного кода. Спасибо большое.

Так пруфы-то будут? А то все так кинулись обсуждать фантазии EXL

Пруфы и фантазии чего? Под X11-сессией Qt по умолчанию (читай во всех десктопных Linux-дистрибутивах) использует XCB из комплекта plugins/platforms/xcb. Спроси у X512, если мне не доверяешь.

будто он уже ссылки на код дал.

Внезапно! В этом посте и давал: Чем вам не нравится X11? (комментарий)

Могу ещё ссылку на документацию дать: https://doc.qt.io/qt-5/linux-requirements.html

On Linux, the xcb QPA (Qt Platform Abstraction) platform plugin is used.

И накой, тогда, спрашивается, нужен этот 2D, и всякие там XRender’ы с трапезоидами, которые даже в KDE/KWin задепрекейтили?
Сегодня, когда каждый чайник имеет GPU рядом с CPU, нет смысла это не форсировать. Это именно что должно стать дефолтом, а в случае неполадок – fallback на CPU-рендеринг. Собственно так какой-нибудь Qt сегодня и делает.

Вот только сегодня отлаживал регрессию в mesa сломавшую одну игру, и угадай чем там рисуется мессажбокс? Правильно, libX11. А чем рисовать на wayland? Правильно, ничем.
Каким бы плохим этот код отрисовки не был, он хотя бы есть, чем сырой после более 10 лет разработки wayland похватстаться не может.
Вторая проблема этим связанная это что ради отрисовки окошка с парой кнопок придётся загрузить больше сотни мегабайт библиотек. Я понимаю что сделанный на голых иксах интерфейс отвратительно выглядит, но это не означает что в альтернативе иксам его не должно быть совсем. Это означает что там должны быть другие более удобные инструменты отрисовки. И лучше один раз это всё загрузить в иксах, чем в каждый процесс который хочет нарисовать пару кнопок.
Третья проблема - давай, напиши мне тут код отрисовки квадрата на opengl в одном комментарии. Причём сразу на gles1 под старое железо и под gl core. А лучше ещё под вулкан, затвра галлиум депрекейтнут ведь?

Оборачиваться во всякие Flatpak’и и прочие Snap’ы, ибо иксы не смогли обеспечить нормальный API для всего для чего пытались они его обеспечить.

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

Пруфы и фантазии чего?

Того, как иксы «портят рендеринг текста».

К слову кстати о винапи - microsoft его конечно развивали, но всё равно 10 лет пытаются дропнуть заменяя на xaml/wpf/maui итд. В винде уже считается чуть ли не позорным иметь винапишный интерфейс в приложении.Так что тут не сколько необходим продвинутый интерфейс со контроллами, сколько просто команды отрисовки глифов и квадратиков с битмапами, в иксах тут не хватает только глифов

«Maybe nobody knows .. LOL»

А вот это лучше, да?

-depends=('pango' 'wlroots>=0.14' 'wlroots<0.15' 'wayland' 'wayland-protocols' 'xorg-xwayland')
+depends=('pango' 'wlroots>=0.15' 'wlroots<0.16' 'wayland' 'wayland-protocols')

-depends=('pango' 'wlroots>=0.15' 'wlroots<0.16' 'wayland' 'xorg-xwayland')
+depends=('pango' 'wayland' 'xorg-xwayland') # 'wlroots>=0.16' 'wlroots<0.17'

-depends=('pango' 'wayland' 'xorg-xwayland') # 'wlroots>=0.16' 'wlroots<0.17'
+depends=('pango' 'wayland' 'wlroots>=0.16' 'wlroots<0.17' 'xorg-xwayland')

Stable API is nonsense.