Приведение массива к двумерному

[dlinyj]

Тупняка псот.

Встала задача "по быстрому" сделать вывод изображений и текста на экранчик через фреймбуффер на Beaglebone. Всё без сторонних либ (тюкю сборка rootfs будет своя, да и просто понять как это работает на нулевом уровне). Для тех кто в танке, считайте что у меня просто одномерный массив (байтов, шортов или 32-х разрядный) размером 1024х768 (или другие разрешения) в который я пишу и получаю изображение на экране. Первая и главная задача - это выводить текст. Да не по горизонтали, а вертикальный текст (имею в виду чтобы дисплей расположен был вертикально. Горизонтально удалось, а вот вертикально уже затупил.

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

Указатель на массив выглядит как:

static uint16_t *fbp = 0;

Вопрос совсем тупой: как преобразовать этот массив к виду arra[1024][768] (или другим разрешениям, они могут быть разные)? Чтобы можно было поставить точку там где ты хочешь? А то в уме уже начинаю путаться, уже второй день туплю.

Так же картинки. Как в старые добрые времена ДОС. Научился выводить pgm изображение, но нужен цвет. Либо преобразованное изображение с помощью программы LCD Image Converter. А вот решил bmp запилить побырому, чтобы можно было подложку менять. Взял примерчик отсюда . Сделал файлик test.bmp 1024x768 16bit

Получаю ссылку на битмам. Копирую её и получаю странный кал.

Цвета побиты, вместо одного сердца - тьма сердечек. Может я чего-то не понимаю? Кто делал, подскажите. Может у кого есть лёгкий пример, как выудить bitmap из bmp-файла. Спасибо!

Comments

[what-me.livejournal.com]

как преобразовать этот массив к виду arra[1024][768] (или другим разрешениям, они могут быть разные)? Чтобы можно было поставить точку там где ты хочешь?
Непонятно зачем преобразовывать массив если можно преобразовать координаты в индекс?
i = y * 1024 + x;

[minimumlaw.livejournal.com]

Стоп. Я чего-то не догнал? Это ж Linux? Фреймбуфферная консоль? Так повернуть ее и все дела

https://askubuntu.com/questions/237963/how-do-i-rotate-my-display-when-not-using-an-x-server

Пусть система решает предъявленную задачу. А у самого голова не болит.

[dlinyj.livejournal.com]

Попробовал, не получилось.

[minimumlaw.livejournal.com]

Файлы /sys/class/graphics/fbcon/rotate* наличествуют? Если нет, то можно ли пересобрать ядро в FBCON_CONSOLE_ROTATE?

[dlinyj.livejournal.com]

Наличиствует, но доступ запрещён. А ядро пересобирать - это уже высший пилотаж. Нет, это не сложно, просто мне кажется что это оверкилл

[mbr.livejournal.com]

приводи к указателю на структуру, описанную с pragma pack. Иначе компилятор оптимизирует, потом не разберешь где что.

Но на мой взгляд правильнее описать, как сказано комментарием выше. Твой подход не то, что прямо говнокод, просто так не принято.

[minimumlaw.livejournal.com]

Там все сложнее. Начало координат у большинства битмапов справа внизу, формат хранения цветов уточняется в заголовке (надо анализировать, как именно эти 16 бит на каждую точку расположены), далее встречается такая гадость как выравнивания (когда размер картинки внутри битмапа больше, чем сам битмап). Короче либо формат попроще (типа DIB), либо битмап строго определенного формата. Что в конкретно взятом примере? По ощущениям формат цветности неправильно распознан. Вполне возможно, что в файле 16 бит на цвет становится тремя байтами на точку.

[mbr.livejournal.com]

я про массив вообще-то писал, а не про битмапы.

[minimumlaw.livejournal.com]

И тем не менее. Формат массива бит сильно зависит от заголовка и тупо отрезать его нельзя.

P.S.
Да, важность #pragma pack необходимость анализа заголовка конечно не отменяет.

[mbr.livejournal.com]

Ну-ка расскажи мне про заголовки двумерных массивов :)))))

[minimumlaw.livejournal.com]

Блин! Мне возраст не позволяет манулы вслух и с выражением читать.

