У тебя всё равно нет возможности показать окно на каком то конкретном экране. Композитор решает на каком экране показать твоё окно.

«решает» или ему можно указать?

Ну тогда как мне сказать композитору, чтоб он показал моё окно на активном экране? Или, дай угадаю, «это уже не проблемы вяленого», и надо писать код специфичный для композитора, если такая функциональность в композиторе вообще предусмотрена? :)

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

У меня не было к нему никаких претензий если было бы так, но к сожалению нет. Что в этом протоколе делает обработка устройств ввода например?

Что в этом протоколе делает обработка устройств ввода например?

Нашёл до чего докопаться. Где ей ещё быть, если и активацией окон, и соответственно перенаправлением ввода (клаву только в активное окно, а mouse events и над неактивными окнами) занимается композитор. Вот если бы её (то бишь обработки устройств ввода) там (то бишь в протоколе) не было, вот тут подгорело бы уже у всех.

Или, дай угадаю, «это уже не проблемы вяленого», и надо писать код специфичный для композитора, если такая функциональность в композиторе вообще предусмотрена? :)

+1. Хотя и боян.

у каждого композитора будут свои расширения/реализации, соответственно, приложения будут по-разному (не)работать в разных DE?

кажись это уже наблюдается в Фаерфоксе и Гноме…

у каждого композитора будут свои расширения/реализации, соответственно, приложения будут по-разному (не)работать в разных DE?

Ну я склонен надеяться, что рано или поздно и это стандартизируют. Хз добавят ли в протокол или как-то вообще отдельно. А не стандартизируют – да и пох, будем выбирать из 1000 и 1 костыльных композиторов наиболее подходящий; и в итоге останется 2-3 стандартных де факто.

мрак

Аватарка, кстати, шикарная. =)

Где ей ещё быть, если и активацией окон, и соответственно перенаправлением ввода (клаву только в активное окно, а mouse events и над неактивными окнами) занимается композитор

Это только в Линуксе так через жопу сделано. Во всех других системах композитор занимается только композитингом окон и ничем больше. За ввод и управление окнами отвечает отдельный процесс (или модуль ядра win32k.sys в случае Windows).

thnx

Это только в Линуксе так через жопу сделано. Во всех других системах

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

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

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

Я хотел было написать «с оконным менеджером» вместо «с композитором», но потом подумал, что учитывая архитектуру вяленого, мне сложно представить, чтобы композитор и оконная система были в разных процессах.

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

всё равно связность между подсистемами получится очень сильная

Где она сильная? Композитор просто рисует буферы на экране и всё. Его можно запустить и без оконной системы, создавая руками поверхности. Или с другой оконной системой. Оконная система – тоже независимый компонент и она может работать без композитора. Например в Windows можно прибить композитор dwm.exe и будет графика без композитора.

Зачем до сих пор нужен wayland

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

Я кстати делаю композитор для Haiku. Там для композитора используется отдельный протокол и процесс. Всё управление окнами будет по прежнему осуществляться обычной GUI системой Haiku. Там подход ещё более модульный: программы могут выводить буферы не только в композитор, но и в другие программы с помощью симметричного интерфейса VideoConsumer, получая возможность делать сложные цепочки обработки буферов из нескольких процессов. Это может быть полезно например для онлайн стримов.

Где она сильная?

Отвечал уже: «Потому что, повторюсь (UPD: в третий раз), чтобы знать кому пересылать ввод, всё равно надо консультироваться с композитором.»

Лишний roundtrip, кстати. Если оконная система и системный обработчик ввода в разных процессах.

Композитор просто рисует буферы на экране и всё.

Например в Windows можно прибить композитор dwm.exe и будет графика без композитора.

Т.е. без рисования буферов на экране? Т.е. либо чёрный экран (а, нет, ты ж написал, что графика таки-будет, но без композитора), либо включится какой-то альтернативный механизм? Зачем в винде два механизма? Это считается не через жопу?

И кстати, зачем коду, который «просто рисует буферы на экране», отдельный процесс? Если используется opengl/vulkan/чтотамещё, на такой «композитор» остаётся две строчки; заголовки структур протокола больше место будут занимать, чем собственно логика, получающая от приложения буфер и тупо передающего его в gl-либу.

Хм… Ну типа авторитет готов признать, но всё равно непонятно. Я бы сделал либой. :)

P.S. Это не отменяет упоротости гномеров, которые блокируют некоторые полезные нововведения в том же wayland.

+1

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

в винде же такого нет, там все универсально

Э, нет. Там куда больше велосипедов.

