LINUX.ORG.RU

Релиз Wayland 1.11

 ,


1

4

После трёх месяцев разработки представлен стабильный релиз протокола, механизма межпроцессного взаимодействия и библиотек Wayland 1.11, а также развиваемый параллельно композитный сервер Weston 1.11. Ветка 1.11 обратно совместима на уровне API и ABI с выпусками 1.x, но дополнительно содержит порцию улучшений, расширяющих возможности композитного сервера Weston. Следующий выпуск 1.12 запланирован на конец сентября.

В композитном сервере Weston развиваются технологии, содействующие появлению полноценной поддержки протокола Wayland в Enlightenment, GNOME, KDE и других пользовательских окружениях. Разработка Weston нацелена на предоставление высококачественной кодовой базы и рабочих примеров для использования Wayland в десктоп-окружениях и встраиваемых решениях, таких как платформы для автомобильных информационно-развлекательных систем, смартфонов, телевизоров и прочих потребительских устройств.

Основные новшества Weston 1.11:

  • В рамках инициативы по выносу функциональности Weston в обособленную библиотеку libweston проведена значительная переработка методов инициализации, загрузки и настройки бэкендов. Разбор файлов конфигурации пока по-прежнему производится в Weston main.c, но данные передаются динамически загружаемым модулям бэкендов в форме унифицированной структуры, состояние которой сохраняется в хранилище внутренних объектов для дальнейшего использования без привязки к main.c. Изменения внесены в бэкенды wayland, drm, x11, headless, fbdev и rdp.
  • В оболочке для информационно-развлекательных систем (IVI Shell) отмечена большая чистка кода, рефакторинг и приведение в порядок документации. Удалена или упрощена большая порция излишних вызовов API, система динамического выделения памяти переведена на использование стека по возможности, приведены в порядок проверки на указатель NULL, добавлена отладочная функция get_label().
  • Переработана система сборки, в которой стандартизировано использование макроса AC_SEARCH_LIBS, решены проблемы со сборкой без включения systemd-login, налажена обработка CFLAGS от systemd, в разряд опциональных зависимостей переведена поддержка JPEG (--with-jpeg/--without-jpeg) и WebP (--with-webp/--without-webp), упрощена логика проверки версии Wayland и Weston.
  • Добавлены новые пиктограммы для поставляемых в комплекте приложений terminal, flower и editor.
  • Реализована возможность настройки панельных часов через файл конфигурации.
  • Улучшена поддержка drag-and-drop.
  • Добавлена поддержка недавно стабилизированного протокола presentation-time.

Улучшения, связанные с протоколом и API Wayland 1.11:

  • Добавлен API Proxy wrapper, позволяющий избежать состояния гонки при работе многопоточных клиентов. API может использоваться для отправки непроксируемых запросов, что даёт возможность избежать ситуации, когда одна нить вызывает события, которые не успевают обработать другие нити.
  • Внесены улучшения в механизм разделяемой памяти (shm): добавлена защита от выполнения операций изменения размера при наличии ссылок на изменяемый блок памяти, обеспечен раздельный подсчёт внешних и внутренних пользователей, расширена информативность текста ошибок распределения памяти.
  • В рамках работы по улучшению поддержки перечисляемых типов в биндингах на различных языках добавлена поддержка межинтерфейсных атрибутов enum.
  • В документацию включены HTML-представления комментариев в коде, оформленных в формате Doxygen, что упрощает ссылки на функциональность клиентского и серверного API.
  • Добавлена сборочная опция --enable-fatal-warnings, приводящая к завершению процесса сборки в случае вывода компилятором предупреждений.
  • Для повышения безопасности в wayland-scanner задействован неисполняемый стек.

