LINUX.ORG.RU
ФорумTalks

про wayland на android

 , ,


7

2

Я просто решил оставить тут несколько фактов о принципах работы wayland и их применимости на android.

И прежде всего я обращаю внимание на тот факт, что ровно две конторы решили сделать мобильные ОС поверх драйверов android: Canonical и Mozilla. Обе перед этим разрабатывали софт под андроид, ubuntu for android и firefox for android соответственно. В ходе разработки они столкнулись с одними и теми же проблемами и интересными решениями от команды разработчиков из Google. Разумность этих решений и побудила их к тому, что они делают.

Часть I, или wayland — не дисплейный сервер

Wayland — название протокола, описанного в XML файле. Из файла генерируется документация к протоколу и код на C, позволяющий общаться посредством этого протокола (libwayland). Если кто-то из разработчиков вейланда говорит вам, что «в вейланде явно не специфицируется то-то и то-то», его слова следует просто игнорировать: протокол-то не специфицирует, но реализация у него была и есть одна — weston — а он как раз специфицирует многие вещи; кроме того, попробуйте-ка заставить авторов тулкитов и mesa вот так взять и добавить поддержку особенностей альтернативной реализации протокола wayland (а таковой в будущем мог бы стать даже mir). С вас шкуру спустят, за то что опять фрагментируете бедное комьюнити своими забагованными альтернативными реализациями.

Часть II, pixmap <-> texture

На многих устройствах с android стоит относительно слабый процессор, и даже его мощность следует максимально беречь из-за батарейки (например, один из смартфонов самсунга имеет два ядра на 1,3 и 1,9 ГГц, но в нормальном режиме работает только слабое ядро), ОЗУ надо беречь из-за батарейки. Также на устройствах есть интеграшка вместо видеокарты и большой экран (у Samsung S3 он больше, чем у iPad без ретины). Увеличение размера экрана в n раз увеличивает число пикселей в n² раз. Как мы все уже знаем, современные тулкиты рисуют готовую картинку и отправляют её серверу, но делать это можно четырьмя способами

  1. Выделять места в памяти, рисовать там картинки, отправлять серверу. Это всегда даёт оверхед на ОЗУ, даёт оверхед на передачу данных по шине для дискретных видеокарт и оверхед на копирование памяти для интеграшек. OpenGL использовать нельзя, аппаратного ускорения нет. В начале своего пути Wayland умел только так.
  2. Выделять OpenGL framebuffer, рисовать туда командами OpenGL, забирать оттуда пиксели с помощью glReadPixels, а потом способ №1; про его оверхед уже сказано. Хотите я вас обрадую? У драйверов android есть баги, например, на видеокартах Qualcomm иногда пиксели из фреймбуфера читаются некорректно, потому что они оптимизировали вывод графики и потребление ресурсов с помощью тайлинга (разбиения фреймбуфера на квадраты 16x16, которые обрабатываются отдельно) и теперь не гарантируют, что весь фреймбуфер целиком может быть нормально разобран на пиксели. Отдельные баги, может быть, исправлены в android 4.2, но кто исправит их в android 4.1, на котором и основан cyanogen mode? Конкретные проблемы и сопутствующий оверхед можно пофиксить путём использования способа №4.
  3. Выделять OpenGL framebuffer, рисовать туда командами OpenGL, отдавать дисплейному серверу. Используется в weston и mir. Кстати, в обоих случаях используется библиотека EGL, которая выступает связующим звеном между объектами OpenGL/OpenGLES/OpenVG и знакомыми всем программистам понятиями из мира программной отрисовки, такими как pixmap, surface, и так далее. В обоих случаях надо попросить weston или mir создать окно, потом попросить libEGL о создании EGLSurface из полученного окна, а дальше уже средствами чистого EGL создать контекст OpenGL и другие ништяки. Недостаток — невозможность использовать частично программную отрисовку, всё только через GPU.
  4. В реальных устройствах на андроиде все карты — интеграшки, и выделенной памяти у них нет. Просим у драйвера видеокарты область оперативной памяти в виде EGLImage (у EGL для android есть такое нестандартное расширение), связываем его с текстурой либо фреймбуфером, рисуем в картинку софтварно и/или через OpenGL и используем дальше как текстуру. Это — идеал, именно он используется внутри андроида, но недоступен прямо через NDK или java: [1], [2], [3]. Нулевой оверхед на копирование, нулевой оверхед на ОЗУ. Поддерживают ли этот способ тулкиты на вейланде? Поддерживает ли его Weston? Зато есть заявления о работоспособности Weston под android и непонимание, зачем нужен Mir.

