Почему xorg сообщает неверные значения DPI и размеров экрана?

Ясно. Сам уже нашел:

By default, Xorg always sets DPI to 96 since 2009 (see [2]). A change was made with version 21.1 to provide proper DPI auto-detection, but reverted (see FS#72661).

https://bugs.freedesktop.org/show_bug.cgi?id=23705

Разрабы сами ломают иксы специально, а потом иксы же и виноваты, а разрабы ни при чем.

Известный вредитель.

Keith Packard 2009-09-16 21:20:56 UTC

The 'screen size' as reported in the core protocol now respects the DPI value given by the user or config file and ignores the actual monitor DPI of any connected monitor.

The real monitor size is reported through the RandR extension if you really need to know the physical size of the display.

This is intentional and follows the practice seen in many other desktop environments where the logical DPI of the screen is used as an application and font scaling factor.

If you don't like it, you're welcome to configure the X server to taste; we haven't removed any of those knobs. And, you can even use xrandr to change things on the fly.

Если Кит Пакард вредитель, то я даже не знаю, что сказать

Зато я знаю:

Ты просто давно не следишь за состоянием дел в иксах.

Это один из тех немногих людей, которые реально над иксами работают

реально над иксами работают

В чем это выражается? Вредить — тоже своего рода работать над иксами.

Пример такой работы приведен выше.

Разрабы сами ломают иксы специально

Форкай и иксы, чё уж там )
Это же очевидно, что нужен единый виджет-сервер, который уравнит look&feel между всем зоопарком тулкитов, как в Y Window, АФАИК.

И в чем он не прав? Использование отличного от 96 DPI даёт уродливый результат и ломает интерфейс, нет смысла выставлять его по умолчанию.

Физический размер диспея, который выдает xrandr (об этом сказано в его мануале) и размер в зависимости от dpi, который показывает xdpyinfo, отличаются. Сделайте скриншот, откройте в гимпе и измерьте размер, меняя dpi. У меня при 190 dpi размер изображения в миллиметрах приблизительно равен физическому. Понятно, что при 96 он будет другим.

Он втащил в иксы всё жирное. До него иксы работали на 4 мб оперативы

Разрабы сами ломают иксы специально

Все врут. И мониторы о своих физических разрешениях в том числе. Выставляю лапками на основе манипуляций с точным измерительным прибором, мненорм.

виджет-сервер, который уравнит look&feel между всем зоопарком тулкитов

Да щаз. Netaqoosick 1.0 будет рисовать на канве любое непотребство

Все врут.

xrandr не врет, физические размеры экрана совпадают, проверял точным измерительным прибором, рулеткой. А xdpyinfo можно проверить только через принтер, у которого в настройках нужно выставить такой же dpi, как у монитора.

> xdpyinfo | grep dimen -A1
dimensions:    2560x1600 pixels (677x423 millimeters)
resolution:    96x96 dots per inch

При разрешении принтера 96x96 dpi и размере изображения 2560х1600 px, распечатается страница с физическим размером 677x423 миллиметров.

Все врут. И мониторы о своих физических разрешениях в том числе.

Даже при корректных даннх dpi от монитора выставлять его по умолчанию в иксах была плохая идея:

1. Тулкиты не поддерживают масштабирование. Иногда увеличивался только текст и вылазил за рамки, иногда вместе с кнопками по горизнонтали и они уже вылазили за рамки. Более-менее сносно переносят несколько фиксированных значений dpi. Некоторые приложения полностью игнорируют отличные от 96 значения, значения ниже 96 не поддерживаются практически ничем.

2. Сам концепт масштабирования десктопных ui подходит только для отдельных случаев. Пользователю не надо уменьшать интерфейс при низком dpi телевизора или увеличивать на 1360x768 11" экране.

3. Не работает для нескольких мониторов.

Потому что костыли это топливо иксов. Без них он не едет.

