Ещё разок по поводу framebuffer на ATI

Можно. Параметр ядра vga=0x317 . Чтобы узнать все режимы сделай vga=ask.

uvesafb

Да, то, что я писал, это vesafb, не забудь вкомпилить в ядро. Вот еще хороший источник с описание и перечнем режимов: /usr/src/linux/Documentation/fb/vesafb.txt

в grub2 это не работает

uvesafb

Это нужно если у тебя архитектура не x86. Иначе vesafb хватает.

в grub2 это не работает

Решение для grub2 гуглится за полсекунды: http://unix.stackexchange.com/questions/107479/how-do-you-pass-vga-vesa-modes...

{amd,проприетарщино}-пользователи должны страдать

конечно, нормальным людям не нужно 3d для всяких 3d sex villa и ビジュアルノベル

Разрешаю. У меня граб2 в 1920x1080 и uvesafb в том же разрешении. Ещё и один рисунок в фоне граба, консолей, кдм и на рабочем столе.

Решение для grub2 гуглится за полсекунды

Пользовался и подобным решением и uvesafb. Проблем от uvesafb было меньше.

в 1920x1080

повезло, обычно в видео биосах нет 16:9

мой граб сказал что можно 1400x1050x32, его и использую (MSI R9 280x), но это efi framebuffer

У меня свободный на AMD Radeon HD 7690M. Но оно дискретное и в обычном режиме отключено. Включается только по явному запросу DRI_PRIME=1. Всегда работает Intel HD3000, через него идёт весь вывод на дисплей. Соответственно, на Intel'е тоже свободный драйвер.

Раньше я использовал различные карточки Nvidia с блобом. Там по умолчанию консоль была тоже в ХЗ каком разрешении. Произвольное нативное разрешение, конечно, выставить не получалось, но подобрать что-то более-менее приближенное к нему получалось опциями в GRUB2:

#GRUB_TERMINAL_OUTPUT="console"
GRUB_GFXMODE=1366x768x32,1366x768x24,1366x768x16,1360x768x32,1360x768x24,1360x768x16,1024x768x32,1024x768x24,1024x768x16,1024x768x8

Эту конструкцию уже давненько в legacy выбросили.

эм, uvesafb работает только на x86 и amd64... Ты точно ничего не перепутал? :-)

На ЛОРе поднимались эти темы и я этим тоже в свое время озаботился. С Блобом нвидии на древнем ноуте это работает как-то так.

По-моему там вообще срать что есть в биосе... В грабе gfxterm, кушает «gfxmode=1920x1080». Uvesafb жрёт «video=uvesafb:mtrr:3,ywrap,1920x1080-24@60».

Спасибо. Только проблема пока что остаётся. Пробовал ставить uvesafb по гентушной вики — словил кернел паник на этапе загрузки — разрешение экрана при этом оставалось таким же убогим.

Попробовал эти строки из SE — вообще сообщений не стало. Идёт уведомление о загрузке ядра, а потом через некоторое время DM.

Какой у тебя grub: первый или второй?

Второй. Поэтому и пользовался строками с SE жеж

эм, uvesafb работает только на x86 и amd64... Ты точно ничего не перепутал? :-)

Откуда инфа?

/usr/src/linux/Documentation/fb/uvesafb.txt :
Unlike other drivers, uvesafb makes use of a userspace helper called v86d. v86d is used to run the x86 Video BIOS code in a simulated and controlled environment. This allows uvesafb to function on arches other than x86.

https://wiki.archlinux.org/index.php/uvesafb
In contrast with other framebuffer drivers, uvesafb needs a userspace virtualizing daemon, called v86d. It may seem foolish to emulate x86 code on a x86, but this is important if one wants to use the framebuffer code on other architectures (notably non-x86 ones).

Я когда-то пытался разобраться во всяких FB. Как я понял, единственное отличие uvesafb от vesafb - возможность работать на не-x86 за счет userspace/virtualization. Учитывая, что он устанавливается чуть сложнее, чем vesafb, я для себя отметил, что он имеет смысл только на не-x86.

Поправляй если что не так.

нет, и в grub и в *vesafb только vesa режимы из конкретного видеобиоса. произвольные режимы можно только с драйвером с kms или в иксах ставить

Вот только и граб и юзерспейсная веса работали у меня в произвольном разрешении на любой даже очень старой видяшке... не сходится.

