Wayland 1.21

А в сторону чего вы отдаете предпочтение, если одно устарело, другое недопилено, а третьего (кажется) не дано?

Для старой техники лучше использовать иксы, для новой – переход на Wayland вместе с дистрибутивами (Ubuntu, Debian, Fedora, RHEL/CentOS/OL, Arch Linux и пр.)

Тем временем (уже правда месяц прошел, но все же), в Debian/Ubuntu наконец-то влили патчи для QtWayland от KDE https://salsa.debian.org/qt-kde-team/qt/qtwayland/-/merge_requests/5#note_305550

Wayland в свое время придумали смешную штуку - кратное масштабирование. То есть вы не можете увеличить картинку из приложения в 1.5 раза. Можно только в 2, 3, и т.п. Чтобы не выглядеть идиотами перед пользователями с мониторами HDPI, популярные композиторы используют костыль. Приложение апскейлит картинку в 3 раза, композитор даунскейлит в 2. На выходе получается 1.5. Естественно все это жрет память, а результат выглядит это как замыленное гмо.

X отродясь считали все в DPI и с увлечением плотности пикселей мониторов все должно было становится только лучше. В Wayland все ровно наоборот.

Да, и теперь эту проблему пытаются решить https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/149 и https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/143

Это не страшно. Похожая проблема есть в GTK, начиная с gtk-3, когда они решили отказаться от X’овых DPI в пользу пикселей, приняв 96dpi за эталон (емнип буквально за полгода до того, как яббл выпустили свой первый HDPI телефон, задав новые модные тренды). Собственно поэтому в Ubuntu, где по умолчанию идёт Gnome, подвоха с Wayland особо ни кто и не заметил - там и так ШГ уже давно.

То есть, простое и удобное решение в целых числах есть уже лет 30 - вернуть все как было в X. Но похоже этим гениям принципиально изобрести что-то своё и они ещё долго будут там спорить придумывая разные волшебные константы.

X512 EXL ой

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

+1

Ничего удивительного, скоро не только GTK, но и Qt будет дропать поддержку X11 в каком-нибудь Qt 7 или Qt 8.

Но главное лишь бы QtWidgets они не дропнули с этим их агрессивным насаждением QtQuick/QML.

Wayland существует 14 лет. Очевидно что он уже устарел и нуждается в замене. Читал что будущее wayland композиторов использующих Vulkan туманно, и это безусловно один из признаков устаревания.

Какие сейчас есть перспективные кандидаты технологий будущего? Есть ли что либо изначально заточенное на работу с графикой через Vulkan например, с какими нибудь прорывными идеями не реализуемыми в рамках расширения протокола Wayland?

Табличка *сарказм* чуточку приподнята.

накину

Маттиас Класен (Matthias Clasen), лидер Fedora Desktop Team, участник GNOME Release Team и один из активных разработчиков GTK (подготовил 36.8% изменений в GTK 4), начал обсуждение возможности прекращения поддержки протокола X11 в следующей значительной ветке GTK5 и оставления возможности работы GTK в Linux только с использованием протокола Wayland.

Ни разу не удивлён. Гном и гтк хоронят иксы давно и последовательно. Но то когда ещё будет, он пока только обсуждение начал. А что выкинут - не сомневаюсь, и qt за ними последует.

Набор протоколов x11 это адское месиво из того что и так уже отсохло само исторически и того что используется частично и вовсе не так как замышлялось изначально. Понятно что это результат долгого пути «естественной» эволюции x11, в ходе которой растерялась логика и красота изначальной концепции, но поддерживать такое всё равно нелегко.

А вот что пишут в планах КДЕ на текущий год: https://pointieststick.com/2022/01/03/kde-roadmap-for-2022/

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

Отличный повод закопать GTK5. Впрочем и Gnome давно пора.

А когда разработчики Qt такую же инициативу опубликуют, тоже Qt и KDE будешь закапывать? Вместе с Linux Desktop’ом?