https://en.wikipedia.org/wiki/BMP_file_format

Или ее же, но по русски. BMP файл это не только массив данных о пикселях. Как, собственно и область данных фреймбуфера.

[mbr.livejournal.com]

Чукча писатель? Причем тут битмап?

[minimumlaw.livejournal.com]

"А вот решил bmp запилить побырому, чтобы можно было подложку менять." в статье ни о чем не намекают?

[mbr.livejournal.com]

Намекает только на то, что ты не очень понимаешь что такое фреймбуфер. Или не очень внимательно читаешь оригинальный пост и вопрос, не говоря уже о комментариях к нему ;)))

[mbr.livejournal.com]

> BMP файл это не только массив данных о пикселях. Как, собственно и область данных фреймбуфера.

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

[minimumlaw.livejournal.com]

https://elixir.free-electrons.com/linux/v4.14.14/source/include/uapi/linux/fb.h#L281

И зачем же нужна эта структура? И самое главное, разве она не имеет наипрямейшего отношения к области данных фреймбуфера?

[mbr.livejournal.com]

И где тут битмаповский заголовок? ;)

[minimumlaw.livejournal.com]

https://elixir.free-electrons.com/linux/v4.14.14/source/include/uapi/linux/fb.h#L241

struct fb_var_screeninfo - собственно он. Не имея его оперировать областью данных неразумно. Ибо даже разрешение неизвестно.

[mbr.livejournal.com]

> BMP файл это не только массив данных о пикселях. Как, собственно и область данных фреймбуфера.

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

[dlinyj.livejournal.com]

Да ладно вам сраться. Чувак комог мне по делу, просто ошибся.

[mbr.livejournal.com]

И да, если уж занудствовать до конца - ты моложе меня ;)

[minimumlaw.livejournal.com]

Хорошо. И тем не менее вслух и с выражением уже не могу. Надоело. Про невнимательно читаю... Учту. Буду внимательней. И перечитаю еще раз...

Перечитал. Или туп как дерево, или меня обвиняют не в тех грехах ;-)

Взял битмап. Было, сконвертировал как понял - было, вывел и получил лажу - было. При этом лажа по внешнему виду как раз напоминает неправильный разбор колор мапа. И где ошибка?

[mbr.livejournal.com]

> static uint16_t *fbp = 0;

>Вопрос совсем тупой: как преобразовать этот массив к виду arra[1024][768] (или другим разрешениям, они могут быть разные)? Чтобы можно было поставить точку там где ты хочешь? А то в уме уже начинаю путаться, уже второй день туплю.

Про конверсию битмапов я вообще ничего не писал.

[minimumlaw.livejournal.com]

Блин, так о том и речь. Нельзя просто так пойти в мордор сделать приведение в типу uint16_t**, uint32_t** или uint8_t**. Надо читать входные данные, анализировать колор мап, преобразовывать и писать в массив. А для вывода наоборот. Либо подбирать такой формат картинки, который бы в точности повторял формат фреймбуфера. И только-то.

Так что это не я не понимаю, как работает фреймбуфер. А читал да. Не внимательно. Признаю. Исправлюсь. А в целом - да повернуть fbcon и не париться. В ядре неплохо оптимизированы функции поворота. Не идеально, но весьма неплохо.

[mbr.livejournal.com]

Преобразование типов не подразумевает преобразование данных. Стоит задача типизировать область видеопамяти. Не преобразовать, а упростить типизацию. Кривая конверсия битмапа это отдельный вопрос.

[minimumlaw.livejournal.com]

Блин, но даже для этого надо иметь
__u32 xres; /* visible resolution */
__u32 yres;
__u32 xres_virtual; /* virtual resolution */
__u32 yres_virtual;
__u32 xoffset; /* offset from virtual to visible */
__u32 yoffset; /* resolution */

__u32 bits_per_pixel; /* guess what */