Там подход ещё более модульный: программы могут выводить буферы не только в композитор, но и в другие программы с помощью симметричного интерфейса VideoConsumer, получая возможность делать сложные цепочки обработки буферов из нескольких процессов.

Это понятно, и вроде как не противоречит моему пассажу про «заголовки структур протокола больше место будут занимать, чем собственно логика».

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

А это – нет.

Отвечал уже: «Потому что, повторюсь (UPD: в третий раз), чтобы знать кому пересылать ввод, всё равно надо консультироваться с композитором.»

Ну нет же. Позицию размер окон хранит оконная система, а не композитор. Оконная система передаёт эту информацию композитору если нужно (окно видно и т.п.).

либо включится какой-то альтернативный механизм?

Да, включается альтернативный механизм без композитора, который там с времён Windows NT 4.

Если используется opengl/vulkan/чтотамещё, на такой «композитор» остаётся две строчки

Для того чтобы только проинициализировать Vulkan надо несколько экранов кода. Логика композитора не так проста как вам кажется. Там управление таймингами перерисовки, отрисовка только того, что поменялось, а не всего экрана, управления буферами, настройка видеорежима, обработка нескольких мониторов и много чего ещё.

Ты мне вот что скажи. Как окно посередине экрана в вялом показывать. Или снизу экрана, например, чтобы панельку отрисовывать. А то выходит что у кед свой велосипед на своём расширении протокола, у гнома свой, а что делать Васе, который пилит условный лаунчер/поисковик непонятно. Тянуть поддержку всех возможных расширений?

Ага, ну в таком разрезе ясно. Про InvalidateRect() и WM_PAINT помню. :) // Боже, как давно это было…

Позицию размер окон хранит оконная система, а не композитор.

Да блин, заговариваюсь. :)

Я бы сделал либой. :)

Может быть и либой. Оно у меня и так и так работать может. Для простоты тестирования всё работает в отдельных процессах, можно перезапускать компоненты по отдельности.

Если гномеры откусят, то не лечится.

Да вроде нету

> grep "WAYLAND" -r /var/db/ports
/var/db/ports/www_webkit2-gtk3/options:_FILE_COMPLETE_OPTIONS_LIST=DEBUG GEOIP GSTREAMER WAYLAND
/var/db/ports/www_webkit2-gtk3/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/graphics_mesa-libs/options:_FILE_COMPLETE_OPTIONS_LIST=WAYLAND ZSTD PLATFORM_X11 PLATFORM_WAYLAND
/var/db/ports/graphics_mesa-libs/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/graphics_mesa-libs/options:OPTIONS_FILE_UNSET+=PLATFORM_WAYLAND
/var/db/ports/x11_mate-panel/options:_FILE_COMPLETE_OPTIONS_LIST=DOCS WAYLAND X11
/var/db/ports/x11_mate-panel/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/graphics_vulkan-loader/options:_FILE_COMPLETE_OPTIONS_LIST=WAYLAND XCB XLIB
/var/db/ports/graphics_vulkan-loader/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/graphics_mesa-dri/options:_FILE_COMPLETE_OPTIONS_LIST=WAYLAND ZSTD PLATFORM_X11 PLATFORM_WAYLAND
/var/db/ports/graphics_mesa-dri/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/graphics_mesa-dri/options:OPTIONS_FILE_UNSET+=PLATFORM_WAYLAND
/var/db/ports/devel_sdl20/options:_FILE_COMPLETE_OPTIONS_LIST=ALSA ASM DLOPEN HIDAPI JACK NAS OSS PTHREADS PULSEAUDIO SAMPLERATE SDL_ATOMIC SDL_AUDIO SDL_CPUINFO SDL_EVENTS SDL_FILE SDL_HAPTIC SDL_JOYSTICK SDL_LOADSO SDL_POWER SDL_RENDER SDL_THREADS SDL_TIMERS SDL_VIDEO SNDIO UDEV VIDEO_KMSDRM VIDEO_OPENGL VIDEO_OPENGLES2 VIDEO_WAYLAND VIDEO_X11
/var/db/ports/devel_sdl20/options:OPTIONS_FILE_UNSET+=VIDEO_WAYLAND
/var/db/ports/multimedia_libva/options:_FILE_COMPLETE_OPTIONS_LIST=WAYLAND X11
/var/db/ports/multimedia_libva/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/multimedia_mpv/options:_FILE_COMPLETE_OPTIONS_LIST=ARCHIVE DOCS EXAMPLES LCMS2 LUAJIT MANPAGES MUJS TEST UCHARDET ZIMG CDIO DVDNAV LIBBLURAY V4L YTDL CACA OPENGL SIXEL VAAPI VDPAU VULKAN WAYLAND X11 ALSA JACK OPENAL PULSEAUDIO SDL
/var/db/ports/multimedia_mpv/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/multimedia_libxine/options:_FILE_COMPLETE_OPTIONS_LIST=AALIB ALSA AOM CACA DAV1D DMX_IMAGE DOCS DVB GNOMEVFS2 IPV6 JACK LIBBLURAY NFS NLS PIXBUF PULSEAUDIO SDL SFTP SMB SNDIO V4L VAAPI WAVPACK WAYLAND XVMC IMAGEMAGICK6 IMAGEMAGICK7 GNUTLS OPENSSL
/var/db/ports/multimedia_libxine/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/x11-toolkits_gtk40/options:_FILE_COMPLETE_OPTIONS_LIST=BROADWAY COLORD CUPS DEBUG FFMPEG GSTREAMER VULKAN WAYLAND X11
/var/db/ports/x11-toolkits_gtk40/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/multimedia_libva-utils/options:_FILE_COMPLETE_OPTIONS_LIST=WAYLAND X11
/var/db/ports/multimedia_libva-utils/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/multimedia_gstreamer1-vaapi/options:_FILE_COMPLETE_OPTIONS_LIST=DRM WAYLAND
/var/db/ports/multimedia_gstreamer1-vaapi/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/x11-toolkits_gtk30/options:_FILE_COMPLETE_OPTIONS_LIST=ATK_BRIDGE BROADWAY CLOUDPRINT COLORD CUPS DEBUG WAYLAND X11
/var/db/ports/x11-toolkits_gtk30/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/x11_libxkbcommon/options:_FILE_COMPLETE_OPTIONS_LIST=EVDEV WAYLAND X11
/var/db/ports/x11_libxkbcommon/options:OPTIONS_FILE_UNSET+=WAYLAND
/var/db/ports/graphics_gstreamer1-plugins-gl/options:_FILE_COMPLETE_OPTIONS_LIST=WAYLAND
/var/db/ports/graphics_gstreamer1-plugins-gl/options:OPTIONS_FILE_UNSET+=WAYLAND