От видеодрайвера ещё зависит. Нвидия берёт размеры из EDID, но пересчитывает их в DPI какой-то своей загадочной арифметикой. Скажем, у меня в EDID монитора «518 mm x 324 mm», но, если не указать «UseEdidDpi» «false», xdpyinfo показывает 524 x 321, и размер A4 в LibreОffice больше натуральной величины на пару процентов. Если запретить UseEdidDpi и указать те же самые «518 324» в DisplaySize — всё идеально совпадает.

Это Кит Пакард без костылей не едет.

Ты же понимаешь, что это всё отмазки? Я эти аргументы и сам перечислить могу. Вот только на каждый аргумент есть контраргумент.

Тулкиты не поддерживают масштабирование.

Ну так надо стимулировать их к этому, а не подкладывать костыли, чтобы этот баг окаменел и стал фичей.

Сам концепт масштабирования десктопных ui подходит только для отдельных случаев. Пользователю не надо уменьшать интерфейс при низком dpi телевизора или увеличивать на 1360x768 11" экране.

Ну так может дадим пользователю выбор, а не будем хардкодить говнокод прямо в иксы? Пакард бы перетрудился, если бы добавил вариант -dpi auto в опции иксов?

Не работает для нескольких мониторов.

Неверная формулировка. Не работает для нескольких мониторов в случае, если у них разный DPI. Зато вне этого кейса - ничего не мешает работать.

как в Y Window

Ух ты, и правда такая штукенция есть

Один XFixes (набор костылей судя из названия) чего стоит за который его выперли из разработчиков XFree86 и он потом сделал форк под названием X.Org.

Ну там не в самом содержимом изменений было дело, а в том, как именно он их засунул в код.

Ну так надо стимулировать их к этому, а не подкладывать костыли, чтобы этот баг окаменел и стал фичей.

Ты предлагаешь сломать UX пользователям ради стимулирования недостижимой цели.

Ну так может дадим пользователю выбор, а не будем хардкодить говнокод прямо в иксы?

Можно было. Хотя пользы от автоматического определения dpi в иксах нет и тяжело будет объяснить разработчикам, зачем им тратить своё время на поддержку этого кода в легаси софте.

Ты предлагаешь сломать UX пользователям ради стимулирования недостижимой цели.

У меня прямо сейчас сломан UX, когда я запускаю на DPI 130 софт, приколоченный гвоздями к DPI 96. Сломать его еще дальше в этом смысле просто невозможно.

недостижимой цели.

А недостижимость кто определил?

тяжело будет объяснить разработчикам, зачем им тратить своё время на поддержку этого кода в легаси софте.

Каким разработчикам? Каком софте? В чем заключается поддержка? Можно яснее выражаться?

By default, Xorg always sets DPI to 96 since 2009

Early KMS настрой

xrandr не врет, физические размеры экрана совпадают, проверял точным измерительным прибором, рулеткой.

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

Даже при корректных даннх dpi от монитора выставлять его по умолчанию в иксах была плохая идея

Это уже совсем другой вопрос. Изначальный вопрос был «почему».

А недостижимость кто определил?

Любой здравомыслящий человек быстро придет к этому выводу. Никто не будет переделывать легаси тулкиты под легаси иксы. Более того, это изменение никак не мешает поправить масштабирование в тулкитах, как так желающие могут получить корректные данные об экранах через randr.

Каким разработчикам? Каком софте? В чем заключается поддержка? Можно яснее выражаться?

Разработчикам иксов и тулкитов. Придется держать бесполезный код в проекте и реагировать на багрепорты. Код откатили, когда он начал приводить к крашам и аномалиям в интерфейсах. Тут и на лоре пример есть:

Arch, Xorg-21.1.1-2, KDE, странности с DPI

На моей памяти, подстановка корректного dpi пару недель работала и прелести этого ощутить успели только владельцы роллинг дистрибутивов. Проблем принесло много, а пользы, даже потенциальной, от этого мало.

Любой здравомыслящий человек быстро придет к этому выводу. Никто не будет переделывать легаси тулкиты под легаси иксы.

