История изменений

Я бы возможно топил за wayland, если бы:

1. Был протокол индиректной отрисовки или хотя бы попытка его сделать
2. были бы модули драйверов наподобии xf86-video-*. Им не обязательно иметь архитектуру как в иксах, но они должны реализовывать аппаратно композитинг и отрисовку там, где это целесообразно. Возможно это должны быть модули render-intel, render-radeon, render-imx, render-vulkan, renger-glcore, render-gl1 и т.д. Композиторы с переключаемыми рендерерами есть, так что это вполне возможно. Тогда эта технология не будет уступать иксам, но очевидно, у таких модулей должен быть стандартный интерфейс между разными композиторами - чтобы не реализовывать везде всё заново. Этого нет.
3. была бы обязательной поддержка server-side декораций для floating комопзиторов, если композитор предполагает использование декораций. Разраб приложения, не заточенного под определённое DE, не должен грузить в свой процесс какой-то libdecor со всеми потрохами, его не волнует как и с какой темой рисуются декорации.

Сейчас wayland - проблема потому что:

1. Я не могу в opengl/vulkan приложении, которое не смогло создать контекст, вывести уведомление об этом пользователю. Нет, меня не интересует возможность загрузить какой-нибудь libcairo и рисовать им, меня интересует инструментарий который это сделать со стороны вашего дисплейного сервера, который как-то гарантированно рисуется
2. Нет возможности использовать аппаратное 2д ускорение там, где оно есть. Нет, гонять gl/vulkan растеризатор всегда менее эффективно. Особенно на энергоэффективных мобильных системах gpu не стоит загружать растеризацией 2д прямоугольников.
3. Моё приложение не будет выгляеть нативно в разных DE, потому что некоторые DE предполагают наличие декораций, а их композитор отказывается их рисовать. И нет, я не должен засорять address space своего процесса всякими libdecor с с зависимостями, моему процессу и так есть чем заняться.

Я бы возможно топил за wayland, если бы:

1. Был протокол индиректной отрисовки или хотя бы попытка его сделать
2. были бы модули драйверов наподобии xf86-video-*. Им не обязательно иметь архитектуру как в иксах, но они должны реализовывать аппаратно композитинг и отрисовку там, где это целесообразно. Возможно это должны быть модули render-intel, render-radeon, render-imx, render-vulkan, renger-glcore, render-gl1 и т.д. Композиторы с переключаемыми рендерерами есть, так что это вполне возможно. Тогда эта технология не будет уступать иксам, но очевидно, у таких модулей должен быть стандартный интерфейс между разными композиторами - чтобы не реализовывать везде всё заново. Этого нет.
3. была бы обязательной поддержка server-side декораций для floating комопзиторов, если композитор предполагает использование декораций. Разраб приложения не заточенного под определённое DE не должен грузить в свой процесс какой-то libdecor со всеми потрохами, его не волнует как и с какой темой рисуются декорации.

Сейчас wayland - проблема потому что:

1. Я не могу в opengl/vulkan приложении, которое не смогло создать контекст, вывести уведомление об этом пользователю. Нет, меня не интересует возможность загрузить какой-нибудь libcairo и рисовать им, меня интересует инструментарий который это сделать со стороны вашего дисплейного сервера, который как-то гарантированно рисуется
2. Нет возможности использовать аппаратное 2д ускорение там, где оно есть. Нет, гонять gl/vulkan растеризатор всегда менее эффективно. Особенно на энергоэффективных мобильных системах gpu не стоит загружать растеризацией 2д прямоугольников.
3. Моё приложение не будет выгляеть нативно в разных DE, потому что некоторые DE предполагают наличие декораций, а их композитор отказывается их рисовать. И нет, я не должен засорять address space своего процесса всякими libdecor с с зависимостями, моему процессу и так есть чем заняться.

Я бы возможно топил за wayland, если бы:

1. Был протокол индиректной отрисовки или хотя бы попытка его сделать
2. были бы модули драйверов наподобии xf86-video-*. Им не обязательно иметь архитектуру как в иксах, но они должны реализовывать аппаратно композитинг и отрисовку там, где это целесообразно. Возможно это должны быть модули render-intel, render-radeon, render-imx, render-vulkan, renger-glcore, render-gl1 и т.д. Композиторы с переключаемыми рендерерами есть, так что это вполне возможно. Тогда эта технология не будет уступать иксам, но очевидно, у таких модулей должен быть стандартный интерфейс между разными композиторами - чтобы не реализовывать везде всё заново. Этого нет.
3. была бы обязательной поддержка server-side декораций для floating комопзиторов, если композитор предполагает использование декораций. Разраб приложения не заточенного под определённое DE не должен грузить в свой процесс какой-то libdecor со всеми потрохами, его не волнует как и с какой темой рисуются декорации. Сейчас wayland - проблема потому что:
4. Я не могу в opengl/vulkan приложении, которое не смогло создать контекст, вывести уведомление об этом пользователю. Нет, меня не интересует возможность загрузить какой-нибудь libcairo и рисовать им, меня интересует инструментарий который это сделать со стороны вашего дисплейного сервера, который как-то гарантированно рисуется
5. Нет возможности использовать аппаратное 2д ускорение там, где оно есть. Нет, гонять gl/vulkan растеризатор всегда менее эффективно. Особенно на энергоэффективных мобильных системах gpu не стоит загружать растеризацией 2д прямоугольников.
6. Моё приложение не будет выгляеть нативно в разных DE, потому что некоторые DE предполагают наличие декораций, а их композитор отказывается их рисовать. И нет, я не должен засорять address space своего процесса всякими libdecor с с зависимостями, моему процессу и так есть чем заняться.