ALT Linux Bugzilla – #42057

> неработающий framebuffer чинится  для virtualbox в EFI с vmsvga
А для EFI с vboxsvga не сломается при этом? Неплохо бы проверить при починке.

@ldv кто будет делать ?

(In reply to Anton Farygin from comment #2)
> @ldv кто будет делать ?

Меня интересует для начала, кто будет думать, как всем угодить и ничего не сломать.

Мне вот DRM=y не нужно вообще нигде, ни на серверах, ни на ноутах.

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

(In reply to Антон Мидюков from comment #0)
> В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено,
> что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если
> использовать simpledrm вместо simplefb. Т.е.:
> CONFIG_FB_SIMPLE=n
> CONFIG_DRM=y
> CONFIG_DRM_SIMPLEDRM=y
> 
> И видимо ещё
> CONFIG_DRM_KMS_HELPER=y
> 
> Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами,
> но только для x86_64.

А почему только для x86_64? Можно и для aarch64.

(Ответ для Alexey Sheplyakov на комментарий #5)
> (In reply to Антон Мидюков from comment #0)
> > В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено,
> > что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если
> > использовать simpledrm вместо simplefb. Т.е.:
> > CONFIG_FB_SIMPLE=n
> > CONFIG_DRM=y
> > CONFIG_DRM_SIMPLEDRM=y
> > 
> > И видимо ещё
> > CONFIG_DRM_KMS_HELPER=y
> > 
> > Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами,
> > но только для x86_64.
> 
> А почему только для x86_64? Можно и для aarch64.

Я проверял для aarch64.
1. Ядро становится несколько больше и u-boot на Raspberry Pi его загрузить не может. Впрочем, эта проблема обязательно вылезет вновь в одном из следующих релизов ядра и так.
2. simpledrm работает только с EFI. При загрузке с u-boot через extlinux.conf framebuffer'а нет. На Allwinner H5 (Orange Pi Prime) так.

А каковы резоны для включения на aarch64?

(In reply to Dmitry V. Levin from comment #3)
> (In reply to Anton Farygin from comment #2)
> > @ldv кто будет делать ?
> 
> Меня интересует для начала, кто будет думать, как всем угодить

Всем угодить невозможно...

> Мне вот DRM=y не нужно вообще нигде, ни на серверах, ни на ноутах.

... особенно если вместо технических критериев пользоваться субъективными предпочтениями.

> и ничего не сломать.

Тут волшебных рецептов нет, только тестировать.

P.S.

Если у Вас графическая подсистема Linux вызывает такое отторжение, то самое время придумать другую, более правильную. Затем адаптировать Mesa, Xorg (а также Qt, gtk, и далее со всеми остановками). Точнее говоря, делать это надо было лет 8 назад (а то и раньше), когда окончательно стало ясно, что fbdev мёртв, а Xorg вскоре за ним последует.

(In reply to Alexey Sheplyakov from comment #7)
> Если у Вас графическая подсистема Linux вызывает такое отторжение,

Вопрос не в отношении, графическая система нужна не для всех классов систем.
Например, на серверах нужна не графическая система, а serial console.

Дима, всё верно, но ядро un-def обычно никто на серверах не использует.

> Например, на серверах нужна не графическая система, а serial console.
Вообще, да. При разделении хотя бы на сервер и десктоп будет проще не мешать всё в кучу.

P.S.
Правда, судя по тому, что в BIOS уже настоящий графический интерфейс с мышью пихают, спрос есть.

(In reply to Anton Farygin from comment #9)
> Дима, всё верно, но ядро un-def обычно никто на серверах не использует.
Не-не. Это "предварительное" ядро. Лучше пусть таким и останется.
Сейчас получается удобно, что можно p10-un-def == sisyphus-std-def.

По мне бы лучше std-srv, std-wks, un-srv и un-wks.

(In reply to Антон Мидюков from comment #6)
> (Ответ для Alexey Sheplyakov на комментарий #5)
> > (In reply to Антон Мидюков from comment #0)
> > > В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено,
> > > что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если
> > > использовать simpledrm вместо simplefb. Т.е.:
> > > CONFIG_FB_SIMPLE=n
> > > CONFIG_DRM=y
> > > CONFIG_DRM_SIMPLEDRM=y
> > > 
> > > И видимо ещё
> > > CONFIG_DRM_KMS_HELPER=y
> > > 
> > > Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами,
> > > но только для x86_64.
> > 
> > А почему только для x86_64? Можно и для aarch64.
> 
> Я проверял для aarch64.
> 1. Ядро становится несколько больше и u-boot на Raspberry Pi его загрузить
> не может.


1. Зачем нужен u-boot на rasberry pi? Встроенный загрузчик прекрасно умеет запускать ядра Linux в разных видах (EFI stub, zImage, и т.п.). Есть UEFI (https://github.com/pftf/RPi4) - это если кому-то хочется стандартизации (я в их числе, если что).

2. Насколько я знаю, и u-boot, и встроенный загрузчик, и UEFI (EDK2) умеют загружать не только EFI stub, но и Image.gz

 Впрочем, эта проблема обязательно вылезет вновь в одном из
> следующих релизов ядра и так.

> 2. simpledrm работает только с EFI.

rock pi 4c (arm-tf + u-boot) - UEFI нет, а framebuffer есть. И неудивительно.
simpedrmfb (как и fb_simple) работает с тем, что настроил и *о чём рассказал* загрузчик/прошивка (рассказал через uefi таблицы, или в device tree). И не важно, какой именно загрузчик - u-boot, UEFI, arm-tf.


> При загрузке с u-boot через extlinux.conf framebuffer'а нет.

Возможно Вы не умеете его готовить (я тоже не умею, я пользуюсь тем, что добрые люди из armbian готовят)


> А каковы резоны для включения на aarch64?

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

(In reply to Sergey V Turchin from comment #11)
> (In reply to Anton Farygin from comment #9)
> > Дима, всё верно, но ядро un-def обычно никто на серверах не использует.
> Не-не. Это "предварительное" ядро. Лучше пусть таким и останется.
> Сейчас получается удобно, что можно p10-un-def == sisyphus-std-def.
> 
> По мне бы лучше std-srv, std-wks, un-srv и un-wks.

А кто тестировать-то всё это будет?

(Ответ для Alexey Sheplyakov на комментарий #12)
> (In reply to Антон Мидюков from comment #6)
> > (Ответ для Alexey Sheplyakov на комментарий #5)
> > > (In reply to Антон Мидюков from comment #0)
> > > > В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено,
> > > > что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если
> > > > использовать simpledrm вместо simplefb. Т.е.:
> > > > CONFIG_FB_SIMPLE=n
> > > > CONFIG_DRM=y
> > > > CONFIG_DRM_SIMPLEDRM=y
> > > > 
> > > > И видимо ещё
> > > > CONFIG_DRM_KMS_HELPER=y
> > > > 
> > > > Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами,
> > > > но только для x86_64.
> > > 
> > > А почему только для x86_64? Можно и для aarch64.
> > 
> > Я проверял для aarch64.
> > 1. Ядро становится несколько больше и u-boot на Raspberry Pi его загрузить
> > не может.
> 
> 
> 1. Зачем нужен u-boot на rasberry pi?

Для унификации. Грузить ядро с FAT раздела то ещё счастье. Вот не грузится с новым ядром и что делать? С предыдущим то не загрузишься.

> Встроенный загрузчик прекрасно умеет
> запускать ядра Linux в разных видах (EFI stub, zImage, и т.п.). Есть UEFI
> (https://github.com/pftf/RPi4) - это если кому-то хочется стандартизации (я
> в их числе, если что).

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

> 
> 2. Насколько я знаю, и u-boot, и встроенный загрузчик, и UEFI (EDK2) умеют
> загружать не только EFI stub, но и Image.gz
> 

Да, u-boot умеет грузиться в режиме EFI. Но и в режиме EFI получившееся ядро не смогло загрузиться. Начало грузиться и не смогло.

>  Впрочем, эта проблема обязательно вылезет вновь в одном из
> > следующих релизов ядра и так.
> 
> > 2. simpledrm работает только с EFI.
> 
> rock pi 4c (arm-tf + u-boot) - UEFI нет, а framebuffer есть. И неудивительно.

Там работает не simpedrmfb, а свой framebuffer. Я пробовал на Nano PC T4 (rk3399). В начале загрузки ядра монитор тухнет, и, пока свой framebuffer не загрузится, изображения нет. Идея вкомпиливания состоит ещё и в том, чтобы framebuffer был доступен с первых секунд загрузки ядра, чтобы на нём можно было видеть сообщения ядра. На Rockchip одинаково бесполезны simpedrmfb и fb_simple.

> simpedrmfb (как и fb_simple) работает с тем, что настроил и *о чём
> рассказал* загрузчик/прошивка (рассказал через uefi таблицы, или в device
> tree). И не важно, какой именно загрузчик - u-boot, UEFI, arm-tf.
> 

Верно. На Orange Pi Prime сообщения нормально выводятся на экран с fb_simple, как при загрузке через extlinux.conf, так и режим EFI. А с simpedrmfb только в режиме EFI.

> 
> > При загрузке с u-boot через extlinux.conf framebuffer'а нет.
> 
> Возможно Вы не умеете его готовить (я тоже не умею, я пользуюсь тем, что
> добрые люди из armbian готовят)
> 
> 
> > А каковы резоны для включения на aarch64?
> 
> 1. Не хочется на создавать дополнительную разницу между разными
> архитектурами.
> 2. fbdev по сути давно заброшен, его уже неоднократно собирались выпилить, и
> лучше заранее к этому подготовиться.

Польза от fb_simple только в том, чтобы выводить сообщения на экран, пока не загрузится нормальный drm-модуль.
Польза от вкомпиливания simpedrmfb видится ещё и в том, что plymouth будет запускаться сразу, а в initrd не будет необходимости класть другие drm-модули. Но это гипотеза, которую нужно будет проверить.
На aarch64 plymouth мы не используем (plymouth не работает при включении вывода на serial console), поэтому и резона не вижу.

> > По мне бы лучше std-srv, std-wks, un-srv и un-wks.
> А кто тестировать-то всё это будет?
Да все те же, кто раньше. Некоторые сразу оба вида будут использовать, только на разных системах.

С тестированием, как раз, будет проще.

(In reply to Dmitry V. Levin from comment #8)
> (In reply to Alexey Sheplyakov from comment #7)
> > Если у Вас графическая подсистема Linux вызывает такое отторжение,
> 
> Вопрос не в отношении, графическая система нужна не для всех классов систем.
> Например, на серверах нужна не графическая система, а serial console.

1. Графическая система всё равно есть (CONFIG_FB_SIMPLE=Y), только ущербная, никем не поддерживаемая.

2. uart/rs232 консоль далеко не у всякого сервера есть.

3. И самое главное: "на серверах не нужна графическая подсистема" - это Ваши личные предпочтения, ничем технически не обоснованные. А принятые на основе этого предпочтения решения (сборка drm модулем + упаковка в отдельный пакет drm драйверов) создают объективные проблемы. Например, обсуждаемый баг. А ещё невозможность автоматической установки обновлений ядра.

(In reply to Антон Мидюков from comment #14)

> На aarch64 plymouth мы не используем

А зря. Очень хотелось бы, чтобы и на aarch64 при загрузке отображалось что-то более человеческое, чем чёрный экран.

> (plymouth не работает при включении вывода на serial console), поэтому и резона не вижу.

Я рассматриваю aarch64 как "обычный компьютер для обычного пользователя", а не как хакерскую игрушку. А соответственно serial console а) нужна < 1% пользователей, б) не всегда (легко) доступна

(Ответ для Alexey Sheplyakov на комментарий #18)
> (In reply to Антон Мидюков from comment #14)
> 
> > На aarch64 plymouth мы не используем
> 
> А зря. Очень хотелось бы, чтобы и на aarch64 при загрузке отображалось
> что-то более человеческое, чем чёрный экран.

И мне хочется, чтобы plymouth выводился исключительно на экран, не мешая serial console:
https://bugzilla.altlinux.org/39326

> 
> > (plymouth не работает при включении вывода на serial console), поэтому и резона не вижу.
> 
> Я рассматриваю aarch64 как "обычный компьютер для обычного пользователя", а
> не как хакерскую игрушку. А соответственно serial console а) нужна < 1%
> пользователей, б) не всегда (легко) доступна

И тем не менее, на одноплатниках обычно врубается она, если не указать console=tty1.

Проблемы больше нет, как в новых, так и в старых образах. Видимо, помогло последнее обновление virtualbox до 6.1.34