Впрочем, замечу, что Jolla пытается накостылить поддержку способа №4 в Weston [4].

Часть III, server allocated buffers

Wayland нам абсолютно неинтересен. Смотреть надо на Weston, и он действует так: клиент просит у видеодрайвера буфер, рисует в него что-то, а затем передаёт этот буфер и время, когда он был отрисован, для Weston через протокол Wayland с просьбой нарисовать. В Mir сделано иначе: клиент просит у Mir буфер, затем пишет в него что-то, затем просит другой буфер и одновременно передаёт имеющийся буфер для отображения на экране. Клиент работает через библиотеку mir-toolkit и не зависит от того, какие именно данные идут от него по сокету.

Преимущество подхода mir в том, что mir может воровать буферы у неактивных приложений и тем самым давать огромную экономию памяти [5]. Именно так сейчас поступает android, и, насколько известно, ios [6] [7].

Часть IV, ввод

Акселерометры, множественные касания, виртуальная клавиатура и аппаратная клавиатура, геймпады, датчики роботов — всё это уже сейчас работает в android. Mir просто взял эту часть гугловского surface flinger и перенёс к себе, отделив его от остального кода и подключив boost, добавил трансляцию в API Mir. Трансляция прямая, например, тип события мыши или касания напрямую кастуется в соответствующий enum из библиотеки mir-toolkit, и дальше передаётся клиенту (и тут же поправлюсь: 4 июля 2013 года кастования типа убрали для ещё большей совместимости с android, потому что иногда приходящее от Surface Flinger значение не укладывается в enum). Как результат, Mir поддерживает абсолютно все фичи ввода, доступные андроиду.

Тем временем в Weston всё ещё продумывают каждую мелкую деталь событий ввода в протоколе wayland. Это прекрасная работа и отличный задел на будущее, но полноценной обработки ввода на weston под android не будет в ближайшие 5-10 лет. Но тут есть выход: если в дисплейный сервер Mir будет добавлена поддержка протокола wayland, то он сможет транслировать события ввода андроида в протокол wayland и потребует для этого гораздо меньше отладки, чем Weston, потому что код mir уже покрыт тестами и может хостить Qt-шные приложения для андроида неотличимо от Surface Flinger.

Часть V, client-side decorations

Каждый тулкит рисует client-side decorations по-своему. Ниже будет список нюансов CSD, для которых должна быть поддержка со стороны каждого из тулкитов — и это очень грустная ситуация, потому что число тулкитов, способных написать и отладить весь этот код со всеми нюансами, резко сокращается. Уже сейчас только Qt5, gtk3 и EFL более-менее поддерживают последние решения вейланда. Итак, нюансы:

  • Wayland не заставляет использовать клиент-серверные декорации, но мы уже знаем, что надо смотреть на Weston. Weston в общем и в целом заставляет, если не считать инициативу мейнтейнера kwin.
  • Для тайлинга, полноэкранных окон и окон на пол-экрана CSD надо частично отключить. Wayland в лице его основателя предлагает [8] давать окнам подсказки, какие именно стороны окна должны быть без декораций. Кстати, именно так kwin может добиться серверных декораций — просто отключив CSD для всех четырёх сторон окна. На андроиде CSD не нужны, как и на любых устройствах с маленьким физическим размером экрана.
  • Заголовок окна не рисуется для развёрнутых на весь экран окон в Unity, KDE Plasma Netbook [9] и, насколько я знаю, в GNOME. Wayland никак об этом не сообщает, но можно использовать тот же механизм, что для глобального меню.
  • Порт Qt на wayland получает оверхед из-за CSD, и поэтому в Qt оставлен флаг для отключения CSD. Скорее всего, у других тулкитов будут те же трудности. Тем более CSD создают очевидный оверхед по оперативной памяти из-за того, что каждое приложение само собирает и хранит в памяти копию всей графики (растровой или векторной), необходимой для декораций.

