X.Org Server 21.1.0

То же, что мешало доделать XOrg.

Но ты верь сильнее, вера, говорят, помогает.

Сейчас есть 3 основыне реализации: Mutter, KWin и Wlroots.

Wayland забыли. Он используется в WSL, у которого большая аудитория.

То же, что мешало доделать XOrg.

Что никто не понимает как он устроен с момента прекращения коммерческой разработки. Это как артифакт умершей высокоразвитой цивилизации.

Можно и так ставить вопрос, но если проще, то банально нету деняк.

Были бы деньги, можно было бы выгнать неспособных разобраться и нанять способных.

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

как он устроен с момента прекращения коммерческой разработки

В каком году закончилась коммерческая разработка X.Org?

В каком году закончилась коммерческая разработка X.Org?

Она закончилась ещё до X.Org с прекращением развития коммерческих UNIX в районе 2000 года.

Всякие костыли вроде XFixes и XRender мне напоминают фильмы про эксплуатацию высокоразвитых технологий отсталыми обществами постапокалиптического мира.

Она закончилась ещё до X.Org

Означает ли это, что коммерческая разработка X.Org никогда не производилась? Если так, то почему окончание коммерческой разработки чего-то там ещё имеет какое-либо значение для X.Org?

Означает ли это, что коммерческая разработка X.Org никогда не производилась?

Да.

Если так, то почему окончание коммерческой разработки чего-то там ещё имеет какое-либо значение для X.Org?

Это изначально проект в рамках Athena. X.Org просто взял готовые исходники когда они уже стали не нужны корпорациям, разрабатывающим коммерческие UNIX. Как говорил EXL: иксы выброшенные на свалку корпорациями и подобранные в Линуксе.

напоминает историю с beos)))

В BeOS исходники никто не выкладывал.

Это как артифакт умершей высокоразвитой цивилизации.

До иксов был более крутой артефакт высокоразвитой цивилизации. Назывался Display PostScript и использовался в Sun и NeXT.

Compared to X, NeWS was vastly more powerful, but also slower (especially for local connections).

https://en.wikipedia.org/wiki/NeWS#Competition_with_X_Window_System

Именно с внедрением иксов в графические UNIX-системы и началась деградация.

значит ли это, что haiku - уровень реактос?

До иксов был более крутой артефакт высокоразвитой цивилизации. Назывался PostScript и использовался в Sun и NeXT.

Исходники видимо не выложили, так что все забыли.

Нет, Haiku в отличии от ReactOS стабильно работает. И в ReactOS есть подозрения на кражу кода из Windows. Haiku несовместима на внутреннем уровне с BeOS, внутренние протоколы и детали реализации отличаются. Совместимы только публичные API/ABI.

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

Нажать на иконку «глаза» в тексте новости.

О,а я забыл про нее, с links в основном на ЛОР хожу,ее тут не видно) Спасибо!

but also slower

Его невозможно «доделать». В принципе. Даже если бы разработчики решили продолжать прикладывать несоизмеримо огромное количество усилий к поддержке легаси-кода.

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

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

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

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

А твой тезис — всё равно что говорить, что если ты пишешь программы на языках кроме ассемблера, то ты неспособный и неосилятор.

Почитай хотя бы статью в Википедии про историю X.Org и того, откуда он взялся.

Когда он появился, развитие уже практически остановилось. Одно название X11 о многом говорит, до этого были X10 и т.д., они часто менялись и было бурное развитие. А с начала X.Org в этот код уже почти никто не лезет.

На всякий случай сообщаю что развитие видеодрайверов и аппаратного ускорения имеет мало отношения к оконной логике.

Weston? Это же техническая демка, а в MS, видимо, решили его использовать, потому что остальное либо к DE прибито, либо тайловое (sway), либо маргинальщина (всё остальное), а свой писать они не захотели. Но если там что-то не будет работать, то это скорее проблема MS.

Так и X.Org в сравнении с тем же Wayland тоже стал «but also slower», учитывая что в Wayland взяли и тупо перенесли всю отрисовку на GPU/EGL, без всех этих иксовых 2D-ускорений, которые нормально так никогда и не работали и лишь ухудшали ситуацию с тирингом при перемещении окон, а базовый протокол ещё разок упростился и получилось «Compared to Wayland, X11 was vastly more powerful».

Если в Display PostScript было: «вот вам буфер, огромный набор векторных примитивов, кривые Безье, графический тулкит, всякие фишки вроде прозрачности, смешивания цветов и halftones», то в иксах стало: «вот вам буфер и набор корявых битмапных примитивов, которые завтра устареют и ими никто пользоваться не будет», а в Wayland вообще: «вот вам буфер».

