ФБИнк

ФБИнк

Фреймбуфер эИнкер

Лицензия GPLv3+. Размещено здесь, на GitHub.

Для чего это нужно?

Это призвано заполнить пустоту, которую ощущают разработчики и мастера Kobo, когда они понимают, что у них нет встроенного способа печати данных на экране устройства!
Это особенно жестоко при переходе на Kobo, после того как вы привыкли к повсеместному распространению eips на Kindle...

Короче говоря, он печатает сообщения или изображения на вашем экране, выполняя низкоуровневую работу как с интерфейсом фреймбуфера Linux, так и с i.MX EPDC (а также с MTK на Kindle и с Sunxi на Kobo).
Он был протестирован на Kobo, Kindle, BQ Cervantes, reMarkable и PocketBook, но его портирование на другие устройства Linux, i.MX eInk должно быть тривиальным (черт возьми, даже поддержка Sipix не должна быть слишком сложной). #64 доказал, что мы можем даже подчинить Sunxi API своей воле, если вы не слишком беспокоитесь о том, чтобы потерять при этом рассудок ;).

По умолчанию рендеринг текста опирается на встроенные растровые шрифты с фиксированными ячейками (небольшую выборку см. в этом посте), но благодаря вкладу @shermp (#20) вы также можете положиться на полноценный рендеринг шрифтов TrueType/OpenType!

Поддержка изображений включает в себя наиболее распространенные форматы (JPEG/PNG/TGA/BMP/GIF/PNM), а также упакованные пиксели в наиболее подходящих форматах пикселей (Gray8 и RGB32; оба +/- Alpha).

Он также отлично работает на любом устройстве с фреймбуфером Linux и поддерживает широкий диапазон битовых глубин (4bpp, 8bpp, 16bpp, 24bpp и 32bpp), так что вы можете использовать это, например, для рисования на вашем EFI fb;) .

Как мне это установить?

Для устройств Kobo здесь, на MobileRead, открыта ветка обсуждения, где вы случайно найдете автономные двоичные файлы. В нем намеренно отсутствуют подробные инструкции, поскольку целевая аудитория — в основном разработчики и мастера. Считайте это мерой предосторожности ;).

Здесь также есть родственная тема для устройств Kindle, где, помимо двоичных файлов, вы также найдете примеры людей, которые делают с ними сумасшедшие вещи ;).

На практике большинство пользователей Kindle и Kobo получат его бесплатно, поскольку он входит в состав большинства моих пакетов.

В качестве примера использования в реальных условиях см. KFMon, где я использую его для обеспечения визуальной обратной связи, или kobo-rclone, где он также используется для очистки экрана. Мы также используем его в KOReader, чтобы сделать процесс обновления OTA более удобным для пользователя.
Быстрый поиск на GitHub кода, в котором упоминается fbink, также должен дать интересные результаты, например, прошивку для обработки DAMAGE для X11, Qt5 QPA или InkVT, эмулятора терминала.
См. также различные привязки на других языках, которые часто включают несколько примеров.

Как я могу с этим повозиться?

Доступна утилита CLI, построенная на основе того же общедоступного API, которую можно использовать через общую или статическую библиотеку для проектов C или через FFI на других языках (однако будьте осторожны, она лицензируется по лицензии GPLv3+, а не LGPL). Информацию об утилите CLI см. в документации или запустите fbink --help для получения подробной информации. По поводу библиотеки смотрите публичную шапку. Не стесняйтесь обращаться ко мне, если что-то окажется неясным!

ПРИМЕЧАНИЕ. Как правило, он НЕ предпринимает никаких попыток выполнить ротацию программного обеспечения, потому что в настоящее время это кажется правильным поступком как для текущих версий прошивки Kobo, так и для Kindle.
YMMV на более старой прошивке, или если что-то еще не работает с вращением fb, или если ваше приложение реализует вращение в программном обеспечении (т. е. повернутое окно просмотра).
Что касается ротации оборудования, для устройств Kobo сделано несколько исключений:

