FBInk 다운로드 - FBInk 소스 코드 다운로드

FBInk

C# 소스 코드

v1.25.0: SoC Puppet

다운로드

FBInk

FrameBuffer eInker

GPLv3+에 따라 라이센스가 부여됩니다. 여기 GitHub에 보관되어 있습니다.

그것은 무엇입니까?

이는 Kobo 개발자와 개발자가 장치 화면에 내용을 인쇄할 수 있는 내장된 방법이 없다는 것을 깨달았을 때 느끼는 공백을 메우기 위한 것입니다!
Kindle에서 편재하는 eips 에 익숙해진 후 Kobo로 이동할 때 특히 잔인합니다...

간단히 말해서, 화면에 메시지나 이미지를 인쇄하고 Linux 프레임 버퍼 인터페이스와 i.MX EPDC(Kindle의 MTK, Kobo의 sunxi) 모두를 사용하여 낮은 수준의 수정 작업을 처리합니다.
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을 참조하세요. 또한 OTA 업데이트 프로세스를 보다 사용자 친화적으로 만들기 위해 KOReader에서도 이를 사용하고 있습니다.
fbink를 언급하는 코드에 대한 빠른 GitHub 검색을 통해 흥미로운 결과(예: X11용 DAMAGE-handling shim, Qt5 QPA 또는 터미널 에뮬레이터인 InkVT)를 얻을 수도 있습니다.
종종 몇 가지 예를 포함하는 다른 언어의 다양한 바인딩도 참조하세요.

어떻게 하면 문제를 해결할 수 있나요?

C 프로젝트용 공유 또는 정적 라이브러리를 통해 또는 다른 언어의 FFI를 통해 사용할 수 있는 동일한 공개 API를 기반으로 구축된 CLI 유틸리티를 사용할 수 있습니다(단, LGPL이 아닌 GPLv3+에 따라 라이센스가 부여된다는 점에 유의하세요). CLI 유틸리티에 대한 자세한 내용은 설명서를 참조하거나 fbink --help 실행하세요. 라이브러리에 대해서는 공개 헤더를 참조하세요. 상황이 불분명한 경우 주저하지 말고 저에게 연락하세요!

참고: 현재 Kobo FW 버전과 Kindle 모두에서 올바른 것으로 보이기 때문에 일반적으로 소프트웨어 교체를 처리하려고 시도하지 않습니다 .
이전 FW의 YMMV, 또는 FB 회전으로 인해 다른 것이 퍼징되는 경우, 또는 응용 프로그램이 소프트웨어에서 회전을 구현하는 경우(즉, 회전된 뷰포트).
하드웨어 교체와 관련하여 Kobo 장치에는 몇 가지 특정 예외가 있습니다.

16bpp 모드에서 실행되고 가로 모드로 보이는 것: 이것이 기본 상태인 것처럼 보이므로 우리는 이를 보상하려고 시도합니다 . Nickel 자체가 이를 수정하기 전에 합법적으로 사용할 수 있기 때문입니다.
Forma & Libra와 같은 가속도계가 있는 장치에서는 니켈 자체가 하드웨어 회전을 처리합니다.

어떻게 보입니까?

고정 셀 텍스트 렌더링의 몇 가지 기본 예

아니면 거기에 이미지를 넣으면...

그리고 고대 하드웨어에서도 작업 투명성의 모든 부가 기능이 제공됩니다 :).

다음은 몇 가지 다른 글꼴과 진행률 표시줄입니다.

그리고 빛나는 트루타입 글꼴을 사용할 때 :).

어떻게 구축하나요?

기본 순수 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 바인딩과 관련된 매우 구체적인 사용 사례에 대한 몇 가지 특이한 사례입니다(PIC 정적 빌드에 대해 make pic 거나 libm에 대해 정적으로 링크를 시도하도록 STATIC_LIBM=1 전달).

대상 플랫폼의 선택은 간단한 변수를 통해 처리됩니다.

Kindle 빌드를 만들려면 KINDLE=1 전달합니다( make kindle 제거된 정적 빌드에서 이 작업을 수행합니다).
FW 2.x Kindle 빌드를 만들려면 KINDLE=1 LEGACY=1 전달합니다( make legacy 제거된 정적 빌드에서 해당 작업을 수행함). 이는 기본적으로 FW 2.x에서 지원되지 않을 수 있는 CLOEXEC를 비활성화합니다.
BQ/Cervantes 빌드를 만들려면 CERVANTES=1 전달합니다( make cervantes 제거된 정적 빌드에서 이 작업을 수행합니다).
reMarkable 빌드를 만들려면 REMARKABLE=1 전달하세요( make remarkable 제거된 정적 빌드에서 해당 작업을 수행함).
PocketBook 빌드를 생성하려면 POCKETBOOK=1 전달합니다( make pocketbook 제거된 정적 빌드에서 해당 작업을 수행합니다).

약간의 조정을 허용하기 위해 동일한 논리가 사용됩니다.

