LINUX.ORG.RU
Форум — Development  

arm linux framebuffer


0

0

fbfd = open("/dev/fb0", O_RDWR);

char *fbp = (char *)mmap(0, screensize, PROT_READ | PROT_WRITE, MAP_SHARED, fbfd, 0);

printf("start memset test...\n");
gettimeofday (& before, NULL);
int i; for(i = 10; i > 0; i--){
memset(fbp, 0xff, screensize);
memset(fbp, 0x00, screensize);
}
gettimeofday (& after, NULL); t = after.tv_sec - before.tv_sec + (double)(after.tv_usec -before.tv_usec)/1000000;
printf("memset 20 test: %f\n\n", t);

printf("\n\nstart write test...\n");
char * buff = alloca(screensize);
memset(buff, 0xaa, screensize);
char * buff2 = alloca(screensize);
memset(buff2, 0xf0, screensize);
gettimeofday (& before, NULL);
for(i = 10; i > 0; i--){
close(fbfd);
fbfd = open("/dev/fb0", O_RDWR);
write(fbfd, buff, screensize);
close(fbfd);
fbfd = open("/dev/fb0", O_RDWR);
write(fbfd, buff2, screensize);
}
gettimeofday (& after, NULL);
t = after.tv_sec - before.tv_sec + (double)(after.tv_usec - before.tv_usec)/1000000;
printf("close open write 20 test: %f\n\n", t);

##############################

И вот что на выходе:

start memset test... memset 20 test: 2.163977

start write test... close open write 20 test: 0.754604

Что-то уж очень медленно. Почему второй вариант быстрее первого? Может кто знает что можно почитать про framebuffer для embedded линуксов, а ещё лучше про линуксы на arm-ах?

Заранее спасибо.

← Теория: хранение графа
[кодировки] wchar_t to char →

>Почему второй вариант быстрее первого?

кривая методика тестирования?

dimon555 ★★★★★
()

>Почему второй вариант быстрее первого?

имхо сильно зависит от драйвера, какой драйвер в данном случае используется ?

>Может кто знает что можно почитать про framebuffer для embedded линуксов

Ничего практически нет, кроме skeletonfb.c

>а ещё лучше про линуксы на arm-ах?

никакой разницы нет - framebuffer это абстракция от хардварной части, без разницы на какой архитектуре реализовано.

если кратко - framebuffer это обычный char device со всеми вытекающими, только запись в эту память приводит к отображению чего-то на экране в зависимости от режима, еще могут быть реализованы ф-ции для ускорения работы с произвольной прямоугольной обласью экрана, скроллинг, это если есть аппаратная поддержка иначе используются стандартные ф-ции ядра. вообщето ремап памяти должен работать быстрей.

imhotep
()
Ответ на: комментарий от imhotep

Драйвер - ep93xxfb

Ну, раз уж нашлись знающие люди - я всё-таки спрошу: как управлять дисплеем через эту абстракцию (framebuffer), есть ли ещё что-нибудь кроме ioctl, и как запретить консоли виводить на экран курсор или захватить этот фреймбуфер?

nibbler
() автор топика
Ответ на: комментарий от nibbler

>есть ли ещё что-нибудь кроме ioctl > как запретить консоли виводить на экран курсор или захватить этот > фреймбуфер?

Где то в исходниках SDL или busybox видел, что открывается не только /dev/fbX но и /dev/ttyX и во второй пишется esc-последовательность для отключения курсора, подробнее об этом наверно только в исходниках fbcon в ядре. А кроме ioctl что ещё может быть? рекоммендую смотреть код утилит настройки фреймбуфера, fbset и т.д.

amaora ★★
()
Ответ на: комментарий от nibbler

Как управлять - смотрите исходники fbset

>как запретить консоли виводить на экран курсор

не включать в ядре модуль fbcon ?

>или захватить этот фреймбуфер

fbcon /dev/fbX не захватывает - можно абсолютно спокойно запустить приложение использующее framebuffer с любой консолии даже в скрипте, даже если fbcon висит на нем, единственно курсор будет виден, да , но тут лекарство я написал перед этим :)

imhotep
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Теория: хранение графа
Development
[кодировки] wchar_t to char →