• Те, которые работают в режиме 16bpp и выглядят как ландшафтный режим: поскольку это кажется их исходным состоянием, мы пытаемся компенсировать это, поскольку нас можно законно использовать до того, как сам Nickel исправит это.

• На устройствах с акселерометром, таких как Forma и Libra, где никель сам будет управлять аппаратным вращением.

Как это выглядит?

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

Или если мы добавим туда изображение...

И со всеми наворотами прозрачности работы, даже на древнем железе :).

Вот несколько других шрифтов, а также индикатор выполнения...

И при использовании блестящих шрифтов TrueType :).

Как мне его построить?

Если вы просто не пытаетесь опробовать его на родной чистой системе Linux ( make linux ), вам понадобится кросс-компилятор, ориентированный на ваше, ну, целевое устройство.
Makefile предназначен для автоматического обнаружения моих собственных настроек ToolChain кросс-компиляции, которые я, очевидно, искренне рекомендую использовать вместо того, чтобы полагаться на общие цепочки инструментов кросс-компиляции, которые могут не совсем нацелены на правильный дуэт ядро/libc;).
Использование интерфейса koxtoolchain должно сделать создание одного из них довольно безболезненным процессом.

Если вы используете собственную цепочку инструментов, обратите внимание, что нам требуется поддержка C11 (GCC >= 4.9, Clang >= 3.0).

Если вы не используете старый компилятор, я настоятельно рекомендую собрать его с включенным LTO!

При этом цель по умолчанию (т. е. make ) даст статическую сборку Kobo, тогда как make kobo даст урезанную общую сборку и дополнительно упакует все способом Kobo. Пакет, найденный в теме Kobo, построен таким образом.

Существует также несколько удобных целей для обычных типов сборок ( make static для статической сборки, make shared для общей сборки, make strip для разделенной статической сборки, make release для разделенной общей сборки, make debug для отладочной сборки), а также как несколько необычных для очень конкретных случаев использования, обычно связанных с привязками FFI ( make pic для статической сборки PIC или передача STATIC_LIBM=1 , чтобы сделать попытку статически связать с libm).

Выбор целевой платформы осуществляется с помощью простой переменной:

• Передайте KINDLE=1 , чтобы создать сборку Kindle ( make kindle делает это на удаленной статической сборке).
• Передайте KINDLE=1 LEGACY=1 , чтобы создать сборку Kindle FW 2.x ( make legacy делает это на удаленной статической сборке). По сути, это просто отключает CLOEXEC, который может не поддерживаться в FW 2.x.
• Передайте CERVANTES=1 , чтобы создать сборку BQ/Cervantes ( make cervantes делает это на удаленной статической сборке).
• Передайте REMARKABLE=1 , чтобы создать сборку reMarkable ( make remarkable делает это на удаленной статической сборке).
• Передайте POCKETBOOK=1 , чтобы создать сборку PocketBook ( make pocketbook делает это на удаленной статической сборке).

Та же логика используется для некоторой адаптации:

• Передайте MINIMAL=1 , чтобы создать сборку с очень ограниченной функциональностью (без примитивов рисования, без рендеринга шрифтов с фиксированными ячейками, без рендеринга изображений, без дополнительных шрифтов, без OpenType), что дает гораздо меньшее приложение и библиотеку.
• Передайте DEBUG=1 , чтобы создать отладочную сборку, и передайте DEBUG=1 DEBUGFLAGS=1 , чтобы создать отладочную сборку с обязательным отладочным CFLAGS.

Вы также можете добавлять функции одну за другой в MINIMAL сборку:

• Передайте DRAW=1 , чтобы добавить поддержку рисования примитивов.
• Передайте BITMAP=1 , чтобы добавить поддержку рендеринга шрифтов с фиксированными ячейками. (Подразумевается DRAW )
• Передайте FONTS=1 , чтобы добавить поддержку дополнительных встроенных шрифтов с фиксированной ячейкой. (Подразумевается BITMAP )
• Передайте IMAGE=1 чтобы добавить поддержку изображений. (Подразумевается DRAW )
• Передайте OPENTYPE=1 , чтобы добавить поддержку рендеринга шрифтов OTF/TTF. (Подразумевается DRAW )
• Передайте INPUT=1 , чтобы добавить поддержку утилит ввода.
• Передайте BUTTON_SCAN=1 , чтобы добавить поддержку сканирования кнопок, специфичного для Kobo. (Подразумевается DRAW )