매우 제한된 기능(그리기 기본 요소 없음, 고정 셀 글꼴 렌더링 없음, 이미지 렌더링 없음, 추가 글꼴 없음, OpenType 없음)으로 빌드하려면 MINIMAL=1 전달하여 훨씬 더 작은 애플리케이션 및 라이브러리를 생성합니다.
디버그 빌드를 만들려면 DEBUG=1 전달하고, 디버그 CFLAGS가 적용된 디버그 빌드를 만들려면 DEBUG=1 DEBUGFLAGS=1 전달하세요.

또한 MINIMAL 빌드에 기능을 하나씩 추가 할 수도 있습니다.

그리기 기본 요소에 대한 지원을 추가하려면 DRAW=1 전달하세요.
고정 셀 글꼴 렌더링에 대한 지원을 추가하려면 BITMAP=1 전달합니다. ( DRAW 의미함)
추가 번들 고정 셀 글꼴에 대한 지원을 추가하려면 FONTS=1 전달합니다. ( BITMAP 암시)
이미지 지원을 추가하려면 IMAGE=1 전달하세요. ( DRAW 의미함)
OTF/TTF 글꼴 렌더링 지원을 추가하려면 OPENTYPE=1 전달합니다. ( DRAW 의미함)
입력 유틸리티에 대한 지원을 추가하려면 INPUT=1 전달합니다.
Kobo 관련 버튼 스캔 기능에 대한 지원을 추가하려면 BUTTON_SCAN=1 전달하세요. ( DRAW 의미함)

고정 셀 코드 경로에서 극단적인 유니코드 적용 범위가 정말로 필요한 경우 UNIFONT=1 전달하여 GNU 유니폰트를 포함하도록 선택할 수도 있습니다.
이렇게 하면 바이너리 크기에 거의 2MB가 추가되고 글꼴이 실제로 두 개로 분할되어(이중 너비 문자는 특정 글꼴로 펀트됨) 실제로 유용성이 저하될 수 있다는 점에 유의하세요.
분명한 이유로 이는 기본적으로 활성화되지 않습니다 .
매우 특정한 작업을 수행하지 않는 한 일반적으로 MINIMAL 빌드에서 최소한 DRAW 및 BITMAP 활성화하는 것이 좋습니다.

대상 플랫폼이나 기능 플래그를 변경할 때 최소한 make cleanlib 실행하는 것을 잊지 마세요. 그렇지 않으면 최신 일치 라이브러리 빌드가 유지됩니다. 왜냐하면 make 종속성을 완전히 채울 것이기 때문입니다.

그 과정에서 몇 가지 보조 도구가 utils 폴더에 나타날 수 있습니다. make utils 이들의 정적 빌드를 수행합니다(FBInk의 내부 API에 다소 조잡하게 피기백하므로 권장되는 방법입니다). 현재 이러한 기능은 회전 동작에 관한 진단 도구와 아래에 설명된 둠 스트레스 테스트로 구성됩니다.
이들 중 대부분은 Kobo 에서만 테스트되었으며, 현재 수행 중인 작업을 모르는 경우에는 그대로 두어야 합니다. ;)

eInk 장치에서 비트 심도를 적절하게 조작하는 도구도 사용할 수 있으며 make fbdepth 사용하여 e-Ink 대상용으로 구축할 수 있습니다.
영감을 받지 못한 이름은 fbdepth 이며 Kobo 및 reMarkable의 KOReader에서 정상적인 회전을 적용하고 보다 효율적인 비트 심도로 전환하는 데 사용됩니다. 또한 회전 처리가 최소한 제대로 작동해야 하는 Kindle에서도 테스트되었습니다. FW 5.x에서 기본 GUI는 X에서 실행되며 X는 발 아래에서 fb를 회전하는 것을 좋아하지 않습니다 .)
가능한 가장 작은 바이너리를 원한다면 깨끗한 소스 트리에서 단독으로 빌드해야 합니다.

make dump 통해 구축할 수 있는 덤프/복원 API를 보여주는 상당히 어리석은 예도 있습니다.
약간 흥미로운 방식으로 EPDC를 스트레스 테스트하기 위해 PSX Doom 화재 효과를 기반으로 한 또 다른 어리석은 데모가 구현되었습니다.

mxcfb alt_buffer shindig 전체에 대해 궁금하신 경우 이 PoC를 살펴보세요.

같은 맥락에서, Kobo에서 회전 및 입력 헛소리를 조사하고 있다면 make devcap 몇 개의 바이너리와 devcap_test.sh 스크립트가 포함된 타르볼을 빌드할 것입니다. 이 스크립트는 대상 장치에서 실행될 때 꽤 많은 내용을 컴파일합니다. 정보. 특히, fbdepth 에 대한 버그를 보고해야 하는 경우 해당 버그를 실행하고 결과를 문제에 첨부하도록 요청할 것입니다.

그리고 Kobo의 입력 및 회전 주제에 대해 make ftrace libevdev와 몇 가지 재미있는 API 호출을 활용하여 Kobo에서 발생하는 입력 변환 헛소리를 이해하려고 시도하는 간단한 포인터 추적 유틸리티를 구축합니다.
코드에서 어떤 방식으로든 터치 입력을 처리하려는 경우 이 부분을 살펴보는 것이 좋습니다.
또한 Elipsa에서 펜 입력 및 그리기를 효과적으로 처리하는 방법을 보여줍니다.

