Просвятите про wayland

Когда это приложения начали писать под конкретный оконный менеджер?

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

Насколько я понимаю, к приложениям главное требование одно: не дёргать xlib или xcb напрямую. А всем остальным занимаются тулкиты.

Приложения пишутся используя протокол. Собственно wayland и есть протокол + сейчас ещё расширения протокола. Разные композитные менеджеры должны соответствовать протоколу, как и приложения, и тогда всё ок. В противном случае не нужно было бы вообще париться с wayland, какие-нибудь гномовцы бы взяли и всё бы сделали на своём сlutter прямо поверх sdl, поверх фреймбуфера, но только gtk приложения бы и работали:)

Композитный менеджер нужен, он даёт поверхности. Если хочется без него, используй Qt или Gtk просто поверх фреймбуфера.

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

Да, если совсем на нижнем уровне пишешь, всё почти также как в xlib и xcb, но просто уровень так сказать по ниже.

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

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

Вот простейший пример https://hdante.wordpress.com/2014/07/08/the-hello-wayland-tutorial/

то на каком уровне работают wm, они обращаются напрямую к вяленому

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

Просвятите про wayland

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

Композитор и клиенты общаются по сокету с помощью библиотеки libwayland, у которой есть такие основные примитивы как wl_surface, wl_shm_pool, wl_buffer. У каждой wl_surface может быть только одна роль - в рамках основного протокола доступны роли wl_shell_surface (окно) и wl_subsurface (подповерхность). При подключении клиент у композитора запрашивает различные глобальные объекты, далее создает wl_surface c ролью wl_shell_surface, к которой он может прикрепить wl_buffer и создать иерархию подповерхностей. Сами буферы (пиксели) хранятся в shm файлах, обернутых в wl_shm_pool, которое уже клиент делит на wl_buffer необходимого размера и формата (argb8888, rgb565 и т.п.). Клиент может создать несколько очередей событий, связав с ними необходимые ему примитивы. Композитору остается только отрисовывать всё это во фреймбуфере. Реализаций библиотеки libwayland может быть несколько, самое главное - следовать спецификации протокола, который един.