FBInk
v1.25.0: SoC Puppet
FrameBuffer eInker
مرخص بموجب GPLv3+. موجود هنا على جيثب.
يهدف هذا إلى ملء الفراغ الذي يشعر به مطورو Kobo والمصلحون عندما يدركون أنه ليس لديهم طريقة مدمجة لطباعة الأشياء على شاشة الجهاز!
إنه أمر قاسٍ بشكل خاص عند الانتقال إلى كوبو، بعد أن اعتدت على وجود eips في كل مكان على Kindle...
باختصار، فهو يطبع الرسائل أو الصور على شاشتك، ويتعامل مع التعديلات ذات المستوى المنخفض مع كل من واجهة Linux Framebuffer وi.MX EPDC (بالإضافة إلى واجهة MTK على Kindle، وواجهة sunxi على Kobo).
لقد تم اختباره على Kobo وKindle وBQ Cervantes وreMarkable وPocketBook، ولكن نقله إلى أجهزة Linux الأخرى وأجهزة i.MX eInk يجب أن يكون أمرًا تافهًا (حتى دعم Sipix لا ينبغي أن يكون صعبًا للغاية). #64 أثبت أنه يمكننا حتى ثني واجهات برمجة تطبيقات sunxi لإرادتنا، إذا كنت لا تهتم كثيرًا بفقدان عقلك في هذه العملية؛).
افتراضيًا، يعتمد عرض النص على خطوط الصور النقطية للخلايا الثابتة المجمعة (راجع هذا المنشور للحصول على عينة صغيرة)، ولكن بفضل مساهمات @shermp (#20)، يمكنك أيضًا الاعتماد على عرض خطوط TrueType/OpenType الكاملة!
يتضمن دعم الصور التنسيقات الأكثر شيوعًا (JPEG/PNG/TGA/BMP/GIF/PNM)، بالإضافة إلى وحدات البكسل الأولية المجمعة بتنسيقات البكسل الأكثر صلة (Gray8 وRGB32؛ كلاهما +/- Alpha).
يحدث أيضًا أنه يعمل بشكل جيد تمامًا على أي نوع من أجهزة Linux Framebuffer، ويدعم نطاقًا واسعًا من أعماق البت (4bpp، 8bpp، 16bpp، 24bpp و32bpp)، لذا يمكنك استخدام هذا للرسم على EFI fb، على سبيل المثال؛) .
بالنسبة لأجهزة Kobo، يوجد موضوع مناقشة مفتوح هنا على MobileRead، حيث ستجد ثنائيات مستقلة. إنها تفتقر بشكل مقصود إلى التعليمات التفصيلية، لأن الجمهور المستهدف هو بشكل أساسي المطورين والمصلحين. فكر في هذا كإجراء وقائي ؛).
يوجد أيضًا موضوع شقيق لأجهزة Kindle هنا، حيث ستجد أيضًا، إلى جانب الثنائيات، أمثلة لأشخاص يقومون بأشياء مجنونة باستخدامها؛).
ومن الناحية العملية، فإن معظم مستخدمي Kindle & Kobo سيحصلون عليه مجانًا، لأنه مرفق مع معظم حزمي.
كمثال للاستخدام في الحياة البرية، راجع KFMon، حيث أستخدمه لتقديم تعليقات مرئية، أو kobo-rclone، حيث يتم استخدامه أيضًا لمسح الشاشة. نحن نستخدمه أيضًا في KOReader، لجعل عملية التحديث عبر الهواء أكثر سهولة في الاستخدام.
يجب أيضًا أن يؤدي البحث السريع على GitHub عن رمز يذكر fbink إلى نتائج مثيرة للاهتمام، على سبيل المثال، شريحة معالجة الأضرار لـ X11، أو Qt5 QPA أو InkVT، وهو محاكي طرفي.
راجع أيضًا الارتباطات المتنوعة باللغات الأخرى، والتي غالبًا ما تتضمن بعض الأمثلة.
تتوفر أداة مساعدة لسطر الأوامر (CLI)، مبنية حول نفس واجهة برمجة التطبيقات العامة التي يمكن استخدامها عبر مكتبة مشتركة أو ثابتة لمشاريع لغة C، أو عبر FFI بلغات أخرى (على الرغم من ذلك، فهي مرخصة بموجب GPLv3+، وليس LGPL). للحصول على الأداة المساعدة CLI، راجع الوثائق الخاصة بها أو قم بتشغيل fbink --help للحصول على التفاصيل. بالنسبة للمكتبة، راجع العنوان العام. لا تتردد في الاتصال بي إذا كانت الأمور تبدو غير واضحة!
ملحوظة: لا يقوم بشكل عام بأي محاولة للتعامل مع تدوير البرامج، لأنه يبدو حاليًا أن هذا هو الشيء الصحيح الذي يجب فعله مع كل من إصدارات Kobo FW الحالية وعلى Kindle.
YMMV على FW الأقدم، أو إذا كان هناك شيء آخر يتلاعب بتدوير fb، أو إذا كان تطبيقك يقوم بتنفيذ التدوير في البرنامج (على سبيل المثال، إطار عرض تم تدويره).
فيما يتعلق بتدوير الأجهزة، هناك بعض الاستثناءات المحددة لأجهزة Kobo:
أولئك الذين يعملون في وضع 16 بت في الثانية ويبدو أنهم في الوضع الأفقي: نظرًا لأن هذا يبدو وكأنه حالتهم الأصلية، فإننا نحاول التعويض عن ذلك، حيث يمكن استخدامنا بشكل قانوني قبل أن يقوم Nickel نفسه بتصحيح ذلك.
على الأجهزة المزودة بمقياس تسارع، مثل Forma وLibra، حيث سيتولى النيكل نفسه دوران الأجهزة.
بعض الأمثلة الأساسية لعرض نص الخلية الثابتة...
أو إذا أسقطنا صورة هناك...
ومع كل أجراس وصفارات شفافية العمل، حتى على الأجهزة القديمة :).
إليك بعض الخطوط الأخرى، بالإضافة إلى شريط التقدم...
وعند استخدام خطوط TrueType اللامعة :).
ما لم تكن تحاول فقط تجربة نظام Linux أصلي خالص ( make linux )، فستحتاج إلى مترجم مشترك يستهدف جهازك المستهدف.
تم تصميم Makefile ليكتشف تلقائيًا إعدادات ToolChain الخاصة بالتجميع المتقاطع، والتي من الواضح أنني أوصي بشدة باستخدامها بدلاً من الاعتماد على سلاسل أدوات التجميع المتقاطع العامة التي قد لا تستهدف بالضبط الثنائي kernel/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 لإنشاء إصدار FW 2.x Kindle ( 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، ثم قم بتمرير DEBUG=1 DEBUGFLAGS=1 لإنشاء Debug باستخدام 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 على الأقل عند تغيير الأنظمة الأساسية المستهدفة أو علامات الميزات، وإلا فسيتم الاحتفاظ بأحدث إصدار للمكتبة المطابقة، لأنه سيملأ تبعيات الإنشاء؛).
على طول الطريق، قد تظهر بعض الأدوات المساعدة في مجلد utils . ستقوم make utils بإنشاء بناء ثابت لهذه العناصر (وهي الطريقة الموصى بها للقيام بذلك، حيث إنها تعتمد بشكل فظ على واجهة برمجة التطبيقات الداخلية لـ FBInk). حاليًا، تتكون هذه من أداة تشخيصية تتعلق بسلوك التناوب، واختبار الإجهاد المدمر المذكور أدناه.
تم اختبار معظمها على Kobo فقط ، ومن المحتمل أن تتركها بمفردها إلا إذا كنت تعرف ما تفعله؛).
تتوفر أيضًا أداة لمعالجة عمق البت على أجهزة eInk بشكل صحيح، ويمكن تصميمها لأهداف الحبر الإلكتروني باستخدام make fbdepth .
اسمه غير الملهم هو fbdepth ، ويستخدمه KOReader على Kobo & reMarkable لفرض دوران معقول والتحول إلى عمق بت أكثر كفاءة. لقد تم اختباره أيضًا على Kindle، حيث يجب أن يتصرف التعامل مع التدوير بشكل صحيح على الأقل. لاحظ أنه في FW 5.x، تعمل واجهة المستخدم الرسومية للسهم تحت X، ولن يعجبك X بتدوير fb من تحت قدميه ؛).
إذا كنت تريد أصغر ثنائي ممكن، فتأكد من إنشائه بمفردك، من شجرة مصدر أصلية.
هناك أيضًا مثال غبي إلى حد ما يعرض واجهة برمجة تطبيقات التفريغ/الاستعادة التي يمكن إنشاؤها عبر make dump .
تم تنفيذ عرض توضيحي غبي آخر يعتمد على تأثير حريق PSX Doom، لاختبار التحمل EPDC بطريقة مثيرة للاهتمام إلى حد ما.
إذا كان لديك فضول بشأن برنامج mxcfb alt_buffer shindig بأكمله، فيمكنك إلقاء نظرة على إثبات المفهوم (PoC) هذا.
وعلى نفس المنوال، إذا كنت تبحث في خدع التدوير والإدخال على Kobo، فسيقوم make devcap ببناء كرة tarball تحتوي على عدد قليل من الثنائيات والبرنامج النصي devcap_test.sh، والذي، عند تشغيله على الجهاز المستهدف، سيجمع قدرًا كبيرًا من معلومات. على وجه الخصوص، إذا كنت بحاجة في أي وقت إلى الإبلاغ عن خطأ ضد fbdepth ، فمن المحتمل أن أطلب منك تشغيل ذلك وإرفاق النتائج بالمشكلة؛).
وفيما يتعلق بموضوع الإدخال والتدوير على Kobo، سيقوم make ftrace بإنشاء أداة مساعدة بسيطة لتتبع المؤشر، والتي تستفيد من libevdev وعدد قليل من استدعاءات واجهة برمجة التطبيقات (API) غير التقليدية لمحاولة فهم خدع ترجمة الإدخال التي تحدث على Kobo.
إذا كنت تنوي التعامل مع الإدخال باللمس بأي شكل من الأشكال في التعليمات البرمجية الخاصة بك، فيجب أن يكون هذا مكانًا جيدًا للبحث؛).
كما يوضح كيفية التعامل بفعالية مع الإدخال بالقلم والرسم على جهاز إليبسا.
أما بالنسبة لـ make input_scan ، فسوف تقوم ببناء أداة CLI صغيرة حول واجهة برمجة fbink_input_scan ، مما يساعد على فهم جهاز الإدخال الذي يفعل ماذا (ويعرف أيضًا باسم، "أين شاشة اللمس اللعينة؟"؛)).
يغطي دعم Kindle تشكيلة Kindle الكاملة، بدءًا من K2.
يغطي دعم Kobo تشكيلة Kobo الكاملة، بدءًا من Kobo Touch A/B/C (ملاحظة: بعض الميزات غير متوفرة في sunxi SoCs وcf وAPI docs).
لقد ساهم @pazos (#17) في دعم BQ Cervantes، ومن المفترض أن يتولى مسؤولية التشكيلة الحالية.
تمت المساهمة بدعم reMarkable بواسطة @tcrs (#41)، ويدعم rM2 عند إقرانه بأحد تطبيقات rm2fb المتنوعة.
تم اختبار دعم PocketBook بواسطة @ezdiy (#47)، ويجب أن يدعم نفس مجموعة الأجهزة التي يدعمها KOReader. ضع في اعتبارك أن PocketBook عبارة عن منصة معقدة للتعامل معها، وأنني لا أستطيع الوصول إليها بنفسي. يعني هناك عدد لا بأس به من المراوغات المعنية:
fbink_get_fb_info بدلاً من اللجوء إلى ioctls الأصلية بنفسك.FBINK_NO_INKVIEW في بيئتك. في الوقت الحالي، سيكون الجانب السلبي الوحيد هو ضعف تعريف الجهاز: على وجه التحديد، لا يوجد اسم للجهاز، وDPI غير دقيقة (سنقوم بالإعداد الافتراضي إلى 212، ما لم تقم بتعيين تجاوز عبر FBINK_FORCE_DPI env var)).FBINK_NO_SW_ROTA في بيئتك، وفي هذه الحالة سنرسم دائمًا تخطيط fb الأصلي. إذا كنت تريد، بدلاً من الكتابة إلى مخزن الإطارات المؤقت، الحصول على لقطة PNG لها (والتي يمكن أن تكون مفيدة)، فلدي نسخة معدلة بشكل كبير من FBGrab والتي يجب أن تتعامل بعقلانية مع المراوغات المختلفة لمخازن إطارات eInk؛). إذا كنت لا تحتاج فعليًا إلى ملف PNG وتريد فقط اللعب باستخدام عمليات تفريغ fb الموجودة في الذاكرة، فابحث في استدعاءات fbink_dump & fbink_restore API بالكامل.
حتى يتمكن الجميع من الاستمتاع، حتى لو كنت لا تستطيع تحمل C!
الصدأ:
اذهب: go-fbink وخليفته go-fbink-v2 بواسطةshermp
LuaJIT: lua-fbink بواسطة @NiLuJe
بايثون: py-fbink بواسطةNiLuJe
لاحظ أنه نظرًا لأن واجهة برمجة التطبيقات (API) قد لا تكون مستقرة تمامًا على المستوى الرئيسي، فكلها مرتبطة بعلامة محددة (عمومًا، أحدث إصدار). يجب عليك احترام هذا المطلب، وإلا فسوف ينفتح كل الجحيم؛).
أحاول بشكل عام إبقاء الأعطال عند الحد الأدنى، أو باستثناء ذلك، جعل مسارات الترقية غير مؤلمة قدر الإمكان، ولكن، إليك الأمر، دعم العناصر الجديدة غالبًا ما يعني أن العناصر الموجودة يجب أن تعمل بشكل مختلف قليلاً.
أحاول تفصيل أعطال API/ABI في تعليقات كل علامة، ولكن الطريقة الجيدة لتصور ذلك هي بالطبع تمييز الرأس العام الفردي (أو، للحصول على نظرة عامة سريعة بدون سياق، الحد الأدنى من الرؤوس التي تم إنشاؤها لربطات FFI) ؛).
