framebuffer драйвер Опции

[amaora]

Пишу драйвер PCF8833 (дисплей от nokia), оказалось взаимодействовать с ядром гораздо сложнее, чем с контроллером LCD.
Дисплей подключен по SPI, в связи с чем такая проблема,
mmap из userspace, похоже нет ни какого хорошего способа узнать, что память была отмэплена и перезаписана, и что новые данные пора отправить контроллеру.
есть два варианта,
- регулярно проверять буфер на изменения, не подходит т.к. это постоянный расход времени процессора
- обновлять по запросу из userspace, есть там какой то sync но как я понял он совсем не для этого, и ни кто его так не использует

может кто нибудь знает вариант получше?

Спасибо,
пока работает только fbcon,  pcf8833.c.txt ( 10.02 килобайт ) Кол-во скачиваний: 426

[amaora]

Да в чем разница то? ну растеризатор там вместо mpeg декодера, как это на работу драйвера влияет?

Переписать софт было бы правильнее, не плохо бы ещё сделать нормальную синхронизацию (ну то есть flush должен блокировать процесс или сообщать, что тот слишком часто шлет новые данные) а не пропуск кадров. Только это все не оправдано для такого дисплея, там 20 кадров в секунду похоже предел самого LCD.

Но скорее сделаю как проще, добавлю свой ioctl, для включения/отключения постоянной отправки кадров в контроллер LCD, а из userspace, когда надо запустить "не правленный" софт, можно включать это. Думаю это окончательный и лучший вариант.

И ещё раз про atmel_spi,
spi_write это синхронная функция, то есть явно не для больших объемов данных. Да можно было бы усложнить драйвер и избавится от этого недостатка, это ворос равновесия между сложностью интерфейса и реализации. Вы похоже сторонник хорошего внешнего интерфейса, и пусть будет кривая (но работающая) его реализация, так?

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

Сообщение отредактировал amaora - Jun 16 2009, 14:08

[sasamy]

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

В общем не вижу смысла в дальнейшей дискуссии

[VDV]

подскажите пожалуйста, можно где-то прочитать о том, что такое фрейм буфер?
в чем его отличие от символьного устройства?
(sceleton.c видел)
как с ним работать со стороны пользовательского пространства?
нашел только документы от 2000 и 2002 года.
технология с тех пор не менялась?

[sasamy]

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

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

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

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

(sceleton.c видел)
как с ним работать со стороны пользовательского пространства?

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

нашел только документы от 2000 и 2002 года.
технология с тех пор не менялась?

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

[VDV]

тогда напрашиваются 2 вопроса.
1. если это просто разделяемый между user и kernel space буфер памяти,
как происходит уведомление драйвера о необходимости перерисовки?
как происходит оптимизация перерисовки?
или же все тупо:
user space заполняет память, а драйвер просто с заданной частотой обновления перекидывает его на экран?

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

[sasamy]

тогда напрашиваются 2 вопроса.
1. если это просто разделяемый между user и kernel space буфер памяти,
как происходит уведомление драйвера о необходимости перерисовки?
как происходит оптимизация перерисовки?
или же все тупо:
user space заполняет память, а драйвер просто с заданной частотой обновления перекидывает его на экран?

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

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

[VDV]

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

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

[sasamy]

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

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

Код

# 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