Как стать автором
Обновить

Комментарии 20

KDE под Wayland поддерживает разный масштаб для разных мониторов и размер панели при этом изменяется. Наверно вам стоило бы отдельно посмотреть под Wayland и X11 и другие десктопы

Спасибо, проверю. Я смотрю в свежих версиях KDE+Wayland вроде добавили возможность отключить принудительное масштабирование Х11 приложений, и такого мыла как в гноме не должно быть.

Да, особенно хорошо это работает для приложений, поддерживающих HiDPI под X11. Никакого мыла и всё выглядит чётко.

Обновил информацию про KDE

я конечно не занимался ещё разработкой на линуксе, но сейчас вынужденно на нём сижу. И иногда такие ситуации бывают что мыло какое-то, теперь зато у меня такого не будет) Спасибо!

60 Hz это VGA на минималках, а все возможности частот не использовались

Также можно почитать хоть и старую, но актуальную статью с Хабра - настраивал по ней.

Linux -- это отнюдь не KDE, Gnome или что-то там ещё. Это Xorg и/или X11, или Wayland, хотя последнее ещё та поделка. И "увеличивать" ничего не нужно. Нужно уметь формировать изображения с нужным разрешением (DPI). В основном это касается шрифтов, битмапа используемого для курсора, размеров элементов GUI и иконок. Шрифты могут выводиться самим X-сервером, а могут через libfreetype, соответственно два разных места для настройки. Курсор приходится заменять. Иконки и размер GUI-элементов задаются в зависимости от тулкита. У Qt своё, у Gtk, своё, у старых тулкитов -- ресурсы. Многие вещи умеют масштабироваться относительно размера DPI, а последний задаётся в конфигурации X-сервера (и часто прибит гвоздями к 96dpi). Отдельный вопрос -- работа веб-браузеров, где в высоком DPI многое рендерится отвратительно. Там есть в about:config своя специальная настройка (что позволяет рендерить картинки как бы с меньшим DPI, а потом увеличивать, что там делается в шрифтами не представляю, т.к. увеличивать битмап отрендеренного шрифта так себе идея, а шрифты более крупного размера могут иметь непропорциональные метрики...)

В иксах уже много лет живёт настройка Xft.dpi и xrandr. Но поддержка тщательно поломана на уровне тулкитов и отдельных приложений https://wiki.archlinux.org/title/HiDPI .

Xft.dpi может банально отсутствовать. Об этом во второй части.

DPI это dots per Inch, inch - мера физической длины и для того чтобы хотя бы оперировать этим термином где либо, необходимо знать физические размеры того на чем выводится изображение. Хоть API для получения физических размеров монитора и есть (EDID), но гарантий что там будут корректные значения нет, например на виртуальной машине не получится их определить, поэтому везде приходится использовать относительные коэффициенты от 100% масштаба который во времена низких разрешений всех устраивал, и даже в конфигурации X-сервера если значение не прибито гвоздями к 96 то просто задается 96 умноженное на коэффициент указанный в настройках.

Никаких гарантий и не надо. Через опцию -dpi 100500 можно передать нужное разрешение иксам. Опцию нужно вписать в скрипт из /etc, который запускается из xdm. Можно в /etc/X11/xorg.conf вписать размеры монитора и разрешение и оно само вычислится. Проблема в том, что на самом деле чуть ли не с 80-х годов оно всё работало корректно (во всяком случае в 2000-м у меня в компе DPI соответствовал "хрустальному" монитору), и только в последнее десятилетие массово всё поломано. И тут (с появлением 4к мониторов) начинаются "открытия".

А да, ещё мониторы через EDID могут выдавать размеры свои неправильно, потому, что 4к монитор сделали, а микросхему для EDID взяли и тупо скопировали с какого-то мелкого монитора и вообще не заморачивались. На работе такой выдали. Собственно линейкой померял и вручную в конфиги вписал.

У меня в swaywm поддерживается и разное масштабирование и разная частота на разных мониторах

да что-то я не понял, если Cinnamon на использует xorg, как они поддерживают независимые настройки масштабирования?

я как-то пытался сделать через xrandr на KDE независимое масштабирование, но помнится вышло так себе, работало но с костылями

Это смотрится отвратительно, когда пытаются масштабировать шрифы. Глаза сломать можно. Такое годится только для просмотров ютуба. Но действительно, xrandr так умеет в режиме дублирования картинки. Заметил случайно когда ноут к телеку подключил.

Не понимаю, как он это делает. Подразумевается видимо, что драйвер и видеокарта должны это уметь, и не всякая видимо умеет. В самих иксах ничего специального для такого нет же. В смысле если я подцеплю два моника через две разные карты -- так работать не будет же? Ну хорошо, для обычных окон что-то можно нахимичить софтово (блит 60 раз в секунду, условно), если есть 3д композитор то тоже можно, а если какое-нибудь окно с оверлеем -- что спрашивается делать? Впрочем непонятно и как оно может работать когда окно разорвано между двумя мониторями (на разных картах). И старые карты очевидно не умели. Ну типа S3 Trio. Те которые с видео выходом (на телек) были уже как-то умели.

Мопед не мой, но для Plasma существует библиотека disman, работающая вместе с KDisplay. Разработчики утверждают, что она масштабирует автоматически и как надо.

Не рассмотрен вопрос поворота второго монитора на 90 градусов, или использования двух мониторов с разным порядком RGB и работы антиалиасинга в библиотеке libfreetype в такой ситуации. В том смысле что он работать не будет нормально никогда, потому, что это невозможно. Разве что переключить на градации серого. Но тогда при сравнении с виндами в последних шрифты более резкие и четкие. Как всегда. Блеск и нищета опенсоурса.

Поворот скорее всего делается с помощью матриц трансформации в xrandr, идея интересная, спасибо проверю, если там окажется что то интересное, то упомяну во второй части. Разный порядок RGB меня пока не интересовал, эта статья следствие того что мне нужно научить приложение правильно масштабироваться на более менее адекватных конфигурациях распространенных дистрибутивов, т.к. используемый фреймворк не умеет сам это правильно делать.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории