Nobody wants to say how this works. Maybe nobody knows ...

© man xorg

Есть X-сервер. Он рисует на экране. И есть X-клиенты. Программы, которые говорят X-серверу что и как он должен рисовать.

Без X-сервера графика тоже есть, но на уровне фреймбуфера. Фреймбуфер поддерживается на уровне ядра. В этом случае программы могут рисовать картинки во фреймбуфер.

Есть X-сервер. Он рисует на экране. И есть X-клиенты. Программы, которые говорят X-серверу что и как он должен рисовать.

А есть современные DE, которые рисуют сами и низводят X-сервер до рисовальщика картинок.

Т.е. x-сервер не нужен, получается?

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

Сами рисуют некоторые тулкиты, такие как GTK и Qt. И они это делают и без DE.

некоторые тулкиты, такие как GTK и Qt

«Некоторые виды людей, такие как мужчины и женщины».

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

Некоторые тулкиты, такие как GTK и Qt, умеют вместо X-сервера использовать, например, Wayland. А ряд других тулкитов, включая Tk, Motif, fltk,... и т.д., пока ещё Wayland использовать не умеют, и требуют X-сервер. На этот случай в Wayland'е, кстати, предусмотрен запуск по копии X-сервера для каждой такой программы.

Но, можно просто юзать иксы. Или не юзать GUI софт вообще.

Как работает X.Org ?

Хреново.

Нужен. Просто его функциональность сводится к минимуму: отображение уже отрендеренных картинок и обработки ввода.

Учитывая такое положение дел, начали пилить вяленного, который не является таким комбайном, как иксы. Правда он ещё не достиг оперативной готовности, прямо как f-35.

Вредные советы от saahriktu:

1. Не юзать GUI софт.
2. Юзать маргинальные дистрибутивы.
3. Юзать маргинальные кодировки.
4. Юзать устаревшее 32-х разрядное говно.
5. ...
<Продолжаю наблюдение>

32-х разрядное

Какое расточительство. Святые 8бит могут всё, они вывезли человека в космос.

Юзать устаревшее 32-х разрядное говно.

Я этого не советовал. Более того, я сторонник компиляции из исходников и отсутствия multilib'а. Чтобы на x86_64 железе стояла x86_64 система и под неё собирался x86_64 софт. Впрочем, я не сторонник закапывания старого железа, и вполне одобряю тех, кто продолжает юзать железо, которое не поддерживает 64-х битные инструкции.

Я этого не советовал.

Видимо с кем-то перепутал.

Более того, я сторонник компиляции из исходников и отсутствия multilib'а. Чтобы на x86_64 железе стояла x86_64 система и под неё собирался x86_64 софт.

Ага, вот и пятый вредный совет. Сборка из исходников и оптимизация под конкретный процессор не даёт особого выигрыша на x86_64. Не поэтому ли гента издыхает?

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

Поэтому Gentoo живее всех живых. Как и LFS, Crux, Lunar, Source Mage,... и т.д.

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

Я понял, что ничего не понял (шутка). Сколько лет полировали иксы, и сколько вяленому. Естественно, в новой сложной системе будут ошибки.

Вообще не столько в готовности дело, а в инерционности, перестраховщиках и легаси.

Сколько лет полировали иксы

Ага, про это была серия разрушителей легенд.

Адам и Джейми взяли в зоопарке разные виды навоза. 

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

Воспользовавшись наработками этого ремесла, и Адам,
и Джейми сумели сделать какашку блестящей.

Как много букв вместо очевидного «у меня бомбит от всех, кто ходит не строем».

На этот случай в Wayland'е, кстати, предусмотрен запуск по копии X-сервера для каждой такой программы.

Кстати. А неужели никому не пришло в голову вместо этого расточительства запускать в системе ОДИН полноценный X-сервер поверх Wayland и предоставлять всем программам, которым он нужен?

Или тогда уже просто только Хсервер вместо вэйланда. Yoba.jpg

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

Ага, вот и пятый вредный совет. Сборка из исходников и оптимизация под конкретный процессор не даёт особого выигрыша на x86_64. Не поэтому ли гента издыхает?

Сборка из исходников браузера, с оптимизацией не под GENERIC, а под своё MNATIVE CPU - даёт выйгрыш в 20% в сопоставительных тестах.

Поди и глянь - на сборку кернелов современных.

Заметьте — не я это предложил!

Просто переход с кукурузы на кофелейк или хотя бы ризен даёт >+200% везде.

Так у разработчиков Wayland'а же свои представления о безопасности. В т.ч. в Wayland'е проблемы с созданием скриншотов, поскольку одна программа не может получать доступ к окнам других программ. Создание скриншотов там возможно только на уровне композитора, а не программ пользователя.

А неужели никому не пришло в голову вместо этого расточительства запускать в системе ОДИН полноценный X-сервер поверх Wayland и предоставлять всем программам, которым он нужен?

В макоси xquartz именно так и работает

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

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

Ви все вrете. Один X сервер и висит. Иначе бы десяток легаси приложений под вяленым сожрал бы всю память

Хорошо, а что с ним тогда не так? Я в том смысле, что его хотят на Wayland заменить. И есть ли его аналоги в Windows и Mac OS ?

