Эмулятор PCSX2 по умолчанию отключает поддержку Wayland

The merge doesn’t strip out the Wayland code but is simply disabling it for the default Flatpak and AppImage builds of this game emulator. Those building PCSX2 can continue to enjoy Wayland support if so desired.

PCSX2 из реп это, похоже, не затронет. Только любителей накачать всяких флатпаков.

Ну хоть кто то разумный. Иксы навсегда!

А как его в бубунте из реп установить? На оф. сайте только AppImage

nix-ом поставь, например.

Мне из реп надо. Аптом.

Не знаю, не пользуюсь убунтой. Неужели нет в репах? Может какой PPA есть.

Я ХЗ, самому интересно.

Disables Wayland, it's super broken/buggy in basically every scenario. KDE isn't too buggy, GNOME is a complete disaster.

    Stupid obsession with CSD in Gnome => inconsistency
    Inability to position windows => window position saving doesn't work, log window attaching (not merged yet) doesn't work
    Hacks in render-to-main because WL craps itself otherwise
    Despite said hacks, game list still glitches after stopping emulation, happens more often in gnome
    NVIDIA just crashes in swap chain creation under Wayland
    Broken global menus
    and many others

Until they sort their s**t out, which is unlikely, since there's been very little progress over the last decade, just keep it disabled. For the Flatpaks, users can re-enable it with flatseal if they really want the crappy experience.

Кросивое… шёл шестнадцатый год вялянда.

It's not removed at all. If you read the title or description, you'd see it is disabled on our release builds, because it's nothing but headaches for us, because of its broken by design nature causing issues for users. I listed a bunch of them in the OP as well.

We're sick of getting blamed for bugs in wayland compositors, while the various committees sit around arguing with each other, finally decide on standard ways of doing things after half a decade, then GNOME ruins it all by refusing to implement it.

If you use the flatpak, it's even just a single flatseal command to re-enable.

PCSX2 runs fine under XWayland. In fact, it runs much better than under native WL, because it doesn't have all the above issues.

Don't get me wrong, X11 is terrible code, and should've been purged a decade ago. But Wayland is just broken, and everyone would rather sit around arguing with each other instead of actually addressing the design flaws.

Ещё больше прекрасного.

А комментарий где?

«Wayland просто будет отключен в приложении, до тех пор, пока они не разберутся со своим поделием, что маловероятно, так как за последнее десятилетие было очень мало прогресса. Что касается flatpak, пользователи могут повторно включить его с помощью flatseal, если они действительно хотят страдать»

Я недавно писал что еще 15 лет минимум понадобится что бы хоть что то под ним заработало. Пока можно glxgears запускать, хотя и он наверное тоже в XWayland крутит свои шестеренки.

Свободу попугаям!

The merge doesn’t strip out the Wayland code but is simply disabling it for the default Flatpak and AppImage builds of this game emulator

Ну и хрен с ним. Дефолтожоры пусть страдают, а я просто включу его обратно.

Don't get me wrong, X11 is terrible code, and should've been purged a decade ago.

Все верно, так и есть.

2 года назад юзал федору под вейландом с гномом. Запускал игру (факторио). Никаких проблем не встретил, всё прекрасно работало. Хз, что там со стороны разработчика, но с точки зрения юзера вейланд прекрасно работает.

Don’t get me wrong, X11 is terrible code, and should’ve been purged a decade ago.

Все верно, так и есть.

И сидеть в ядерной консоли, ведь вялянд до сих пор не может.

С запуском 2D игр на весь экран Wayland прекрасно справляется, это же прям как в DOS, никаких тебе кнопок, DPI, текста, виджетов, просто пишешь пиксель в буфер по адресу 0xB8000, и намана.

Проблема начинается когда хочешь запустить что то кроме Alley Cat, и сталкиваешься с тем что в Wayland не завезли HiDPI, заголовки окон, расстановку окон, с лагами в 3D играх, с тем что Firefox, Google Chrome, IDEA, Eclipse, Discord, VSCode и прочие все еще не могут из коробки запуститься на нем. А в GNOME даже нельзя Flameshot пользоваться, а это крайне важно для моего рабочего процесса!

Я так понял, в основном подгорает от невозможности расстановки окон и лагов в 3D играх (с неотключаемой вертикальной синхронизацией).

Всё остальное - мелочи. Flameshot допилят когда-нибудь.

and many others

Оказалось, что даже гордость 60 fps - только до нагрузки. Например, в Weston и Sway: График FPS.

Доступна Louvre 1.0, библиотека для разработки композитных серверов на базе Wayland (20.11.2023). Первое упоминание тут: Спустя 15 лет индеец Зоркий Глаз заметил, что... (комментарий).

Разве что, разработчики скромно умолчали о том, сколько их новинка памяти потребляет.

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

Я уверен что его не допилят, скорее появится что то новое, такой проект с кучей разных расширений, и реализаций никогда нормально работать не будет, причин на это много, во первых у WM/DE нету столько разработчиков что бы поддерживать не только существующие, но и будущие расширения, во вторых они могут не захотеть по каким то причинам поддерживать некоторые, как GNOME.

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

