Дробный масштаб если поддерживается соответствующий протокол не вызывает мыла. Мыло возникает только в Xwayland и там другая проблема, которая описана ниже в комментах. Но сейчас у меня осталось только одно приложение, которое не умеет нативно работать в Wayland и это Steam. Например в VS Code починили Wayland в последних релизах. Думаю, если у вас дистрибутив не эпохи царя гороха, то вы вряд ли найдете приложение, которое не умеет работать нативно в Wayland.
KDE не колхозят свой протокол для Fractional Scaling, это бы сломало совместимость и никто бы его кроме них не реализовал. Они решали проблему синхронизации размеров и координат виртуальных поверхностей Xwayland с композитором и реализовали это через хак - спавнят все диаголовые окна в центре экрана. Проблема заключается в том, что там сложные расчеты, надо считать unscale и scale размеры, что делали патчем xwayland. Патчи эти не принял никто. Но можно обойтись без патча xwayland, и делать unscale на стороне композитора, мыла не будет в xwayland, но окна будут спавниться в рандомном месте экрана, поэтому можно с помощью хака их спавнить всегда в центре экрана. Я делал похожий хак и MR для Hyprland https://github.com/hyprwm/Hyprland/pull/3942 и вот багрепорт https://github.com/hyprwm/Hyprland/issues/3029
Тут ключевая ошибка мышления, все думают как им удобно. Программисты это не UI специалисты, которые продумывают интерфейс. Это не коммерческий софт, где есть отдельные люди для этого. Поэтому все делается, по мере возможности, если вас не устраивает, форкайте и присылайте MR, люди коллективно подумают, и если все хорошо и правильно, примут ваш код в основной проект. Даже в коммерческом софте с одинаковым функционалом, хоткеи и скролл работают по разному! Все на усмотрение разработчика, ваши привычки не равно привычкам разработчика!
Экстеншены вестона и кде используются только внутри кде и вестона. Это не официальные расширения. Я вот не пойму зачем вы упорно игнорируете реальность. Вот список официальных.
Не пилят! Только свой софт который в паре с композитором работает может использовать эксперементальные расширения. Например так работают плагины в hyprland.
А разрабам софта что поддерживать?
Официальные расширения. см. выше.
Или скажете что есть базовые протоколы которые обязаны поддерживать все композиторы?
Не обязан никто поддерживать все. Все реализуют, то что им нужно. Например не всем нужен fractional scaling, банально это может быть простой wayland сервер для смартфона, где остальной интерфейс уже рисуют например с помощью egl. Но если вы пишете софт взаимодействующий с сервером, то он должен поддерживать официальные расширения, которые вам необходимы, и не городить изобретение колеса.
Что за глупость. Почему я вообще должен? Как это вообще относится к обсуждению вообще?
Так вы же топите за X11. Сделайте и рассказывайте, как все круто в X11, а на данный момент это потуги горе теоретика, который никогда не программировал ни X11 ни Wayland.
Проблема старого оборудования заключается в том, что оно содержит кучу ошибок, проектировалось на старых системах без должного тестирования. В современном мире они никому не нужны, разработчик кто поддерживал этот драйвер мог уже уйти из жизни, и кроме него никто в этом не разбирается. А у других людей нет этого оборудования, другие подсистемы, и другие задачи. Ядро сложное и содержит более 30млн строк кода, и каждый разработчик разбирается только в паре подсистем. Инженер проектировщик автодорог, не может стать врачом проктологом! Так же поддержка старого оборудования требует грязных хаков кода, написан код под старые компиляторы, и мешает поддержке более современного оборудования, компиляторов и безопасных стандартов С, отсюда не редко страдает производительность всего ядра! Весь этот старый код очень усложняет добавление нового кода и поддержку современного оборудования. Благо разработчики начали вычищать этот мусор и грязный код, чтобы было проще его сопровождать и разобраться в нем. Нужна поддержка старого оборудования, качайте старое ядро с архива, и не мешайте разработчикам делать свою работу.
Согласен с вами. Когда занимался Open Source проектами, то почти каждый второй приходит, и считает, что ты им что-то должен! Притом они очень настойчиво и в грубой форме пытаются в этом тебя убедить! И не важно, что ты итак тратишь свои деньги и время на поддержание проекта. Open Source это не благотворительность, у людей есть кроме этого основная работа, семья, и еще куча проблем. Если что-то не устраивает, бери и форкай проект, это никто не запрещает.
У вас там сборка зависла. Я нашел инфу по бесплатным лимитам, там всего 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.
FS давно уже поддерживают все нормальные композиторы, проблема только есть в XWayland. Но это не проблема Wayland, это проблема X11.
Дробный масштаб если поддерживается соответствующий протокол не вызывает мыла. Мыло возникает только в Xwayland и там другая проблема, которая описана ниже в комментах. Но сейчас у меня осталось только одно приложение, которое не умеет нативно работать в Wayland и это Steam. Например в VS Code починили Wayland в последних релизах. Думаю, если у вас дистрибутив не эпохи царя гороха, то вы вряд ли найдете приложение, которое не умеет работать нативно в Wayland.
KDE не колхозят свой протокол для Fractional Scaling, это бы сломало совместимость и никто бы его кроме них не реализовал. Они решали проблему синхронизации размеров и координат виртуальных поверхностей Xwayland с композитором и реализовали это через хак - спавнят все диаголовые окна в центре экрана. Проблема заключается в том, что там сложные расчеты, надо считать unscale и scale размеры, что делали патчем xwayland. Патчи эти не принял никто. Но можно обойтись без патча xwayland, и делать unscale на стороне композитора, мыла не будет в xwayland, но окна будут спавниться в рандомном месте экрана, поэтому можно с помощью хака их спавнить всегда в центре экрана. Я делал похожий хак и MR для Hyprland https://github.com/hyprwm/Hyprland/pull/3942 и вот багрепорт https://github.com/hyprwm/Hyprland/issues/3029
Тут ключевая ошибка мышления, все думают как им удобно. Программисты это не UI специалисты, которые продумывают интерфейс. Это не коммерческий софт, где есть отдельные люди для этого. Поэтому все делается, по мере возможности, если вас не устраивает, форкайте и присылайте MR, люди коллективно подумают, и если все хорошо и правильно, примут ваш код в основной проект. Даже в коммерческом софте с одинаковым функционалом, хоткеи и скролл работают по разному! Все на усмотрение разработчика, ваши привычки не равно привычкам разработчика!
Так вы же утверждаете, что там все замечательно собирается, но по вышей же ссылке сборка завершилась с ошибкой. Слова с реальностью не вяжутся.
Экстеншены вестона и кде используются только внутри кде и вестона. Это не официальные расширения. Я вот не пойму зачем вы упорно игнорируете реальность. Вот список официальных.
Не пилят! Только свой софт который в паре с композитором работает может использовать эксперементальные расширения. Например так работают плагины в hyprland.
Официальные расширения. см. выше.
Не обязан никто поддерживать все. Все реализуют, то что им нужно. Например не всем нужен fractional scaling, банально это может быть простой wayland сервер для смартфона, где остальной интерфейс уже рисуют например с помощью egl. Но если вы пишете софт взаимодействующий с сервером, то он должен поддерживать официальные расширения, которые вам необходимы, и не городить изобретение колеса.
Так вы же топите за X11. Сделайте и рассказывайте, как все круто в X11, а на данный момент это потуги горе теоретика, который никогда не программировал ни X11 ни Wayland.
Так запустите, сделайте бенчмарк сборки, сколько она займет.
Проблема старого оборудования заключается в том, что оно содержит кучу ошибок, проектировалось на старых системах без должного тестирования. В современном мире они никому не нужны, разработчик кто поддерживал этот драйвер мог уже уйти из жизни, и кроме него никто в этом не разбирается. А у других людей нет этого оборудования, другие подсистемы, и другие задачи. Ядро сложное и содержит более 30млн строк кода, и каждый разработчик разбирается только в паре подсистем. Инженер проектировщик автодорог, не может стать врачом проктологом! Так же поддержка старого оборудования требует грязных хаков кода, написан код под старые компиляторы, и мешает поддержке более современного оборудования, компиляторов и безопасных стандартов С, отсюда не редко страдает производительность всего ядра! Весь этот старый код очень усложняет добавление нового кода и поддержку современного оборудования. Благо разработчики начали вычищать этот мусор и грязный код, чтобы было проще его сопровождать и разобраться в нем. Нужна поддержка старого оборудования, качайте старое ядро с архива, и не мешайте разработчикам делать свою работу.
Согласен с вами. Когда занимался Open Source проектами, то почти каждый второй приходит, и считает, что ты им что-то должен! Притом они очень настойчиво и в грубой форме пытаются в этом тебя убедить! И не важно, что ты итак тратишь свои деньги и время на поддержание проекта. Open Source это не благотворительность, у людей есть кроме этого основная работа, семья, и еще куча проблем. Если что-то не устраивает, бери и форкай проект, это никто не запрещает.
Может это сделаете вы?
У вас там сборка зависла. Я нашел инфу по бесплатным лимитам, там всего 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.