Теоретически, у иксов больше оверхед. На практике весь рендеринг и композитинг всё равно делается через GPU у современных приложений. Что иксы что вейланд занимаются только тем, что выделяют буфферы видеопамяти. К тому же в вейланде Xwayland будет где то болтаться в фоне.
жрёт WM и композитор, а не протокол. Sway и i3, вероятнее всего, будут жрать одинаково. в иксах больше всего жрёт ресайз окон, для i3, думаю, это не особо актуально.
несколько неочевидных нюансов, на которые следует обратить внимание:
- иксовые приложения (особенно игры в вайне), запущенные через XWayland, будут потреблять больше ресурсов (и энергии), чем запущенные нативно в иксах.
- в Wayland работает аппаратное декодирование видео в Firefox, в иксах нет (работало в Firefox 88, потом опять сломали). это очень сильно влияет на энергопотребление, но только если смотришь ютуб в браузере (а не в mpv, как нормальные люди, например)
- некоторые вещи, к которым лично я привык — в Wayland больше не работают. пример — тонкая настройка тачпада (syndaemon, synclient), автоматизация с помощью xdotool и проч.
как-то так, выбирай в зависимости от юзкейса и потребностей. я пока сижу на иксах, в основном из-за тачпада, переиду на вяленый окончательно тогда, когда отпадёт потребность в XWayland (я думаю, года через два-три?)
Ты слишком специфичные вещи спрашиваешь. Никто этого не знает наверняка. К тому же даже если кто то померяет, результаты будут отличаться на разном железе.
не умеет. libinput умеет только полностью отключать тачпад во время печати на клавиатуре, а syndaemon умеет отключать только тапы и скроллинг.
это очень редкий кейс, но я к этому поведению привык настолько, что не могу пользоваться ноутбуком без syndaemon -d -t -i 0.8. отучиться пробовал, не выходит.
ну такое. я бы конечно воспользовался этой фичей если бы она была. одно время пробовал играть в террарию без мышки, невозможность одновременно управлять с клавиатуры и тачпада сильно раздражала. но я приловчился отключать эту фичу на время игры и включать обратно после.
Какая разница? Независимо от того кто лучше, Вейланд будет повсеместно внедряться, а иксы выпиливаться. Если особо хитрых запросов нет, то им уже можно нормально пользоваться, уже полгода, если не больше. Что тут выбирать?
Флаг wayland заставляет пересобрать пол мира. Попробуй
Пробовал - за полчаса пересобралось.
Я так понял, что на ЛОР многие просто без знаний, лишь бы пукнутьв теме.
Лишь пукнутые в теме телепаты скажут, что конкретно в твоем юзкейзе будет работать более энергоэффективнее. В теории конечно wayland, на практике - что угодно.
У меня это день. Железо разное.
А хотелки просты - понять и простить, разобраться в вопросе.
Жить на Xorg или собирать всё с поддержкой Wayland (firefox, gtk, mesa) и отказываться от XWayland потихоньку.
At the top of the driver stack lie the application drivers. These drivers can contain common user stuff like shapes, or windows, easier API for buffers and additional support for things like displays. Generally graphics driver do not care about displays. However, nowadays mode setting (setting display resolution and color depth) is tied to GPU graphics so graphics libraries can provide some functionality for mode setting.
X11 has a complex protocol that defines various stuff like window management and shapes and ways to define regions that are drawn by graphics driver on the display again called buffers. X11 provides APIs for changing display resolution and all the other complex stuff. The days before everybody used GPUs and (hence) graphics drivers to draw stuff, this required GPU specific drivers and nowadays we need libraries to translate X11 commands to OpenGL commands and provide other functionality. This is what xf86-video-{intel, amdgpu, ati, nouveau} drivers do. There is a special one among them: xf86-video-modesetting. A lot of functionality is carried to kernel drivers due to the complex nature of resource management in user-space and kernel being the ultimate resource manager. So changing display resolution and allocating memory buffers is on kernel space. The modesetting driver uses the kernel facilities of mode setting and puts an end to GPU specific X11 drivers.
On the other hand Wayland defines nearly nothing about GUI. It defines a communication protocol between the graphics driver and client applications. That’s it. The components that make up the GUI environment is left to the compositor implementors to figure out. Wayland doesn’t define the exact details of what can be drawn in a buffer. It only defines that the communication protocol includes «a» buffer. Everything like windows, buttons, events, display, mode setting, GUI stuff, shapes and all is left to the compositor implementors. So they can come up with any kind of mind boggling complex GUI thing and there can be loads of incompatible compositors and they can now truly drive application developers insane :) . Or they can just tell application developers to suck it and use a GUI toolkit like Qt.
Everything like windows, buttons, events, display, mode setting, GUI stuff, shapes and all is left to the compositor implementors. So they can come up with any kind of mind boggling complex GUI thing and there can be loads of incompatible compositors and they can now truly drive application developers insane :)
ну такое. я бы конечно воспользовался этой фичей если бы она была. одно время пробовал играть в террарию без мышки, невозможность одновременно управлять с клавиатуры и тачпада сильно раздражала. но я приловчился отключать эту фичу на время игры и включать обратно после.
дело не только в играх. когда что-то увлечённо печатаешь, можно краем ладони задеть тачпад и сработает тап, и либо переместится курсор на рандомное место, либо куда-то нажмётся, либо что-то ещё. отключать полностью тачпад во время печати не вариант, так как часто приходится что-то печатать в нескольких окнах, а курсором как раз удобно менять фокус. и ждать доли секунды, пока тачпад снова включится — неимоверно раздражает.
собственно, из-за таких мелочей до сих пор не могу пользоваться ни виндой, ни маком.
Возьми десктопный компьютер и два мультиметра: одним мультиметром замеряй ток системного ящика, другим мультиметром замеряй ток монитора. Замеряй при холостой работе и при запуске различных приложений.
Ожидаю что ты придёшь к выводу что основную мощность ест подсветка монитора, а графические сервера где-то на пределах погрешности.
это всё супер. Я не сомневаюсь. Вот только Wayland протокол, а реализации в силу умений. И что-то у меня сомнения в тех, кто чейчас реализует его в Linux. Wlroots? Поделки на его основе в Htop показывают нагрузку до 50%. Тот же River на каждый терминал съедает 3-5% CPU. После определённого предела включается охлаждение, что ест батарею.
Без разницы, жрать будут твои рабочие приложения. Но у Xorg есть тонкая настройка всего и вся. А эта реализация вяленого умеет только окошки показывать и всё.
Что «это»? Окошки показывать? Иксы этим дцать лет занимаются. А вяленый просто копирует базовые возможности не давая никаких преимуществ. Если просто окна показывать и всё бери вяленый. Но в иксах без композитинга GPU будет отдыхать, в вяленом нет. Если твой ГПУ жручий то бери иксы без композитинга. А так, тебе просто нужно потратить пару дней и протестировать от полного заряда до полного разряда на обоих вариантах. При этом написать скрипты где окна будут по экрану гулять и менять размер всё время тестирования. На иксах это легко, на вяленом не знаю.
ну ты же не играешь постоянно. в большинстве популярных композиторов Xwayland умеет запускаться только когда он нужен
так с играми через XWayland в принципе есть небольшие проблемы во-первых, в рандомные моменты курсор может внезапно оказаться аккурат посередине окна (уже пофиксили в апстриме, когда доедет до дебиана — непонятно, может и доехало уже) во-вторых, FPS немного, но ниже, а на ноутбуке с ограниченными ресурсами это актуально.
переключать окна != переключать фокус focus-on-mouseover ещё одна вредная привычка, из-за которой я не могу пользоваться ни виндами (хотя там костыль какой-то был), ни маками
эээ... при режиме фокуса «следует за мышью» фокусом (т.е. в какое окно происходит ввод) можно управлять с помощью курсора. переключение же активного окна клавиатурой поднимет окно на передний план, что нужно не всегда.
тайлинг решает эту проблему, но это лень и привыкать заново.