Wayland разрабатывается 15 лет, может показаться что это показатель того что осталось немного потерпеть и вот вот допилят, но на самом деле это показатель того что подобный проект невозможно допилить и использовать.

Ну, когда реализуют все нужные фичи в зоопарке композиторов wayland, там будет

is terrible code, and should've been purged a decade ago

Чудес не бывает.

с самого начала Wayland спроектирован отвратительно

Да не, нормально спроектирован. Проблема в том, что декларируемые задачи не соответствуют типичному пользователю оконной системы.

Ну «нормально» наверное для всех разное, но для меня, если у Wayland проблемы с HiDPI, HDR, несколькими GPU, и даже колесиком мышки (точная прокрутка), то это признак некой проблемы в архитектуре.

Ну «нормально» наверное для всех разное, но для меня, если у Wayland проблемы с HiDPI, HDR, несколькими GPU, и даже колесиком мышки, то это признак некой проблемы в архитектуре.

Потому что он был спроектирован для автомобильных дисплеев и прочего ебмеддеда.

в Wayland не завезли HiDPI

Завезли, даже в гноме fractional scaling протокол есть.

заголовки окон

Вообще сам называл это крупным минусом вяленого, но вот использую Fedora и не замечаю никаких проблем с ними. qt5/6 через qadwaitadecor дают стандартный заголовок, libdecor давно научился в gtk.. остаётся 1.5 приложения, которые сами рисуют заголовок, некритично.
Если использовать KDE/wlroots, то такой проблемы в принципе нет.

с лагами в 3D играх

Не наблюдал, Radeon RX 580.

с тем что Firefox, Google Chrome, IDEA, Eclipse, Discord, VSCode и прочие все еще не могут из коробки запуститься на нем.

Тогда бы вяленд по дефолту не был включён. Но нет, даже в дебиане уже давно.
Да и указанные приложения УМР, как говорится, искаропки.

А в GNOME даже нельзя Flameshot пользоваться

Работает он там уже давно, если нативно без xwayland запущен. Один раз спросит разрешение на создание скриншота и всё.

HDR

X’ы в него вообще не умеют. KDE/gamescope могут.

несколькими GPU

А там что? У меня встройка и дискретка, обе отлично работают, PRIME тоже. Если второй монитор воткнуть в выход видеокарты(при этом 1 торчит на встройке), тоже всё нормально.

Завезли, даже в гноме fractional scaling протокол есть.

Оно не работает, некоторые приложения становятся в 2 раза больше чем нужно, при этом события мыши они ловят как нормально окно, ну это только избранные, обычно просто мыльная растяжка.

libdecor давно научился в gtk

В XFWM4 у меня можно прокрутить вверх колесиком по заголовку, и приложения свернется в заголовок, libdecor такое умеет?

с тем что Firefox, Google Chrome, IDEA, Eclipse, Discord, VSCode и прочие все еще не могут из коробки запуститься на нем.

Тогда бы вяленд по дефолту не был включён.

Я про то что они в XWayland, там все мыльное и плохо работающее.

Работает он там уже давно, если нативно без xwayland запущен. Один раз спросит разрешение на создание скриншота и всё.

У меня все еще не работает. Может на арчике починили...

То есть нормальная графическая подсистема в линуксе недостижима. Либо гора древнего, кривого говнокода, либо что-то нерабочее. Третьего не дано.

То есть нормальная графическая подсистема в линуксе недостижима.

Так и есть.

Похоже, даже до Полугнома стало доходить.

Вполне себе достижимо. Надо сделать рефакторинг кода иксов, еще попричесать код. Тот же CDE просто небо и земля по сравнением с тем что было раньше.

KDE/gamescope могут

Такое вот будущее будет, ставишь 10 DE и WM, и каждое для своего приложения. Стоп, а gamescope так и работает уже! Иксы в такое не могут, но все недостатки Wayland по сравнению с иксами уже и так давно известны.

Неосилятор жалуется, что за его говнокод начали бить по рукам. Какая трагедия (нет).

Слабо отключить XWayland?

Зачем мне его отключать?

Неосилятор жалуется, что за его говнокод начали бить по рукам. Какая трагедия (нет).

Его говнокод работает под всеми другими платформами кроме Wayland.

У Wayland реально есть огромная проблема с подходом к рендерингу, на которую игроделы давно и много жалуются.

Что бы пользоваться только нормальными приложениями не от быдлокодеров, которые даже не хотят бесплатно адаптироваться под шизу гениев из rh?

libdecor такое умеет?

Должен. На нормальных композиторах с xdg-decoration заголовок рисует сам WM, как в иксах ЕМНИП, а не lbdecor. А в гноме оно и так не поддерживалось.

По остальному с 1024х768 монитором сказать ничего не могу.

Его говнокод работает под всеми другими платформами кроме Wayland.

Только потому что он заговнокодил и прибил гвоздями к ним. Как только прибьёт гвоздями, а лучше нормально перепишет, то и под вейландом будет работать.

Твой тейк мимо. Я не заявлял, что под вейландом нет быдлокодеров. Таким образом отказ от xwayland не приблизит меня к светлому безбыдлокодерскому будущему, а значит и нет никакого смысла отказываться.