Сначала пускай опубликуют. Может к тому времени и вэйланд сам собой помрёт от старости.

Вот что пишут, например, разработчики KDE:

X has some serious issues and is rather old. The protocol is designed for the usecases three decades ago. Over the last years more and more functionality has been moved from X either into the kernel or into the compositors. The X server is more or less only a proxy between kernel, compositor and the X clients.

Today the compositor does everything the X server used to do. There are some remaining features not yet moved into the compositor (e.g. input handling) but those would make most sense in the compositor. The best situation would be to let the compositor directly work together with the kernel for rendering and input handling and manage the clients directly, which means to remove the Proxy. This is what Wayland is about. More reasons for Wayland in the FAQ.

In Plasma we need Wayland support as we are hitting the limitations of X all the time. Wayland will simplify our architecture and allow us to composite the screen in the way we consider as most useful.

https://community.kde.org/KWin/Wayland#Why_Plasma_needs_Wayland.3F

Так что вряд ли это случится.

https://gitlab.gnome.org/GNOME/gtk/-/issues/5004

однако здравствуйте

Почему-то я не удивлён.

Адекватные люди спокойно воспринимают критику, умеют из неё что-то подчеркнуть, а эти - наше мнение единственное верное, а ваще неверное и на этом закончим.

Да ну нафиг!?

Будьте терпеливы, не всем дано мыслить рационально. :)

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

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

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

Я мало видел тех людей, готовых убивать себя в 0 ради одной концепции, одного проекта. А те, у кого хватает сил на развитие чего-то одного - они занимаются многим, чтобы скучно не было. Вот и «распыляют силы и без того маленького сообщества». :)

Уже после слов «ну, тут вроде нормально, пожалуй… Пойду отдохну, может быть, через недельку доделаю…» стоит отнять от количества энтузиастов одного неосилившего энтузиаста. В результате «кучка» или группа заинтересованных превращается в «парочку» или в «пару». :)

Wayland был как один из примеров успешных проектов…

Был и будет.

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

успешных проектов…

Успешный, не успешный, а Wayland развивается в нужном направлении.

Успешный, не успешный, а Wayland развивается в нужном направлении.

Я об этом и говорю, что нужно много людей и тонна времени. Если бы их было больше, то они бы за 10 лет управились до вылизанного кода, где всё работает. Но кто-то мне говорил, что они в пятером(!) игру писали, типо 1 типлид, 2 прогера и 2 дизайнера. Но что они писали не сказали, может калькулятор соски нами.

Какие сейчас есть перспективные кандидаты технологий будущего?

Arcan

коммерческих организаций с их чёткими планами

О, прекрасные корпорации будущего. Дожить бы.

Ссылка на статью есть?

Firefox до сих пор не использует wayland по умолчанию. Без MOZ_ENABLE_WAYLAND=1 он запускается на xwayland.

Ссылка на статью есть?

The situation on Vulkan is more dire. The indefinite blocking behavior outright violates the Vulkan spec. Giving a timeout in AcquireImage does nothing in practice because the blocking is done in PresentQueue. Only two presentation modes on Wayland actually work: fifo (well this works by breaking the spec) and mailbox. Additionally, radv currently has 4 swapchain images for seemingly no actual reason which causes input lag. amdvlk apparently uses 2 somehow which admittedly doesn’t make sense to me. I would expect 3. This last one may get fixed soon since it’s simple enough, but it’s just an example of how far behind the implementation is.

https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html

X has some serious issues and is rather old. The protocol is designed for the usecases three decades ago

И иксов «три декады назад», а у вэйланда — 15 лет. Не такая уж и большая разница. Так что подождём немного и новое поколение пионеров начнёт закапывать древний вэйланд, а новое поколение старперов (добро пожаловать в клуб) ныть, что им всё портят.

почему разработчики Linux-дистрибутивов не скооперировались

Басню Эзопа про лебедя, рака и щуку знаешь? Там все ответьі на твой вопрос.