В преддверии выхода Ubuntu 17.10, в которой по умолчанию используется Wayland, поговорим об этом протоколе для организации графического сервера в Linux и других UNIX-подобных операционных системах. А также разберём, зачем Wayland пришёл на замену Xorg.
Графическая система Linux оставалась в своей сути неизменной с 1993 года. Xorg (до 2004 года он назывался XFree86) — это та реализация графической системы, которая лучше всего соответствует инженерной направленности Linux. Она построена по архитектуре «клиент-сервер», может отрисовывать окна на удалённых машинах, её функциональность легко нарастить расширениями.
Но такой подход заложил и слабые места, которые ярко проявились в наше время многоядерных вычислений, сложной графики и множества устройств ввода. Сейчас Xorg — это рядовая программа, через которую проходит вся графика и данные от клавиатур, мышей, джойстиков, тачпадов, и т. д. Существование такой монолитной прослойки порождает уйму проблем:
Как с этим бороться?
Были попытки создать X12 (нынешняя реализация Xorg обозначается как X11), но скоро разработчики Xorg поняли, что проще всё выкинуть и сделать с нуля, заложив современные возможности в самую основу протокола. Так был начат проект Wayland — начала его компания Intel, которая активно участвует в развитии Linux.
Wayland — протокол общения приложений с композитным менеджером. Композитный менеджер это почти всегда менеджер окон: Weston, KWin, Mutter, Compiz, и т. д. Он напрямую использует ресурсы видеокарты, взаимодействуя с ядром. Сам протокол Wayland включает в себя только работу с поверхностями — окнами, панелями, виджетами. То, что внутри панели, рисует сама программа.
Так исчезает надобность в графическом сервере типа того, что виден в диспетчере задач под именем Xorg (в некоторых дистрибутивах — просто X). Как следствие, отрисовка становится очень быстрой и плавной, при этом нагрузка на оборудование — минимальна. Особенно сильно разница заметна на слабом «железе», например, на Raspberry Pi.
Когда же Wayland придёт в Linux?
Разработка Wayland длится больше 5 лет, но до сих пор он применяется лишь на некоторых смартфонах. Но в ближайшем будущем следует ожидать начала массового прихода Wayland на компьютеры пользователей. Ведь, с одной стороны, KDE и Gnome уже готовы для работы на Wayland, с другой — Nvidia, наконец, реализовала полноценную поддержку протокола в своём драйвере.
На память приходит дистрибутив Fedora, в котором используется Wayland, а теперь еще и Ubuntu 17.10 (следующие версии также будут на Wayland). Но в Ubuntu 17.10 всё еще доступны две сессии, как Xorg, так и Wayland. Так как проблем с новым дисплейным сервером ещё достаточно, нельзя совсем отказываться от Xorg в данный момент.
Wayland не единственная альтернатива Xorg — для Ubuntu разрабатывался протокол Mir, на который планировалось перевести окружение Unity. Он также избавляет графическую систему от посредничества X-сервера. Mir не был готов для использования и Canonical отказались от собственного варианта, как отказалась от своего upstart и перевела Ubuntu на systemd. И сейчас Mir разрабатывается исключительно для IoT устройств (интернет вещей). А Ubuntu возвращается на Gnome и начинает использовать протокол Wayland с версии 17.10.
В предыдущем посте мы узнали, почему X Window System — один из самых успешных проектов с открытым кодом в истории, пора заменить на новое решение для графического окружения Linux. В этой же статье мы узнаем, каков из себя Wayland — наиболее вероятный кандидат на замену X.
Глоссарий Wayland
Имеет смысл сначала разобраться с некоторыми определениями и терминологией.
Compositor — Композитный оконный менеджер является одним из центральных понятий Wayland и вокруг него. Нигде толком не определено, что это такое, но термин этот используется так, как будто все всё знают. Во всяком случае на русском языке никакого определения я так и не нашел. К счастью примеры-таки проясняют суть дела. Вот их список в контексте Wayland:
Как мы видим, это не что иное как знакомые нам оконные менеджеры, хотя на самом деле нет. Это дисплейные сервера, которые все-таки отличаются по своему функционалу от WM. Первые взаимодействуют с пользовательскими устройствами ввода-вывода, с железом, управляют потоком данных клиентских программ. Вторые же отвечают за отображение окон и их размещение в системе оконного интерфейса.
Иллюстрация со страницы в википедии.
Композитный менеджер, он же дисплейный сервер может обозначаться еще как композитный оконный менеджер.
Weston — Эталонный дисплейный сервер протокола Wayland. Недавно вышла вторая версия КОМ-а. EGL — платформонезависимый эквивалент программных интерфейсов OpenGL GLX/AGL/WGL, разрабатываемый Khronos Group. EGL предоставляет инфраструктурный набор для быстрой настройки приложения и инициализации сцены.
EGL в отличие от GLX/AIGLX умеет выполнять лишь direct rendering, в котором приложения через DRI2/DRI3 могут безопасно и быстро получать доступ к видеоаппаратуре минуя X сервер.
GLES — Подмножество OpenGL, разработанное специально для встраиваемых систем — мобильных телефонов, планшетов, компьютеров, игровых консолей.
Архитектура Wayland
Итак, что представляет собой Wayland? Так же как и в случае с X Window System, речь идет о протоколе и его реализации. Wayland — это протокол взаимодействия между КОМ и клиентами, а также его библиотечная реализация в Си. В роли клиента может выступать пользовательское приложение, X сервер или другой дисплейный сервер.
Wayland — асинхронный протокол, объектно ориентированный и нацеленный на обработку сообщений. Сообщение, передаваемое от клиента серверу, есть вызов, а в обратную сторону — событие. Каждое сообщение состоит из 32-битных слов, значения представлены в порядке следования байтов хоста.
Как взаимодействуют эти блоки?
А как происходит рендеринг? Клиенты самостоятельно производят отрисовку своих окон в отдельном буфере, передавая информацию об обновлениях дисплейному серверу, который комбинирует содержимое буферов разных приложений для формирования итогового вывода с учетом возможных нюансов, таких как перекрытие окон и прозрачность.
Wayland vs. X
Ошибочные суждения об X и Wayland
Существует ряд устойчиво неправильных мнений на сей счет.
Wayland is a display server protocol. It is aimed to become the successor of the X Window System. You can find a comparison between Wayland and Xorg on Wikipedia.
Display servers using the Wayland protocol are called compositors because they also act as compositing window managers. Below you can find a list of Wayland compositors.
For backwards compatibility to seamlessly run legacy X11 applications, XWayland can be used, which provides an X Server in Wayland.
Contents
Requirements
Most Wayland compositors only work on systems using Kernel mode setting. Wayland by itself does not provide a graphical environment; for this you also need a compositor (see the following section), or a desktop environment that includes a compositor (e.g. GNOME or KDE).
For the GPU driver and Wayland compositor to be compatible they must support the same buffer API. There are two main APIs: GBM and EGLStreams.
Buffer API
GPU driver support
Wayland compositor support
GBM
All except NVIDIA *: Nvidia >= 495 supports both EGLStreams and GBM.[1]
Compositors
See Window manager#Types for the difference between Tiling and Stacking.
Tiling
Stacking
Other
Some of the above may support display managers. Check /usr/share/wayland-sessions/compositor.desktop to see how they are started.
Display managers
Display managers listed below support launching Wayland compositors. The «Type» column indicates whether the display manager supports running itself on Wayland or not.
Name
Type
Description
GDM
Runs on Wayland
GNOME display manager.
greetd
Login daemon
Minimal and flexible login daemon.
LightDM
Runs on X11
Cross-desktop display manager.
Ly
Runs in console
TUI display manager written in C
SDDM
Runs on X11
QML-based display manager.
tbsm
Runs in console
Simple CLI session launcher written in pure bash.
GUI libraries
To enable Wayland support in Qt 5 or 6, install the qt5-wayland or qt6-wayland package, respectively.
On some compositors, for example sway, Qt applications running natively might have missing functionality. For example, KeepassXC will be unable to minimize to tray. This can be solved by installing qt5ct and setting QT_QPA_PLATFORMTHEME=qt5ct before running the application.
Clutter
The Clutter toolkit has a Wayland backend that allows it to run as a Wayland client. The backend is enabled in the clutter package.
To use GLFW with the Wayland backend, install the glfw-wayland package (instead of glfw-x11 ).
The glew-wayland AUR package currently still does not work with a lot of GLEW-based applications, so the only option is to use glew with Xwayland. See FS#62713.
EFL has complete Wayland support. To run a EFL application on Wayland, see Wayland project page.
winit
Electron
Note that older versions of electron require their own electron-flags.conf file. For example, if you have the electron12 package installed, you may wish to do
XWayland
XWayland is an X Server that runs under Wayland. It provides backwards compatibility for legacy X11 applications.
In order to use it, install the xorg-xwayland package.
XWayland is started via a compositor, so you should check for XWayland compatibility and instructions on how to start XWayland, with the compositor of your choice.
Nvidia driver
Note that enabling DRM KMS is required. Also note additional information in the official documentation regarding your display manager (e.g. GDM).
Tips and tricks
Detect Xwayland applications visually
Alternatively, you can use xorg-xeyes and see if the eyes are moving, when moving the mouse pointer over an application window.
Remap keyboard keys
Troubleshooting
Color correction
Slow motion, graphical glitches, and crashes
Gnome-shell users may experience display issues when they switch to Wayland from X. One of the root cause might be the CLUTTER_PAINT=disable-clipped-redraws:disable-culling set by yourself for Xorg-based gnome-shell. Just try to remove it from /etc/environment or other rc files to see if everything goes back to normal.
Cannot open display: :0 with Electron-based applications
The factual accuracy of this article or section is disputed.
Remote display
Input grabbing in games, remote desktop and VM windows
In contrast to Xorg, Wayland does not allow exclusive input device grabbing, also known as active or explicit grab (e.g. keyboard, mouse), instead, it depends on the Wayland compositor to pass keyboard shortcuts and confine the pointer device to the application window.
This change in input grabbing breaks current applications’ behavior, meaning:
Wayland solves this by adding protocol extensions for Wayland and XWayland. Support for these extensions is needed to be added to the Wayland compositors. In the case of native Wayland clients, the used widget toolkits (e.g GTK, Qt) needs to support these extensions or the applications themselves if no widget toolkit is being used. In the case of Xorg applications, no changes in the applications or widget toolkits are needed as the XWayland support is enough.
Читая Хабр, я много раз натыкался на упоминания о загадочном Wayland, о котором мало что писали конкретного, просто давали ссылку на http://wayland.freedesktop.org (кстати, это официальный сайт). Поискав на Хабре информацию о нем, честно, очень удивился, не найдя ничего информативного (а может быть плохо искал), и решил написать статью, рассказывающую об этом проекте.
Так что же такое «Wayland»?
Wayland — новая система отображения графики для Linux, которая может, впоследствии, заменить X.org. Разработка Wayland начата Кристианом Хогсбергом (Kristian Høgsberg) в 2008 году как «секретный» проект, затем wayland всплыл на сайте www.phoronix.com, немного пошумел в узких кругах и, снова, вернулся в прежнее состояние.
Лирическое отступление
X.org уже давно испытывает проблемы, как всем уже давно известно. К тому же, думаю Вы все читали эту статью, так что не буду описывать вопросы типа: «А почему бы не допилить X?», «Зачем создавать велосидублировать работу?», «Что не так с X.org?»
По сути
Wayland НЕ ответвление X.org’а, а новый, самостоятельный проект, использующий современные достижения GNU/Linux, например управление памятью или шрифтами, которые уже переданы в ядро или специальные библиотеки fontconfig, cairo, pixman, freetype, pango и другие. По сути, wayland — это компоновщик окон, всю работу выполняют клиенты, например wayland-приложение «рисует» собственное окно в предопределенной области памяти, а wayland только компонует окно, получив ивент от приложения. Так же, к задачам wayland относятся управление визуальными эффектами и направление входных команд пользователя соответствующим клиентам.
Аргументы?
— Ускорение графики — Групповая работа с GPU — Фишки с игровой стороны, а именно обеспечение полноэкраного режима, не блокирующего остальную часть рабочего стола, а так же, более простая и «легкая» работа с 3D-играми
Кто в этом заинтересован?
Естественно, сами разработчики Ubuntu, пруфлинк Fedora. пруфлинк Intel и Nokia операционной системе MeeGo, пруфлинк
К сожалению, wayland такое не умеет, потому что большинству оная фича не нужна, а для тех, кто в ней нуждается, могут использовать VNC, RDP, или просто работать с X. Хотя, разработчики предлагают сделать сетевой клиент wayland, в будущем. Тем самым проект не будет тащить монстрообразный багаж модулей/расширений/кода X.org’а для удовлетворения нужд того меньшинства.
Выходит, что надо переписать все приложения под wayland?
Нет, надо всего-лишь передописать общие библиотеки Gtk и Qt.
А минусы есть?
Конечно, помимо сетевой прозрачности так же, будут проблемы с поддержкой старого железа, но незначительные — потеря будет измеряться в паре процентов от доступного списка устройств. Так же, трудно сказать будут ли писать NVidia проприетарные драйвера с поддержкой wayland.
Ниасилил. Вкратце можно?
Wayland — это отказ от лищних слоев между ядром, оборудованием и композитным менеджером, чем, по сути, сейчас и является X.org. В Wayland используется прямой рендеринг через OpenGL или OpenGL ES, тем самым увеличивая быстродействие и отзывчивость графики в linux, чего, по крайней мере, мне очень не хватает. Думаю, Вы с этим согласитесь. Проект выпускается под лицензией MIT, часть кода под GPL
Общественные обязательства интроверта. Сообщения на ИТ тематику, но не обязательно.
О Wayland
Всё началось с того как я купил первый Asus Zenbook. У него был FullHD экран (то есть 1920 на 1080 пикселей) запихнутый в 13.3 дюйма. Это примерно 165 точек на дюйм. В 1.7 раза больше, чем когда-то стандартные в Windows 96 dpi. Так началась для меня эпоха HiDPI.
Во всех ОС с HiDPI (aka Retina display) справляются одинаковым способом. Масштабируют изображение.
Тут есть много нюансов. Растровые изображения нужно либо выбирать побольше (если они есть), либо растягивать (с потерей чёткости). Всяческие иконки это, чаще всего, тоже растровые изображения. Векторные изображения стоит рендерить в соответствующем большем разрешении. Шрифты у нас векторные, их прямо обязательно нужно отрисовывать в большем разрешении. Собственно, ради этого, смотреть на красивые шрифты, и стоит заморачиваться с HiDPI.
А ещё приложения рисуют только своё окно. А декорации окон, панельки и прочее рисует уже ОС. Само приложение может использовать различные тулкиты для отрисовки. И этих тулкитов довольно много, и они весьма разные, особенно в Linux. И всем этим ребятам нужно правильно сказать, какое масштабирование мы тут используем.
Соответственно, поддержка HiDPI в ОС определяется тем, какие варианты масштабирования поддерживаются. И насколько хорошо поддерживаются. И насколько хорошо живут в этих условиях разные тулкиты.
В те стародавние времена более-менее нормально работало только целое масштабирование. То бишь, увеличиваем всё в 2 (а не в 1.7) раза. На 13 дюймовом дисплее всё становится красиво, но несколько крупновато.
Проблема усугубляется необходимостью подключать внешний монитор. Который тоже FullHD, но на 23 дюймах. Получаются стандартные 96 dpi.
Имеем два монитора, оба разрешением 1920 на 1080 пикселей. Но один 13.3 дюйма, а другой 23 дюйма. 165 ppi vs 96 ppi.
X11 не умел тогда и не умеет сейчас выставлять разное масштабирование для разных мониторов. А увеличение в 2 раза при 96 dpi совершенно неприемлемо.
Тогда я остановился на варианте без масштабирования. А чтобы 13 дюймовым экраном можно было пользоваться, я просто слегка увеличил шрифты. Как правило, при использовании двух мониторов, на экране ноутбука у меня живут только всякие чаты. Вот у них шрифт и увеличил. Да, менюшки и панельки мелковаты, но вполне удобно. Зато всё помещается. Ну а 23 дюймовый монитор выглядит как обычно.
Да, размеры одного и того же окна (и даже курсора мыши) на разных мониторах получаются разными. Но к этому на удивление быстро привыкаешь, и это никак не мешает.
Вот тогда я начал присматриваться к Wayland. Потому что там обещали разное масштабирование для разных мониторов. И, в общем-то, не обманули. Однако, в KDE это дело завезли значительно позже. А заработало это нормально только совсем недавно.
Wayland — это альтернатива X Window. Призванная всё упростить и исправить фатальные недостатки. Вот уже почти десять лет как активно внедряется во все дистрибутивы Linux. Внедряется, внедряется, но все никак окончательно внедрится не может.
Какие такие фатальные недостатки?
У иксов есть проблемы с безопасностью. Любой клиент, подключившийся к X серверу, может читать все клавиши, которые нажимаются на клавиатуре. А вы же там пароли вводите. Также клиенты «видят» всё, что происходит на экране.
Когда-то X создавался для того, чтобы приложения могли рисовать на удалённом дисплее. В протоколе есть примитивы рисования, вроде рисования линий. Но сейчас современные тулкиты (те самые тулкиты, GTK и Qt в первую очередь) предпочитают отрисовывать все эти кнопочки интерфейса в локальном буфере, а на X сервер отправляют уже готовое растровое изображение. В таком варианте использования все возможности X становятся излишними.
X11 предоставляет сетевую прозрачность. Это значит, что экран, клавиатура и мышь могут находиться на одном компьютере, где запущен X сервер, а само графическое приложение, X клиент, может быть запущено на другом компьютере. X клиент подключается к X серверу и рисует там. Но, вместо команд рисования, наши GTK и Qt будут передавать по сети большие картинки. А для этого есть более эффективные протоколы. Тот же VNC или SPICE. Так что сетевая прозрачность X в настоящее время не востребована.
Вот Wayland и есть полный пересмотр и упрощение того, что нужно для отрисовки GUI. Тут нет сетевой прозрачности, нет возможности рисования. Зато есть изоляция приложений.
В Wayland приложение просто рисует свой интерфейс в некоей прямоугольной области заданного размера, в окне. Как это уже и делают GTK и Qt. Далее вступает в работу так называемый композитор. Другое приложение, которое собирает все картинки других приложений, пририсовывает к ним рамки и формирует то, что видит пользователь. И всё это с использованием OpenGL, то есть с аппаратным ускорением всякого масштабирования и прозрачности. Как уже давно делают и под X менеджеры окон популярных DE. Собственно, в KDE именно менеджер окон KWin и выступает в роли композитора Wayland.
Я каждые полгода поглядывал на поддержку Wayland в KDE. Чтобы включить это грешное разное масштабирование на разных экранах. Но всё было плохо. То настройки мышки куда-то пропадали. То панели падали. То половина программ отображалась хреново. То скриншоты не работали. Но сейчас, наконец-то, оно почти стабилизировалось. Но не до конца. Всё ещё не до конца.
Проблема снова усугубилась с появлением у меня нового Zenbook. Теперь на тех же 13.3 дюймах разместились 3200х1800 пикселей. Почти 4K (точнее, QHD+ или WQXGA+). Это порядка 276 точек на дюйм. И нового монитора. 27 дюймов. 3840х2160 пикселей, полноценный 4K. Почти те самые 165 точек на дюйм, что были на 13 дюймовом FullHD.
Ну вот дайте мне обратно FullHD экран на Zenbook, и будет всё почти идеально. Но нет.
С тех пор в иксах появилось дробное масштабирование. Но не появилось разного масштабирования на разных мониторах. Полагаю, уже никогда не появится.
Я поставил не 200%, а 175%. Хорошо. Так же комфортно, как и без масштабирования. Шрифты везде — загляденье.
Из неприятного только: не масштабируются панели. Приходится им выставлять большущие размеры в реальных пикселях.
Возможно, это глюк Latte Dock. У него много глюков. Иногда тормозит и постоянно жрёт много памяти (в моей конфигурации). Но зато только он может (наконец-то!) изобразить глобальное меню, замещаемое на заголовок окна, в верхней панели, как оно было в (светлой памяти) Unity. Ну и сам док у него работает заметно адекватнее штатного, особенно в случае двух мониторов.
Не масштабируются иконки в GTK приложениях, остаются маленькими. Кажется, это можно починить. Ведь этот показатель масштабирования тупо передаётся в приложения через переменные окружения. Конечно же разные для разных тулкитов. Что-то KDE не до конца добавляет.
На большом разрешении подтормаживают всякие эффекты, особенно размытия заднего плана через полупрозрачные окна. Возможно, вот тут и не помешала бы дискретная видюха. Но это замечаешь только, когда переключаешься обратно на FullHD. Менюшки начинают открываться неуловимо быстрее. Но любые эффекты в KDE можно отключить, и это ничего не портит.
Wayland есть, и в нём действительно можно выставить разное масштабирование для разных мониторов. Можно даже сделать так, чтобы окна на разных экранах физически были почти одинакового размера. Это получается где-то 200% масштабирование на маленьком экране и 125% на большом. Но я от этого так отвык, что окна привычного размера на экране ноутбука на большом мониторе кажутся слишком мелкими. Так что я, когда экспериментирую с Wayland, ставлю масштабирование 200% на маленьком экране, а 175% на большом.
Размеры панелей и курсора мыши в Wayland нужно уменьшить. Они масштабируются правильно. Даже по-разному на разных экранах. Курсор мыши, кстати, тоже масштабируется и выглядит очень «пиксельно», и умудряется менять масштаб между разными окнами. Это раздражает.
Субъективно Wayland в HiDPI немного поотзывчивее, чем X11. Первые несколько минут. Это хорошо. Но не всегда и не везде. Это плохо.
В Wayland в KDE многое починили за последний год. Нормально заработал Latte Dock и глобальное меню, вернулись почти все настройки (а устройства ввода в Wayland ведь работают совсем по-другому). Вон, даже скриншоты произвольного прямоугольника на экране в Spectacle завезли. Но есть две вещи, которые делают мой переезд на Wayland пока невозможным.
Wayland в HiDPI и KDE мылит окна. Нет, родные приложения KDE и Qt выглядят просто прекрасно. Шрифты великолепны, всё чётенько и красивенько. А вот GTK приложения, у которых нет родной поддержки Wayland, выглядят «мыльно».
Дело в том, что для старых приложений, которые умеют только X11, запускается прослойка XWayland. По сути, для приложения запускается свой X сервер, куда оно рисует. А уже вывод этого сервера Wayland композитор помещает в Wayland окно. И вот в KDE XWayland запускается с масштабированием 100%, а уже KWin растягивает это окно до более высокого разрешения. То есть приложение рисует себя под низкое разрешение, а потом, через OpenGL, изображение апскейлится до большего разрешения. Отсюда и возникает премерзкое «мыло». Говорят, в GNOME такого нет, хотя там тоже используется XWayland.
И как избавиться от мыла в IntelliJ IDEA — моём основном рабочем инструменте, куда я смотрю более 60% времени, когда я за компьютером, я не знаю. Непонятно, что случится быстрее, родная поддержка Wayland в Swing или JavaFX, или исправление работы XWayland в KDE. Это я намекаю на то, что баги в поддержке Wayland исправляют обычно долго.
Вторая проблема связана с классом окна.
Таким образом я запускаю Gmail, DevDocs и ещё пару приложений по мелочи.
Ключевым моментом здесь является задание WM_CLASS у окна. Это класс окна для менеджера окон. У окон веб приложений должен быть отдельный уникальный класс, отличный от класса окна самого Chrome. Тогда окна будут корректно отображаться и группироваться на панели задач или в доке. Этот WM_CLASS имеет прямое отношение к протоколу X. В Wayland его, по-видимому, просто нет.
В результате в Wayland отдельные ярлык и иконка для запуска в доке есть. А запускаешь приложение, и появляется ещё одно окно Chrome. Технически так оно и есть, да. Но я хочу, чтобы подсветилась иконка веб приложения в доке. Иначе какой в этом смысл?
Пока Wayland не готов для постоянного использования. По крайней мере, для меня. Если с «мылом», я верю, рано или поздно справятся, то что делать с веб приложениями? Надо искать альтернативный подход.
Ну и всё ещё слишком много более мелких глюков.
Похоже, Spectacle в HiDPI Wayland мылит скриншоты. Возможно, он делает и правильно, изображения получаются приемлемого разрешения. А то в X11 получаются скриншоты пиксель в пиксель, а это слишком много для веба. В вебе ведь HiDPI не завезли. Точнее, браузер масштабирует все картинки согласно тому самому коэффициенту масштабирования. И скриншоты с HiDPI дисплея приходится уменьшать, чтобы браузер их потом увеличил, если страницу будут просматривать на HiDPI мониторе. От этого тоже возникает «мыло». С редактированием изображений в HiDPI вообще иногда есть проблемы.
Указатель мыши, как я уже говорил, может менять размер над разными окнами и элементами экрана. При переключении языка в центре экрана вылезает сообщение о том, какой язык выбран. Совершенно ненужное. Но как его отключить, я пока не нашёл.
Полноценных настроек тачпада нет, и он не отключается при подключении мыши. Похоже, в Wayland нет полноценного драйвера для тачпадов Synaptics. Вероятно, нормальной поддержки планшетов Wacom тоже нет. Полагаю, для очень многих пользователей это критично.
Изменение масштабирования в X11 и Wayland работает по-разному. X11 честно предупреждает, что без перелогина ничего работать не будет. Ну действительно, нужно же все приложения перезапустить, чтобы они усвоили новую настройку. А проще всего это сделать, если вылогиниться и залогиниться заново. И да, старые окна рисуются в старом масштабе, а новые запущенные приложения рисуются уже в новом. Wayland же тут же начинает масштабировать окна по-новому. Однако, само приложение будет продолжать рисовать под старое разрешение. И будет «мыло». Чтобы избавиться от «мыла» везде, снова нужно перелогиниться.
Wayland, HiDPI и KDE? Выберите два. Три вместе — пока невозможно.
Жду улучшений. Избавление от «мыла» в GTK приложениях. Решение вопроса веб приложений. Полноценной поддержки тачпада.
UPD 2021-03-20
Wayland для работы с устройствами ввода использует (как правило) библиотеку libinput. Её же по умолчанию использует и X Server. Эта библиотека умеет тачпады Synaptics и планшеты Wacom. Однако, для X есть и отдельные драйверы ввода, которые вроде как предоставляют больше возможностей для тонкой настройки.
Сложность в том, что у libinput нет своего стандартного конфига и стандартной утилиты настройки. В X это конфиги X сервера и утилита xinput. В Wayland все настройки отданы на волю конкретного композитора, которые в разных DE разные. В KDE под Wayland таки есть настройки для тачпадов. Но (сейчас) нет настроек для планшетов Wacom.
Приложение Upwork не умеет делать скриншоты под Wayland. Похоже, что протокол создания скриншотов, то есть доступа к итоговому изображению, которое видит пользователь, у разных композиторов разный. А KDE (точнее, KWin) — не самый популярный композитор.
Jetbrains начали перенос платформы IntelliJ на JDK17. Это значит, что скоро в IDEA появится родная поддержка Wayland.
The factual accuracy of this article or section is disputed.