И точно так же, когда в случае перехода Display PostScript => X11 наблюдалась деградация и к протоколу X11 начали прикручивать всякие XRender’ы, трапезоиды, композиторы и пр. чтобы хоть немного навернуть утраченное из Display PostScript, так и к Wayland сегодня прикручивают всякие расширения XDG, чтобы хоть как-то приблизиться к тому что было доступно в X11 и его расширениях.

Девиз UNIX-like десктопа: сосём с 1984 года.

А корпорации тут причём?

Именно.

Все успешные платформы просто отказались от иксов при первой же возможности

А какие есть успешные платформы? Огласите весь список, пожалуйста, я вот только солярку вспомню, остальное мертво.

Список отказавшихся: Android, ChromeOS, RHEL/GNOME, Embedded, Steam Deck, …

Список использующих:

Android, ChromeOS

Никогда не использовали.

Steam Deck

Уже вышел?

Embedded

Графический стек на роутере?

Только RHEL/GNOME можно назвать условной платформой использующей wayland, но у меня нет информации какой протокол используется большую часть времени. Может оказаться что используется xwayland предоставляющий реализацию X протокола.

Никогда не использовали.

Но когда-то стояли перед выбором. Как и тот же macOS (+ iOS) от Apple. В итоге решили не тянуть весь этот иксовый хлам в современные системы и правильно сделали.

Embedded

Графический стек на роутере?

В Embedded можно внести различные Sailfish OS, KaiOS, MotoMAGX, EZX и пр. Linux-платформы для телефонов и смартфонов, которые не использовали X11.

Только RHEL/GNOME можно назвать условной платформой использующей wayland

Речь шла об отказе от иксов, а не использовании Wayland.

Никогда не использовали.

В том-то и дело. Отказались от иксов ещё на этапе рассмотрения.

Уже вышел?

Уже известно, что в полноэкранном экране там Wayland.

Графический стек на роутере?

При чём тут роутер?

но у меня нет информации какой протокол используется большую часть времени. Может оказаться что используется xwayland предоставляющий реализацию X протокола.

При чём тут XWayland? Сессия на Wayland, официальные приложения работают через Wayland. Софта, требующего X11, со временем будет становиться только. Так-то и в макоси XQartz есть.

Если сессия на основе Wayland, он там используется 100 % времени. Это по определению ≥ времени использования X11.

В том-то и дело. Отказались от иксов ещё на этапе рассмотрения.

Все успешные платформы просто отказались от иксов при первой же возможности

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

Уже известно, что в полноэкранном экране там Wayland.

И как там в 2025 году? До выхода платформы говорить об успешности рановато.

При чём тут роутер?

Роутеры это одни из самых успешных embedded платформ.

Если сессия на основе Wayland

А если нет, у вас есть данные по сессиям? У меня нет.

Sailfish OS, KaiOS, MotoMAGX, EZX и пр. Linux-платформы для телефонов

Не относятся к успешным платформам. Продолжая вашу мысль выше - их неуспешность это следствие отказа от X11. Скорее успешность/неуспешность платформы не зависит от использования X11.

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

Не вижу. Почему на момент отказа платформа уже должна быть успешной? Какое-то бесполезное передёргивание, никак не относящееся к предмету обсуждения.

Вот как раз благодаря отказу от иксов они успешными и стали.

Роутеры это одни из самых успешных embedded платформ.

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

До выхода платформы говорить об успешности рановато.

Можно на предзаказы посмотреть хотя бы.

А если нет, у вас есть данные по сессиям? У меня нет.

Мне достаточно знать, что там Wayland по умолчанию, а X.Org на правах legacy. Направление развития вполне очевидно. А демагогия на тему «а что если там его ещё используют?» мне абсолютно неинтересна.

Вот как раз благодаря отказу от иксов они успешными и стали.

Бездоказательно, полно неуспешных платформ без X11.

Какое-то бесполезное передёргивание, никак не относящееся к предмету обсуждения.

Относится, успешность платформы от используемого графического протокола не зависит. Как пример Sega Saturn и PS3, разработка для которых была по воспоминаниям сущим адом (берем аналогию с иксами).

Бездоказательно, полно неуспешных платформ без X11.

Не знаешь, в чём разница между достаточным и необходимым условием?

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

Она зависит от эффективности использования ресурсов и от соответствия продукта потребностям пользователей.

Не знаешь, в чём разница между достаточным и необходимым условием?

Знаю. Отказ от x11 не является ни необходимым, ни достаточным условием.

Она зависит от эффективности использования ресурсов