Дополнительно можно отметить выход набора расширений wayland-protocols 1.4, в прошлом году выделенный из основной кодовой базы в отдельный пакет. Wayland-protocols включает набор протоколов и расширений, дополняющих возможности базового протокола Wayland и предоставляющих возможности, необходимые для построения композитных серверов и пользовательских окружений. В новой версии представлен стабильный протокол "viewporter" (ранее "wl_scaler"), позволяющий клиенту выполнять действия по масштабированию и обрезанию краёв поверхности на стороне сервера. Статус стабильного протокола подразумевает завершённость разработки и обязательное обеспечение обратной совместимости. Ранее был стабилизован протокол "presentation time", предоставляющий возможности для организации отображения видео. Остальные протоколы имеют статус нестабильных:

  • "fullscreen-shell" - управление работой в полноэкранном режиме;
  • "input-method" - обработка методов ввода;
  • "linux-dmabuf" - совместное использование нескольких видеокарт при помощи технологии DMABuff;
  • "text-input" - организация ввода текста;
  • "pointer-gestures" - управление с сенсорных экранов;
  • "xdg-shell" - XDG-расширения для рабочего стола;
  • "relative pointer events" - относительные события указателей;
  • "pointer constraints" - ограничения указателей (блокировка);
  • "tablet" - поддержка ввода с планшетов.

Статус поддержки Wayland в окружениях рабочего стола и дистрибутивах:

  • В GNOME 3.20 поддержка Wayland приближена к паритету в функциональности с сеансом на базе X.org. Реализована большая порция мелочей и устранены многие недоработки, которые оставались последними звеньями, мешающими созданию готового для ежедневного использования окружения GNOME на базе Wayland. В частности, добавлены полная поддержка механизма drag-and-drop, уведомлений о запуске приложений, первичного основного буфера обмена (заработала вставка средней кнопкой мыши), решены проблемы с позиционированием диалоговых окон, меню и различных всплывающих элементов интерфейса приложений, до должного уровня доведено качество кинетической прокрутки.
  • Репозиторий Fedora Rawhide, на базе которого формируется релиз Fedora 24, изначально был переведён на использование по умолчанию рабочего стола GNOME поверх Wayland, но в итоге решение по использованию Wayland по умолчанию в Fedora 24 было отложено, так как не все проблемы удалось решить. Сеанс GNOME на базе Wayland в Fedora 24 будет доступен в качестве опции.
  • Экспериментальный сеанс рабочего стола GNOME на базе Wayland поставляется в Ubuntu GNOME (следует установить пакет gnome-session-wayland и выбрать на экране входа "GNOME on wayland").
  • Началось формирование ежедневных Live-сборок Neon Plasma Wayland, позволяющих оценить текущее состояние рабочего стола KDE Plasma в окружении на базе Wayland. Wayland задействован по умолчанию в платформе Plasma Mobile. В основной состав KDE Frameworks принята библиотека KWayland, в которую вынесен код Plasma, специфичный для поддержки Wayland. KWayland отнесён к фреймворкам первого уровня, т.е. является функциональным дополнением к Qt и, кроме Qt, не требует дополнительных зависимостей. При этом KWayland позиционируется не как замена QtWayland, а как дополнение к QtWayland, предоставляющее большую гибкость за счёт приближения программного интерфейса к Wayland API.
  • В KDE Plasma 5.6 продолжена адаптация KDE для работы с использованием протокола Wayland, появилась поддержка декорирования окон для Wayland-клиентов, позволяющая унифицировать оформление. Реализованы все доступные в окружениях на базе X11 средства управления вводом, добавлена поддержка различных раскладок клавиатуры и переключения между ними.
  • В пользовательском окружении Enlightenment 0.20 обеспечена полноценная поддержка Wayland. Работа поверх Wayland реализована с применением собственного композитного менеджера wl-desktop-shell. Отмечается, что все необходимые для работы поверх Wayland возможности реализованы, но окружение на базе Wayland пока недостаточно протестировано для ежедневного использования.
  • Для ОС DragonFly BSD подготовлен порт с Wayland и Weston. Обеспечена поддержка XWayland.
  • Wayland задействован по умолчанию в мобильных платформах Sailfish 2 и Tizen 3.
  • В панели Cairo-Dock реализована возможность работы в окружении композитного сервера Weston.
  • Работа по добавлению поддержки Wayland ведётся для рабочих столов LXQt и MATE.
  • Развиваются новые десктоп-окружения, работающие только на базе технологий Wayland: Quantum Shell, Hawaii и Orbital.
  • Для тестирования работы GNOME, KDE и Enlightenment, Hawai и Orbital поверх Wayland выпускается специальный Live-дистрибутив Rebecca Black Linux.
  • Отмечается прогресс в адаптации Firefox, Chrome и LibreOffice для работы поверх Wayland без привлечения прослойки XWayland. В Chrome 50 интегрированы наработки проекта ozone-wayland, в рамках которого развивался вариант веб-браузера Chromium, предназначенный для работы в окружениях на базе Wayland.
  • Firefox 46 перешёл на GTK+ 3 в Linux, что является важным звеном в реализации работы на системах, поддерживающих протокол Wayland.
  • В текстовом выпуске Qt 5.7 появился новый модуль Qt Wayland Compositor TP с реализацией многопоточной системы отрисовки для встраиваемых устройств, использующая протокол Wayland.
  • В проприетарном драйвере NVIDIA 364.x обеспечена официальная поддержка Wayland, включая все необходимые расширения: EGL, библиотеку libnvidia-egl-wayland.so и KMS API.

