Почему Wayland?

Собственноручно графическую систему написать…

Это просто обёртка над другой оконной системой, а не собственная графическая система. Общение с GUI сервером Haiku (app_server) по-прежнему происходит через IPC порты.

Действительно можно программировать себе WM

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

Обратите внимание,я не про сохраниение протокола говорил,а про сохранение API.

Поясню свою мысль. Вот сейчас мы имеем кусок графической подсистемы в ядре,в виде модуля, отдельно X-сервер,и отдельно библиотеку xlib которой пользуются программы-клиенты. Библиотека с сервером общаются через последовательный канал - локальный сокет или сетевое соединение. Классическая архитектура иксов.

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

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

Вэйланд - не причина стагнации,а ее результат. Просто никто не смог придумать ничего лучше

Это какая-то безумная логика: мы не смогли придумать ничего лучше X11, поэтому будем продвигать нечто худшее, чем X11.

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

Так ведь никто не запрещает кому угодно придумать что-то лучше вейланда,

Это уже проделано 40 лет назад.

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

Да что-то не демонстрирует wayland какой-то суперпроизводительности, относительно иксов. Если драйвера хорошие, всё хорошо работает под обеими системами. Если с драйверами/железом проблемы — всё плохо. На основании этого наблюдения я предлагаю считать, что проблема с сокетами сильно преувеличена.

Так это не реализация протокола, а библиотеки libwayland.

А теперь объединяем Х-сервер и библиотеку в одно целое, оно теперь будет разделяемой библиотекой

Не получится. Задача сервера - объединить окна всех клиентов в единую картинку, как он это будет делать, если у каждого клиента свой «сервер»? Придётся значительную часть кода сервера переносить в ядро.

Это реализация именно протокола. Там используется немного пропатченная версия libwayland, но основной API используется без изменений. Также сделан кодогенератор протоколов для C++.

поэтому будем продвигать нечто худшее, чем X11.

Это твоё мнение.

проблема с сокетами

Её не существует. А вот тройная буферизация в GLX - существует.

Можно ли к этой «реализации» подключиться клиентом, не использующим libwayland? Если нет, то это реализация именно API libwayland, а не протокола.

Можно ли к этой «реализации» подключиться клиентом, не использующим libwayland?

Можно, если переключится на обычный сокетный транспорт. Это например используется с Waypipe. То есть можно в Haiku показывать окна Wayland приложений, запущенных в Линуксе на другом компьютере по сети.

Это эдакий Xwayland наоборот, но для Haiku, а не X11.

если переключится на обычный сокетный транспорт

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

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

сомневаюсь что подобное вообще возможно где-либо, воркспейс статичен, он всегда опеределенного номера, программы же динамически меняют WM_NAME, но при этом WM_CLASS остается один на все экземляры программы, так что определить какое окно из одинаковых вызвать в данный момент вм не способен, если конечно это не ванга-вм)

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

нет, он использует переменную WM_CLASS — xprop | grep WM_CLASS

Чтобы выбрать что нравится - надо сначала вообще узнать о том что оно существует и что может

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

Извините если утомил вопросами и обсуждениями своих хотелок.

я вас умоляю, мы тут один :)

Кто сервером wayland в таком случае будет? Кто слушает сокет?

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

. В Wayland’е картнка гораздо более плавная, а в иксах сплошной тиринг.

Так производительность страдает или тиринг появляется? Это разные вещи.

В иксах можно выставить этому RetroArch’у видеодрайвер xvideo, тогда тиринга становится меньше, но картинка при этом размытая.

В иксах можно выключить тиринг: Option "TearFree" "true"

Подтверждаю. На 4К с 2016 года.

У меня 4k появился в 2013, когда Wayland не мог вообще ничего. В иксах всё работало. Правда, тоже через задницу, потому что тайловый экран (не путать с WM, это когда физически один экран виден системой как два) приходилось собирать в один через особую магию в xorg.conf. Wayland кстати такие мониторы до сих пор не умеет, но, благо, они вышли из моды.

Грёбаный стыд.

Не понял.

У иксов проблема — тройная буферизация. Т.е. низкоуровневая деталь реализации, которая ни на что не влияет и никого, крому фанатиков и задротов не интересует. У вейланда проблема — он говно и не работает. Как видим, никто не совершенен.