насколько сложно иксовые приложения (точнее - библиотеки, например JUCE) портировать на Haiku?

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

Вот только сначала эти разработчики из X.Org, науськанные Intel и AMD, отстранили от разработки представителей Apple, FreeBSD и Solaris. А так да — процесс пошёл.

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

wlr-layer-shell. Поддерживается в KDE и композиторах на wlroots.

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

Бойкотировать GNOME.

Тянуть поддержку всех возможных расширений?

В худшем случае двух: wlr и GNOME.

Можно запустить через порт X.Org: https://discuss.haiku-os.org/t/x11-support-for-haiku/10502/46.

Починка тиринга так важна?

Разработка Wayland проходила под лозунгами «каждый кадр будет идеальным» и «каждый пиксель будет прорисован как должно и расположен где должно, и появляется, когда клиент того потребует», так что исправление этой нерешимой и извечной проблемы X.Org наверное и было стимулом для появления Wayland вообще.

Почему тогда с X.Org это работает?

Не работает. Mutter давно гвоздями прибит к GNOME, и хотя технически возможно запустить его под Plasma, работать это будет как попало.

XDG Shell оказывается недостаточно?

Я утверждал, что этого будет достаточно?

1. Это было ответом на другое утверждение, и я ясно отделил его от ответа на предыдущее.

2. Вы опять не ответили на мой вопрос.

Итого, вы в своем духе продолжаете заниматься демагогией. Вам не надоело?

Они дергают Qt и KDE API, которые больше не работают, например QCursor::pos, который возвращает нули если курсор не в окне приложения, или KWindowSystem, который вообще ничего не делает

KDE очень даже причём.

Нет, KDE ни при чем. QCursor::pos возвращает нули, потому что в Wayland нет абсолютных координат – есть только относительные для каждого окна.

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

Нет универсального API, потому что нет концепта «активного экрана». Концепта нет, потому что его не может быть в Wayland, это должно входить в XDG Shell или его расширения. Для wlroots свое API, что в KDE и GNOME – не знаю.

Это у всех фанатов Wayland проблемы с логикой?

Вы опять не ответили на мой вопрос.

