FBInk
v1.25.0: SoC Puppet
FrameBuffer eInker
ได้รับอนุญาตภายใต้ GPLv3+ อยู่ที่นี่บน GitHub
สิ่งนี้มีจุดประสงค์เพื่อเติมเต็มช่องว่างที่นักพัฒนา Kobo และคนจรจัดรู้สึกได้ เมื่อพวกเขารู้ว่าพวกเขาไม่มีวิธีพิมพ์สิ่งต่าง ๆ บนหน้าจอของอุปกรณ์!
มันโหดร้ายเป็นพิเศษเมื่อย้ายไป Kobo หลังจากคุ้นเคยกับความแพร่หลายของ eips บน Kindle...
กล่าวโดยย่อคือ จะพิมพ์ข้อความหรือรูปภาพบนหน้าจอของคุณ โดยจัดการการแก้ไขในระดับต่ำด้วยอินเทอร์เฟซ framebuffer ของ 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 framebuffer ทุก ประเภท และรองรับบิตความลึกที่หลากหลาย (4bpp, 8bpp, 16bpp, 24bpp & 32bpp) ดังนั้นคุณสามารถใช้สิ่งนี้เพื่อวาดบน EFI fb ของคุณ เป็นต้น ;) .
สำหรับอุปกรณ์ Kobo มีเธรดการสนทนาเปิดอยู่ที่นี่บน MobileRead ซึ่งคุณจะพบไบนารีแบบสแตนด์อโลน ขาดคำแนะนำโดยละเอียดโดยตั้งใจ เนื่องจากกลุ่มเป้าหมายส่วนใหญ่เป็นนักพัฒนาและนักปรับแต่ง คิดว่านี่เป็นข้อควรระวังเพื่อความปลอดภัย ;)
นอกจากนี้ยังมีเธรดในเครือสำหรับอุปกรณ์ Kindle ที่นี่ ซึ่งนอกจากไบนารีแล้ว คุณยังจะพบตัวอย่างของคนที่ใช้มันบ้าๆบอ ๆ ;)
ในทางปฏิบัติ ผู้ใช้ Kindle & Kobo ส่วนใหญ่จะได้รับมันฟรี เนื่องจากมาพร้อมกับแพ็คเกจส่วนใหญ่ของฉัน
เป็นตัวอย่างการใช้งานทั่วไป โปรดดูที่ KFMon ซึ่งฉันใช้มันเพื่อให้การตอบสนองด้วยภาพ หรือ kobo-rclone ซึ่งใช้สำหรับการขูดหน้าจอด้วย นอกจากนี้เรายังใช้ใน KOReader เพื่อให้กระบวนการอัปเดต OTA ใช้งานง่ายยิ่งขึ้น
การค้นหาโค้ดที่กล่าวถึง fbink อย่างรวดเร็วใน GitHub ควรให้ผลลัพธ์ที่น่าสนใจ เช่น แผ่นชิมการจัดการความเสียหายสำหรับ X11, Qt5 QPA หรือ InkVT ซึ่งเป็นโปรแกรมจำลองเทอร์มินัล
ดูเพิ่มเติมที่การเชื่อมโยงต่างๆ ในภาษาอื่นๆ ซึ่งมักจะมีตัวอย่างบางส่วนด้วย
ยูทิลิตี้ CLI พร้อมใช้งานแล้ว ซึ่งสร้างขึ้นโดยใช้ API สาธารณะเดียวกันกับที่สามารถใช้ผ่านไลบรารีที่ใช้ร่วมกันหรือแบบคงที่สำหรับโปรเจ็กต์ C หรือผ่าน FFI ในภาษาอื่น (แต่ระวัง จะได้รับใบอนุญาตภายใต้ GPLv3+ ไม่ใช่ LGPL) สำหรับยูทิลิตี้ CLI โปรดดูเอกสารหรือเรียกใช้ fbink --help เพื่อดูรายละเอียด สำหรับห้องสมุด โปรดดูที่ส่วนหัวสาธารณะ อย่าลังเลที่จะติดต่อฉันหากสิ่งต่างๆ ดูไม่ชัดเจน!
หมายเหตุ: โดยทั่วไปแล้ว จะ ไม่ พยายามจัดการการหมุนเวียนซอฟต์แวร์ เนื่องจากในปัจจุบันดูเหมือนว่าจะเป็นสิ่งที่ถูกต้องสำหรับทั้ง Kobo FW เวอร์ชันปัจจุบันและบน Kindle
YMMV บน FW รุ่นเก่า หรือหากมีอย่างอื่นที่รบกวนการหมุน fb หรือหากแอปพลิเคชันของคุณใช้การหมุนในซอฟต์แวร์ (เช่น วิวพอร์ตแบบหมุน)
ในส่วนของการหมุนเวียนฮาร์ดแวร์ มีข้อยกเว้นเฉพาะบางประการสำหรับอุปกรณ์ Kobo:
อุปกรณ์ที่ทำงานในโหมด 16bpp และดูเหมือนว่าจะอยู่ในโหมดแนวนอน: เนื่องจากนั่นดูเหมือนจะเป็นสถานะดั้งเดิมของพวกเขา เรา จึงพยายาม ชดเชยสิ่งนี้ เนื่องจากเราสามารถนำมาใช้ได้อย่างถูกกฎหมายก่อนที่ Nickel จะแก้ไขสิ่งนี้เอง
บนอุปกรณ์ที่มีมาตรความเร่ง เช่น Forma และ Libra โดยที่ Nickel จะจัดการการหมุนของฮาร์ดแวร์เอง
ตัวอย่างพื้นฐานบางส่วนของการแสดงข้อความเซลล์คงที่...
หรือถ้าเราใส่ภาพลงไปตรงนั้น...
และด้วยความโปร่งใสในการทำงาน แม้แต่กับฮาร์ดแวร์โบราณ :)
ต่อไปนี้คือแบบอักษรอื่นๆ บางส่วน รวมถึงแถบความคืบหน้า...
และเมื่อใช้ฟอนต์ TrueType แวววาว :)
เว้นแต่ว่าคุณแค่พยายามที่จะลองใช้ระบบ Linux ดั้งเดิม ( make linux ) คุณจะต้องมีคอมไพเลอร์แบบข้ามที่กำหนดเป้าหมายอุปกรณ์เป้าหมายของคุณ
Makefile ได้รับการปรับแต่งให้ตรวจจับการตั้งค่า ToolChain การคอมไพล์ข้ามของฉันเองโดยอัตโนมัติ ซึ่งฉันแนะนำให้ใช้อย่างเต็มที่แทนที่จะพึ่งพา toolchain การคอมไพล์ข้ามทั่วไปซึ่งอาจไม่ได้กำหนดเป้าหมายเคอร์เนล/libc duo ที่ถูกต้องอย่างแน่นอน ;)
การใช้ส่วนหน้า koxtoolchain ควรทำให้การสร้างหนึ่งในกระบวนการเหล่านี้ค่อนข้างลำบาก
ในกรณีที่คุณใช้ toolchain ของคุณเอง โปรดทราบว่าเราต้องการการสนับสนุน 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 build ( make kindle ทำสิ่งนั้นบนบิลด์สแตติกที่ถูกแยกออก)KINDLE=1 LEGACY=1 เพื่อสร้าง FW 2.x Kindle build ( make legacy ทำสิ่งนั้นบนบิลด์สแตติกแบบแยกส่วน) โดยพื้นฐานแล้วจะเป็นเพียงแค่ปิดการใช้งาน CLOEXEC ซึ่งอาจไม่ได้รับการสนับสนุนบน FW 2.xCERVANTES=1 เพื่อสร้าง BQ/Cervantes build ( make cervantes ทำสิ่งนั้นบนบิลด์คงที่แบบแยกส่วน)REMARKABLE=1 เพื่อสร้างบิลด์ reMarkable ( make remarkable บนบิลด์สแตติกแบบแยกส่วน)POCKETBOOK=1 เพื่อสร้าง PocketBook build ( make pocketbook ทำสิ่งนั้นบนบิลด์แบบคงที่ที่ถูกถอดออก)ตรรกะเดียวกันนี้ใช้เพื่อปรับแต่งเล็กน้อย:
MINIMAL=1 เพื่อสร้างบิลด์ที่มีฟังก์ชันการทำงานที่จำกัด มาก (ไม่มีการวาดภาพแบบดั้งเดิม ไม่มีการแสดงแบบอักษรแบบเซลล์คงที่ ไม่มีการแสดงภาพ ไม่มีแบบอักษรพิเศษ ไม่มี OpenType) ซึ่งทำให้แอปพลิเคชันและไลบรารีมีขนาดเล็กลงมากDEBUG=1 เพื่อสร้าง Debug build และส่ง DEBUG=1 DEBUGFLAGS=1 เพื่อสร้าง Debug build ด้วย 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 อย่างมาก ใน codepath เซลล์แบบคงที่ คุณสามารถเลือกฝัง GNU Unifont ได้โดยส่ง UNIFONT=1
ได้รับการเตือนว่านี่จะเพิ่มเกือบ 2MB ในขนาดไบนารี่ และแบบอักษรนั้นจะถูกแบ่งออกเป็นสองส่วนจริง ๆ (สัญลักษณ์ความกว้างสองเท่าจะถูกตัดออกไปเป็นแบบอักษรเฉพาะ) ซึ่งอาจทำให้ประโยชน์ในทางปฏิบัติลดลง...
ด้วยเหตุผลที่ชัดเจน สิ่งนี้ ไม่เคย เปิดใช้งานตามค่าเริ่มต้น
เว้นแต่ว่าคุณกำลังทำสิ่งที่เฉพาะ เจาะจง โดยทั่วไปคุณต้องการเปิดใช้งาน DRAW & BITMAP เป็นอย่างน้อย ในรุ่น MINIMAL ...
อย่าลืมรัน make cleanlib อย่างน้อยที่สุดเมื่อเปลี่ยนแพลตฟอร์มเป้าหมายหรือแฟล็กฟีเจอร์ ไม่เช่นนั้นบิลด์ไลบรารีที่ตรงกันล่าสุดจะถูกเก็บไว้ เพราะมันจะเติมเต็มการขึ้นต่อกันของ make ;)
ระหว่างทาง เครื่องมือเสริมบางอย่างอาจปรากฏขึ้นในโฟลเดอร์ utils make utils จะทำการสร้างแบบคงที่ของสิ่งเหล่านี้ (ซึ่งเป็นวิธีที่แนะนำในการดำเนินการ เนื่องจากค่อนข้างจะสับเปลี่ยนกับ API ภายใน ของ FBInk) ปัจจุบันประกอบด้วยเครื่องมือวินิจฉัยเกี่ยวกับพฤติกรรมการหมุน และการทดสอบความเครียดแบบดูมที่กล่าวถึงด้านล่าง
สิ่งเหล่านี้ส่วนใหญ่ได้รับการทดสอบบน Kobo เท่านั้น และควรปล่อยให้อยู่ตามลำพัง เว้นแต่คุณจะรู้ว่ากำลังทำอะไรอยู่ ;)
นอกจากนี้ยังมีเครื่องมือในการจัดการความลึกของบิตบนอุปกรณ์ eInk อย่างเหมาะสมอีกด้วย และสามารถสร้างสำหรับเป้าหมาย e-Ink ด้วย make fbdepth
ชื่อที่ไม่ได้รับแรงบันดาลใจของมันคือ fbdepth และถูกใช้โดย KOReader บน Kobo & reMarkable เพื่อบังคับใช้การหมุนอย่างมีเหตุผลและเปลี่ยนไปใช้ความลึกบิตที่มีประสิทธิภาพมากขึ้น นอกจากนี้ยังได้รับการทดสอบบน Kindle ด้วย ซึ่งอย่างน้อยที่สุด ควรมีการทำงานอย่างถูกต้องในการจัดการกับการหมุน โปรดทราบว่าใน FW 5.x GUI ของหุ้นจะทำงานภายใต้ X และ X จะ ไม่ ชอบให้คุณหมุน fb จากใต้ฝ่าเท้าของมัน ;)
หากคุณต้องการไบนารี่ที่เล็กที่สุดเท่าที่จะเป็นไปได้ ตรวจสอบให้แน่ใจว่าคุณสร้างมันขึ้นมาเพียงลำพังจากแผนผังต้นทางที่เก่าแก่
นอกจากนี้ยังมีตัวอย่างที่ค่อนข้างโง่ที่แสดง dump/restore API ที่สามารถสร้างผ่าน make dump ได้
มีการสาธิตโง่ๆ อีกครั้งที่ใช้เอฟเฟกต์ไฟ PSX Doom เพื่อทดสอบความเครียด EPDC ในลักษณะที่น่าสนใจเล็กน้อย
หากคุณเคยสงสัยเกี่ยวกับ mxcfb alt_buffer shindig ทั้งหมด คุณสามารถดู PoC นี้
ในทำนองเดียวกัน หากคุณกำลังมองหาการหมุนและการป้อนข้อมูลบน Kobo make devcap จะสร้าง tarball ที่ประกอบด้วยไบนารีสองสามตัวและสคริปต์ devcap_test.sh ซึ่งเมื่อทำงานบนอุปกรณ์เป้าหมาย จะคอมไพล์ได้ไม่น้อย ข้อมูล. โดยเฉพาะอย่างยิ่ง หากคุณต้องการรายงานจุดบกพร่องต่อ fbdepth ฉันอาจจะขอให้คุณดำเนินการดังกล่าวและแนบผลลัพธ์ไปกับปัญหา ;)
และในเรื่องของการป้อนข้อมูลและการหมุนบน Kobo นั้น make ftrace จะสร้างยูทิลิตี้พอยน์เตอร์เทรลอย่างง่าย ซึ่งใช้ประโยชน์จาก libevdev และการเรียก API ที่สนุกกว่าของเราบางส่วนเพื่อพยายามทำความเข้าใจกับปัญหาการแปลอินพุตที่เกิดขึ้นบน Kobo
หากคุณตั้งใจจะจัดการกับการป้อนข้อมูลแบบสัมผัสด้วยวิธีใดก็ตามในโค้ดของคุณ นี่ควรเป็นสถานที่ที่ดีในการดู ;)
นอกจากนี้ยังสาธิตวิธีจัดการกับการป้อนข้อมูลด้วยปากกาและการวาดภาพบน Elipsa อย่างมีประสิทธิภาพ
สำหรับ make input_scan มันจะสร้างเครื่องมือ CLI ขนาดเล็กรอบ ๆ fbink_input_scan API ซึ่งช่วยให้เข้าใจว่าอุปกรณ์อินพุตใดทำอะไร (หรือที่เรียกว่า "หน้าจอสัมผัสไอ้เวรนั่นอยู่ที่ไหน" ;))
การสนับสนุน Kindle ครอบคลุมกลุ่มผลิตภัณฑ์ Kindle ทั้งหมดโดยเริ่มจาก K2
การสนับสนุน Kobo ครอบคลุมกลุ่มผลิตภัณฑ์ Kobo ทั้งหมด โดยเริ่มจาก Kobo Touch A/B/C (หมายเหตุ: คุณสมบัติบางอย่างไม่พร้อมใช้งานบน sunxi SoCs, cf, เอกสาร API)
การสนับสนุน BQ Cervantes ได้รับการสนับสนุนโดย @pazos (#17) และควรจัดการกับผู้เล่นตัวจริงในปัจจุบัน
การสนับสนุน reMarkable ได้รับการสนับสนุนโดย @tcrs (#41) และสนับสนุน rM2 เมื่อจับคู่กับหนึ่งในการใช้งาน shim 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 ดั้งเดิมเสมอ แทนที่จะ เขียน ถึง framebuffer หากคุณต้องการ จับ ภาพ PNG (ซึ่งมีประโยชน์) ฉันมี FBGrab เวอร์ชันที่ได้รับการปรับเปลี่ยนอย่างมาก ซึ่งควรจะจัดการกับลักษณะเฉพาะต่างๆ ของ eInk framebuffers ;) หากคุณไม่ต้องการไฟล์ PNG จริงๆ และเพียงต้องการเล่นกับไฟล์ดัมพ์ fb ในหน่วยความจำ โปรดดูการเรียก fbink_dump & fbink_restore API ทั้งหมด
เพื่อให้ทุกคนได้สนุกกันถึงแม้จะทนไม่ไหว C!
สนิม:
Go: go-fbink และผู้สืบทอด go-fbink-v2 โดย @shermp
LuaJIT: lua-fbink โดย @NiLuJe
Python: py-fbink โดย @NiLuJe
โปรดทราบว่าเนื่องจาก API อาจไม่เสถียรบนต้นแบบทั้งหมด ทั้งหมดนี้จึงเชื่อมโยงกับแท็กเฉพาะ (โดยทั่วไปคือรุ่นล่าสุด) คุณควรปฏิบัติตามข้อกำหนดนั้น ไม่เช่นนั้นนรกทั้งหมดจะพังทลาย ;)
โดยทั่วไปฉันพยายามที่จะรักษาการแตกหักให้เหลือน้อยที่สุด หรือยกเว้นสิ่งนั้น ทำให้เส้นทางการอัปเกรดไม่เจ็บปวดเท่าที่จะเป็นไปได้ แต่คุณก็มีอยู่แล้ว การรองรับสิ่งใหม่ๆ มักจะหมายความว่าสิ่งที่มีอยู่จะต้องทำงานแตกต่างออกไปเล็กน้อย
ฉันพยายามให้รายละเอียดการแตกของ API/ABI ในความคิดเห็นของแต่ละแท็ก แต่เป็นวิธีที่ดีในการเห็นภาพซึ่งแน่นอนว่าจะทำให้ส่วนหัวสาธารณะต่างกัน (หรือสำหรับภาพรวมแบบไม่มีบริบทอย่างรวดเร็ว ส่วนหัวขั้นต่ำสุดที่สร้างขึ้นสำหรับการเชื่อมโยง FFI) ;)
