Bug 38113

Удаление kernel-modules-drm-std-def и make-initrd проблему решают.

Я считаю, что это проблема является препятствием для попадания ядра 5.4 в качестве std-def в p9, так как мы же ещё делаем десктопные сборки для cloud. Пока это только alt-workstation-cloud.

А что значит - не маштабируется ? 
При увеличении окна ?

(Ответ для Anton Farygin на комментарий #3)
> А что значит - не маштабируется ? 
> При увеличении окна ?

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

Чтобы почувствовать разницу, нужно загрузиться в qemu с ядром 4.19, а потом с ядром 5.4.

Проблема присутствует как при запуске с опцией -vga virtio (используется модуль ядра virtio-gpu), так и без неё (используется модуль ядра bochs_drm).

А с qxl есть проблема ?

(Ответ для Anton Farygin на комментарий #5)
> А с qxl есть проблема ?

С опцией -vga qxl проблема не наблюдается. Но она же доступна только для x86?

Created attachment 8635 [details]
мате в qemu с ядрами 4.19 и 5.4

Не вижу никакой разницы в размерах шрифтов и элементов интерфейса.

(Ответ для Anton V. Boyarshinov на комментарий #7)
> Создано вложение 8635 [details] [подробности]
> мате в qemu с ядрами 4.19 и 5.4
> 
> Не вижу никакой разницы в размерах шрифтов и элементов интерфейса.

А версия qemu у вас какая?

(Ответ для Антон Мидюков на комментарий #0)
> не масштабируется интерфейс во всех DE
Есть разница в выводе от
xdpyinfo | grep -E '(resol|dimen)'
?

(Ответ для Sergey V Turchin на комментарий #9)
> (Ответ для Антон Мидюков на комментарий #0)
> > не масштабируется интерфейс во всех DE
>А версия qemu у вас какая?

QEMU emulator version 3.0.1

> Есть разница в выводе от
> xdpyinfo | grep -E '(resol|dimen)'
> ?

Нет, всё одинаково.
1024x768 pixels (270x203 millimeters)
96x96 dpi

> > Есть разница в выводе от
> > xdpyinfo | grep -E '(resol|dimen)'
> > ?
> 
> Нет, всё одинаково.
> 1024x768 pixels (270x203 millimeters)
> 96x96 dpi

А вот после обновления qemu до p9, разрешение получается 65 dpi, а размер экрана 403x203 мм

Created attachment 8636 [details]
мате в qemu с ядрами 4.19 и 5.4 (qemu-4.2.0)

У меня qemu 4.2.0. Я установил стартеркит p9, обновил ядро, сделал скрины при загрузке с ядрами 5.4 (справа) и 4.19 (слева). При загрузке с ядром 4.19 dpi 96x96, при загрузке с 5.4 dpi 65x65. Я уже думал, что проблема в том, что у меня на хосте принудительно установлен dpi 96x96 (пакет xorg-96dpi). Удалил пакет, перезагрузилс результат тот же. Остаётся грешить на qemu 4.2.0 раз нет проблем с qemu 3.0.1.

Также убедился, что проблема есть и на aarch64. Проверял с опциями -device virtio-gpu,xres=1280,yres=800 -vnc :0

исследование исходников показало вот что:
1) в версии ядра 4.20 добавили чтение EDID в драйвера virtio-gpu и bochs
2) в qemu после 3.1 добавили поддержку создания этого самого edid

До этой версии ядра и qemu разрешение считалось равным 96 и размеры экрана вычислялись из него. А теперь они приходят из qemu. Срабатывает это, естественно, когда ядро >4.20 и qemu >3.2

Почему qemu выдаёт такие странные размеры экрана я сказать не могу. В qemu, насколько я понял, можно отключить поддержку EDID (во время комплияции), но не знаю как наши образы поведут себя на чужих qemu.

Я нашёл забавную ошибку в qemu, из-за которой это происходит. Будем делать исправление и апстримить его.

http://git.altlinux.org/people/boyarsh/packages/qemu.git?p=qemu.git;a=commit;h=01c46e6850c6d4586674c1e54fd2e403c6ae867c

(In reply to Anton V. Boyarshinov from comment #16)
> http://git.altlinux.org/people/boyarsh/packages/qemu.git?p=qemu.git;a=commit;
> h=01c46e6850c6d4586674c1e54fd2e403c6ae867c

Разве cast сделает из float то что ты хочешь?

(Ответ для Gleb F-Malinovskiy на комментарий #17)
> (In reply to Anton V. Boyarshinov from comment #16)
> > http://git.altlinux.org/people/boyarsh/packages/qemu.git?p=qemu.git;a=commit;
> > h=01c46e6850c6d4586674c1e54fd2e403c6ae867c
> 
> Разве cast сделает из float то что ты хочешь?

В половине случаев -- да. Для реальных случаев 96 и 100 -- он делает ровно то, что надо 27 и 26. Я писал тестовую программу.

Так или иначе, ошибка на полсантиметра явно лучше, чем ошибка почти вдвое.

А почему просто не написать info->prefx * 254 / 100 / info->dpi и info->prefy * 254 / 100 / info->dpi?

(Ответ для Dmitry V. Levin на комментарий #19)
> А почему просто не написать info->prefx * 254 / 100 / info->dpi и
> info->prefy * 254 / 100 / info->dpi?
Попробовал: у Boyarsh меньше на 1. Видимо, тут точнее, т.к. у Антона обрезание без округления.

(Ответ для Sergey V Turchin на комментарий #20)
> (Ответ для Dmitry V. Levin на комментарий #19)
> > А почему просто не написать info->prefx * 254 / 100 / info->dpi и
> > info->prefy * 254 / 100 / info->dpi?

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

> Попробовал: у Boyarsh меньше на 1. Видимо, тут точнее, т.к. у Антона
> обрезание без округления.

А в этой конструкции округление откуда возьмётся?

(Ответ для Anton V. Boyarshinov на комментарий #21)
> А в этой конструкции округление откуда возьмётся?
Просто меньше обрезается, видимо.

Не будите float, пока оно тихо.

Есть новости какие-нибудь?

(Ответ для Антон Мидюков на комментарий #24)
> Есть новости какие-нибудь?
в qemu-4.2.0-alt2 этот патч добавлен, и в сизифе и в p9.

(Ответ для Alexey Shabalin на комментарий #25)
> (Ответ для Антон Мидюков на комментарий #24)
> > Есть новости какие-нибудь?
> в qemu-4.2.0-alt2 этот патч добавлен, и в сизифе и в p9.

В qemu-5.0.0-alt1 проблема есть.

Исправлено и уже очень давно.