В X11 оконный сервер и оконный менеджер работают в разных процессах и это описано в протоколе. Во всех имеющихся реализациях Wayland это работает в одном процессе и прибито гвоздями друг к другу. Если WM упало, то все приложения упадут вместе с ним и будет потеря данных. Это и есть монолитность. У X11 модульная архитектура в соответствии с философией UNIX и можно запускать X11 серверы, DE и WM в любых комбинациях если они соответствуют протоколу. Падение DE и WM не приводит к падению программ.

wl-copy

Завязан на GTK. Но таки да, от конкретного DE не зависит

IM_MODULE

не гуглится

Это у всех фанатов Wayland проблемы с логикой?

Вокруг все ***, один я Д’Артаньян.

В X11 оконный сервер и оконный менеджер работают в разных процессах и это описано в протоколе. Во всех имеющихся реализациях Wayland это работает в одном процессе и прибито гвоздями друг к другу. Если WM упало, то все приложения упадут вместе с ним и будет потеря данных. Это и есть монолитность. У X11 модульная архитектура в соответствии с философией UNIX и можно запускать X11 серверы, DE и WM в любых комбинациях если они соответствуют протоколу. Падение DE и WM не приводит к падению программ.

И… что? Как это относится к тому, что

«Создание API для DE – обязанность GUI протокола»?

Почему 1) это утверждение вообще истинно, 2) какое отношение к созданию API имеет навязываемая модульность?

1. это утверждение вообще истинно

Потому что DE (оболочка) – это такой же клиент GUI протокола как и всё остальное.

2. какое отношение к созданию API имеет навязываемая модульность?

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

нет абсолютных координат – есть только относительные для каждого окна

Нет универсального API

нет концепта «активного экрана

Концепта нет, потому что его не может быть в Wayland

«Полезных ископаемых нет. Воды нет. Растительности нет. Населена роботами.»

Зачем это Wayland тогда вообще нужен, если в нём ничего нет? Могли бы его оставить только как протокол композитора, а для оконной системы оставить X11

Вот только сначала эти разработчики из X.Org, науськанные Intel и AMD, отстранили от разработки представителей Apple, FreeBSD и Solaris. А так да — процесс пошёл.

Брёд. Solaris сегодня мёртв, разработчики FreeBSD не могут осилить не то что разрабатывать X.Org, а даже собственное DE сделать для FreeBSD: всё они тянут из Linux’а, в т. ч. и его форк X11 – X.Org.

А вот Apple, разрабатывает XQuartz каким-то одним своим программистом: https://github.com/freedesktop/xorg-xserver/commits?author=jeremyhu для каких-то совсем Legacy-проектов. По сути XQuartz даже в стандартную поставку macOS давно уже не входит, отдельно нужно скачивать и устанавливать.

В идеале в Linux должно быть так же со временем. Нужно запустить какое-то Legacy завязанное на X11? Ставим из репозитория XWayland и запускаем. Иксы, этот позор коммерческого мира UNIX, каким-то фигом оказавшийся в Linux со временем вырежут из Linux-дистрибутивов.

Если WM упало, то все приложения упадут вместе с ним и будет потеря данных

графические данные такие важные, каждый пиксель на вес золота :)

У X11 модульная архитектура в соответствии с философией UNIX и можно запускать X11 серверы, DE и WM в любых комбинациях если они соответствуют протоколу. Падение DE и WM не приводит к падению программ.

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

графические данные такие важные, каждый пиксель на вес золота :)

Там и неграфические данные зачастую теряются. Редактируешь текст в GUI редакторе, упал Wayland сервер и все изменения пропали.

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

Работает, сам проверял.

Редактируешь текст в GUI редакторе, упал Wayland сервер и все изменения пропали

толи дело икс-сервер - никогда не падает, да ?

Да, у меня ни разу не падал. А вот KWin может запросто упасть.

С тем же fcitx спрашиваешь его по dbus’у

"org.fcitx.Fcitx" "/inputmethod" "GetCurrentIM"

точно так же, как и в иксах.

Иксовых раскладок нехватает: они не умеют в CJK.

Зачем это Wayland тогда вообще нужен, если в нём ничего нет?

Добро пожаловать в Unix-way. Каждая компонента занимается своим делом.

а для оконной системы оставить X11

То есть, использовать X11 там, где он ущербен?

Добро пожаловать в Unix-way. Каждая компонента занимается своим делом.

(facepalm) Это поэтому туда запихивают оконный менеджер и оболочку?

То есть, использовать X11 там, где он ущербен?

Где ущербен? Ничего лучше X11 по управлению окнами в Линуксе нет. Wayland какой-то кастрированпый. Его как раз можно было бы задействоать для борьбы с тирингом, а всё остальное оставить как есть.