Так производительность страдает или тиринг появляется? Это разные вещи.

Взаимосвязанные же. Картинка рвётся потому, что производительность страдает. 'Option «TearFree» «true»' не помогает совсем.

А в Wayland'е всё хорошо.

У вейланда проблема — он говно и не работает

Ну ЛПП же.

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

Прогрессом можешь не считать, твоё право. Но необоснованно бросаться словами вроде «говно» - говорит больше о тебе как о человеке.

я прогрессом это считать отказываюсь

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

Но необоснованно бросаться словами вроде «говно

Ах, извините. Забыл, мы живём в эпоху толерантости к снежинкам и виноват не то, кто наговнокодил, а тот, кто об этом сказал.

Прогресс закончился в 1990-х.

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

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

Вообще ни разу. Картинка рвётся, потому что вывод на экран происходит во время обновления буфера. Это отсутствие синхронизации и может происходить вообще на любых фреймрейтах, хоть 500fps.

Это какая-то безумная логика: мы не смогли придумать ничего лучше X11, поэтому будем продвигать нечто худшее, чем X11.

Справедливости ради, всё же некоторые именно «пользовательские» недостатки иксов всё же вроде как устранены. Например улучшена поддержка мониторов с высоким dpi. Игроманы еще «тиринг» упоминают. Наверно есть и что-то еще о чем я просто не знаю так как никаких особых требований к линуксовой графике не предъявляю. Не просто так же корпораты стали вейланд пропихивать. Хотя альтернативы иксам и до того предлагались.

Если драйвера хорошие, всё хорошо работает под обеими системами.

Вон выше люди говорили что на 4К мониторах у них картинка медленно рисуется. А согласно книгам, заметная глазом прорисовка интерфейса сильнее утомляет пользователя так как глаз(мозг) эволюционно настроен следить за движущимися объетами. Вот хорошая книга про разработку визуальных интерфейсов,она у меня в бумаге есть: https://www.ozon.ru/product/interfeys-chelovek-kompyuter-kouts-r-vleymink-i-652049923/ К тому же кроме высокопроизводительных компов бывают и менее производительные - потому что высокая производительность означает высокое энергопотребление,а это не всегда приемлимо. И надо чтобы картинка быстро рисовалась и там.

Прогрессом можешь не считать, твоё право. Но необоснованно бросаться словами вроде «говно» - говорит больше о тебе как о человеке.

Так он вполне обоснованно это делает. 17 лет пилить граф.систему – это какой-то позор. 17 лет – это время между Windows 3.11 и Windows 7.

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

Одна надежда, что придёт Габен и локомотивом вытащит вялянд из болота. Собственно, уже это и происходит, с КДЕшниками на подхвате.

Например улучшена поддержка мониторов с высоким dpi.

Было бы странно, если бы за столько лет вообще ничего не сделали. Однако если все те усилия по реализации и переводу всего на вэйланд, потратили бы на X11, у нас бы такая конфетка была … И документацию бы улучшили и код вылизали, но имеем что имеем.

Не просто так же корпораты стали вейланд пропихивать.

Я бы не стал вот так с порога отметать версию обыкновенного масонского заговора.

Я бы не стал вот так с порога отметать версию обыкновенного масонского заговора.

Там сложно. С одной стороны, Red Hat действительно подминают лялекс под себя и переписывают с нуля открытые компоненты, которые им не по нраву. Дескать, будет полностью открытый десктоп но под контролем Red Hat. С GNOME и GTK так вышло, например.

С другой, на лицо типичный CADT driven development и «давайте опять херачить с нуля ведь мы лучше знаем как надо».

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

На моей первой околоайтишной работе, первым же делом я затеял переписывание рабочего проекта на более правильном стеке технологий (т.е. на perl). Я был юн, неопытен и вокруг не было никого, чтобы вправить мне мозги. А эти-то чего?

перейти к стагнации

Только тем, кому достаточно 4 Гб RAM.

Задача сервера - объединить окна всех клиентов в единую картинку, как он это будет делать, если у каждого клиента свой «сервер»?

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

С «запускаемыми библиотеками» я экспериментировал очень давно(два десятка лет назад),причем на ADA и совсем не по «графическим» поводам. Результаты были обнадеживающие. Но вопросы взаимодействия между запущенной «библиотекой» и линкующимися к ней программами требуют дальнейшего изучения на предмет того что там работает,а что нет,и как именно этим пользоваться.

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