Напомним, что Wayland представляет собой протокол взаимодействия композитного сервера и работающих с ним приложений. Клиенты самостоятельно выполняют отрисовку своих окон в отдельном буфере, передавая информацию об обновлениях композитному серверу, который комбинирует содержимое буферов отдельных приложений для формирования итогового вывода с учётом возможных нюансов, таких, как перекрытие окон и прозрачность. Иными словами, композитный сервер не предоставляет API для отрисовки отдельных элементов, а оперирует только с уже сформированными окнами, что позволяет избавиться от двойной буферизации при использовании высокоуровневых библиотек, таких как GTK+ и Qt, берущих на себя работу по компоновке содержимого окон. В настоящее время поддержка прямой работы c Wayland уже реализована для библиотек GTK+ 3, Qt 5, SDL (начиная с выпуска 2.0.2), Clutter и EFL (Enlightenment Foundation Library). Начиная с версии 5.4, в состав библиотеки Qt включён модуль QtWayland с реализацией компонентов для работы Qt-приложений в окружении композитного сервера Weston, развиваемого проектом Wayland.

Взаимодействие с аппаратным обеспечением в Wayland/Weston, например, проведение инициализации, переключение видеорежимов и управление памятью (GEM для i915 и TTM для radeon и nouveau) графических карт, может производиться напрямую через модуль, работающий на уровне ядра, что позволяет обойтись без привилегий суперпользователя. Композитный сервер Weston может работать не только с использованием DRM-модуля ядра Linux, но и поверх X11, другого композитного сервера Wayland, фреймбуфера и RDP. Кроме того, развиваются проекты по обеспечению работы поверх графического стека платформы Android.

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

Для обеспечения выполнения обычных X11-приложений в окружении на базе Wayland используется DDX-компонент XWayland (Device-Dependent X), похожий по организации работы на Xwin и Xquartz для платформ Win32 и OS X. Поддержку запуска X11-приложений планируется встроить непосредственно в композитный сервер Weston, который при попытке выполнения X11-приложения будет инициировать запуск X-сервера и связанных с ним компонентов XWayland. При таком подходе процесс запуска X11-приложений будет бесшовным и неотличимым для пользователя от запуска приложений, работающих напрямую с Wayland.

Источник

>>> Подробности

★★★★

Проверено: Falcon-peregrinus ()
Последнее исправление: DeadEye (всего исправлений: 2)

Ответ на: комментарий от Shaman007

А что, задевает что кто-то без ошибок может накатать новость и тебе нечего будет прошляпить?

anonymous
()
Ответ на: комментарий от EXL

Почему шрифты в системе с иксами становятся говном, как их не настраивай?

Неосиляторы инфиналити всё по прежнему страдают? Кстати, на скрине шрифты ужасно жирные, я бы сказал - ШГ, если бы это не было вкусовщиной.

Дектопный линукс никогда не выберется за 0.91%

Ох уж эти мифы древних юниксоидов. 3.4% было, когда я последний раз на StatCounter залезал.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()

В Chrome 50 интегрированы наработки проекта ozone-wayland, в рамках которого развивался вариант веб-браузера Chromium, предназначенный для работы в окружениях на базе Wayland.

Глянул на установленный хром, вроде слинкован с libwayland-{client,server}, а запустить под weston не получилось — может, кто подскажет, какие переменные окружения/флаги для этого нужны?

Softwayer ★★
()

им реально кто то пользуется ? или это разработка на перспективу все еще ?

alwayslate ★★
()
Ответ на: комментарий от EXL

Где обработка кнопок по отжатию, а не нажатию?

Откуда вы это взяли? Запусти xev и посмотри что там приходит. События отпускания кнопок там есть. Зачем эти мантры бездумно копировать. Проблема была с переключением раскладок и она немного в другом...

