Created attachment 8617 [details] скрин regular-mate При использовании ядер std-def и un-def в qemu не масштабируется интерфейс во всех DE, кроме gnome3 и Cinnamon. При загрузке с ядром 4.19 такой проблемы нет.
Удаление 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 проблема есть.
Исправлено и уже очень давно.