Зависит, но слабо.

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

Зависит. А ещё зависит от множества других факторов.

Ну, то есть, по-твоему, то, что все успешные коммерческие платформы либо не стали использовать иксы с самого начала, либо отказываются от них — это чистая случайность, никак не связанная с состоянием кодовой базы и неисправимыми техническими проблемами X.Org/X11?

На вялом всё плохо по WM и адекватности их API (да даже панельку нельзя написать без разных костылей к KDE свой, к Gnome свой, а больше и нету ничего). Спасибо, кушайте сами.

В Wlroots уже есть layer-shell, в Plasma он будет. А в GNOME такое by design не приветствуется и смысла не имеет даже под иксами.

не стали использовать иксы с самого начала

У них были на это свои причины, так что о случайности говорить не приходится и

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

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

либо отказываются от них

Успешными эти платформы стали на иксах, повлияет ли отказ от иксов на их успешность неизвестно, +/- будет то же самое.

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

Да неужели?

Успешными эти платформы стали на иксах, повлияет ли отказ от иксов на их успешность неизвестно, +/- будет то же самое.

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

Технически это можно пофиксить, да. Но, когда проектировали первую реализацию X-ов в MIT, на это никто не обращал внимание. Тогда многие системы в принципе не сильно парились по поводу безопасности и изоляции.

Но, емнип, X.org был спроектирован так, что он не скрывал от процессов инфу об окнах других процессов. А потому реализацию изоляции для true X-based GUI-тулкитов, что не просят создать у иксов чисто окно, на котором сами будут рисовать что им угодно, а используют X-протокол для создания и взаимодействия со всеми контролами, придётся пилить на уровне самого X-сервера. А для GTK и Qt, которые давно забили на стандартный иксовый подход, и рисуют контролы на окне и управляют ими, а также обеспечивают взаимодействие между ними сами, почти так же, как они это делают в Wayland, изоляцию нужно пилить как на уровне X.Org, так и на уровне самих тулкитов. И если для Wayland всё, что нужно для изоляции уже запилили на обоих концах изначально(у Wayland архитектура планировала необходимость обеспечение изоляции между приложениями), то с X-ми переделки придётся внедрять с обоих сторон, и это будут изменения, ломающие обратную совместимость. А ведь X-ы юзают и очень старые, в том числе научные, приложения. Написанные с тулкитами чисто под X-ы, ещё времён 1980-х и первой половины 90-х. Переписывать кучу кода под X-ы никто не будет. Переделывать проприетарные либы и приложения - тоже. Никто не будет этим заниматься. Проще оставить X-ы такими, как есть. И запускать на них старые приложения. Обеспечивая обратную совместимость.

Разрабы X-ов не случайно отказались от разработки X12. Они хотели улучшить X11, сделав их более современными и избавив от дыр с безопасность. Посмотрели, какие изменения для этого нужно внести в протокол и реализацию X-сервера, и поняли, что изменения напрочь ломают обратную совместимость. А это единственное, ради чего вообще держались за идею X-сервера. Стало понятно, что овчинка выделки не стоит. Раз обратная совместимость всё равно теряется, смысл за неё цепляться? Нужно пилить на замену X-ам что-то, не страдающее обратной совместимостью, крайне простое на стороне сервера, но современное и заточенное под актуальную архитектуру графических ускорителей , и актуальные требования популярных тулкитов, с их подходом реализовывать почти всё, что раньше делал X-протокол, кастомно на своей стороне, в рамках тулкита. Так появились сразу два проекта: Wayland и Mir. Очень похожие в плане архитектуры. Над Wayland работает большая часть людей, что работали над X-ами. По факту они признали, что будущее за Wayland. А X-ы пилят чисто из соображений обратной совместимости. И делают это, последнее время, по остаточному принципу.

Тут парадоксальная ситуация с менеджерами буфера обмена сложилась. У wlroots своя реализация этого дела. У gnome-shell и mutter - своя.

Для Sway и wlroots-based оконных менеджеров рекомендую:

• Clipman
• wl-clipboard-manager

Под wlroots запилили протокол, позволяющий узнать инфу об окнах, в том числе о контроле, где был курсор до того, как открыли буфер обмена. Там, в принципе, можно реализовать старый подход к вставке в нужное поле нужного окна текста из буфера обмена автоматом. В остальных случаях(если у вас Gnome, к примеру) - вставлять выбранное в буфере обмена куда нужно нужно будет хоткеем/мышью/из контекстного меню. Что не удобно, конечно.

На Gnome в Wayland можно юзать GPaste.