Где поддержка адекватных современных HiDPI-устройств?

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

Почему постоянные проблемы с тирингом?

Проблемы возникли в 2005-2006-м году после появления компиза и композитного режима. Тогда сказали, что в композитном режиме исправить невозможно by design композитного режима. Неожиданно (во всяком случае для меня, до сих пор не понимаю как они это сделали), в 2011-м году проблемы с тирингом обошли как раз в композитном (!) режиме. Хотя там 2 тиринга, может это не тот исправили. После этого сломали VSync в обычном режиме... ХЗ, может опция в драйвере видеокарты сможет все решить, или ключ запуска сервера... Но в любом случае на моей памяти тиринга не было и в композитном режиме и в обычном режиме. Чтобы его одновременно не было еще ни разу не наблюдал, Типа DRI3/PRIME и т.д. это должны исправить, но пока не везде можно попробовать.

Почему шрифты в системе с иксами становятся говном, как их не настраивай?

Вопрос во freetype/fontconfig. Хотя отчасти они спихнули вопрос на сторону графического сервера (черные линии кажутся тоньше чем светлые при одинаковой толщине, ну и еще пара эффектов нелинейности восприятия яркости/цвета) проблему можно решить и без модификации отрисовки на стороне X-сервера. Ну и понятно что сейчас шрифты говно вовсе не из-за этих эффектов. Мое имхо, лучше растра для интерфейса ничего нет; в браузерах и офисах уже нужен вектор (в эти приложения его можно и целиком затащить и заново навелосипедить).

P.S. Вот ты программист вроде, знаешь Qt. Подумай как сделать qmmp под Wayland. Он там никогда не заработает без костылей (в перспективе ближайших пары лет точно не заработает). Хотя да, можно научить его работать под каким-нибудь конкретным KWayland, но в mutter половина функций отвалится. Можно настандартизировать два десятка расширений для wayland, но это почему-то никому не нужно... После этого сразу отпадут вопросы типа: «Говно Wayland, или будущее?»

anonymous
()

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

eR ★★★★★
()
Ответ на: комментарий от anonymous

3.4% было, когда я последний раз на StatCounter залезал.

Ври больше

Linux - 1.55%. Desktop OS market share according to StatCounter for April 2016

anonymous
()

Steam и игры под Wayland или под Mir будут работать?

duott ★★★★★
()

Недавно заводил Weston на генте. Все работает, очень плавно, без тиринга. Жду не дождусь биндингов в Хаскеле, чтобы сваять на них XMonad для Wayland.

s9gf4ult ★★
()
Ответ на: комментарий от anonymous

Подумай как сделать qmmp под Wayland. Он там никогда не заработает без костылей

Qt знаю весьма поверхностно, но почему не заработает, ведь Qt поддержит Wayland, следовательно все должно работать, или там помимо Qt юзается что то специфичное из xlib ?

После этого сразу отпадут вопросы типа: «Говно Wayland, или будущее?»

Мне кажется тут будет как с UNIXами разными, у каждого свой блэкджек и дамы, то есть свои иниты расчудесные, свои графические сервера и полтора инвалида в качестве не до конца соблюдаемых стандартов, плюс over9000 расширений у каждого, поддерживать которые голова распухнет у тех кто пишет кроссплатформенные приложения, либо библиотеки. Или я преувиличиваю ?

alwayslate ★★
()
Ответ на: комментарий от alwayslate

Qt поддержит Wayland, следовательно все должно работать

Ну давай подумаем... Вот есть у тебя иконка в трее. В Wayland трея нет, значит и проблем нет :) Есть трей во всяких gnome-shell, plasma-desktop и т.д. Стандартного пути почему-то нету. В X11 конечно тоже не фонтан, но хотя бы что-то. Есть в плеере плагин для глобальных горячих клавиш, в Wayland никаких глобавльных хоткеев не предусмотрено, каждый композитор велосипедит на свое усмотрение. Есть в плеере функция, когда окна тащаться друг за другом (эквалайзер и плейлист прилипают к основному окну), а потом еще и прилипают к краям экрана при близком приближении. В wayland не предусмотрено получении координат окна на экране, да и прилипающие друг к дружке окна вроде можно сделать (кажется с wayland 1.2), но в Qt такое API не предусмотрено... Это вот прям то что с ходу бросается в глаза.

