Comments 58
Не помешало бы в первом абзаце написать зачем всё это нужно и что это даёт по сравнению обычным wine/proton из дистрибутива.
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.
>Мною же ошибки были пофиксены с помощью патчей
Предложить мёрж реквесты мейнтейнерам вайна не вариант? Или там от абы кого не принимают?
Тем временем поставить винду 3 минуты...
Да, только в том случае если у вас топовая видеокарта и куплена Windows. А в линукс можно получить минимальный FPS где-то на 20 кадров в секунду больше в Apex Legends на моей AMD Radeon RX5700XT.
Явно не 3 минуты)
Тут кстати скорей всего будет парадокс, что с нуля установка линуха и запуск игры будет гораздо быстрей, чем венда установится с её тысячами перезагрузок и запуск игры)
Давно видимо последний раз винду ставили) моя последняя установка 11 заняла не более пяти минут, далее все зависит от скорости инета и собственной расторопности, а у токсичной линьки то дрова отвалятся то пакеты не найдутся/не встанут а да упаси это все еще не обновить перед началом + этот секас с терминалом ну камон)
Давно похоже не пользовались линухом) Наверно лет 15)
Как помнится венда всё ещё перегружается при установке и что там накручивает, последний раз ставил на быстрый SSD и всё это заняло в сравнении установки в тот же день линух, раза в три-пять больше времени чем у линуха, который к тому же был не пустой как венда, а сразу с горой софта)
Самое главное почему писалась статья, ни официальный Proton, ни GE не умеют работать нативно в Wayland! И скорее всего поддержку Wayland не завезут даже в Proton 9 из-за отсутствия некоторого функционала в Wine Wayland, и будет он добавлен только в Wine 10 в следующем году. А мне же удалось запустить игры Steam, и с помощью самописного патча добавить Raw Input в Wine Wayland. С учетом, что все переходят на Wayland, а я на Wayland уже несколько лет, то этот опыт будет полезен другим людям.
Если ты вы запилили ppa с deb пакетами, я бы вам даже спасибо сказал :)
Смысла нет, да и дебиана у меня тоже нет, если брать и копипастить готовые команды из двух статей, то на копипаст уйдет не больше минуты, а на общую сборку минут 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.
Да уж, после такого никакие игры уже не нужны. Посмотреть красными глазами на восход солнца и пойти досыпать последние часы перед работой.
Пользуюсь вот этим репозиторием для сборки WINE: https://github.com/Frogging-Family/wine-tkg-git
Так же собираю себе ядро и месу: https://github.com/Frogging-Family/linux-tkg и https://github.com/Frogging-Family/mesa-git соответственно
Для dxvk и vkd3d-proton использую https://github.com/Frogging-Family/dxvk-tools
Очень удобные скрипты, с возможностью конфигурирования отдельными конфиг файлами вне репозитория и простой патчинг закидыванием файлов в папку. Очень рекомендую, уже пару лет пользуюсь.
В 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
В Wine-tkg старая версия FSync патча
Она не может быть старой, когда есть конфиг _protonify=true. Тем более патч протонизации постоянно обновляют под новые версии вайна. Если уж так хочется без "грязных хаков протона" (а без них я вообще не представляю как играть) - берётся свежий winesync/ntsync и ставится ядерный модуль из dkms.
dxvkиvkd3d-protonнет смысла собирать используя левый репозиторий, просто клонируетеdxvkиvkd3d-protonи собираете
Именно потому что мне лень. Я в "левый репозиторий" кинул свой конфиг, патчи build-winXX.txt (флаги компиляции) и двумя командами у меня есть всегда bleeding edge сборки, на которые симлинком смотрит мой wineprefix - не надо ничего даже копировать.
меня порадовала безграмотность специалистов из убунты
Ну здесь снимаю шляпу. Я когда свалил на арчеподобные, прямо пожалел себя - сколько же времени я убил на борьбу с убунтой, когда есть замечательный суперстабильный дистрибутив с максимально дружелюбной пакетной системой. Плюс становишься старым и хочется один раз сделать конфиг и потом 2 года его собирать, а не вот это всё убунтовое.
тестируйте, и не копируйте чужие ошибки
Полностью разделяю такой подход, поэтому прошу прощения, так как вынужден отказаться от
Вот мой скрипт сборки
=)
Она не может быть старой
Делают только его перебазирование, но это старая версия Fsync.
Сравните файлы https://github.com/ValveSoftware/wine/blob/7e4f2dd4c74d5721b59e0340ac31beeda3c7578c/server/fsync.c
А если вам лень, то сравните просто server protocols и поищите строки fsync https://github.com/ValveSoftware/wine/blob/7e4f2dd4c74d5721b59e0340ac31beeda3c7578c/server/protocol.def
Господи Иисусе... Сколько всего чтобы просто поиграть :(
Мне честно говоря было лень все это делать. Устанавливаю на Винде игры, потом в линухе через Стим запускаю.
А можете просто в линухе устанавливать и играть. Под иксами конечно. Зачем автор заморочился с Wayland(который уже 15 лет "почти готов") не понятно. Пробую это поделие каждый год, но оно всё ещё не готово. Конкретно у меня даже инпут лаг под вайландом выше.
Про "поделие" вы конечно завернули. 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.
See the discussion in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/65
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.
https://www.reddit.com/r/Fedora/comments/16r2un6/fedora_removes_x11/
Wayland не лёгкий и не современный. 2008 год же, не сильно моложе иксов уже. Каждый пилит свою реализацию, не совместимую с остальными. Как там в 2024, научились уже в gtk приложениях оконными декорациями управлять? Я думаю нет. А зелёные карточки как поживают?
Вообще я как-то сам был амбосадором wayland и пытался в него ещё лет 7 назад. Хайпово же, круто, модно, современно. Как было его не попробовать. Но ощутив какое это г... я вернулся на иксы. С тех пор каждый год тыкаю новый композитор и возвращаюсь обратно на AwesomeWM. Хотя идеи конечно есть крутые, к примеру 2 недели назад пробовал Niri, очень понравилась концепция управления окнами. Но wayland портит всё.
Вот если бы усилия разрабов направить на фикс иксов, то уже бы отлично жили. Потому что проблем там на текущий момент меньше чем у вейланда. Не слушайте мифы про безопасность(её там легко организовать, чтобы каждый клиент не имел полный доступ) или отсутствие hdr(сами иксы могут). Да и разную частоту с разным разрешением на разных мониторах тоже можно настроить.
Раньше я всё ждал когда же ситуация улучшится, но нет у меня больше надежды что вейланд допилят в ближайшие пару лет. Я следил за обсуждением расширений wayland, там всё печально. Гномеры пилят свой собственный мирок и болт ложили на мнение всех остальных.
Если вам очень нравится идея запилить всё по новой и с учётом ошибок иксов, то рекомендую взглянуть на arcan. Это просто великолепнейшая вещь с технической точки зрения. По возможностям и продуманности превосходит вейланд на порядок. И будущее у него позитивное. А самое главное вдохновляет, ощущение что автор у себя звездолёт в гараже пилит, пока ты пытаешься починить велосипед. И ведь уже который год пилит и не забрасывает.
UPD:
про федору то понятно. Они пилят гном, они же затеяли вейланд. Причину я не знаю, может им лицензия иксов не нравится, может хотят дискредитировать весь десктопный линукс(у них это отлично получается с гномом).
А монитор у меня 144 герца, честно говоря не вижу смысла для 27 дюйм выше, я думаю попросту не замечу разницы, а вот железо нужно дорогое. Но и в шутеры я толком не играю, так иногда заглядываю в батлбит.
ак там в 2024, научились уже в gtk приложениях оконными декорациями управлять?
При чём тут бзик разрабов gtk до Wayland?
А зелёные карточки как поживают?
Нормально уже пару лет как поживают
Вот если бы усилия разрабов направить на фикс иксов, то уже бы отлично жили.
Разрабы сами забили на иксы, их уже ничто не спасёт.
Да и разную частоту с разным разрешением на разных мониторах тоже можно настроить.
Нельзя никак и пофиксить это не возможно
При чём тут бзик разрабов gtk до Wayland?
Ну действительно. Это же всего лишь туклит на котором половина DE сделана. А ещё большая часть приложений под linux его использует.
Вы так написали, какбудто это не Redhat инициировал разработку Wayland и не ведёт в ней активно участие. Вы знаете кто принимает решения по экстеншенам Wayland?
Нормально уже пару лет как поживают
Ну это откровенная ложь даже на текущий момент. А уж пару лет назад было совсем печально. Вот интересующимся пруфы про текущий момент:
А вот про пару лет назад:
https://github.com/hyprwm/Hyprland/issues/12
Я уже и забыл про такую забавную штуку как флаг --my-next-gpu-wont-be-nvidia без которого не запустить композитор.
Разрабы сами забили на иксы, их уже ничто не спасёт.
Не малая часть разарбов иксов к сожалению либо мертвы, либо на пенсии. Хотя пару человек точно осталось и допиливают иксы. Но некоторые злые языки распостраняют дезу что все разрабы отказались от иксов и они вообще заброшены.
Нельзя никак и пофиксить это не возможно
Вы не предполагали, что если человек что-то пишет, то он пишет не безосновательно? Возможно даже на своём опыте? Ну по крайней мере я такое по умолчанию предполагаю о собеседнике, как бы основы культурного общения.
Ну действительно. Это же всего лишь туклит на котором половина DE сделана. А ещё большая часть приложений под linux его использует.
Тем не менее это именно бзик разрабов gtk, только они одни отказались реализовывать csd по религиозным соображениям.
Вы так написали, какбудто это не Redhat инициировал разработку Wayland и не ведёт в ней активно участие. Вы знаете кто принимает решения по экстеншенам Wayland?
Ред хат и за иксы отвечал и именно разрабы иксов решили написать все с нуля. RTFM.
Ну это откровенная ложь даже на текущий момент.
Мой Sway на оптимус ноуте уже давно запускается без --my-next-gpu-wont-be-nvidia
Не малая часть разарбов иксов к сожалению либо мертвы, либо на пенсии.
Похоже вы давно не в теме
Вы не предполагали, что если человек что-то пишет, то он пишет не безосновательно?
По вашей ссылке костыль для зелёных карт, на моей АМД он не заведется, поэтому да, безосновательно.
По вашей ссылке костыль для зелёных карт, на моей АМД он не заведется, поэтому да, безосновательно.
У меня амд встройка. И когда было два моника, я настраивал разную частоту. Без проблем, что-то там где-то прописал и всё заработало
Мой Sway на оптимус ноуте уже давно запускается без
--my-next-gpu-wont-be-nvidia
Вот только этот флаг был в контексте "про пару лет назад". С таким передёргиванием контекста и негативом не вижу смысла продолжать обсуждение.
Это же всего лишь туклит на котором половина 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 в гитлаб идет и там постоянно патчи новые принимают.
На нем не сделана половина DE. В Wayland большая часть DE сделаны с помощью Wlroots.
Для Wayland всего два DE пока что: KDE и Gnome. Ни крысу, ни что либо ещё на сколько я знаю ещё не портировали. Ну м.б. ещё какой-нибудь budgie уже перёшл, но там тоже gtk.
Всякие sway это композиторы, не путайте.
А вот под иксы много DE. И большая часть на GTK. А уже софта и тем более больше под GTK к сожалению.
Проблемы вашего производителя GPU не проблемы Wayland.
Вы как-то из контекста вырываете. Вопрос был про зелёные карточки. Человек соврал что всё отлично. Я показал что это ложь. Теперь вы говорите что самые популярные видеокарты это не проблема Wayland.
Даже у Intel вероятно намного лучше драйвер сделан
Два года назад на ноутах с интеловской встройкой у меня были проблемы с шатерингом в играх. И я был далеко не одинок. А уж какое качество дров у их новых дискретных GPU. Хотя активно фиксят вроде.
Еще раз, что вам мешает сделать форк и пилить свои патчи и отправлять в апстрим?
Тем что разработку курирует Redhat и они показали своё отношение. Изменения(а не багфиксы) туда протолкнуть около не реально.
Да и иксы действительно лучше переписать с нуля. Но не под руководством от Redhat. Благо есть mir и arcan. Я если и буду контрибьютить, то в аркан.
Опять с больной головы на здоровую перекладываете. Проблемы вашего производителя GPU не проблемы Wayland. У NV дерьмовые драйвера, и они нормально egl и vulkan расширения не могут реализовать, и другим надо костылить из-за лени и закрытости NV. Даже у Intel вероятно намного лучше драйвер сделан и они постоянно что-то новое добавляют в свой драйвер.
безотносительно wayland.
С LLM на линуксе все отлично на nvidia потому что идеально работающая CUDA. С AMD танцы с бубном потому что opensource rocm...слишком уж opensource, но потихоньку решается хотя производительность пониже. Intel? а это что такое?
Вот ROCM действительно отвратителен. Я думал добавить пакет в void-linux, но это просто ужас какой-то и я сдался. А ещё он последние версии начиная с ROCM 5.7 не работают с Linux старше 6.2
Хотя опенсорсность здесь не причём. Просто кривые руки разрабов.
Мне значительно помогло повысить производительность обновив ядро до 6.6 на ROCm 5.6. Последнюю(6.0) я не тыкал, жду когда выйдет исправление бага выше.
Каждый пилит свою реализацию, не совместимую с остальными.
Вранье чистой воды. Есть Wayland Protocols в котором описаны все протоколы, DE обязаны поддерживать Wayland Protocols которые им необходимы. Т.е. DE не может и изменить какой-то протокол на свое усмотрение. Wayland Protocols развивается, некоторые протоколы устаревают и им на замену приходят новые, некоторые переходят и staging в stable и в этом случае чуть меняются имена функций генерируемых сканеров. В остальном Wayland Protocols это стандарт, как должен быть реализован тот или иной протокол.
научились уже в gtk оконными декорациями управлять
Это вообще не проблема Wayland. Вы бы еще влияние фазы луны на курс доллара тут написали. В Wayland как раз этот функционал отдали клиенту сервера, из-за того, что это очень ресурсоемкая задача, не все ими пользуются и сервер не должен этим заниматься.
Вообще я как-то сам был амбосадором wayland и пытался в него ещё лет 7 назад.
В таком случае я был 7 лет назад балеруном.
Не слушайте мифы про безопасность(её там легко организовать, чтобы каждый клиент не имел полный доступ) или отсутствие hdr(сами иксы могут).
Что же вы не организуете и патчи не отправить в апстрим? Заодно статью тут напишете про это.
> Каждый пилит свою реализацию, не совместимую с остальными.
Вранье чистой воды. Есть Wayland Protocols в котором описаны все
протоколы, DE обязаны поддерживать Wayland Protocols которые им
необходимы.
Я вот не пойму зачем вы упорно игнорируете реальность. Я предлагаю открыть доки по протоколу(https://wayland.app/protocols/) и убедиться в моих словах. Там есть 22 экстеншена от KDE. Думаете их поддерживает кто-то кроме kde? Ну вроде sway 1 или 2 поддерживал. Там есть 10 экстеншенов от wlr, скажете что вестон или гном их поддерживает? И там есть 11 от Weston, как их к примеру KDE поддерживает?
DE обязаны поддерживать Wayland Protocols которые им
необходимы.
Ну т.е. каждый пилит то что хочет. А разрабам софта что поддерживать? Они глянут на этот зоопарк и возьмут gtk чтобы не париться. И ой, а у gtk весьма своеобразная поддержка Wayland. Только то что интересно разрабам Gnome.
Или скажете что есть базовые протоколы которые обязаны поддерживать все композиторы? Ну дак таких протоколов всего 5. С ними только очень простой софт можно сделать.
И даже тут если пролистать вниз и глянуть кто и что поддерживает, то окажется что и здесь разногласия у композиторов.
Что же вы не организуете и патчи не отправить в апстрим?
Что за глупость. Почему я вообще должен? Как это вообще относится к обсуждению вообще?
Экстеншены вестона и кде используются только внутри кде и вестона. Это не официальные расширения. Я вот не пойму зачем вы упорно игнорируете реальность. Вот список официальных.
find /usr/share/wayland-protocols -type f
/usr/share/wayland-protocols/stable/presentation-time/presentation-time.xml
/usr/share/wayland-protocols/stable/viewporter/viewporter.xml
/usr/share/wayland-protocols/stable/xdg-shell/xdg-shell.xml
/usr/share/wayland-protocols/stable/linux-dmabuf/linux-dmabuf-v1.xml
/usr/share/wayland-protocols/staging/content-type/content-type-v1.xml
/usr/share/wayland-protocols/staging/drm-lease/drm-lease-v1.xml
/usr/share/wayland-protocols/staging/ext-idle-notify/ext-idle-notify-v1.xml
/usr/share/wayland-protocols/staging/ext-session-lock/ext-session-lock-v1.xml
/usr/share/wayland-protocols/staging/fractional-scale/fractional-scale-v1.xml
/usr/share/wayland-protocols/staging/single-pixel-buffer/single-pixel-buffer-v1.xml
/usr/share/wayland-protocols/staging/tearing-control/tearing-control-v1.xml
/usr/share/wayland-protocols/staging/xdg-activation/xdg-activation-v1.xml
/usr/share/wayland-protocols/staging/xwayland-shell/xwayland-shell-v1.xml
/usr/share/wayland-protocols/staging/cursor-shape/cursor-shape-v1.xml
/usr/share/wayland-protocols/staging/ext-foreign-toplevel-list/ext-foreign-toplevel-list-v1.xml
/usr/share/wayland-protocols/staging/security-context/security-context-v1.xml
/usr/share/wayland-protocols/staging/ext-transient-seat/ext-transient-seat-v1.xml
/usr/share/wayland-protocols/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
/usr/share/wayland-protocols/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
/usr/share/wayland-protocols/unstable/input-method/input-method-unstable-v1.xml
/usr/share/wayland-protocols/unstable/input-timestamps/input-timestamps-unstable-v1.xml
/usr/share/wayland-protocols/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
/usr/share/wayland-protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
/usr/share/wayland-protocols/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
/usr/share/wayland-protocols/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
/usr/share/wayland-protocols/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
/usr/share/wayland-protocols/unstable/primary-selection/primary-selection-unstable-v1.xml
/usr/share/wayland-protocols/unstable/relative-pointer/relative-pointer-unstable-v1.xml
/usr/share/wayland-protocols/unstable/tablet/tablet-unstable-v1.xml
/usr/share/wayland-protocols/unstable/tablet/tablet-unstable-v2.xml
/usr/share/wayland-protocols/unstable/text-input/text-input-unstable-v1.xml
/usr/share/wayland-protocols/unstable/text-input/text-input-unstable-v3.xml
/usr/share/wayland-protocols/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
/usr/share/wayland-protocols/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
/usr/share/wayland-protocols/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
/usr/share/wayland-protocols/unstable/xdg-output/xdg-output-unstable-v1.xml
/usr/share/wayland-protocols/unstable/xdg-shell/xdg-shell-unstable-v5.xml
/usr/share/wayland-protocols/unstable/xdg-shell/xdg-shell-unstable-v6.xml
/usr/share/wayland-protocols/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
Ну т.е. каждый пилит то что хочет.
Не пилят! Только свой софт который в паре с композитором работает может использовать эксперементальные расширения. Например так работают плагины в hyprland.
А разрабам софта что поддерживать?
Официальные расширения. см. выше.
Или скажете что есть базовые протоколы которые обязаны поддерживать все композиторы?
Не обязан никто поддерживать все. Все реализуют, то что им нужно. Например не всем нужен fractional scaling, банально это может быть простой wayland сервер для смартфона, где остальной интерфейс уже рисуют например с помощью egl. Но если вы пишете софт взаимодействующий с сервером, то он должен поддерживать официальные расширения, которые вам необходимы, и не городить изобретение колеса.
Что за глупость. Почему я вообще должен? Как это вообще относится к обсуждению вообще?
Так вы же топите за X11. Сделайте и рассказывайте, как все круто в X11, а на данный момент это потуги горе теоретика, который никогда не программировал ни X11 ни Wayland.
У меня к концу этой эпопеи уже желание играть пропало бы.
За статью плюс. Повторять этот путь я, конечно, не буду.
@nullc0deа вы не думали это дело опакетить и предоставить людям(и себе) удобный способ попробовать всё быстро и без возни? Я за федору не знаю, но должен же быть какой-то аналог AUR или хотя бы подключаемых реп.
Нет, и не буду делать. Это не благодарное дело, я проходил уже это, делал форк пакетов Arch Linux. Выхлоп и отдача от этого 0, забирает кучу личного времени, и деньги на хостинг файлов.
Странный у вас опыт. Мне кажется на эту статью ушло просто дочерта усилий и времени, а толку через уже пару месяцев от неё почти не будет. Зато пакетик чуть поправить и он будет актуальным. Про какой хостинг вы говорите? У вас же только инструкция по сборке, она размещается на самом aur'e. Если нужно какие-то патчи, то на гитхаб можно закинуть(бесплатно же).
Вы можете прямо на гитхаб (где у вас уже лежат патчи) выкладывать готовые сборки wine на основе ваших скриптов. Так GloriousEggroll делает, например. Тогда не придется тратить ни лишнее время, ни деньги на хостинг (ведь сборки вайна у вас уже есть, а хостинг бесплатный на гитхабе). И тогда любой желающий сможет воспользоваться вашей версией вайна без повторения всего опыта.
Proton и GE используют CI/DI для сборки в контейнере. Для этого нужен сервер с Docker. Там более сложные сборочные скрипты. Они поставляют кучу системных компонентов типа ffmpeg и gstreamer, чтобы сборки были переносимые и работали на любой Linux. Сборка такого проекта вместо минут 10 превратится в час. Дальше это все запускается в Steam в виртуальной контейнере с ubuntu linux и изолированно от вашей системы, системных библиотек! Да здравствуют всеми любимые namespaces и cgroups в Linux. Про это я расскажу завтра, во второй части данной статьи посвященной Wine и Proton.
Если что travis-ci дает бесплатно контейнеры для сборки опенсорса с гитхаба, можно настройить автосборку при коммите и загрузку артефактов. И вроде есть еще пара бесплатных вариантов.
Не смог найти такую инфу в интернете. Зато нашел: https://www.linux.org.ru/forum/talks/16012023
Он билдится прям на самом гитхабе с помощью github actions:
https://github.com/GloriousEggroll/proton-ge-custom/actions/runs/7683279330
Никаких серверов для этого не надо. Вот их конфиги:
https://github.com/GloriousEggroll/proton-ge-custom/blob/master/.github/workflows/build.yml
https://github.com/GloriousEggroll/proton-ge-custom/blob/master/.github/workflows/release.yml
Никаких серверов для этого не надо. Вот их конфиги
Да ладно? Это не конфиги, а сценарии. Сценарии запускаются при определенном условии, прописанном в них. Дальше они через 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.
Для меня как человека пользовавшегося actions очевидно что вы не разбираетесь в теме. И зачем-то делаете какие-то предположения(и агрессивно отстаиваете) вместо того чтобы просто проверить. Вот, я не поленился и форкнул репозиторий чтобы вам показать:
https://github.com/Jipok/proton-ge-custom/actions/runs/7934863774/job/21666743846
Это я оформил новый релиз и сборка пошла автоматически. Естественно никаких секрертных ключей и билд серверов не указывал.
У вас там сборка зависла. Я нашел инфу по бесплатным лимитам, там всего 500мб дают хранилища под релизы. GE пользуется платной подпиской. Да, и как показано по вашей ссылке, ваша сборка накрылась медным тазом.
Она не зависла. Я прерывал. Зачем бессмысленно тратить ресурсы?
Вы можете зайти и убедиться что сборка шла. Все этапы включая make. Логи там доступны.
Так запустите, сделайте бенчмарк сборки, сколько она займет.
И зачем это мне? Вы тут говорили что нужен Docker и свой билд сервер. Я показал что вы не правы.
Что касается производительности, то я уверен, что за ночь соберётся. Если вас интересуют подробности, то проверьте сами. Это буквально 5-10 кликов.
Так вы же утверждаете, что там все замечательно собирается, но по вышей же ссылке сборка завершилась с ошибкой. Слова с реальностью не вяжутся.
Я устал от этой бессмысленной возни. Ты как chatgpt - забываешь что было через одно сообщение назад.
Повторюсь: я прервал выполнение руками потому что итак было ясно что всё билдится на серверах предоставляем гитхабом бесплатно. И я не хочу бессмысленно эксплуатировать свободно предоставляемые ресурсы и ждать ненужного мне билда до конца.
В остальном я ухожу их этой дискуссии. Сообщения выше с кучей выхлопа вида /usr/share/wayland-protocols/unstable/... мне хватило.
Да, такие вещи надо в пакет и с описанием куда-то в дистры проталкивать. Wine-patch100500
Если честно, я вайн последний раз использовал (чистый вайн) лет так 10 или 12 назад, тогда играл в Deus Ex: Human Revolution. И тогда мне потребовалось внести всего 3 ключа в реестр, для починки пары багов и увеличения производительности. Кстати, работало быстрее чем на винде на том же железе (я пробовал подкинуть диск и поставить винду и игру там). А, ещë долго играл тогда в cs1.6 через вайн. Потом забросил надолго, и уже дальше на стимовском линуксовом играл в csgo, и чуток в 1.6 (не знаю, есть ли она ещë).
Пару лет назад наткнулся на упоминание игры Mafia, и поддался ностальгии, поставил протон, и с ним играл. Мне показалось, что довольно корявое поделие - протон этот. Баги тут и там, после завершения игры остаются кучи процессов .exe, и не так просто их прибить (иногда проще ребутнуть). Если уж и вайн сейчас такой... Надеюсь что нет (но пробовать не хочу, пока реальной потребности не будет).
Wine вещь вообще интересная и нужная. Жаль, на безопасность никто внимания не обращает. А ведь словить шифровальщика в нëм - без проблем. Если я ничего не забыл, вайн по умолчанию даëт хомяк юзера в виде диска (z что-ли), виндовым программам. А надо бы максимально ограничивать, и только если пользователь реально хочет, и после нескольких предупреждений давать такой доступ. Это раньше шутки про вирусы в линукс были (типа попробуй ещë запусти его там), а сейчас много чего прямо в фоне копается и делает свои грязные дела...
Столько возни а веселую ферму все равно не запустите
Было бы интересно ещё увидеть сравнение хотя бы для 2-3 игр разницы в ФПС. Просто для понимания насколько нативный Вейланд лучше искового. Ну и для понимания вообще смысла всех манипуляций. Плюс вам еще материал для статьи
Было бы интересно, если бы люди читали статью и комментарии.
FPS плюс минус такой же, но зато инпут лаг заметно ниже
Инпут лаг это не про FPS.
Безумно интересно было прочитать.
Однозначно + за старания
Запускаем игры под Wine c поддержкой Native Wayland