make input_scan 의 경우 fbink_input_scan API를 중심으로 작은 CLI 도구를 구축합니다. 이는 어떤 입력 장치가 무엇을 하는지 이해하는 데 도움이 됩니다(일명 "그 망할 터치스크린이 어디 있지?";).

참고 사항

Kindle 지원은 K2부터 시작하여 전체 Kindle 라인업을 포괄합니다.

Kobo 지원은 Kobo Touch A/B/C부터 시작하여 전체 Kobo 라인업을 포괄합니다(참고: sunxi SoC, cf, API 문서에서는 일부 기능을 사용할 수 없습니다).

BQ Cervantes 지원은 @pazos(#17)가 기여했으며 현재 라인업을 처리해야 합니다.

reMarkable 지원은 @tcrs(#41)에 의해 기여되었으며 다양한 rm2fb shim 구현 중 하나와 결합될 때 rM2를 지원합니다.

PocketBook 지원은 @ezdiy(#47)에 의해 테스트되었으며 KOReader와 동일한 장치 세트를 지원해야 합니다. PocketBook은... 처리하기 복잡한 플랫폼이고 나 자신이 그것에 접근할 수 없다는 점을 명심하세요. 즉, 몇 가지 단점이 관련되어 있습니다.

우리는 그림을 그리는 데 InkView를 사용하지 않습니다. 이는 다양한 단점 중에서도 색상 렌더링이 컬러 장치에서 지원되지 않으며 특히 AW SoC에서 실행되는 장치에서 파형 모드 매핑이 불확실 할 수 있다는 것을 의미합니다(우리는 항상 mxcfb 커널 API를 사용합니다) , 그리고 해당 장치에서는 매우 기발한 심입니다. 특히 하드웨어 FB 회전을 시작하는 경우 이상하고 이상한 버그가 발생할 수 있습니다.
AW 장치에서 특히 널리 퍼져 있는 또 다른 특이한 점은 두 개의 fbinfo 구조체가 완전히 가짜라는 것입니다. FBInk는 init에서 이를 경험적으로 조작하므로 액세스가 필요한 경우 기본 ioctl을 직접 사용하는 대신 항상 fbink_get_fb_info 통해 이동하십시오.
InkView에 관해 말하면 기본적으로 장치 식별을 돕기 위해 init에서 dlopen'됩니다. InkView는 DT_NEEDED...를 통해 오래된 라이브러리의 메트릭 크래튼을 가져 오고 로드 시 일부를 초기화하기 때문에 문제가 될 수 있습니다. 다른 버전을 사용하고 있습니다. 이러한 혼란을 피하기 위해 환경에서 FBINK_NO_INKVIEW 변수를 설정하여 FBInk에게 InkView를 건드리지 않도록 요청할 수 있습니다. 현재 유일한 단점은 장치 식별이 손상된다는 점입니다. 특히 장치 이름이 없고 DPI가 부정확합니다( FBINK_FORCE_DPI 환경 변수를 통해 재정의를 설정하지 않는 한 기본값은 212입니다).
그리고 회전 주제에 대해 기본적으로 장치의 기본 방향이 가로 방향인 것처럼 보이면 (대부분의 라인업에서 발생함) FBInk는 실제로 세로 방향으로 항목을 인쇄하기 위해 소프트웨어 회전을 시행합니다(대부분 KOReader와의 상호 운용성을 돕기 위해). 환경에서 FBINK_NO_SW_ROTA 변수를 설정하여 이 동작을 비활성화할 수 있습니다. 이 경우 우리는 항상 기본 FB 레이아웃을 그립니다.

다른 언어로 된 바인딩

C를 못 참더라도 모두가 즐겁게 지낼 수 있도록!

녹:

@Szybet의 fbink-sys(베어 bingen 바인딩)
@sublipri의 fbink-rs(베어 빈드겐 바인딩, 일부 안전한 래퍼, 크로스에 따라 다름)

Go: go-fbink 및 그 후속 버전인 go-fbink-v2(@shermp 제작)

LuaJIT: @NiLuJe의 lua-fbink

Python: @NiLuJe의 py-fbink

API는 마스터에서 완전히 안정적이지 않을 수 있으므로 모두 특정 태그(일반적으로 최신 릴리스)에 연결되어 있습니다. 그 요구 사항을 존중해야 합니다. 그렇지 않으면 지옥이 풀릴 것입니다.)
나는 일반적으로 파손을 최소화하거나 이를 방지하여 업그레이드 경로를 최대한 쉽게 만들려고 노력하지만, 새로운 기능을 지원한다는 것은 기존 기능이 약간 다르게 작동해야 한다는 것을 의미하는 경우가 많습니다.

각 태그의 주석에서 API/ABI 손상을 자세히 설명하려고 노력하지만 이를 시각화하는 좋은 방법은 물론 단일 공개 헤더(또는 빠른 컨텍스트 없는 개요를 위해 FFI 바인딩을 위해 생성된 최소 헤더)를 비교하는 것입니다.

확장하다

추가 정보