Если задуматься о DE-специфичных штуках вроде панелей со списком открытых окон, клиентских декорациях, возможности подсунуть свой оконный менеджер, программах которые делают скриншоты и т.д. Становится понятно что Wayland категорически не подходит для создания полноценного десктопа. На всяких андроидах/tizen/jolla и прочих у него в принципе неплохие шансы, как только появится стабильность. Но нормальный десктоп он потянет только если каждое DE изобретет 100500 костылей для отсутсвующих в Wayland функциях. DE уже не захотели идти по пути унификации... так что программа снятия скриншотов из KDE в EFL не заработает. Ну и т.д.

anonymous
()

У меня с ним лагает только больше. Пойду дальше во фреймбуффере порно-картинки смотреть.

gnomosek
()
Ответ на: комментарий от EXL

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

В KDE декорации рисует композитор, в отличии от ГНОМА, где всё рисуется клиентом и да, будет адъ и израиль с заголовками. Поэтому CSD - это зло, и кедоразрабы правильно поступили, что юзают SSD. Не важно какое приложение и на чём написано. Заголовок будет выдаваться один и тот же

Sunderland93 ★★★★★
()
Ответ на: комментарий от anonymous

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

«переводчик неплохой, только ссыться и глухой»

anonymous
()
Ответ на: комментарий от unixnik

А я то думал его отдельно ставить надо. Сейчас зашел под ним, разницы не замечено.

Большинство программ работают через XWayland. У меня в сессии Wayland не отображаются некоторые значки в гномовском трэе.

vold ★★★★★
()
Ответ на: комментарий от anonymous

You are not logged into your account. Please login to continue.

Сам такой, даже нормальную ссылку дать не можешь. Ну где? В твоих фантазиях только.

statcounter

anonymous
()
Ответ на: комментарий от anonymous

В твоей Плазме они падают 3 или 4 раза в день, ты же не жалуешься?

anonymous
()

Зачем оно нужно? Я так понимаю надо для дипломной было?... эпично заменим userland что был в иксах запилим новое вместо того что-бы доделать старое. Мы можем, но лучше будем маргиналами, как вариант патчи выкидывали на мороз тк не достойны внимания. А все началось с того что пропиетарщина дала вам kms. Теперь вообще нигде нет вашей свободки.

anonymous
()
Ответ на: комментарий от anonymous

вместо того что-бы доделать старое.

Объясни мне, как грязные иксы, которые до Linux'а десятилетиями насиловали все проприетарщики, кому не лень (SGI->IRIX там с их патчами, и иже с ними), стали, внезапно, самой популярной оконной системой в GNU/Linux?

EXL ★★★★★
()
Ответ на: комментарий от anonymous

QQ

Хотя да, можно научить его работать под каким-нибудь конкретным KWayland, но в mutter половина функций отвалится. Можно настандартизировать два десятка расширений для wayland, но это почему-то никому не нужно...

А вот смотри, есть же QtWayland: https://doc-snapshots.qt.io/qt5-dev/qtwaylandcompositor-module.html на этой библиотеке основан KWayland: http://www.opennet.ru/opennews/art.shtml?num=44446 Я так понимаю, зависимость от QtWayland будет у Qt-only приложений, а от KWayland — у KDE-приложений. Или же этот QtWayland, это подобие Weston в том же Rebecca Black Linux, которое нафиг никому будет ненужно, кроме, допустим, Embedded?

Если в композитор QtWayland, будут добавлено то, что поможет работать QMMP так же, как и в иксах (прилипание окон, координаты окна на экране), то будет ли это означать, что в GNOME на Mutter этот QMMP будет работать так же, как в KDE? При условии, конечно, что Qt на GNOME полноценно развёрнут.

Или там QMMP подцепит Mutter, который разрушит привычное поведение окошек, ибо стандартизации нет?

EXL ★★★★★
()
Ответ на: комментарий от anonymous

Написано же - statcounter worldwide.

А откопать как ты любую фигню можно. Вот

PS: не спрашивай меня что это, не знаю. наверно статистика блога какого-то линуксоида. Посещают одноклассники арчешкольники - вот и получается.

anonymous
()
Ответ на: комментарий от alwayslate

то есть свои иниты расчудесные, свои графические сервера