Напоследок процитирую слова Мартина Грэсслина:

Is this fear valid? Well during said presentation Weston was running with two windows. They had different decorations. One was the terminal with minimize, maximize and close button on the right. One was a pdf viewer with a standard GNOME Shell decoration: minimize button missing. And during FOSDEM I had also a look on the decorations for Qt Wayland: again different decorations.

GNOME уже не раз убирал из своих приложений и из GTK фичи, непосредственно нужные другим DE. Например, автора Transmission попросили выкинуть что-то из уведомлений [10], причём багу присвоен тип «Улучшение» ☺. Дальше диалог развивался так:

Removing it altogether, as you suggest, will hurt XFCE users. I wish GNOME, Canonical, and everyone else involved would settle on one consistent API for this and stop fucking the app developers over.

Ответ:

I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.

Никогда у вас не будет нормальных клиентских декораций в официальном GTK 3. Забудьте об этом. Могут помочь те, кто патчит GTK в своём дистрибутиве — но пока конкретно этот тулкит более-менее патчит только Canonical.

но пока конкретно этот тулкит более-менее патчит только Canonical.

и только Марк всех нас спасет?

derlafff ★★★★★ ()
Последнее исправление: derlafff (всего исправлений: 2)

Какой то get the facts - mir хорошо, wayland говно.

andreyu ★★★★★ ()

Firefox OS разве ведроидовские драйверы использует?

Quasar ★★★★★ ()

Классно пишешь, я прямо зачитался. Сам хочу когда-нибудь перейти на вейленд на всяких embedded-железках. Только не будет ли у меня проблем со старыми ядрами?

CYB3R ★★★★★ ()

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

CYB3R ★★★★★ ()

android 4.1, на котором и основан cyanogen mode

4.2

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

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

Т.е ситуация та же как и «gnome не торт мы будет пилить unity».

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

Mir использует Wayland. Может ты имел в виду Weston?

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

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

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

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

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

Возвращалось, но только в неупоротые проекты. Гном да, в их число не входит.

OperaSoftvvare ★★ ()
Последнее исправление: OperaSoftvvare (всего исправлений: 2)
Ответ на: комментарий от init_6

Вы совершенно правы. Но со временем, может, ситуация изменится к лучшему. Может, и у canonical получится что-то хорошее.Не зря же их разработчики получают свою зарплату.

lucentcode ★★★★★ ()

Многабукв! И много шума об этом wayland'е, а результата не видно.

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

Здрасти. Апстрим сам принимать не хочет. А Canonical лишь пожимает плечами, ибо те же гномеры упороты до кончиков волос.

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

Здрасти. Апстрим сам принимать не хочет. А Canonical лишь пожимает плечами, ибо те же гномеры упороты до кончиков волос.

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

Так вот такое, в апстрим понятное дело не пойдет. И так понятно, что это убунту-онли поделки.

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

А от каноникалского upstart'a у RH бомбануло так, что всех systemd забрызгали.

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

Так вот такое, в апстрим понятное дело не пойдет.

В апстрим не идет, потому что апстрим это «идея ради идеи», на юзеров насрать.

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

У арчеводов получилось портировать. Другое дело, что почему-то замашки RH с его пульсой и systemd воспринимаются нормально, хот я они вообще linux-only.

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

Сам хочу когда-нибудь перейти на вейленд на всяких embedded-железках.

Зачем? Чем тебя рисование во фреймбуфер не устраивает?

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

на юзеров насрать

Это ты про тестирование пользователями 13.10 нового Mir?

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

Вот сейчас сижу и рисую во фреймбуффер. Устраивает. Но хочется чего-нибудь вяленого.

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

Лишняя прослойка между приложением и железом - нет, не нужно

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

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

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

А я юзаю DirectFB. Тоже лишняя прослойка, но очень удобная.

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

Насколько я помню, изначально mir создавался как альтернатива weston. то, что он пока недопилен и юзает иксы - вполне нормальное явление.

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

А что не так? Они никога не скрывали и всегда говорили, что не lts выпуски — это полигон для впиливания новых технологий.

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

А на деле фрагментацию, велосипеды и раздор творят вообще все, и когда каноникал в этом обвиняют — это обычное лицемерие.