Утверждается, что, как минимум, архитектура иксов не учитывает особенности современного железа и софта на GTK и Qt, и что Wayland позволяет эффективнее задействовать аппаратное ускорение современных видеокарт и видеочипов. Ну и т.д. Авторы Wayland'а появились из рядов разработчиков иксов, но при этом они основательно раскритиковали архитектуру иксов, назвав её неюниксвейной. И начали делать свой вариант с более простой архитектурой. Не реализуя всё то, что они посчитали лишним. В т.ч. возможность рисовать примитивами на стороне сервера.

В винде и так своя графическая подсистема другой архитектуры в ядре. Про MacOS не знаю.

Есть X-сервер. Он рисует на экране. И есть X-клиенты. Программы, которые говорят X-серверу что и как он должен рисовать.

То есть получается, X-сервер общается с видеокартой, чтобы рисовать то, что говорит рисовать X-клиент?

Да.

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

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

- иксы запускаются, включают видеорежим (см KMS в ядре) и слушают сокет(ы)

- клиент запускается, смотрит в переменную окружения DISPLAY и выбирает куда соединяться

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

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

Есть X-сервер. Он рисует на экране. И есть X-клиенты. Программы, которые говорят X-серверу что и как он должен рисовать.

Ага только наоборот

Да, и это всё происходит «поверх» системы виртуальных консолей ядра, которые переключаются обычно кнопками [Ctrl+]Alt+Fn

Хз как теперь, раньше init запускал по дефолту на первых 6 консолях getty, а на 7й - иксы и какой-нибудь xdm.

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

Ну не надо. Теоретически, это конечно возможно. Но практически — тебе уже много раз отвечали, что в иксах никто не хочет копаться. Иксы это отличный пример того, когда проще «выкинуть и переписать заново». Слишком сильно разрослась кодовая база. Слишком большой гнёт Legacy-кода. Слишком мало людей имеют представление того, как подсистемы иксов уживаются вместе друг с другом. Именно поэтому у иксов давно уже нет никакого развития, а только: X.org Server 1.19.5

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

Именно поэтому Ubuntu, Fedora, SUSE уже перешли на Wayland, а Debian с CentOS/RHEL скоро на него перейдут.

В конце-концов позор мира UNIX, этот комбайн, который катком прошёлся по всем мыслимым и немыслимым принципам UNIX-Way и KISS, будет низвержен в преисподнюю.

Просто не нужно гальванизировать трупы.

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

А что, кроме X.Org есть ещё эталонные реализации X11?

Авторы Wayland'а появились из рядов разработчиков иксов

Будем называть вещи своими именами: авторы Wayland — создатели не только Xorg, но и протокола X11.

Почему-то необходимость писать с нуля эталонную реализацию одновременно придумываемого Wayland людей не смущает, а сделать собственную реализацию давным-давно задокументированного и хорошо исследованного X11 (раз уж пошла такая пьянка) - это типа тяжелее, да?

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

Про UNIX-Way

В конце-концов позор мира UNIX, этот комбайн, который катком прошёлся по всем мыслимым и немыслимым принципам UNIX-Way и KISS, будет низвержен в преисподнюю.

Вот, кстати, это даже интереснее того, о чём я писал комментарием выше.

Каким боком X11 нарушает UNIX-Way? Если, конечно, опять-таки понимать, что X11 - это в первую очередь, протокол. А уже во вторую, третью и двадцать пятую - программа или совокупность программ, которые этот протокол реализуют.

Да, согласно UNIX-Way, каждая программа должна выполнять свою узкую задачу. Но программы бывают разные. Есть такие программы (и ещё в большей степени API), назначение которых - быть «клеем», связующим звеном, средой, в которой работают юниксвейные утилиты.

Вот стандарт POSIX - он нарушает UNIX-Way? По твоей логике получается, что нарушает, ибо занимается всем, от файловых операций до расширений реального времени. Тем не менее, UNIX-системы основаны именно на этом стандарте-«нарушителе». На самом же деле просто не надо путать системные библиотеки и утилиту sed (например). У них в юниксвее разные роли. А X11 - это своего рода продолжение POSIX, описывающее диалоговый ввод-вывод.

Если же перейти от стандартов к реализующему их программному коду, то получается, что главные нарушители юниксвея - это ядра Linux и *BSD. Они же монолитные и занимаются всем, какой ужас! Почему-то xorg-server торопятся заменить, хотя замену, скорее, надо начинать с ядра. По сути, сервер иксов - это продолжение ядра, просто не для всех типов систем оно является нужным.

Сборка из исходников браузера, с оптимизацией не под GENERIC, а под своё MNATIVE CPU - даёт выйгрыш в 20%

Брехня.

выйгрыш

Убейся.

> Брехня.

Мнение эксперта?
А здесь - логи тестов Firefox и Chromium, собранных с аппаратным ускорением clang.

https://youtu.be/GWQh_DmDLKQ?t=20m53s

Не поэтому ли гента издыхает?

Непотому.

Каким боком X11 нарушает UNIX-Way?

Цитируя Даниэля из презентации выше, «что делает X и что он делает хорошо?».

И разве пресловутый UNIX-way не распространяется только на программную часть? Так как в действительно UNIX-way'ном Plan 9 тоже, хоть и гибридное, но ядро, что делает всё и сразу, и тоже POSIX-совместимые программы.

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

Неэнтерпрайзно.