Вот тебе евангелисты RH в мозг-то нас....
В конце 90-х не то, что иниты, даже пакетные менеджеры у солярки и, например, слаки, были похожи.

Shadow ★★★★★
()
Ответ на: QQ от EXL

Если в композитор QtWayland, будут добавлено то, что поможет работать QMMP так же, как и в иксах

Это понятно, что под QtWayland все будет как в X11, ну еще KDE-шники смогут обеспечить совместимость. Вопрос в другом - сможет ли тот же плеер работать полноценно под mutter/efl/инновационным тайловым композитором на haskell? На сегодняшний момент ответ «не сможет», поддержку каждого композитора нужно запилить явно (это почти как отдельная платформа, сейчас их уже минимум 4! EFL, Gnome/Mutter, KWin/Wayland и Weston). Можно сделать расширения протокола Wayland, но никто ими не занимается, а несовместимости все плодятся и плодятся...

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

Или же этот QtWayland, это подобие Weston в том же Rebecca Black Linux, которое нафиг никому будет ненужно, кроме, допустим, Embedded?

Не знаю что хотят от QtWayland, но скорее всего он слабоват для повседневного десктопа. KDE-шники вроде обеспечивают совместимость с ним, так что наверное лучше выбрать KWin для Wayland. Хотя, если из задач терминал и браузер... то можно взять и Weston и QtWayland.

anonymous
()
Ответ на: комментарий от anonymous

а несовместимости все плодятся и плодятся...

Ага, скоро нас ждёт Qt OS, KDE OS и GNOME OS. А Wayland будет толчком к этому.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

Но вот выясняется, что аудиоплееру уже не пофиг

Аудиоплееру и под иксами не пофиг (видео плееру - точно). Есть такой словесный стандарт ICCCM, который описывает поведение оконного менеджера и других X клиентов, если оконный менеджер не совместим, или ведет себя как-то не так, то клиент будет работать не корректно.

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

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

s9gf4ult ★★
()
Ответ на: комментарий от s9gf4ult

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

Там говорят не про совместимость саму по себе, а про отсутствие кросс-DEшного способа сделать некоторые вещи, например, обработку глобальных хоткеев.

Esper
()
Ответ на: QQ от EXL

в композитор QtWayland

Ну ты хоть матчасть осиль, задолбал своей тупостью. Композитор — это kwin/mutter. QtWayland — просто либа. Любой вэйланд композитор сможет рисовать окна программ, дергающих функции протокола wayland. Нет, блджад, все тупые, перейдут на вэйлант и все перестанет работать. Иди лучше на оксиджен подрочи, у тебя это лучше получается.

anonymous
()
Ответ на: комментарий от Shadow

В конце 90-х не то, что иниты, даже пакетные менеджеры у солярки и, например, слаки, были похожи.

Лолшто? Даже sysvinit от bsd init отличается, а уж про smf молчу.

anonymous
()
Ответ на: комментарий от Esper

хоткеев

Тебя не смущает, что подобным должен заниматься вообще libinput, а не wayland. И какие же там проблемы с libinput.

anonymous
()
Ответ на: комментарий от s9gf4ult

В Wayland нужно лишь привести протокол к общему знаменателю между различными DE/WM до той степени, до которой это возможно.

Именно! Сначала нужно подготовить адекватную замену существующей графической системе (не обязательно даже ограничиваться X11), а потом уже начинать закапывать. Прошло 6 лет, а проблемы все плодятся и плодятся. А решать их все не хотят и не хотят... Разрабов DE по сути оставили с полурабочей поделкой и сказали: «Ну вы там сами придумайте что вам еще надо и как-нибудь сами реализуйте.» Разрабы DE скооперироваться не захотели или не смогли. Стандарта который определит что нужно велосипедить, а на что можно рассчитывать нет. Поэтому DE-разработчики велосипедят по привычке все подряд. И потом гордо сообщают, что мол мы долго пилили и запилили переключение раскладки через DBus! Вместо того, чтобы реализовать более-менее совместимый механизм (пусть даже через тот же DBus, хрен бы с ним).

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

