Перейти к содержанию
    

подскажите пожалуйста, можно где-то прочитать о том, что такое фрейм буфер?

в чем его отличие от символьного устройства?

(sceleton.c видел)

как с ним работать со стороны пользовательского пространства?

нашел только документы от 2000 и 2002 года.

технология с тех пор не менялась?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

подскажите пожалуйста, можно где-то прочитать о том, что такое фрейм буфер?

 

Это буфер окна :)

 

в чем его отличие от символьного устройства?

 

В терминах системы это и есть символьное устройство.

 

(sceleton.c видел)

как с ним работать со стороны пользовательского пространства?

 

Как с символьным устройством - read/write или mmap (последний чаще всего, вернее первый я кроме консоли нигде не встречал)

 

нашел только документы от 2000 и 2002 года.

технология с тех пор не менялась?

 

Да какие там технлогии - это просто кусок памяти который имеет структуру в соответствии с текущим режимом: разрешение и цветность. Для fbcon кроме того есть специальные ф-ции с помощью которых можно ускорить работу с кусором или скролингом экрана - если это не поддерживается устройством аппаратно то их нет смысла эмулировать програмно, они не нужны для нормальной работы. Для примера простой вариант: экран 320х200@16 будет соответствовать сишному массиву uin16t fbscreen[200][320]; и для 16 бит пиксель состоит из rgb 565.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

тогда напрашиваются 2 вопроса.

1. если это просто разделяемый между user и kernel space буфер памяти,

как происходит уведомление драйвера о необходимости перерисовки?

как происходит оптимизация перерисовки?

или же все тупо:

user space заполняет память, а драйвер просто с заданной частотой обновления перекидывает его на экран?

 

2. программы пользовательского пространства как-то видимо должна получать параметры дисплея (через ioctl?) и понимать, отрисовку чего видеокарта может ускорить, а что надо эмулировать программно.

как это делается?

если через ioctl, значит, есть стандартные коды запросов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

тогда напрашиваются 2 вопроса.

1. если это просто разделяемый между user и kernel space буфер памяти,

как происходит уведомление драйвера о необходимости перерисовки?

как происходит оптимизация перерисовки?

или же все тупо:

user space заполняет память, а драйвер просто с заданной частотой обновления перекидывает его на экран?

 

2. программы пользовательского пространства как-то видимо должна получать параметры дисплея (через ioctl?) и понимать, отрисовку чего видеокарта может ускорить, а что надо эмулировать программно.

как это делается?

если через ioctl, значит, есть стандартные коды запросов?

 

1 Если mmap то никак, read/write - я думаю с этим понятно - пишешь свои ф-ции и обрабатываешь переданные из/в юзерспейс данные. Вообще это сегодня появились всякие SoC, lcd и framebuffer используют как некий слой абстракции над железом, изначально он использовался в x86 по назначению - это был прямой доступ к памяти видеоконтроллера. Если видеобуфер выделяется в озу то да, так и делают - постоянно обновляется экран.

2 Я думаю в Интернете немало информации чтобы спрашивать все подряд на форуме :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 Я думаю в Интернете немало информации чтобы спрашивать все подряд на форуме :)

я потому и спрашиваю на форуме, что не смог найти в интернете.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я потому и спрашиваю на форуме, что не смог найти в интернете.

 

 

Да перестаньте - это смешно. Я например обычно начинаю поиск в документации идущей в исходниках ядра, как ни страноо там есть вот это:

# pwd
/usr/src/linux-2.6.33/Documentation/fb

 

Совсем странно что там есть описание fbcon и собственно fb

fbcon.txt

framebuffer.txt

 

Например framebuffer.txt нам говорит:

/dev/fb* also allows several ioctls on it, by which lots of information about

the hardware can be queried and set. The color map handling works via ioctls,

too. Look into <linux/fb.h> for more information on what ioctls exist and on

which data structures they work. Here's just a brief overview:

 

 

Теперь достаточно посмотреть include/linux/fb.h

# cat fb.h | grep FBIO
#define FBIOGET_VSCREENINFO    0x4600
#define FBIOPUT_VSCREENINFO    0x4601
#define FBIOGET_FSCREENINFO    0x4602
#define FBIOGETCMAP        0x4604
#define FBIOPUTCMAP        0x4605
#define FBIOPAN_DISPLAY        0x4606
#define FBIO_CURSOR            _IOWR('F', 0x08, struct fb_cursor_user)
#define FBIO_CURSOR            _IOWR('F', 0x08, struct fb_cursor)
/* #define FBIOGET_MONITORSPEC    0x460C */
/* #define FBIOPUT_MONITORSPEC    0x460D */
/* #define FBIOSWITCH_MONIBIT    0x460E */
#define FBIOGET_CON2FBMAP    0x460F
#define FBIOPUT_CON2FBMAP    0x4610
#define FBIOBLANK        0x4611        /* arg: 0 or vesa level + 1 */
#define FBIOGET_VBLANK        _IOR('F', 0x12, struct fb_vblank)
#define FBIO_ALLOC              0x4613
#define FBIO_FREE               0x4614
#define FBIOGET_GLYPH           0x4615
#define FBIOGET_HWCINFO         0x4616
#define FBIOPUT_MODEINFO        0x4617
#define FBIOGET_DISPINFO        0x4618

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

видимо я опять задал не тот вопрос...

даже не знаю как сформулировать...

вот смотрите.

есть драйвер с кадровым буфером.

это символьное устройство.

следовательно, подразумевается, что работа с ним - это операции чтения и записи.

однако, это видео-устройство. следовательно должны быть какие-то спец вызовы.

ну и видимо, они как-то должны зависеть от способностей карты к ускорению.

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

но если есть эти функции, значит, если в драйвере они не реализованы, их кто-то должен делать за него.

так?

то есть видимо

драйвер - графическая подсистема - программа.

и следовательно, должны быть, наверно, стандартные вызовы?

или же в линуксе нет такой подсистемы? (я не про X сервер!!!)

как тогда обращаться к этим функциям акселерации драйвера?

и напрашивается вопрос:

а если есть новое устройство, которое умеет ускорять нечто новое (отрисовку шариков, например), для чего не предусмотрены функции в скелете, как они задействуются?

 

видимо, не я один че-то не понимаю...

http://linuxhaters.blogspot.com/2008/06/ni...pen-source.html

Изменено пользователем VDV

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

нашел наконец-то что-то

http://books.google.ru/books?id=sTDHUr4eGY...p;q&f=false

Изменено пользователем VDV

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

вопрос появился

написал драйвер для своего дисплея.

оформил как внешний модуль

определил для вызовов в нем функции sys_fillrect и подобные ей от системы.

при компиляции получаю предупреждения, что таких функций в ядре нет.

не могу в меню найти этий опций!

попробовал прямо в .config включить, но это не срабатывает.

как включить их компиляцию?

 

далее сделал пока так:

отключил их из списка в fops и в ядре выключил консоль для кадрового буфера.

драйвер теперь грузится.

для проверки делаю так:

# cat test > /dev/fb0

cat: write error: File too large

 

файл test имеет размер 1 байт.

куда копать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...