у меня ни на одной из пачки видях не работают

иди почитатай про vbe и убедись что и в grub и в vesafb через него

или ты мыльный апскейл принимаешь за нативное разрешение, как вариант

Я вижу два варианта.

Первый, по идее более правильный:

GRUB_GFXMODE=1024x768x16M
GRUB_GFXPAYLOAD_LINUX=1024x768x16M

Второй способ:

GRUB_CMDLINE_LINUX_DEFAULT="vga=0x317"

Пробуй, отписывайся по результатам.

Да, если не получится, еще выгрузи куда-то конфиг ядра.

Поправляй если что не так.

Документация справедлива, v86d ТЕОРЕТИЧЕСКИ позволяет работать с uvesafb на не-x86 архитектурах. Проблема в том, что код для этих архитектур пока никто не написал, а главный разработчик(spock) забросил проект.

Так что - возможность конечно есть, но по факту на текущий момент - это не работает нигде кроме x86/amd64.

Вроде бы были какие-то подвижки завести uvesafb на arm или mips, но подробнее сказать не могу - так, что-то слышал краем уха на каком-то IRC-канале(кажется это был #gentoo-embedded).

Как я понял, единственное отличие uvesafb от vesafb - возможность работать на не-x86 за счет userspace/virtualization.

Не совсем. На тот момент, когда я им только начинал пользоваться(2007 год кажется) - он поддерживал гораздо большую гибкость в управлении разрешением консоли(включая битность), чем стандартный параметр vga= для vesafb.

То есть его имело смысл использовать на x86/amd64, если vesafb не поддерживал какое-то разрешение(1366x768, например, заводился на uvesafb тогда с пол пинка, в отличие от vesafb)

Нативное разрешение, не поддерживаемое на тот момент vesafb, но имеющееся в uvesafb было, как я уже упоминал. И это был таки не upscale.

Другое дело что с введением KMS в большинство opensource-драйверов, польза от uvesafb стала мягко говоря сомнительна.

Спасибо за помощь, но пока что не успешно :( В каждом из предложенных случаев ничего, кроме чёрного экрана, я не получил.

Конфиг ядра скинул сюда: http://pastebin.com/p4dNWaN5

Может, интересует какой-то конкретно параметр вместо той простыни?

Проблема в том, что код для этих архитектур пока никто не написал, а главный разработчик(spock) забросил проект.

Хм, похоже на то. По крайней мере не в Gentoo.
Ну, тогда становится вопрос, чем uvesafb лучше или вообще отличается (с точки зрения результата) от vesafb?

тогда становится вопрос, чем uvesafb лучше или вообще отличается (с точки зрения результата) от vesafb?

Я уже говорил - раньше uvesafb поддерживал более гибкое управление разрешением и битностью фрэймбуффера.

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

У меня тоже ATI/AMD. Пользуюсь grub1 и параметром vga=... Ядро 3.12.

Вот сравнение наших конфигов.

$ sdiff -s video2_ecko.config video2_kroz.config 
CONFIG_AGP is not set                                         | CONFIG_AGP_ALI is not set
                                                              > CONFIG_AGP_AMD64=y
                                                              > CONFIG_AGP_AMD is not set
                                                              > CONFIG_AGP_ATI is not set
                                                              > CONFIG_AGP_EFFICEON is not set
                                                              > CONFIG_AGP_INTEL=y
                                                              > CONFIG_AGP_NVIDIA is not set
                                                              > CONFIG_AGP_SIS is not set
                                                              > CONFIG_AGP_SWORKS is not set
                                                              > CONFIG_AGP_VIA is not set
                                                              > CONFIG_AGP=y
CONFIG_BACKLIGHT_LM3630A is not set                           | CONFIG_BACKLIGHT_LM3630 is not set
                                                              > CONFIG_FB_EFI=y
                                                              > CONFIG_FB_GEODE is not set
                                                              > CONFIG_FB_I810 is not set
CONFIG_FB_OPENCORES is not set                                <
CONFIG_FB_SIMPLE=y                                            | CONFIG_FB_SIMPLE is not set
CONFIG_FB_TILEBLITTING is not set                             | CONFIG_FB_TILEBLITTING=y
                                                              > CONFIG_FB_TMIO is not set
CONFIG_FB_UVESA=y                                             | CONFIG_FB_UVESA is not set
CONFIG_FRAMEBUFFER_CONSOLE is not set                         | CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
                                                              > CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
                                                              > CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_VGA_SWITCHEROO=y                                       | CONFIG_VGA_SWITCHEROO is not set
CONFIG_VIDEO_OUTPUT_CONTROL is not set                        | CONFIG_VIDEO_OUTPUT_CONTROL=y
                                                              >

В общем, можно тупо привести в соответствие с моим, а можно попробовать те опции, что я указал. Первое лучше, ибо мы на самом деле не знаем на 100% влияние каждой опции. Как говорится, сначала заставь работать, потом чисти/оптимизируй.

Сейчас попробую поставить grub 2. Хочешь жди результатов, хочешь сразу пробуй.

Огромное спасибо, дружище!

Сдаётся мне, проблема была в невыставленном CONFIG_FRAMEBUFFER_CONSOLE, в большинстве своём. Выставил его, закомментив все изменения в /etc/default/grub — после перезагрузки то же самое. Раскомментил снова в /etc/default/grub

GRUB_GFXMODE=1366x768x32M
GRUB_GFXPAYLOAD_LINUX=1366x768x32M

Тогда ещё такой вопрос к carasin, как к человеку, у которого прописано несколько пунктов в GRUB_GFXMODE: каким образом он выбирает нужный из них? Если у меня, например, есть монитор 1920x1200, то смогу ли я выставить и его разрешение, получив, тем самым, 1920х1200 при подключённом мониторе и 1366х768 иначе?

Ну вот, а я только grub2 поставил, думал конфигурить. А теперь будет лень :)

Ладно, удачи!

Я прописывал разрешения, начиная от нативного для монитора и далее в порядке уменьшения. ЕМНИП, оно останавливает свой выбор на первом из указанных разрешений, для которого имеется соответствие в VBIOS.

это был баг или отсутствие поддержки чего-то в обычном vesafb

зачем упорно спорите с документацией на сам же uvesafb:

The most important limitations are:
A strict and limited set of supported video modes. Often the native or most optimal resolution/refresh rate for your setup will not work with uvesafb, simply because the Video BIOS doesn't support the video mode you want to use. This can be especially painful with widescreen panels, where native video modes don't have the 4:3 aspect ratio, which is what most BIOS-es are limited to.

где мои 1920x1080, я слепой, может, или что:

$ sort -rn </sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes
1600x1200-8, 0x0145
1600x1200-32, 0x014a
1600x1200-16, 0x0146
1280x1024-8, 0x0107
1280x1024-32, 0x011b
1280x1024-16, 0x011a
1024x768-8, 0x0105
1024x768-32, 0x0118
1024x768-16, 0x0117
800x600-8, 0x0103
800x600-32, 0x0115
800x600-16, 0x0114
640x480-8, 0x0101
640x480-32, 0x0112
640x480-16, 0x0111
640x400-8, 0x0100
640x400-32, 0x013e
640x400-16, 0x013d
320x400-8, 0x0131
320x400-32, 0x0133
320x400-16, 0x0132
320x240-8, 0x0134
320x240-32, 0x0136
320x240-16, 0x0135
320x200-8, 0x0130
320x200-32, 0x010f
320x200-16, 0x010e

simply because the Video BIOS doesn't support the video mode you want to use.

У тебя нет в данном списке того же 1366x768 - у меня он был. Так что документация права.

where native video modes don't have the 4:3 aspect ratio, which is what most BIOS-es are limited to.

most != all

most ≈ all

когда в вашей генте починят opencl?

Уточни что сломано. Я имею ввиду, какой именно баг с багзиллы, связанный с opencl, тебя раздражает.

https://bugs.gentoo.org/show_bug.cgi?id=521734

https://bugs.gentoo.org/show_bug.cgi?id=520736

https://bugs.gentoo.org/show_bug.cgi?id=496418

Последний баг по ссылке зафикшен. По поводу первых двух - надо тыкать чуваков из media-video. Поймай кого-нибудь из них на #gentoo-dev-help в IRC и спроси их о сроках.

рисунок в фоне ... консолей

Ловите наркомана!

Мсье никогда не слышал про framebuffer-консоли, fbcondecor и splashutils? :-)