Я не знаю насчет «всех» которые творят «раздор» но убунта почему то появляется в списке «творящих раздор» чаще остальных. Как примеры "globalmenu vs appmenu", "gnome-shell vs unity" а теперь вот и "wayland vs mir«… И в первых двух случаях форки убунты ничем не помогли всем остальным. А в последнем я не демаю чтобы mir как то положительно скажется на wayland.

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

Они никога не скрывали и всегда говорили, что не lts выпуски — это полигон для впиливания новых технологий.

Они никога не скрывали и всегда говорили

Ну ты, конечно же, поделишься пруфами.

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

globalmenu

сдохло, appmenu живо (пачти приняты в qt)

gnome-shell

сдыхает, unity живее всех живых

а теперь вот и «wayland

думаю понятно что с ним будет.

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

А я не вижу примеров того что оно «сдохло» зато вижу что поделия убунты живут только в убунте и дальше неё никуда не расползаются.

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

А я не вижу примеров того что оно «сдохло» зато вижу что поделия убунты живут только в убунте и дальше неё никуда не расползаются

Что еще раз доказывает упоротость апстрима и RH

OperaSoftvvare ★★ ()

первый раз в своей жизни я пишу это...

КАК МНОГО БУКАФФФ....

nerfur ★★★ ()

Прочитал на одном дыхании. Очень интересно, спасибо! Интересно, чем закончится противостояние Wayland vs Mir. Скорее бы тесты производительности.

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

Интересно, чем закончится противостояние Wayland vs Mir.

Что первый, что второй, сольют ванильным иксам.

Но придут главный Бубунтоид и RedHat и скажут, что на приборе они крутили пользователей, а для бабла так надо.

devl547 ★★★★★ ()
Последнее исправление: devl547 (всего исправлений: 2)

Спасибо за статью. Заинтересовало. Аж открыл (еще раз) спеки и прочие доки на «почитать».

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

Mir использует Wayland. Может ты имел в виду Weston?

Мне казалось, что Wayland - это протокол, а Weston - это оконный менеджер.

andreyu ★★★★★ ()

там в продолжении совсем лол от гномодевелопера:

I have never used it with the status icon myself.

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

Мне казалось, что Wayland - это протокол, а Weston - это оконный менеджер.

Со слов основателя обоих проектов, Weston — это и есть дисплейный сервер + оконный композитор + оконный менеджер.

Статья получилась немного похожей на get the facts, потому что речь об андроиде и мобильных устройствах, а для них weston не приспособлен. Хуже того, пока в weston и wayland переосмысливали десктопные парадигмы, Google уже ускакал вперёд с оптимизациями под реалии ARM.

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

Лишняя прослойка между приложением и железом - нет, не нужно

Ещё один фанат ассямблера?

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

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

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

quiet_readonly> Мультитач в иксах от каноникал.

Каноникал закоммитил в иксы поддержку мультитача и multipointer? Что-то не видел такого. Зато про utouch знаю, который нафиг никому не сдался и на жестах кончается.

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

А почему от OpenRC не бомабануло, который в разы круче апстарта?

Quasar ★★★★★ ()

Толсто.

Псевдоанализ шел ровно, пока не наступила внезапная концовка — фарш из субъективных выкладок.

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

OperaSoftvvare> Они никога не скрывали и всегда говорили, что не lts выпуски — это полигон для впиливания новых технологий.

Ложь.

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

То есть, шаттлврот предлагает пользоваться заведомо глючной и тестовой системой как основной? Круто, чо.

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

У каждой железки есть вендорный API для аппаратно-ускоренной графики

Внезапно, никому на..й не нужны «вендорные API для аппаратно-ускоренной графики». Пример CUDA и OpenCL как бы демонстрирует, что получается в этом случае (а получается говно), когда каждая программа должна фактически писаться столько раз, сколько «вендорных API» существует. Поэтому в нормальную систему всегда добавляется дополнительный уровень, полностью изолирующий приложение от железа, и бакэнд для этого уровня, реализующий некий набор операций (драйвер). И завязываться на «вендорный API» означает завязываться на конкретное оборудование, чем страдают ассямблерщеги (и от чего они практически вымерли).

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