В каком месте xorg был легаси в 2009-м году? В каком месте стал легаси весь текущий винегрет тулкитов, которые не умеют масштабировать интерфейс?

Более того, это изменение никак не мешает поправить масштабирование в тулкитах, как так желающие могут получить корректные данные об экранах через randr.

Не мешает. И как видишь, тулкиты плевали на корректное масштабирование вне зависимости от того, легаси они или не легаси, предоставляют им иксы информацию или не предоставляют. Поэтому никакой здравой причины ломать поведение иксов просто нет.

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

То есть код для масштабирования UI - бесполезный. Окей…

Код откатили, когда он начал приводить к крашам и аномалиям в интерфейсах. Тут и на лоре пример есть

Краши и аномалии нужно чинить по месту их появления. У иксов есть способ сообщить о DPI, и приложения обязаны корректно обрабатывать эту информацию. Если приложение берёт значение DPI, а потом крашится при его обработке, то это проблемы приложения.

В данном случае просто с нихрена отломали API у иксов из-за неконформных приложений. При чем не в виде настройки, которую можно отключить, а сразу с мясом захардкодили. Это говнокод и говноподход к архитектуре. Называется - костыли на костылях.

Ульрика Дреппера на них нет.

В данном случае просто с нихрена отломали API у иксов из-за неконформных приложений.

Тут же надо сделать патч на иксы, затем патч на каждый тулкит и затем патч на каждое приложение, которое использует этот тулкит. Неудивительно что проблему решили через костыли, если делать по нормальному тут много работы.

Неудивительно что проблему решили через костыли, если делать по нормальному тут много работы.

Вот из-за таких решений(в течении многих лет) иксы и пришли в то состояние в котором они находятся. Технический долг не просто так придуман.

PS: Подозреваю, что можно было бы сделать как делает мелкософт, для легаси софта сделать возможность запуска в режиме совместимости(например выставлением переменной окружения), а для актуального софта и тулкитов - ну пусть правят, ибо нефиг.

То есть код для масштабирования UI - бесполезный.

Это бесполезная часть из одного подхода к масштабированию UI, который никогда нормально не работал. Её отсутствие никак не мешает масштабировать UI.

В данном случае просто с нихрена отломали API у иксов из-за неконформных приложений.

Её отломали, так никому до неё не было дело и она вызывала краши иксов, а для масштабирование UI она не нужна.

Это бесполезная часть из одного подхода к масштабированию UI, который никогда нормально не работал.

Это какого? Снова загадки.

Её отломали, так никому до неё не было дело и она вызывала краши иксов

Классный подход к починке багов. А потом некоторые еще жалуются, что для иксов в ядре linux специальные костыли предусмотрены.

Это какого? Снова загадки.

Какие загадки? Через передачу dpi.

Классный подход к починке багов.

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

А «ненастоящие» параметры дисплея нужны чтобы что? Какую они функцию выполняют?

Какие загадки? Через передачу dpi.

Так оно так и сделано. Просто этот dpi засунут в 10 мест, то в xrdb, то в gsettings, то еще куда-нибудь.

А «ненастоящие» параметры дисплея нужны чтобы что?

Для предсказуемой работы UI. Метод с автоматическим масштабированием от dpi показал себя плохо и был не удобным в управлении. Развивать его смысла не было, а приложения по прежнему ожидают от иксов параметры.

А есть метод лучше?

А «ненастоящие» параметры дисплея нужны чтобы что? Какую они функцию выполняют?

Масштабирование GUI зависит не только от физического DPI экрана, но и от расстояния от экрана до пользователя. Информацию о расстоянии до пользователя получить через EDID нельзя.

Это уже «высшая математика». Сейчас, пока пилят бюджет на переписывании композитора то ли 11-й, то ли 14-й год (я уже сбился со счета), заниматься вопросами корректного масштабирования UI просто некому. У них там другие «инновации».

Хотя бы научились масштабировать под указанный скейлинг фактор без багов, и на том спасибо.

А есть метод лучше?