из fix_screeninfo или их аналоги из заголовка битмапа. Иначе все бесполезно. Не надо меня тролить. Не люблю. Мы в двух параллельных ветках говорим об дном и том же. И тут размер массива будет xres*yres, а xres_virtual*yres_virtual. Что частенько совсем не одно и то же. А без bits_per_pixel мы не узнаем размер элемента массива. И только после этого стоит вспомнить о pragma pack. Правда к этому моменту выяснится, что _virtual как раз и нужен для выравнивания, а потому pack по сути ничего не изменит. И ровно аналогично при разборе битмапа. Там все те же поля, но по другому названные.

[mbr.livejournal.com]

Никто и не троллит. Надо просто понимать как физически устроена видеопамять простых 16-битных дисплеев.

[dlinyj.livejournal.com]

У меня две платы. На одной 32 бита дисплей, на другой 16. Никто не мешает сделать её 8-ми битной, или 24-х битной.

[mbr.livejournal.com]

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

[dlinyj.livejournal.com]

Мы на разных языках говорим. Это один вызов ioctl. И нужно быть готовым, что разрешение будет любым. Но я уже выкрутился, по принципу первого комментатора.

[minimumlaw.livejournal.com]

Там все сложнее и проще. Вся хохма в том, что внутри в большинстве армов все хранится в 24-х битном варианте RGB 8:8:8 или BGR 8:8:8 в зависимости от конкретной железки. А на интерфейс или на юзерспейс фреймбуфер это все банально мапится и никакого физического перекодирования не происходит. А классический фреймбуфер в том виде, в котором его обсуждают в данной теме, живет только на ряде не самых свежих платформ, да в виде SPI или USB дисплеев (с последними, кстати, уже не совсем так).

Что до физического устройства - так не только простых 16-и битных. Есть странные варианты типа RGB 5:5:5, или 32-х битные с альфа-каналом (который на самом деле яркостный) и все они хранятся так же. И отличаются только колор мапом и полем bits_per_pixel.

[dlinyj.livejournal.com]

Ой, спасибо, спасибо за комментарий!!! Покурю поболее!

[mbr.livejournal.com]

комментирий выше == первый комментарий.

[dlinyj.livejournal.com]

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

[mbr.livejournal.com]

Я не про то. На практике. Если тебе область памяти нужно привести к многомерному массиву заданной размерности, способ совершить меньше всего ошибок - описать массив единственным элементом структуры, упаковать через pragma и типизировать так область памяти.

Но в твоем случае лучше делать как в первом комментарии.

[dlinyj.livejournal.com]

Не побоюсь сказать, что не знаю как это делать. Можешь кинуть пример кода?

[mbr.livejournal.com]

#pragma pack(push, 1)

typedef struct {
uint16_t a[1024][768]
} FB_ARRAY

#pragma pack(pop)

FB_ARRAY* fba = (FB_ARRAY*)(0x12345678)

fba->a[10][20] = 30;

но так делать не стоит :)

[dlinyj.livejournal.com]

Да, не элегантно...

[savant (from livejournal.com)]

> #pragma

в реалиях gcc/clang лучше использовать __attribute((packed)). Тогда не остаётся шансов забыть pack(pop).

[mbr.livejournal.com]

Истинная правда.

Я как-то забыл и микроконтроллерный код вырос раза в два. Но когда структур 5-6 тупо писать лень. Сам себя по рукам ведь бить не будешь, хех.

[savant (from livejournal.com)]

Ладно когда сам с собой.

Ещё в инсте чел из Транзаса рассказывая про прагмы, рассказал кулстори как уволил нахрен чела, который забыл такой pragma pack закрыть из-за чего куча народу кучу времени ловила абсолютно странные баги в странных местах.

[mbr.livejournal.com]

Врут. Ибо за куда большие грехи прощали.

А если пошло багами - дело не в прагме, а в говнокоде. Так что там всех уволить надо :)

[savant (from livejournal.com)]

Я ж так и написал, что кулстори, в части про увольнение. Но в то что от съехавшего по проекту struct alignment вполне может начаться нездоровая хуйня - верю.

А насчёт уволить за говнокод - тогда можно вообще всех программистов увольнять :)

[dlinyj.livejournal.com]

Говнокодер вам машет ручкой

[savant (from livejournal.com)]

Чего махать? я сам такой, вон mbr мои исходники видел, не даст соврать :)

[dlinyj.livejournal.com]

Мои он тоже видел, чё-т ржу