Это же всего лишь туклит на котором половина DE сделана.
Что что? На нем не сделана половина DE. В Wayland большая часть DE сделаны с помощью Wlroots. Так что не надо с больной головы на здоровую перекладывать. gtk это чисто гномовская разработка, и что они там пилят, это только их проблемы. В KDE к примеру лучше все, там даже починили fractional scaling в прошлом году, а KDE 6 будет еще лучше.
Я уже и забыл про такую забавную штуку как флаг --my-next-gpu-wont-be-nvidia без которого не запустить композитор.
Опять с больной головы на здоровую перекладываете. Проблемы вашего производителя GPU не проблемы Wayland. У NV дерьмовые драйвера, и они нормально egl и vulkan расширения не могут реализовать, и другим надо костылить из-за лени и закрытости NV. Даже у Intel вероятно намного лучше драйвер сделан и они постоянно что-то новое добавляют в свой драйвер.
Тут я процитирую вас же вашими словами:
Ну это откровенная ложь даже на текущий момент.
Но некоторые злые языки распостраняют дезу что все разрабы отказались от иксов и они вообще заброшены.
Еще раз, что вам мешает сделать форк и пилить свои патчи и отправлять в апстрим? Разработка xorg в гитлаб идет и там постоянно патчи новые принимают.
Каждый пилит свою реализацию, не совместимую с остальными.
Вранье чистой воды. Есть Wayland Protocols в котором описаны все протоколы, DE обязаны поддерживать Wayland Protocols которые им необходимы. Т.е. DE не может и изменить какой-то протокол на свое усмотрение. Wayland Protocols развивается, некоторые протоколы устаревают и им на замену приходят новые, некоторые переходят и staging в stable и в этом случае чуть меняются имена функций генерируемых сканеров. В остальном Wayland Protocols это стандарт, как должен быть реализован тот или иной протокол.
научились уже в gtk оконными декорациями управлять
Это вообще не проблема Wayland. Вы бы еще влияние фазы луны на курс доллара тут написали. В Wayland как раз этот функционал отдали клиенту сервера, из-за того, что это очень ресурсоемкая задача, не все ими пользуются и сервер не должен этим заниматься.
Вообще я как-то сам был амбосадором wayland и пытался в него ещё лет 7 назад.
В таком случае я был 7 лет назад балеруном.
Не слушайте мифы про безопасность(её там легко организовать, чтобы каждый клиент не имел полный доступ) или отсутствие hdr(сами иксы могут).
Что же вы не организуете и патчи не отправить в апстрим? Заодно статью тут напишете про это.
Никаких серверов для этого не надо. Вот их конфиги
Да ладно? Это не конфиги, а сценарии. Сценарии запускаются при определенном условии, прописанном в них. Дальше они через API и секретного ключа передают задание на внешний сервер, там происходит сборка. Дальше происходит тестирование, а затем сборка артефактов с сервера сборка и упаковка в архив и загрузка на гитхаб. Мне гитхаб предлагает скачать их агент https://github.com/actions/runner/releases/download/v2.313.0/actions-runner-linux-x64-2.313.0.tar.gz и поставить на своей сервер. Как знаю github не предоставляет свои мощности для сборки, а только дает аналог Jenkins, Travis CI, Gitlab CI/CD.
Proton и GE используют CI/DI для сборки в контейнере. Для этого нужен сервер с Docker. Там более сложные сборочные скрипты. Они поставляют кучу системных компонентов типа ffmpeg и gstreamer, чтобы сборки были переносимые и работали на любой Linux. Сборка такого проекта вместо минут 10 превратится в час. Дальше это все запускается в Steam в виртуальной контейнере с ubuntu linux и изолированно от вашей системы, системных библиотек! Да здравствуют всеми любимые namespaces и cgroups в Linux. Про это я расскажу завтра, во второй части данной статьи посвященной Wine и Proton.
Да, только в том случае если у вас топовая видеокарта и куплена Windows. А в линукс можно получить минимальный FPS где-то на 20 кадров в секунду больше в Apex Legends на моей AMD Radeon RX5700XT.
Смысла нет, да и дебиана у меня тоже нет, если брать и копипастить готовые команды из двух статей, то на копипаст уйдет не больше минуты, а на общую сборку минут 10. Все скрипты можно скопировать и сохранить, как shell скрипты, и запускать для сборки. Могу патчи обновлять в github после тестов, и обновлений develop версии Wine. На данный момент, это develop сборка Wine 9.2, и она довольно стабильно ведет себя в играх и лучше Wine 9.0. Пока в вайн develop не добавили, что-то критического и ломающего, и там больше багфиксов, то можно собирать dev сборки и использовать. В принципе, можно практически забыть про сборку Wine до следующего года, когда выйдет Wine 10.0. Хотя некоторые дистрибутив собирают dev версии Wine, вместо стабильных X.0 версий, которые выходят раз в год. Статья больше создана для тех кто хочет разобраться, как собрать Wine и как работает Proton. Не пропустите в пятницу вторую часть этой статьи, там мы эту сборку Wine превратим в Proton.
Нет, и не буду делать. Это не благодарное дело, я проходил уже это, делал форк пакетов Arch Linux. Выхлоп и отдача от этого 0, забирает кучу личного времени, и деньги на хостинг файлов.
Про "поделие" вы конечно завернули. Wayland давно уже готов к использованию. Насчет инпут лага у меня есть, что вам ответить, процитирую автора sway:
No. A well-optimized vsync compositor has comparable latency to tearing content updates. Instead of investing efforts in tearing, invest efforts in improving vsync.
X11 сложнее в реализации, с кучей расширений и багов, отсюда он использует больше ресурсов, Wayland же более легкий и современный протокол. Самое главное в Wayland нет разрывов и статеров, цена тому задержка не превышающая 1 кадр, что на 240гц мониторе вы даже не заметите, при этом будет более плавная картинка, в шутеры играть со статерами ужасно, и я проходил это в X11. Задержку можно уменьшить включив VRR, который сейчас используют большинство мониторов. По личному опыту играть в Apex в X11 c Proton очень сложно, дикие статеры, картинка скачет, 240гц ощущаются как 60гц, все реагирует с заметным запозданием. При этом в Sway у меня плавная картинка, и все отзывчиво на команды от мыши и клавиатуры. Потому, что кроме vsync инпут лаг вносит кучу компонентов в системе. И есть вполне объективные способы проверить, что стало лучше, есть бенчмарки AIM. Например в Apex чем ниже инпут лаг тем легче контролить спрей в точку т.к. игра быстрее реагирует на мышь. Если есть инпут лаг, то спрей контролить сложнее, это очень заметно в такой игре как Apex. Плюс например в Overwatch 2 можно запустить VAXTA и сравнить результаты на Widow и Soldier 76, точность вырастает, и можно трекать более мелкие движения и больше попадать в голову. Я сравнивал Windows, Gamescope(запуск как DE без прослойки из композитора), KDE X11 и инпут лаг в Sway не хуже. Ну а если у вас монитор 60гц, то это не про игру в шутеры, нормальных результатов там не добиться с 60гц, можно забыть про инпут лаг и играть, что-то казуальное.
Fedora is going to completely remove X11 for certain desktop environments and is going to use wayland now.
В Wine-tkg старая версия FSync патча. Я переносил вручную, обновленную версию из Proton, там больше функций синхронизации она поддерживает. dxvk и vkd3d-proton нет смысла собирать используя левый репозиторий, просто клонируете dxvk и vkd3d-proton и собираете, месу да в ручную собираю, но со своими патчами, про один из патчей я написал во второй части статьи. Кастомные ядра кривые, у меня свое ядро, плюс многие оптимизации про которые пишут в интернете таковыми не являются, например меня порадовала безграмотность специалистов из убунты, которые не понимают, что делают, и приписывают параметрам ядра из статьи ниже Low Latency, когда там почти все параметры заставляют экономить энергопотребление, пропуская работу некоторых функций ядра, что полезно например для ноутбуков и никаким Low Latency там не пахнет, и Latency увеличивается от этих параметров. https://www.phoronix.com/news/Ubuntu-Low-Lat-Generic-Kernel
Отсюда доверяй, но проверяй! Изучайте сами параметры ядра, тестируйте, и не копируйте чужие ошибки.
Самое главное почему писалась статья, ни официальный Proton, ни GE не умеют работать нативно в Wayland! И скорее всего поддержку Wayland не завезут даже в Proton 9 из-за отсутствия некоторого функционала в Wine Wayland, и будет он добавлен только в Wine 10 в следующем году. А мне же удалось запустить игры Steam, и с помощью самописного патча добавить Raw Input в Wine Wayland. С учетом, что все переходят на Wayland, а я на Wayland уже несколько лет, то этот опыт будет полезен другим людям.
Proton не стабилен из грязных специфичных хаков для определенных игр. Эти хаки грязнее чем патчи из Wine-Staging. Отсюда вы их чаще всего никогда не увидите в основном Wine. Отсюда могут быть разные ошибки, и не стабильная работа в некоторых играх. Моя задача была получить лучший результат в шутерах, в которые я играю.
Wine 9.0 из дистрибутивов не стабилен и содержит ошибки. Мною же ошибки были пофиксены с помощью патчей. В дистрибутивах обычно есть только Esync т.к. применяют патчи Wine-Staging, но нет FSync и темболее NtSync. Чем лучше FSync и NtSync вы можете загуглить в интернете.
Лучше поддержка Native Wayland чем в Wine 9.0.
У меня FPS плюс минус такой же, но зато инпут лаг заметно ниже, меньше пропусков кадров и статеров, особенно это заметно в игре Apex Legends. При этом результат на 240гц мониторе, лучше чем в Windows, или X11 c Proton. На удивление игры имеют лучшую производительность в Wine чем в Windows. Про специфику протона написано во второй части статьи, она выйдет в пятницу.
Очень часто люди спрашивают, как запустить Steam игры в Wine c Native Wayland. Ставят Steam в Wine, и это не работает. Я один из первых кто еще в декабре смог запустить Steam игры в Wine Wayland.
Объяснить специфику ручной сборки Wine и Proton. Официальный протон собирается в контейнере и скрипты сборки сложны для изучения новичками не знакомыми с Proton.
Нет, Линус Торвальдс не принял патчи по причине того, что якобы можно для этого еще использовать написанный им perf, но я нигде не видел как это сделать. Теоретически можно использовать AutoFDO, но когда я с ним игрался и с ядром ничего хорошего из этого не вышло, профиль нормально не собирался. Чистой воды политика.
Я там ничего не ускорял, перечитайте внимательно статью, там все изменения написаны в последнем абзаце.
Если в кратце я добавил поддержку профиля llvm 13-14, оригинальная версия патча работала с профилем 12 версии, она собирала профиль, но при конвертации сырого профиля выскакивала ошибка т.к. формат профиля отличался.
После того как компания Google выпустила набор патчей для PGO оптимизации, мною была добавлена поддержка LLVM 13 и LLVM 14, т.к. в них менялся формат профиля и с оригинальными патчами clang его не понимает. Также файл профиля и сброса были перенесены из debugfs в proc для устранения проблем с включённым kernel_lockdown (man kernel_lockdown) в ядре Linux, который не даёт прочесть профиль. Данное изменение позволять профилировать ядро с включёнными системами безопасности ядра, без их отключения на этапе загрузки. Дополнительную информацию вы можете найти в файле Documentation/dev-tools/pgo.rst после применения патча ядра.
Что что? На нем не сделана половина DE. В Wayland большая часть DE сделаны с помощью Wlroots. Так что не надо с больной головы на здоровую перекладывать. gtk это чисто гномовская разработка, и что они там пилят, это только их проблемы. В KDE к примеру лучше все, там даже починили fractional scaling в прошлом году, а KDE 6 будет еще лучше.
Опять с больной головы на здоровую перекладываете. Проблемы вашего производителя GPU не проблемы Wayland. У NV дерьмовые драйвера, и они нормально egl и vulkan расширения не могут реализовать, и другим надо костылить из-за лени и закрытости NV. Даже у Intel вероятно намного лучше драйвер сделан и они постоянно что-то новое добавляют в свой драйвер.
Тут я процитирую вас же вашими словами:
Еще раз, что вам мешает сделать форк и пилить свои патчи и отправлять в апстрим? Разработка xorg в гитлаб идет и там постоянно патчи новые принимают.
Вранье чистой воды. Есть Wayland Protocols в котором описаны все протоколы, DE обязаны поддерживать Wayland Protocols которые им необходимы. Т.е. DE не может и изменить какой-то протокол на свое усмотрение. Wayland Protocols развивается, некоторые протоколы устаревают и им на замену приходят новые, некоторые переходят и staging в stable и в этом случае чуть меняются имена функций генерируемых сканеров. В остальном Wayland Protocols это стандарт, как должен быть реализован тот или иной протокол.
Это вообще не проблема Wayland. Вы бы еще влияние фазы луны на курс доллара тут написали. В Wayland как раз этот функционал отдали клиенту сервера, из-за того, что это очень ресурсоемкая задача, не все ими пользуются и сервер не должен этим заниматься.
В таком случае я был 7 лет назад балеруном.
Что же вы не организуете и патчи не отправить в апстрим? Заодно статью тут напишете про это.
В следующем году. Цикл разработки в Wine и выпуск стабильной версии - 1 год. Плюс самому протону надо некоторые их разработки перевести на Wayland.
Не смог найти такую инфу в интернете. Зато нашел: https://www.linux.org.ru/forum/talks/16012023
Да ладно? Это не конфиги, а сценарии. Сценарии запускаются при определенном условии, прописанном в них. Дальше они через API и секретного ключа передают задание на внешний сервер, там происходит сборка. Дальше происходит тестирование, а затем сборка артефактов с сервера сборка и упаковка в архив и загрузка на гитхаб. Мне гитхаб предлагает скачать их агент https://github.com/actions/runner/releases/download/v2.313.0/actions-runner-linux-x64-2.313.0.tar.gz и поставить на своей сервер. Как знаю github не предоставляет свои мощности для сборки, а только дает аналог Jenkins, Travis CI, Gitlab CI/CD.
Proton и GE используют CI/DI для сборки в контейнере. Для этого нужен сервер с Docker. Там более сложные сборочные скрипты. Они поставляют кучу системных компонентов типа ffmpeg и gstreamer, чтобы сборки были переносимые и работали на любой Linux. Сборка такого проекта вместо минут 10 превратится в час. Дальше это все запускается в Steam в виртуальной контейнере с ubuntu linux и изолированно от вашей системы, системных библиотек! Да здравствуют всеми любимые namespaces и cgroups в Linux. Про это я расскажу завтра, во второй части данной статьи посвященной Wine и Proton.
Да, только в том случае если у вас топовая видеокарта и куплена Windows. А в линукс можно получить минимальный FPS где-то на 20 кадров в секунду больше в Apex Legends на моей AMD Radeon RX5700XT.
Смысла нет, да и дебиана у меня тоже нет, если брать и копипастить готовые команды из двух статей, то на копипаст уйдет не больше минуты, а на общую сборку минут 10. Все скрипты можно скопировать и сохранить, как shell скрипты, и запускать для сборки. Могу патчи обновлять в github после тестов, и обновлений develop версии Wine. На данный момент, это develop сборка Wine 9.2, и она довольно стабильно ведет себя в играх и лучше Wine 9.0. Пока в вайн develop не добавили, что-то критического и ломающего, и там больше багфиксов, то можно собирать dev сборки и использовать. В принципе, можно практически забыть про сборку Wine до следующего года, когда выйдет Wine 10.0. Хотя некоторые дистрибутив собирают dev версии Wine, вместо стабильных X.0 версий, которые выходят раз в год. Статья больше создана для тех кто хочет разобраться, как собрать Wine и как работает Proton. Не пропустите в пятницу вторую часть этой статьи, там мы эту сборку Wine превратим в Proton.
Было бы интересно, если бы люди читали статью и комментарии.
Инпут лаг это не про FPS.
Нет, и не буду делать. Это не благодарное дело, я проходил уже это, делал форк пакетов Arch Linux. Выхлоп и отдача от этого 0, забирает кучу личного времени, и деньги на хостинг файлов.
Про "поделие" вы конечно завернули. Wayland давно уже готов к использованию. Насчет инпут лага у меня есть, что вам ответить, процитирую автора sway:
X11 сложнее в реализации, с кучей расширений и багов, отсюда он использует больше ресурсов, Wayland же более легкий и современный протокол. Самое главное в Wayland нет разрывов и статеров, цена тому задержка не превышающая 1 кадр, что на 240гц мониторе вы даже не заметите, при этом будет более плавная картинка, в шутеры играть со статерами ужасно, и я проходил это в X11. Задержку можно уменьшить включив VRR, который сейчас используют большинство мониторов. По личному опыту играть в Apex в X11 c Proton очень сложно, дикие статеры, картинка скачет, 240гц ощущаются как 60гц, все реагирует с заметным запозданием. При этом в Sway у меня плавная картинка, и все отзывчиво на команды от мыши и клавиатуры. Потому, что кроме vsync инпут лаг вносит кучу компонентов в системе. И есть вполне объективные способы проверить, что стало лучше, есть бенчмарки AIM. Например в Apex чем ниже инпут лаг тем легче контролить спрей в точку т.к. игра быстрее реагирует на мышь. Если есть инпут лаг, то спрей контролить сложнее, это очень заметно в такой игре как Apex. Плюс например в Overwatch 2 можно запустить VAXTA и сравнить результаты на Widow и Soldier 76, точность вырастает, и можно трекать более мелкие движения и больше попадать в голову. Я сравнивал Windows, Gamescope(запуск как DE без прослойки из композитора), KDE X11 и инпут лаг в Sway не хуже. Ну а если у вас монитор 60гц, то это не про игру в шутеры, нормальных результатов там не добиться с 60гц, можно забыть про инпут лаг и играть, что-то казуальное.
Вы статью не читали? Там есть ссылки на MR! Только многие MR вы увидите только в следующем dev релизе или в Wine 10.
Делают только его перебазирование, но это старая версия Fsync.
Сравните файлы https://github.com/ValveSoftware/wine/blob/7e4f2dd4c74d5721b59e0340ac31beeda3c7578c/server/fsync.c
https://github.com/ValveSoftware/wine/blob/7e4f2dd4c74d5721b59e0340ac31beeda3c7578c/dlls/ntdll/unix/fsync.c
А если вам лень, то сравните просто server protocols и поищите строки fsync https://github.com/ValveSoftware/wine/blob/7e4f2dd4c74d5721b59e0340ac31beeda3c7578c/server/protocol.def
В Wine-tkg старая версия FSync патча. Я переносил вручную, обновленную версию из Proton, там больше функций синхронизации она поддерживает.
dxvkиvkd3d-protonнет смысла собирать используя левый репозиторий, просто клонируетеdxvkиvkd3d-protonи собираете, месу да в ручную собираю, но со своими патчами, про один из патчей я написал во второй части статьи. Кастомные ядра кривые, у меня свое ядро, плюс многие оптимизации про которые пишут в интернете таковыми не являются, например меня порадовала безграмотность специалистов из убунты, которые не понимают, что делают, и приписывают параметрам ядра из статьи ниже Low Latency, когда там почти все параметры заставляют экономить энергопотребление, пропуская работу некоторых функций ядра, что полезно например для ноутбуков и никаким Low Latency там не пахнет, и Latency увеличивается от этих параметров. https://www.phoronix.com/news/Ubuntu-Low-Lat-Generic-KernelОтсюда доверяй, но проверяй! Изучайте сами параметры ядра, тестируйте, и не копируйте чужие ошибки.
Вот мой скрипт сборки
dxvkиvkd3d-proton: https://pastebin.com/6qQBwbjrСамое главное почему писалась статья, ни официальный Proton, ни GE не умеют работать нативно в Wayland! И скорее всего поддержку Wayland не завезут даже в Proton 9 из-за отсутствия некоторого функционала в Wine Wayland, и будет он добавлен только в Wine 10 в следующем году. А мне же удалось запустить игры Steam, и с помощью самописного патча добавить Raw Input в Wine Wayland. С учетом, что все переходят на Wayland, а я на Wayland уже несколько лет, то этот опыт будет полезен другим людям.
Proton не стабилен из грязных специфичных хаков для определенных игр. Эти хаки грязнее чем патчи из Wine-Staging. Отсюда вы их чаще всего никогда не увидите в основном Wine. Отсюда могут быть разные ошибки, и не стабильная работа в некоторых играх. Моя задача была получить лучший результат в шутерах, в которые я играю.
Wine 9.0 из дистрибутивов не стабилен и содержит ошибки. Мною же ошибки были пофиксены с помощью патчей. В дистрибутивах обычно есть только Esync т.к. применяют патчи Wine-Staging, но нет FSync и темболее NtSync. Чем лучше FSync и NtSync вы можете загуглить в интернете.
Лучше поддержка Native Wayland чем в Wine 9.0.
У меня FPS плюс минус такой же, но зато инпут лаг заметно ниже, меньше пропусков кадров и статеров, особенно это заметно в игре Apex Legends. При этом результат на 240гц мониторе, лучше чем в Windows, или X11 c Proton. На удивление игры имеют лучшую производительность в Wine чем в Windows. Про специфику протона написано во второй части статьи, она выйдет в пятницу.
Очень часто люди спрашивают, как запустить Steam игры в Wine c Native Wayland. Ставят Steam в Wine, и это не работает. Я один из первых кто еще в декабре смог запустить Steam игры в Wine Wayland.
Объяснить специфику ручной сборки Wine и Proton. Официальный протон собирается в контейнере и скрипты сборки сложны для изучения новичками не знакомыми с Proton.
Для удобства сравнения результатов можете использовать KDiff3 или Kompare.
Если в кратце я добавил поддержку профиля llvm 13-14, оригинальная версия патча работала с профилем 12 версии, она собирала профиль, но при конвертации сырого профиля выскакивала ошибка т.к. формат профиля отличался.