Если вам действительно нужно максимальное покрытие Unicode в кодовом пути с фиксированной ячейкой, вы также можете встроить GNU Unifont, передав UNIFONT=1 .
Имейте в виду, что это добавит почти 2 МБ к двоичному размеру и что шрифт фактически разделен на две части (глифы двойной ширины переносятся на определенный шрифт), что может снизить его полезность на практике...
По понятным причинам это никогда не включено по умолчанию.
Если вы не делаете очень специфических вещей, вам обычно нужно включить хотя бы DRAW и BITMAP в MINIMAL сборке...

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

Попутно в папке utils могут появиться несколько вспомогательных инструментов. make utils выполнит их статическую сборку (это рекомендуемый способ сделать это, поскольку они довольно грубо сочетаются с внутренним API FBInk). В настоящее время они состоят из диагностического инструмента, касающегося поведения вращения, и стресс-теста Doom, упомянутого ниже.
Большинство из них были протестированы только на Кобо, и их, вероятно, следует оставить в покое, если вы не знаете, что делаете ;).

Также доступен инструмент для правильного управления битовой глубиной на устройствах eInk, который можно создать для целевых устройств e-Ink с помощью make fbdepth .
Его скучное имя — fbdepth , и оно используется KOReader на Kobo и reMarkable для обеспечения разумного вращения и переключения на более эффективную битовую глубину. Он также был протестирован на Kindle, где обработка вращения, по крайней мере, должна вести себя правильно. Обратите внимание, что в FW 5.x стандартный графический интерфейс работает под X, и X не понравится, если вы выкрутите fb у него из-под ног ;).
Если вам нужен минимально возможный двоичный файл, убедитесь, что вы собираете его самостоятельно, из чистого дерева исходного кода.

Также есть довольно глупый пример, демонстрирующий API дампа/восстановления, который можно собрать с помощью make dump .
Была реализована еще одна дурацкая демоверсия, основанная на эффекте огня PSX Doom, чтобы провести стресс-тестирование EPDC в довольно интересной манере.

Если вам когда-нибудь было интересно узнать об этой вечеринке mxcfb alt_buffer, вы можете взглянуть на этот PoC.

Аналогичным образом, если вы изучаете махинации с ротацией и вводом данных на Kobo, make devcap создаст tar-архив, содержащий несколько двоичных файлов и скрипт devcap_test.sh, который при запуске на целевом устройстве скомпилирует довольно много информация. В частности, если вам когда-нибудь понадобится сообщить об ошибке в fbdepth , я, вероятно, попрошу вас запустить это и приложить результаты к проблеме;).

Что касается ввода и вращения на Kobo, make ftrace создаст простую утилиту отслеживания указателей, которая использует libevdev и несколько наших более интересных вызовов API, чтобы попытаться разобраться в махинациях с трансляцией ввода, происходящих на Kobo.
Если вы собираетесь каким-либо образом обрабатывать сенсорный ввод в своем коде, это хорошее место для поиска;).
Он также демонстрирует, как эффективно работать с перьевым вводом и рисованием на Elipsa.

Что касается make input_scan , он создаст небольшой инструмент CLI на основе API fbink_input_scan , который поможет понять, какое устройство ввода что делает (то есть «где этот чертов сенсорный экран?» ;)).

ПРИМЕЧАНИЯ

Поддержка Kindle распространяется на всю линейку Kindle, начиная с K2.

Поддержка Kobo распространяется на всю линейку Kobo, начиная с Kobo Touch A/B/C (ПРИМЕЧАНИЕ: некоторые функции недоступны в SoC Sunxi, см. документацию по API).

