RedHat представила kernel-based переключатель видеорежима

P.S. Если мне не измеяет склероз - то на каких то из последних геркулесов была такая возможность - смешение теста и графики в несколько слоёв...

Кажется, шрифты корёжить можно было только на ega+, до этого знакогенератор был только фиксированный в ПЗУ

> А так и есть. Я видел ЭТО. Они просто в качестве desktop shell поставили cmd.exe :-)

а я в 98й far ставил, когда у меня виндовая оболочка стала вылетать при загрузке :)

>CRTшка была насколько уродливо и бестолково сконструирована что из нее выбивали подчас феноменальные эффекты

Это был VGA.

Да елки люди - грузитесь в консоль без всяких X - в одном терминале запускаем mc - в другом запускаем mplayer -vo fbdev - и что в графический режим перешли? А кто ж это для mc так все транслировать стал да еще налету? Или что кусок экрана в графическом режиме а кусок в текстовом? Или что?

>У Корветов было 2 подсистемы. Одна — текстовая, другая — графическая.

Мля - естественно! Я не про подсистемы говорю а про режимы. В одном и том же режиме рисовались и символы знакогенератором и графика.

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

8x8 Один байт и на цвет фона и на цвет пикселов и яркости. Зато можно было делать прикольную атрибутную "плазму" =)

Хехехехе... Они оба в графике.

> пытается ещё сильнее косить под винду ... Гном там по умолчанию

:))

> сделали графику в ядре

:))

> куда катится RedHat? ... и это кому-то ещё нравится ...

Ну так, не нравится - не юзай, кто же заставляет.

И новость желательно осилить, да. :)

>Снег о котором говорил r в текстовом режиме делался путем перепрограммирования аппаратной таблицы шрифтов

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

Нет там нигде текстового режима.

>Хехехехе... Они оба в графике.

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

>Нет там нигде текстового режима.

Ты тоже можешь все исчеркать диагональными линиями да?

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

Хорошо. Вот, в стандартном текстовом режиме буфер расположен в b800, на каждое знакоместо отведено 2 байта - код символа + атрибуты. Где находится предполагаемая графическая составляющая, какое разрешение и глубина цвета у этого режима? Каким образом оно рисуется адаптером: за, перед текстом, или с полупрозрачностью? Почему нигде не использовались эти чудесные возможности текстовых режимов? Прикиньте, были б обои в ДОСе

>Ты тоже можешь все исчеркать диагональными линиями да?

Любыми, кто мне запретит? А ты нет?

ну тут уже всё просто:

пример кода с линиями в студию и спор будет разрешён.

?

Короче, насколько я помню fbcon.c занимается прорисовкой символов в fb консоли. Возможности ее ограничены текущим загрудженным фонтом. Однако никто не мешает рисовать там же что угодно.

А сплэш-заставка при загрузке у тебя тоже в текстовом режиме?

>b800

На B800 находится только _текстовый_ буффер.

> Почему нигде не использовались эти чудесные возможности текстовых режимов? Прикиньте, были б обои в ДОСе

Венда появлась когда? А когда появился VGA? Вы задаете вопрос почему вообще никто графические среды под досом серьезно не разрабатывал.

>Прикиньте, были б обои в ДОСе

Исходя из вашего вопроса остается только удивлятся почему текстовые режимы в линукс с более высоким разрешением чем 80x25 воявились не в 94 когда вышли первые VESA расширения. Что-то я и виртульных скринов не помню в досе которые можно было делать уже в 94 году. И TrueColor как-то не прижился в том же лохматом году - почему так?

>А сплэш-заставка при загрузке у тебя тоже в текстовом режиме?

Попробуй порисовать графику функциями биоса - увидишь.

Биос вызвать будет несколько затруднительно 8) Хотя, в принципе, можно.

......./kernel/Documentation/fb/framebuffer.txt........