Если у вас есть XWayland(прослойка, что обеспечивает работу X-овых приложений в Wayland), то будут работать и старые X-овые менеджеры буфера обмена, в том числе Parcelite или CopyQ.

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

Протоколы wlroots со временем стают частью стандарта, в частности их переносят в KDE. Поэтому со временем ситуация с менеджерами буфера обмена и вставкой из них текста в контрол, где мышь была до октрытия окна менеджера буфера обмена, наладится. Везде, кроме, вероятно, Gnome. Разрабы последнего плевать хотели на дополнительные протоколы, и их расширения, что пилят в wlroots. Они берут голый wayland, поверх которого натягивают свои расширения протокола, не совместимые с другими проектами. Там цветёт NIH во всей красе. А потому у Gnome под Wayland будет свой менеджер буфера обмена, не совместимый с тем, что пилит сообщество под другие реализации Wayland-композитора.

бОльшая отзывчивость интерфейса

Это до сих пор актуально.

и никакого конфигурирования кроме шрифтов … вяленый не дает возможности подстраивать дпи дисплея

ЕМНИП, DPI Wayland не меняет. Он играется со scale factor. Но, если настроить верно, внешне эффект тот же, что в иксах при смене DPI. Sway позволяет кастомно менять это значение, дробно, к примеру указать scale 1.2, что равно 120%. У Gnome вроде выбор пока только между 100 и 200%, что не круто. В KDE на Wayland(Plasma 5.23) есть пункт «Force Custom DPI»(под «System Settings->Fonts»), который вроде как позволяет менять DPI. Но, учитывая тот факт, что у дисплея разрешение физически всё то же, пересчёт с нужного по Custom DPI разрешения в имеющееся физически всё ещё решается отрисовкой в одном виртуальном разрешение со scale до нужного, просто настройка выглядит так, как это было принято во время иксов.

Но, емнип, X.org был спроектирован так, что он не скрывал от процессов инфу об окнах других процессов. А потому реализацию изоляции для true X-based GUI-тулкитов, что не просят создать у иксов чисто окно, на котором сами будут рисовать что им угодно, а используют X-протокол для создания и взаимодействия со всеми контролами, придётся пилить на уровне самого X-сервера.

Конечно, в сервере, а где же ещё? И не для каких-то определённых тулкитов, а для всех. Зависящая от клиента изоляция это фейк вообще.

изоляцию нужно пилить как на уровне X.Org, так и на уровне самих тулкитов.

На уровне тулкитов не нужно ничего, они всего лишь клиенты к иксам.

и это будут изменения, ломающие обратную совместимость

Опять начинается. Сломаются только те проги, которые опираются на закрытую от всех подряд информацию. О таких прогах система (по мере получения от них legacy-запросов, к которым будут порезанные ответы) должна оповещать юзера и предлагать либо выдать проге нужные права, либо подтвердить что проге права не нужны и конкретно этот (опирающийся на закрытые данные) её функционал должен быть сломан. Ни эмулятор терминала, ни браузер, ни редактор картинок, ни текстовый процессор, ни ещё куча софта вообще ничего не заметят - они пользуются только своими окнами.

Переписывать кучу кода под X-ы никто не будет.

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

Разрабы X-ов не случайно отказались от разработки X12

Просто забили. И дело тут не в объективных причинах, связанных с иксами, а в профнепригодности нынешних их разрабов. Те, кто что-то могли, видимо потеряли со временем интерес, ещё какие-то впали в старческий маразм, ну а новопришедшие страдают слабоумием.

Пример: в 2005 (!) году им зарепортили тривиальный баг (тогда ещё не было этого шума про вейланд). В 2010 году на него повторно обратили внимание, на что от xorg-разраба был получен идиотский ответ «эта функция deprecated, поэтому она выдаёт не то». Другой xorg-разраб (видимо с правами комиттера) по сути подтвердил это «решение». В 2019 году я, в процессе написания своего «тулкита» к иксам, тоже столкнулся с этим багом, начал искать в инете причины, и нашёл весь вышеописанный бред. У меня заняло меньше дня (а может и меньше часа, не помню, давно было) на то, чтобы с нуля разобраться в нужном коде xlib, и найти эти несчастные 4 строки, в которых надо было поправить по несколько символов. Прислал я им этот «патч» с указанием на проблему.

https://bugs.freedesktop.org/show_bug.cgi?id=5349

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

https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/97

Ну, жду я, вот я же всё им приготовил, надо только внести эту правку. Неделю, месяц, год... И вот этим летом (спустя два года) вижу что наконец кто-то сделал мерж-реквест. Этот кто-то, как совершенно неудивительно оказалось, не из команды xorg, а просто сочувствующий. И что дальше?