Поддержка BQ Cervantes была предоставлена ​​@pazos (#17) и должна соответствовать текущему составу.

Поддержка reMarkable была предоставлена ​​@tcrs (#41) и поддерживает rM2 в сочетании с одной из различных реализаций прокладки rm2fb.

Поддержка PocketBook была протестирована @ezdiy (#47) и должна поддерживать тот же набор устройств, что и KOReader. Имейте в виду, что PocketBook — это... сложная платформа, и у меня самого нет к ней доступа. Это означает, что здесь есть немало особенностей:

• Мы не используем InkView для рисования, что означает, помимо других особенностей, что цветопередача не поддерживается на цветных устройствах и что отображение режима формы волны может быть ненадежным, особенно на устройствах, работающих на AW SoC (мы всегда используем API ядра mxcfb). , и на этих устройствах это очень, очень, очень причудливая прошивка. Ожидайте странных и странных ошибок, особенно если вы начнете играть с аппаратной ротацией фб).
• Еще одна странность, особенно распространенная на устройствах AW, заключается в том, что две структуры fbinfo являются полностью фиктивными. FBInk эвристически преобразует их в форму при инициализации, поэтому, если вам понадобится доступ к ним, всегда используйте fbink_get_fb_info вместо того, чтобы самостоятельно прибегать к собственным ioctls.
• Говоря о InkView, по умолчанию он открывается при инициализации, чтобы помочь с идентификацией устройства. Это может быть проблематично, потому что InkView извлекает метрику старых библиотек через DT_NEEDED... и инициализирует некоторые из них при загрузке, что является идеальным рецептом для катастрофы, если вы сами используете те же самые библиотеки, особенно если вы вы используете разные их версии. Чтобы избежать этого беспорядка, вы можете попросить FBInk никогда не трогать InkView, установив переменную FBINK_NO_INKVIEW в вашей среде. В настоящее время единственным недостатком будет нарушение идентификации устройства: в частности, отсутствие имени устройства и неточный DPI (по умолчанию мы используем значение 212, если вы не установите переопределение через переменную окружения FBINK_FORCE_DPI )).
• Что касается ротации, то по умолчанию, если устройство выглядит так, будто его собственная ориентация — альбомная (что справедливо для большинства моделей линейки), FBInk обеспечивает программную ротацию, чтобы фактически печатать материалы в книжной ориентации (в основном для обеспечения совместимости с KOReader). Вы можете отключить это поведение, установив переменную FBINK_NO_SW_ROTA в своей среде, и в этом случае мы всегда будем использовать собственный макет fb.

Связанные проекты

Если вместо записи в фреймбуфер вы хотите получить его снимок в формате PNG (что может пригодиться), у меня есть сильно модифицированная версия FBGrab, которая должна нормально справляться с различными особенностями фреймбуферов eInk ;). Если вам на самом деле не нужен PNG-файл и вы просто хотите поиграться с дампами fb в памяти, просмотрите все вызовы API fbink_dump и fbink_restore .

Привязки на других языках

Чтобы всем было весело, даже если вы терпеть не можете C!

Ржавчина:

• fbink-sys от @Szybet (голые привязки привязки)
• fbink-rs от @sublipri (голые привязки привязки, некоторые безопасные оболочки, зависящие от кросс-платформы)

Go: go-fbink и его преемник go-fbink-v2 от @shermp

LuaJIT: lua-fbink от @NiLuJe

Python: py-fbink от @NiLuJe

Обратите внимание: поскольку API может быть не совсем стабильным на главном сервере, все они привязаны к определенному тегу (как правило, к последней версии). Вы должны соблюдать это требование, иначе разразится ад ;).
Обычно я стараюсь свести поломки к минимуму или, за исключением этого, сделать пути обновления как можно более безболезненными, но вот и все: поддержка новых вещей часто означает, что существующие вещи должны работать немного по-другому.

Я пытаюсь подробно описать поломки API/ABI в комментариях к каждому тегу, но хороший способ визуализировать это, конечно, — это сравнить один общедоступный заголовок (или, для быстрого бесконтекстного обзора, минимальные заголовки, сгенерированные для привязок FFI) ;).