The frame buffer devices are also `normal' memory devices, this means, you can
read and write their contents. You can, for example, make a screen snapshot by

  cp /dev/fb0 myfile

There also can be more than one frame buffer at a time, e.g. if you have a
graphics card in addition to the built-in hardware. The corresponding frame
buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently.

..........................................................

Можно вывести туда любой файл и убедитмся что это таки графика 8)

> по поводу Руссиновича+Катлера мы как-то столкнулись

Хм, не припомню совместных работ Руссиновича и Катлера :)

> ты сказал что это тоже маркетинговый материал =)

мне нравится это словосочетание %) впрочем, для того, чтобы понять, что NT не основана на Mach, достаточно и маркетинговых материалов.

>Можно вывести туда любой файл и убедитмся что это таки графика 8)

С чего бы это? Если у него функция как раз делать такие хаки?

>Биос вызвать будет несколько затруднительно 8) Хотя, в принципе, можно

Ну вот попробуй. Если мы уже находимся в графическом режиме следовательно переход делать не нужно и функция bios set pixel отработает шикарно.

На AMD.COM некогда валялись видеоролики с Катлером. Там он, в частности, как то прошелся по истории выней. Достаточно любопытное зрелище (или слушище ? 8).

>пример кода с линиями в студию и спор будет разрешён.

cat /dev/urandom >/dev/fb0 устроит? Линии сейчас лень рисовать.

Э, батька.... тут я бессилен - завтра с утречка непременно посетите психиатра. Может быть он вам поможет.

>Ну вот попробуй. Если мы уже находимся в графическом режиме следовательно переход делать не нужно и функция bios set pixel отработает шикарно.

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

>cat /dev/urandom >/dev/fb0 устроит? Линии сейчас лень рисовать.

Нет конечно! ТЫ суть то понимаешь? ТЫ утверждаешь что мы находимся в видеорежиме а я что фреймбуффер - это хитрый враппер вокруг видеопамяти. Ты что мне хочешь доказать что мы в видережиме через хитрый враппер? Нефига - бере либую удобную либу - хоть ассемблер и биосовское 10h и вызывай графическую функцию без перехода в режим - если мы в графике - она должна отработать без всяких проблем и сопротивления и нарисоваться.

Любопытная возможность..

>И на каой вообще использовать эти тормозные функции, когда у драйвера fb есть прямой доступ к видеобуферу, аппаратное ускорение(в некоторых случаях) и функции рисования примитивов?

Тебя что скорость пикселя в тестовой проге заботит или что?

>когда у драйвера fb есть прямой доступ к видеобуферу,

Замечательно! Но ты его не используй - ты выведи пиксель хоть бы с пмощью svgalib при этом опустив vga_setmode - потому что мы уже в нем. Если в нем - значит будет телемаркет.

>аппаратное ускорение(в некоторых случаях) и функции рисования примитивов?

Так я тоже тогда в досе не посредством молитвы аллаху эти фигни писал - а именно с прямой записью в видеопамять, координаты вычислялись путем определения адреса в памяти где этот пиксел находится - а не обращением к графическим функциям биоса - потому и работало. Конечно если ты скажешь в текстовом режиме int 10h put pixel - ты будешь послан с матами.

Ну блин ....

Из того же файла ...

0. Introduction
---------------

The frame buffer device provides an abstraction for the graphics hardware. It
represents the frame buffer of some video hardware and allows application
software to access the graphics hardware through a well-defined interface, so
the software doesn't need to know anything about the low-level (hardware
register) stuff.

The device is accessed through special device nodes, usually located in the
/dev directory, i.e. /dev/fb*.

--------------------------------------

Ну чего еще надо то ? 8)

> Каким образом оно рисуется адаптером: за, перед текстом, или с полупрозрачностью? Почему нигде не использовались эти чудесные возможности текстовых режимов?

такие возможности были только у вышеупомянутых корветов, возможно (не проверял), у геркулесов.

а как корветы плоскости располагали – не помню. Помню, что их вроде было 5 – 4 цветовые графические, одна текстовая.

переключение без этой фичи: http://youtube.com/watch?v=X1hUEecCjCs

с этой фичей: http://youtube.com/watch?v=QAYrltN1gzQ

Ну, под занавес, ДВК тоже обзавелись подобным видеоадаптером. Вот не помню как было на Электронике-85 8)

Эээ, так на втором видео разрешение не меняеццо при переключении в консоль!

Вот, написал щас на коленках пример, который получает адрес видеобуфера и выводит туда произвольное изображение.  Жду разъяснений, почему этот режим - текстовый.


#include <fcntl.h> 
#include <unistd.h> 
#include <sys/types.h> 
#include <sys/stat.h> 
#include <sys/mman.h> 

#define FB_WIDTH (1024) 
#define FB_HEIGHT (768) 
#define FB_BPP (4) //bytes per pixel 
#define FB_SIZE (FB_WIDTH * FB_HEIGHT *  FB_BPP) 

int fb_fd;
unsigned int * fb_mem;

int fb_init(char *path)
{
    fb_fd = open(path, O_RDWR);
    if (fb_fd == -1)    return -1;

    fb_mem = mmap(0, FB_SIZE , PROT_READ | PROT_WRITE, MAP_SHARED, fb_fd, 0);
    if (fb_mem == MAP_FAILED) {
        close(fb_fd);
        return -2;
    }
return 0;
} 
void fb_exit(void)
{
    munmap(fb_mem, FB_SIZE);
    close(fb_fd);
}

int main(void) {
    int x,y;
    printf("init fb: %i\n",fb_init("/dev/fb0"));
    for (y=0;y<FB_HEIGHT;y++)
        for ( x=0;x<FB_WIDTH;x++)
            fb_mem[y*FB_WIDTH + x]=x*y;
    fb_exit();
    return 0;
}

Да, и со своей стороны приведи пример вывода символа во фреймбуфер путем записи его кода в некую область памяти, если утверждаешь, что это текстовый режим :)

пример кстати работает даже с запущенными иксами.

usr/include/linux/fb.h - там смещения нужны.

Подтверждаю. У "r" в голове каша.

Хоть он вроде и знает, что такое текстовый и графический режимы на PC, но объяснить не может.

>Один раз (при старте) ;)

Четыре звёздочки наговорил, а кроме как про vesafb ничего не слышал?

>С драйвером vesafb - да, другие дрова умеют переключать в любой момент. Ну и есть модификация vesafb-ng, которая умеет также.

vesafb-ng - R.I.P. uvesafb уже в ванильном ядре (начиная с 2.6.25).

Это просто минимальный рабочий(при определенных условиях:) пример, не хотелось исходник лишним перегружать. Главное, суть ясна - получаем адрес видеопамяти и делаем туда что хотим, как это было в ДОСе с весой2

>У меня кстати прекрасно дружит на старом десктопе...

Врёшь

>Какая разница? Этот режим ни разу не графический. Это называется vesa-mode - там настоящий текстовый терминал - просто в другом разрешении.

А сейчас ты обогощаешь лужи метаном:)

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

В случае с vesafb (и любым другим *fb) - это не так.

>В текстовом режиме на экран могут выводится 2 сегмента памяти

Озучь как кую архитектуру ты имеешь ввиду. На PC-like это не так. На PDP/ДВК-3 можно было так делать.

Я думаю - он уже осознал 8)

>Скорость загрузки и быстрое переключение TTY/X - это не самое ценное в kernel mode settings. Самое ценное - это аналог "синего экрана смерти". Раньше при зависании X никто не мог узнать и не знал, что же на самом деле является причиной заисания? Теперь core dump можно будет увидеть на экране.

>Цитата: Kernel mode-setting will also allow for an improved debugging experience, as this will eliminate the "hard hang" and make it possible to display a graphical error message (think the "Blue Screen of Death" for Linux).

OH MY FOCKING GOD! Я чуть штаны не обоссал! Ну всё, виндузятнички, прощайте навсегда, я перехожу на BSD.

>Ну всё, виндузятнички, прощайте навсегда, я перехожу на BSD.

Ура! Только ты перепутал: не "прощайте навсегда", а "здравствуйте, братки! отсыпте семок!"

>BSOD портировали? кому капец то?!

Да я запутался уже :( Аналитики, выручайте!!