Уже просто не делать масштабирование автоматически будет лучшим решением. Можно попробовать продумать сценарии использования и устанавливать коэффициент автоматически опираясь на размер экрана и разрешение. Со стороны пользователя параметр должен отображаться как коэф. увеличения для экрана. Ни о каких размерах монитора он думать не должен, а уж о dpi и подавно.

Хотя бы научились масштабировать под указанный скейлинг фактор без багов, и на том спасибо.

Тут у иксов проблема только с разным масштабированием под разные мониторы. Всё остальное на тулкитах.

Всё остальное на тулкитах.

И на приложениях. На тех самых, которых мы так оберегаем от переменного dpi, вдруг в них что-то отвалится.

И по итогу имеем ситуацию, когда запустив live-систему на 2-х разных ноутбуках, пользователь вынужден настраивать размеры всего подряд в 10 разных местах.

Уже просто не делать масштабирование автоматически будет лучшим решением.

Нет, не будет.

Можно попробовать продумать сценарии использования и устанавливать коэффициент автоматически опираясь на размер экрана и разрешение. Со стороны пользователя параметр должен отображаться как коэф. увеличения для экрана. Ни о каких размерах монитора он думать не должен, а уж о dpi и подавно.

Такие вещи делаются через правильное разбиение на абстракции.

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

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

На тех самых, которых мы так оберегаем от переменного dpi, вдруг в них что-то отвалится.

Оберегают пользователя от проблем.

И по итогу имеем ситуацию, когда запустив live-систему на 2-х разных ноутбуках, пользователь вынужден настраивать размеры всего подряд в 10 разных местах.

Необходимость менять в 10 местах с фиксированным dpi не связана.

о аргументация на уровне «от переменного масштаба крашатся приложения» - это детский сад.

И где я такое написал? Автоматическое масштабирование от dpi не связанно с возможностью масштабирование поменять. Ну и падали там иксы.

А не «фиксить» тот код, который выявил наличие проблемы.

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

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

Это, конечно, проблема. Но и мониторы и телики иногда через храндр показывают ерунду. У меня был такой, показывал размер полтора метра на чотатам. И dpi выставлял непойми какую, разглядеть невозможно было.

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

В КДЕ такой-то шрифт выглядит нормально, в Гтк может быть мелковатым, или даже крупноватым, а в Блендере мелочь, что больно глазам. Один шрифт, один экран, один dpi в настройках.

Но меня интересует другое - кто где и как и в скольки местах сейчас расставляет размеры шрифтов?

Где угодно и как попало. Так же как и параметры dpi волюнтаристски задаются в куче мест.

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

Со стороны иксов требуется только сообщать физические размеры экрана той функцией, которая должна сообщать физические размеры экрана. А не возвращать там мусор, не имеющий отношение к тому, что описано в документации на API.

Автоматическое масштабирование шрифтов работает в xft согласно значению из xrdb. Независимо от того, что сообщают иксы.

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

В связи с этим, какие «проблемы» были «решены», из данной аргументации абсолютно не ясно.

Ну и падали там иксы.

Тем более нужно чинить, значит. Там, где сломано.

Необходимость менять в 10 местах с фиксированным dpi не связана.

Она связана с тем, что разрабы до сих пор смотрят на идею масштабировать UI как на инопланетную технологию. Будто это всё где-то далеко и не про них. Если бы иксы им в этом не потворствовали, до многих бы дошло быстрее.

кто где и как и в скольки местах сейчас расставляет размеры шрифтов?

Со шрифтами в линуксе всегда было сложно. Поэтому у юзеров и развивается тулкитофобия. Я вот так и не осилил настройку Qt. Там и сглаживание какое-то своё уличное, и размеры неправильные (относительно гтк).

В связи с этим, какие «проблемы» были «решены», из данной аргументации абсолютно не ясно.

Пример я скидывал.

Тем более нужно чинить, значит. Там, где сломано.

Так и починили, радикально. Ничего утеряно не было.

Если бы иксы им в этом не потворствовали, до многих бы дошло быстрее.

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