Сейчас кроме команднострочного отладчика gdb есть полноэкранный nemiver,так что заниматься подобными хакерскими извращениями будет существенно проще.

Придётся значительную часть кода сервера переносить в ядро.

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

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

7 лет пилить граф.систему

не 17 а 8, потому что 9 лет назад она уже была готова.

основная проблема Wayland лежит абсолютно не в технической плоскости

Да. И проблема эта называется - лучшее - враг хорошего.

Поясните свою мысль, пожалуйста.

9 лет назад она уже была готова.

Люди! Я пришельца из будущего поймал!

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

И чем это отличается от того что имеем сейчас? Кроме имени файла и того что ты напихал в один бинарник то что можно разложить по разным.

Но уж точно не через последовательный канал-сокет.

Почему? В чём твоя проблема с этим? У тебя есть предложения получше?

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

В чём преимущество этого подхода? Насколько он пригоден для двустороннего обмена информацией в формате 1 сервер, много клиентов? На мой дилетантский взгляд, плохо пригоден.

В 2016 году я использовал gnome на wayland на постоянной основе на работе и дома.

А я в 2003-м на Slackware 8.0 перешёл, как на основную рабочую систему.

Я бы не стал вот так с порога отметать версию обыкновенного масонского заговора.

Грёбаный стыд.

не 17 а 8, потому что 9 лет назад она уже была готова.

9 лет назад там нихрена не было готово. Не было захвата экрана, не было глобальных хоткеев (до сих пор нет лол), не было дробного масштабирования. Да много чего не было.

Да. И проблема эта называется - лучшее - враг хорошего.

Нет. Основная проблема – кривой изначально дизайн, который потом допиливали на ходу. Что, в общем-то, достаточно поразительно, потому что в 2008 году все требования к графической подсистеме давно были известны: примеров реализаций был вагон и их опыт можно было использовать. Но вместо этого было решено переизобретать велосипед и самостоятельно набивать все шишки.

В итоге на сегодня средняя реализация Wayland по сложности уже догоняет Xorg server и имеет не сильно меньше костылей.

В 2016 году я использовал gnome на wayland на постоянной основе на работе и дома.

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

На моей первой околоайтишной работе, первым же делом я затеял переписывание рабочего проекта на более правильном стеке технологий (т.е. на perl). Я был юн, неопытен и вокруг не было никого, чтобы вправить мне мозги. А эти-то чего?

У этих нет никого кто бы вправил им мозги. Серьёзно, сходи посмотри кто в основном в wayland protocol коммитит. Там юные дарования лет 20-25, многие в юбках и на искусственных гормонах.

9 лет назад там нихрена не было готово. Не было захвата экрана, не было глобальных хоткеев (до сих пор нет лол), не было дробного масштабирования. Да много чего не было.

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

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

Что значит «не успевает отрисовываться с нужной скоростью»? Меньше 1 fps, что ли?

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

Захват экрана в OBS/слаке не работал. Да и сейчас иногда криво работает. Глобальных хоткеев всё ещё нет. Декорации для всех окон (в gnome отказываются делать xdg-decorations или как его по религиозным причинам). Это уже давно не столько проблема Wayland, сколько ущербность самого GNOME.

И чем это отличается от того что имеем сейчас?

Я так думаю что если серверную и клиентскую часть будет «порождать» один бинарник то объявив для них какую-то общую область памяти (shared memory) будет проще «договариваться» об адресах в ней. В том смысле что адреса будут известных обоим частям такой конструкции,их не нужно будет передавать туда-сюда. Область памяти будет выглядеть как бы уже «размеченной»,причем одинаково и на сервере и на клиенте. Но чтобы понять насколько это упростит взаимодействие - требуются эксперименты.

Но уж точно не через последовательный канал-сокет.

есть предложения получше?

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

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

Глобальных хоткеев всё ещё нет

Будет в следующем релизе.

Захват экрана в OBS/слаке не работал.

Мне это было не нужно.

Мне ничего из этого не было нужно.

Это слабый аргумент. Мне тоже не нужно управление жестами и я никогда не видел живьем «тиринг». А кому-то это всё надо.

скриншотилка

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