А, действительно, тогда libdecor же будет отключаться. Правда оно как то криво работает, у меня некоторые приложения на Ubuntu без заголовков запускаются, например qbittorrent. Наверное можно ждать двойного заголовка на XFCE5.

Только потому что он заговнокодил и прибил гвоздями к ним

Нет, потому что Wayland очень особенный и его проектировали очень особенные люди.

Wayland's render loop design is ridiculous.

This is one of those parts where the limited design of Wayland really hits you in the face. You must design your render loop in a certain way. If you don't, prepare to face the pain. How this works on Wayland is that you get a callback from the compositor (the infamous frame callback), which essentially acts as a hint telling you when to draw. That's cool. The idea is that the compositor tells you when to draw, you obey like a good client, and everything works. Unfortunately, life is not actually that simple. Most compositors throttle rendering by not sending frame callbacks when the client is hidden. Internally in Mesa, a swap interval of 1 on EGL and FIFO mode on Vulkan (AKA basically vsync) work by waiting for frame callbacks. Do you see where this is going? If your client tries to draw while it is hidden, woops it gets indefinitely stalled until you bring it back into view. Well surely the client can just check if it is visible before drawing, right? Actually no, you can't. That's right, clients have no way of knowing if they are hidden or not. It's common to come up with some heuristic to deal with this.

This is the part where Wayland developers will say something like "just draw with the frame callback". If you build a client from ground up specifically with Wayland in mind, sure this is easy. But many applications are cross platform and internally driven. Refactoring a render loop to operate completely differently, just for the sake of one platform that acts like a special snowflake is not appealing to anybody. At this point, many applications just give up and set the swap interval to 0 or Vulkan to mailbox and call it a day. In mpv, I came up with a weird hack that essentially implements a blocking call with a timeout since we need vsync obviously but blocking forever isn't acceptable. There's a heuristic that guesses when mpv is hidden (been wrong before) and it doesn't draw in that case, so we have the same idealized efficiency, just not exactly in the "Wayland-approved" way.

In the past, there was actually an externally driven render loop specifically for mpv which worked like how upstream Wayland developers say it should work. It was extremely buggy, lacked features, and totally brittle. Reverting it was definitely one of the better commits I made. And in retrospect, this actually makes perfect sense. mpv has a crapload of timing code specifically designed to deliver the frame at exactly the right time. It's been battle tested and used over many years. Why would the compositor know when to draw better than mpv? Of course, it wouldn't. And indeed, when I squeezed Wayland's weird rendering design into mpv's internal workflow, frame timings dramatically improved (even before presentation was implemented) and tons of bugs were fixed in the process. The dislike of internally driven renderloops is purely driven by ideology, not any actual technical sound reasoning. There's nothing wrong with an application managing how it should render internally. It's a natural choice for any program that operates in a cross-platform manner. Wayland is the only platform like this, and it makes operating in this way needlessly difficult for no particular reason. We can't "waste" frames but never mind that you can just set the swap interval to 0 and belt it away anyway.

Источник: https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html

Как только прибьёт гвоздями, а лучше нормально перепишет, то и под вейландом будет работать.

Зачем? Под другими платформами работает. На вялянд проще болт положить, он всё равно не нужен.

gamescope работает внутри сессии. Я его здесь упомянул, потому что используется в SD OLED с HDR экраном.

А так работают над color-management протоколами, в гноме MR висят уже.

Так что ставить 255 DE ради X функции вряд ли придётся.

qt в libdecor не умеет, там декорации через плагин.

У меня под Fedora/Arch всё рисовалось.

Почти всё вышеперечисленное у меня прекрасно работало. Эклипс только не использовал и дискорд запускал в в браузере. Кстати трансляция экрана из браузера тоже работала, смутно припоминаю, что под иксами у меня с этим когда-то были проблемы.

Портянка

Устарела и протухла. В вейланд добавили режим без vsync, теперь спецификация пукана вулкана не ломается.

«just draw with the frame callback»

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

Как вариант, плясать не от композитинга в 3D, а от nanoX или как там его - добавлять к нему фичи типа сглаженных шрифтов, многоголовости и т.п.

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

Ну правильней сказать что проблем ты не замечал, или они не доставляли неудобств. На ноутбуке со встройкой AMD я тоже Wayland запускаю что бы в браузере что то посмотреть, или книгу почитать, если подальше отсесть то даже мыло не сильно видно. Но на десктопе уже проблемнее, краши и артефакты.

Устарела и протухла. В вейланд добавили режим без vsync, теперь спецификацияпуканавулкана не ломается.

Совсем тупенький? VSync там не при делах в принципе. Читай ещё раз, авось осилишь.

И что ему не нравится.

Прочитай внимательно, там написано что ему не нравится.

В вейланд добавили режим без vsync

Как ее включить?))))

В вейланд добавили режим без vsync

Где-то есть реализация? А то я у себя в ксочке второй тиринга не видел пока. FPS при этом был выше герцовки монитора.

Я эту портянку год назад читал. Она уже протухла.

Смотри настройки своего композитора.