Какой оконный стряпчий умеет в разные dpi?

Cinnamon попробуй. Он криво-косо, но пытается в вышеозвученное.

Гнум не умеет ничего кроме 100%, 200% и 300%

В X-сессии можно так:

xrandr --output eDP1 --scale 1.25x1.25

Подробнее в арч-вике можно прочитать. Из вэйлэнд - sway в такое точно умеет, но это тайлинг.

Какой казалось бы простой вопрос, и какой непростой на него ответ...

Ну, начнём. Есть два разных DPI. Общий DPI, влияющий на рендеринг всех векторных элементов экрана (кнопки, формы, панели, векторные иконки), и xft.DPI, который влияет только на рендеринг шрифтов.

Есть две разных реализации графической системы (извини что я от динозавров и на пальцах, мне так самому проще) — Иксы, которые сервер (не углубляясь в тонкости кто там в их терминологии сервер, а кто клиент), поверх которых уже работает WM\DE, и Wayland, который протокол, и соответственно весь функционал его реализации ложится полностью на WM\DE, главное чтобы эта реализация соответствовала спецификациям протокола. Никакой прослойки в виде сервера в этом случае нет. Понимание что такое DPI и подход к масштабированию всех элементов у иксов и вейланд разный.

Начнём с Иксов (xorg). Исторически иксы умеют в динамический DPI, который высчитывается для каждого монитора индивидуально исходя из геометрических размеров экрана получаемых с самого устройства (например через EDID) и используемого разрешения. Очевидно что для экранов с одним разрешением, но разной диагональю DPI будет разный. Соответственно иксы умеют (умели) в разный DPI для разных устройств. Если устройство не отдаёт свою геометрию, или отдаёт чушь, или отдаёт непонятными иксам способом DPI назначается «по умолчанию» равным 96. Дабы этого избежать можно измерить физические размеры экрана линейкой и прописать геометрию в миллиметрах самостоятельно, в секции описывающие подключённые мониторы в xorg.conf.

Это всё работало, раньше, пока не сломалось сразу в нескольких местах. Во первых это сломали (точнее переделали) в ядре, когда внедряли технологию KMS (kernel modesetting). Иксы по причине сложности и древности своего кода не умеют получать геометрию с монитора если используют KMS драйверы для работы с видеокартами. Точнее умеют, но не для всех видеокарт, мониторов и типов подключения. Например пропиетарные Nvidia драйверы до сих пор способны отдать иксам эту информацию, но не в случае использования драйвера modesetting в качестве прокси (да, это сложно, углубляться не буду, сам смутно понимаю). Попытка вылечить иксы была, но патч в итоге откатили, так как он что то ломал в работе qt, разбираться никто не стал. Почему — сейчас расскажу, и это будет «во вторых».

Во вторых, концепцию глобального DPI поломали в gtk. Там решили что это вот всё слишком сложно, нужно быть проще, в результате виджеты gtk используют при рендеринге фиксированные 96 DPI. А для изменения размеров виджетов и иконок используется значение scale, то бишь изменение масштаба в процентах. Как видим никакой привязки к «реальной» геометрии больше нет. Тем не менее gtk продолжает реагировать на указание DPI! Но эта циферка теперь понимается как xft.DPI, то есть относится исключительно к рендерингу шрифтов. С qt несколько другая ситуация, виджеты qt адекватно реагировали на указание DPI (раньше, как сейчас не знаю, может и сломали уже).

В результате получился бардак, так как программы использующие разные библиотеки по разному реагировали на DPI, требовали по разному управлять масштабом, и по разному понимали подключенные мониторы с разным DPI. Напоминаю, мы сейчас говорим про ситуацию с иксами. В итоге в большинстве дистрибутивов (во всех), в целях сохранения единства внешнего вида виджетов приняли решение — задавать иксам фиксированные 96 DPI вне зависимости от подключенного монитора\мониторов. Это параметр либо форсится в конфиге, либо при запуске иксов в ключах запуска. То DPI которое в KDE например на вкладке настройки шрифтов — это xft.DPI, и влияет только на шрифты, а на глобальный DPI влияет параметр scale, который gtk и qt понимают и обрабатывают по разному (я по прежнему про иксы сейчас).

Теперь про вайланд. В вайланд решено ВООБЩЕ отказаться от такого понятия как DPI (он всегда 96) и оставить только scale. При этом по неведомой причине решено что масштабирование может быть только целочисленным, то бишь x2 x3 x4 и так далее, но не x1.5 или x1.2. Так же, чтобы добавить путаницы, xft.DPI продолжает влиять на рендеринг шрифтов, поскольку это отдельная библиотека, та же что и в иксах кстати, она способна принимать любое разумное значение DPI, в том числе такое при котором увеличение размера будет дробным. Wayland рендеринг шрифтов вообще не описывает, это вне задачи протокола.

Поскольку протокол Wayland значительно проще и ограниченнее чем иксы (точнее он вообще не иксы, он протокол), весь функционал по управлению масштабом берёт на себя WM\DE, точнее его часть называемая «композитор». И поскольку каждый WM/DE теперь вынужден самостоятельно реализовывать то что раньше было частью иксов — реализации друг от друга отличаются полнотой и подходом, основное требование — соответствие протоколу. Например в части управления масштабом на разных мониторах — согласно спецификации wayland масштабирование 1.5 например будет реализовано так — сначала увеличение до x3, а потом уменьшение получившегося на x2. На каком этапе и как при этом будут рисоваться шрифты, с каким DPI, забота композитора и библиотек qt и gtk, не wayland, он про шрифты ничего не знает.

Как привязаться к реальной геометрии — никак, на глаз подбирай, приблизительно. Как будет всё это выглядеть когда одному монитору нужен масштаб x1.5, а другому x2, и как будут перемасштабированы шрифты, виджеты, курсор — целиком зависит от используемого WM\DE.

Подвожу итог своей портянке. Работа с несколькими мониторами разного размера, а так же с разными параметрами scale сейчас реализована плохо всюду, и в иксах, и в вайланд, и в кедах, и в гноме, а самое главное — всюду плохо по разному.

Самостоятельно бороть этот адок тебе может помочь статья https://wiki.archlinux.org/title/HiDPI

Э? Последний не пробовал, но это вроде тот же гном. С эксперементальным патчем на дробный масштаб, с таким же предупреждением о просадках производительности

Ага, так и есть. Мыльцо и тормоза, но для каждого дисплея можно выставить свой масштаб, и слётов не замечал.

Мыльцо с тормозами оттого что оно сначала увеличивает кратно с избытком, рисует с учётом этого всего шрифт и векторную графику (иконки там, виджеты), а потом уменьшает в потребный тебе дробный масштаб уже отрендерённый битмап, естественно убивая при этом чёткость шрифтов и контуров, (ломая pixel perfect). Ну и тормозя при этом, так как утаптывает каждый кадр.

ага, по офигенному сглаживанию шрифтов это видно..

Гнум не умеет ничего кроме 100%, 200% и 300%

https://wiki.archlinux.org/title/HiDPI#Fractional_scaling

Судя по отзывам, в последних кедах ситуация с дробным масштабированием существенно улучшилась

Там никогда не было проблем с собственно масштабированием. Проблема в том, что масштабирование не прибито к конкретному экрану и некоторые элементы его не слушаются, потому что задаются в пикселях

Ох, вот это матчасть! Респект!

Ну и начинается адок. Гнум не умеет ничего кроме 100%, 200% и 300%,

Умеет.

Спасибо, лайк поставил.

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