У вас там сборка зависла. Я нашел инфу по бесплатным лимитам, там всего 500мб дают хранилища под релизы. GE пользуется платной подпиской. Да, и как показано по вашей ссылке, ваша сборка накрылась медным тазом.
Это же всего лишь туклит на котором половина 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, но когда я с ним игрался и с ядром ничего хорошего из этого не вышло, профиль нормально не собирался. Чистой воды политика.
У вас там сборка зависла. Я нашел инфу по бесплатным лимитам, там всего 500мб дают хранилища под релизы. GE пользуется платной подпиской. Да, и как показано по вашей ссылке, ваша сборка накрылась медным тазом.
Что что? На нем не сделана половина 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.