https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/78

Мердж не удался, надо rebase, который никто разумеется за 4 месяца не сделал. В мастере до сих пор старый код. Зато как оказалось обвешать pragma-костылями ту же самую функцию год назад (чтобы не писало варнинги про ими же зря добавленный deprecated) у них «ума» хватило.

https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/d127217f26df1bf7566c1...

Опять начинается. Сломаются только те проги, которые опираются на закрытую от всех подряд информацию. О таких прогах система (по мере получения от них legacy-запросов, к которым будут порезанные ответы) должна оповещать юзера и предлагать либо выдать проге нужные права, либо подтвердить что проге права не нужны и конкретно этот (опирающийся на закрытые данные) её функционал должен быть сломан. Ни эмулятор терминала, ни браузер, ни редактор картинок, ни текстовый процессор, ни ещё куча софта вообще ничего не заметят - они пользуются только своими окнами.

Это если оптимизировать только код связанный с изоляцией, будет так как вы описали. Они заодно хотели перейти и на модель, где область окна даётся сервером, а все контролы рисует и отвечает за них чисто тулкит(сервер знает только об окне и его размерах, но всё что внутри для него тупо контекст, в который что-то рисует тулкит). Вот эти изменения сломали бы все старые приложения, ЕМНИП. И именно из-за них больше всего копий ломали.

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

Конечно, в сервере, а где же ещё? И не для каких-то определённых тулкитов, а для всех. Зависящая от клиента изоляция это фейк вообще.

Это всё верно в случае, когда клиентская часть(тулкит) по максимуму юзает стандартные протоколы X-ов. Насколько я помню, бывает GUI на тулкитах, создающих окно средствами X-ов, в котором они рисуют что хотят не в соответствии со спецификациями X-ов для контроллов, а своими силами. Такой GUI можно скринить из других приложений в X-ах, но не получится на уровне X API получать инфу о контролах внутри этого окна. И тут уже определённая, пусть и фейковая, изоляция на уровне тулкита тоже нужна(если тулкит поддерживает возможность из другого приложения получать инфу о контролах, трудящихся в другом окне). Но, опять таки, я в тулкитах не спец, как там утроено под капотом знаю только из попсовых статеек, так что насколько верное впечатление по ним у меня создалось, не скажу. Вероятно вы в этом случае можете более трезво оценить, нужны ли правки подобные на уровне подобных тулкитов(если видели их код/имели с ними дело).

Ну и не всегда прозрачность - это плохо. Видел ОС на Lisp/Scheme когда-то, в которых каждое окно и каждый контрол были видны как иерархия объектов со стороны системы. Там можно было делать из одного приложения с любым другим потрясающие вещи. Автоматизаций рутинных действий в таких системах тоже выглядела просто потрясно. Но с точки зрения безопасности это была одна большая дырень, да…

Это если оптимизировать только код связанный с изоляцией, будет так как вы описали. Они заодно хотели перейти и на модель, где область окна даётся сервером, а все контролы рисует и отвечает за них чисто тулкит(сервер знает только об окне и его размерах, но всё что внутри для него тупо контекст, в который что-то рисует тулкит). Вот эти изменения сломали бы все старые приложения, ЕМНИП. И именно из-за них больше всего копий ломали.

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

(если тулкит поддерживает возможность из другого приложения получать инфу о контролах, трудящихся в другом окне)

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

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

Согласен. Но, насколько я понимаю, реализация первого режима куда сложней в техническом плане, чем простой вариант - одно окно, один фреймбуффер, а дальше пусть тулкит делает с ним что хочет. Вероятно текущих ментейнеров X-ы пугают своей монументальностью и сложностью(как текущих разработчиков космических аппаратов напугали бы Буран и Апполон, до которых теперешним убогим ракетам как до Луны пешком), и они просто хотят упростить монструозное нечто, доставшееся им от пращуров. А заодно убедить всех, что оно простое, лёгкое и быстрое, надёжное как автомат Калашникова. А значит хорошее. А старое - over engineering, и потому его закопали.

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

И я не знаю. Статью читал, но код не смотрел, и не факт что в нём бы разобрался, я с C слабо знаком. Ничего не могу сказать по существу.

ssh -X somehost someprog в Wayland осуществить можно?

С ssh я мало работал и мне сложно понять что делает данная команда. В man ssh написано:

Enables X11 forwarding.

То есть это возможность подключиться по ssh с иксовой сессией?

На вялом всё плохо по WM

В плане их наличия и разнообразия?

адекватности их API

Можно поподробнее? Не имел опыта разработки под оконные менеджеры.