Да, я в курсе. Только разработчики Wayland такое не осилят... они переложили эту задачу на разработчиков DE и тулкитов, а разработчики DE и тулкитов между собой договариваться не спешат (и скорее всего не будут). Да и вообще у разрабов Wayland с проектированием систем не оче, а графическая система нуждается в хорошем проектировании. Ключевая идея отрисовки в Wayland безусловно хороша (то как должен работать композитный режим), но ее катастрофически недостаточно чтобы предоставить замену текущей графической системе Linux.

в Wayland все должно быть гораздо лучше с совместимостью программ между DE.

Генерация IPC из XML поможет избежать каких-то опечаток и механических ошибок. Но она никаким образом не поможет совместимости. Сейчас проблема в том, что этого самого XML нет... А уже вовсю клепают. А когда XML появится (если он вообще когда-то появится), то придется либо забить на его существование, либо переделать то что сделали.

anonymous
()
Ответ на: комментарий от s9gf4ult

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

shaiZaigh
()
Ответ на: комментарий от anonymous

подобным должен заниматься вообще libinput,

Нет, речь о «глобальных хоткеях». Приложение получает кнопки только если имеет фокус. А что делать если плеер свернут, сейчас активен Libreoffice Writer, но захотелось нажать Super+Down, чтобы перейти к следующему треку? Super+Down будет честно и «абсолютно защищенно» отделегирован во Writer и плеер ничего не увидит. Поэтому плеер должен как-то сообщить (скорее всего композитору), что «вот этот Super+Down нужно перенаправлять в плеер». В KDE для этого прикрутили DBus-интерфейс к KWin/Wayland. Естественно этот интерфейс не совместим с другими композиторами. Работать с этим интерфейсом сможет скорее всего khotkeys и еще пара KDE-специфичных приложений, а остальным наверное пофиг на велосипеды KDE, так же как и KDE пофиг на велосипеды гнома/EFL и прочих.

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

anonymous
()
Ответ на: комментарий от Esper

Можно же «перебрасывать» через D-Bus в фоновые программы не все клавиши, а лишь те, что являются определёнными сочетаниями, чтобы решить проблему с созданием keylogger'ов.

Не думаю, что эту проблему оставят без решения.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

Ключевая идея отрисовки в Wayland безусловно хороша (то как должен работать композитный режим)

ты сам понял что написал ? не занимается композитор никакой отрисовкой.

а разработчики DE и тулкитов между собой договариваться не спешат (и скорее всего не будут)

нахер им это надо - чтобы как с иксами плодить кучи похожего друг на друга дерьма но зато совместимого ? хоткеи, раскдалки, тайловые wm - на вот утрись

https://github.com/Cloudef/orbment

https://www.youtube.com/watch?v=nh_7aqNtrik

anonymous
()
Ответ на: комментарий от EXL

Можно же «перебрасывать» через D-Bus в фоновые программы не все клавиши, а лишь те, что являются определёнными сочетаниями

Можно, наверное. Мне так-то вообще пофиг, я в домике на mpd.

Не думаю, что эту проблему оставят без решения.

Ну, пока не разродились. А ведь с релиза уже не один год прошёл.

Esper
()
Ответ на: комментарий от Esper

Интересно, но ведь можно решить эту проблему вполне безопасно. Если композитор отвечает за хоткеи, то он может выдать пользователю окошко, что «Программа Х хочет назначить хоткеи, разрешить?». Этот механизм можно вполне сделать частью протокола. Возможно, все не так просто, на самом деле, ведь нужно еще как-то идентифицировать приложение X. А ещё в Wayland есть multiseat, то есть, несколько людей сидят в одной сессии (соответственно, несколько клавиатур и поинтеров), и не понятно, как должны обрабатываться глобальные хоткеи в таком окружении.

s9gf4ult ★★
()
Ответ на: комментарий от anonymous

Композитор — это kwin/mutter.

А KWayland тогда что такое? Либа для kwin_wayland? Чем отличается от QtWayland? И какие у всего этого аналоги в том же GNOME?

Спасибо.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

не занимается композитор никакой отрисовкой.

Здрасьте приехали... Вот запустил ты 3 программы и каждая нарисовала 3 текстуры. На экране надо показать как выглядит итоговый десктоп. Внутри текстур композитор не рисует, но из этих текстур он «композитит» (читай рисует) финальную картинку (как будет выглядеть твой рабочий стол).

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

anonymous
()
Ответ на: комментарий от anonymous

Внутри текстур композитор не рисует, но из этих текстур он «композитит» (читай рисует)

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.