🚔 💠 🍀 OpenWRT के साथ एक राउटर से मिनीकंप्यूटर: एक फ्रेमबफ़र ड्राइवर लिखना 🥨 😁 🙈

शुभ दोपहर, प्रिय Khabrovites। इसलिए हम एक छोटे रूटर को एक मिनीकंप्यूटर में बदलने के बारे में लेखों की मेरी श्रृंखला के सबसे दिलचस्प और महत्वपूर्ण हिस्से में आते हैं - अब हम एक वास्तविक फ्रेमबफ़र ड्राइवर विकसित करेंगे जो आपको राउटर पर विभिन्न ग्राफिक्स अनुप्रयोगों को चलाने की अनुमति देगा। ताकि उत्साह फीका न पड़े, यहाँ इन अनुप्रयोगों में से एक का एक वीडियो है - मुझे लगता है कि सबसे अधिक इस शानदार पुराने इतिहास को पहचानेंगे:

यदि आप पिछले भागों को छोड़ देते हैं, तो यहां लिंक दिए गए हैं:
1 - OpenWRT के साथ एक राउटर से मिनीकंप्यूटर: एक यूएसबी वीडियो कार्ड विकसित करना
2 - OpenWRT के साथ एक राउटर से मिनीकंप्यूटर: हम लिनक्स के लिए यूएसबी क्लास-ड्राइवर लिखते हैं
तो, चलो काम करने के लिए।

परिचय

हमारा हार्डवेयर फिर से नहीं बदला है (हालांकि हम अगले लेख में फर्मवेयर में निश्चित रूप से कुछ बदलेंगे), तो चलिए शुरू करते हैं कि हमें क्या करना है।
इस तथ्य के बावजूद कि पिछले लेख से हमारा ड्राइवर पहले से ही जानता है कि ग्राफिक्स कैसे प्रदर्शित करें, इसे पूरी तरह से उपयोग करना बहुत मुश्किल है (उदाहरण के लिए, एक कंसोल प्रदर्शित करें या एक ग्राफिकल एप्लिकेशन लॉन्च करें)। तथ्य यह है कि इस तरह के अनुप्रयोगों के लिए एक अच्छी तरह से परिभाषित, मानकीकृत इंटरफ़ेस, तथाकथित फ़्रेमबफ़र की आवश्यकता होती है। सिस्टम में फ्रेमबफ़र को पंजीकृत करते समय, हमें कई विशिष्ट विवरणक संरचनाओं को भरने की आवश्यकता होगी, इस बार केवल सार "फ़ाइल संचालन" की तुलना में अधिक विशिष्ट है जिसे हमने पिछली बार पूरा किया था। संचालन भी होगा, लेकिन उनके अलावा विशेष कॉलबैक भी होंगे, जैसे कि fb_imageblit (जिसे जब कोई व्यक्ति स्क्रीन पर किसी विशिष्ट स्थान पर छवि के साथ बिट्स के ब्लॉक को स्थानांतरित करना चाहता है), fb_copyarea (एक समान स्थानांतरण, लेकिन बिट्स का ब्लॉक बाहरी बफर से नहीं लिया जाता है, लेकिन वीडियो मेमोरी), आदि। इसके अलावा, स्क्रीन रिज़ॉल्यूशन, रंग बिटनेस और इस "बिटनेस" में रंग घटक कैसे स्थित हैं, इसका वर्णन करने वाली संरचनाएं होंगी।

पहली चीज जो आपको महसूस करने की आवश्यकता है: हमारे पास कुछ हद तक गैर-मानक स्थिति है, जब पीसी वीडियो कार्ड के साथ तुलना की जाती है (हालांकि यह एम्बेड उपकरणों के लिए काफी सामान्य है) - हमारे डिवाइस में वीडियो मेमोरी ऐसी नहीं है, जिसे हम एक्सेस कर सकते हैं - अधिक सटीक रूप से, इसमें मेमोरी है, उसी GRAM को डिस्प्ले के बॉल्स में छिपाया गया है, लेकिन हमारे पास केवल 16 बिट्स की "विंडो" के माध्यम से पहुंच है। वहाँ पूरे फ्रेम बफर को स्टोर करने के लिए बोर्ड पर पर्याप्त मेमोरी नहीं है।
सौभाग्य से, लिनक्स के पास इसके लिए एक विशेष दृष्टिकोण है - हम पहले से ही उपसर्ग " sys_ " के साथ फ़ंक्शन लिख चुके हैं, उदाहरण के लिए, " sys_imageblit ", जो आवश्यक फ़्रेमबफ़र कार्यक्षमता को लागू करते हैं, सिस्टम के मुख्य मेमोरी क्षेत्र के साथ एक फ्रेम बफर के रूप में काम करते हैं।
यही है, अगर हमारे पास फ़्रेम बफ़र वीडियो कार्ड पर स्थित है और हमारे पास इस तरह के ऑपरेशन के लिए हार्डवेयर समर्थन है, तो हम कॉलबैक में बस लोहे के हमारे टुकड़े को मारते हैं, जिससे कमांड "बिट ब्लॉक ट्रांसफर निष्पादित करें" या "वीडियो मेमोरी क्षेत्र को कॉपी करें"।
यदि हमारे पास इनमें से कुछ भी नहीं है, तो हम अपने फ्रेम बफ़र के आकार में बराबर कर्नेल में मेमोरी आवंटित करते हैं, और कॉलबैक में हम उपसर्ग " sys_ " के साथ इन समान फ़ंक्शन को कॉल करते हैं, जो रैम में आवश्यक संचालन करते हैं।
इस प्रकार, आप एक पूरी तरह से काम कर रहे फ्रेमबफ़र प्राप्त कर सकते हैं जो हार्डवेयर के साथ बिल्कुल भी बातचीत नहीं करेगा - पहले से ही ऐसा ड्राइवर है और इसे vfb, वर्चुअल फ्रेमबफ़र कहा जाता है। इसका सोर्स कोड ड्राइवर / वीडियो / vfb.c.
यदि हम ऐसे ड्राइवर को वास्तविक डिवाइस में आवधिक डेटा जोड़ते हैं, तो हमें एक वास्तविक फ्रेमबफ़र ड्राइवर मिलेगा। लेकिन इससे पहले कि हम इसमें उतरें , अपने सिस्टम को थोड़ा ट्यून करें और वर्चुअल ड्राइवर पर अभ्यास करें, vfb ।

कर्नेल ग्राफिक्स समर्थन सक्षम करें

मैंने इस भाग के साथ बहुत समय बिताया, मुख्यतः क्योंकि मैंने अपना ड्राइवर पहले लिखा था, और फिर यह समझने की कोशिश की कि मेरे पास केवल काली स्क्रीन क्यों थी - मैंने कोड में अपनी गलतियों के लिए पाप किया। फिर उन्होंने VFB ड्राइवर को स्थापित करने का अनुमान लगाया, इसके बजाय उस मेमोरी की सामग्री को पढ़ा, जिसमें उन्होंने उसी ब्लैक स्क्रीन को देखा था। फिर, आखिरकार, मुझे एहसास हुआ कि समस्या ड्राइवर के साथ नहीं थी, लेकिन इस तथ्य के साथ कि कर्नेल ने खुद को इसकी जानकारी देने से इनकार कर दिया था, जिसके बाद समस्या का हल जल्दी हो गया था। लेकिन पहले बातें पहले।

फ्रेमबफ़र मेमोरी में कंसोल आउटपुट को देखने के लिए (अच्छी तरह से, स्क्रीन पर, अगर यह वास्तविक है, आभासी नहीं है), दो ड्राइवरों की आवश्यकता है - यह, वास्तव में, फ्रेमबफ़र ड्राइवर है, जो डिवाइस / देव / fb [x] और कंसोल ड्राइवर का निर्माण करेगा। इसके शीर्ष पर काम करने वाला fbcon ड्राइवर है
कर्नेल में, तदनुसार, फ़्रेमबफ़र्स के लिए समर्थन, वर्चुअल टर्मिनलों के लिए समर्थन (आउटपुट डिवाइस + इनपुट डिवाइस, डिस्प्ले और कीबोर्ड का संयोजन एक अमूर्त) को शामिल किया जाना चाहिए, ऐसे टर्मिनलों पर सिस्टम कंसोल प्रदर्शित करने के लिए समर्थन (हाँ, यह अक्षम भी हो सकता है, फिर सिस्टम कंसोल होगा) केवल शारीरिक रूप से मौजूदा चरित्र उपकरणों जैसे कॉम पोर्ट), स्वयं fbcon ड्राइवर , साथ ही इसमें उपलब्ध कुछ फोंट में भी आउटपुट है ।
वह बिंदु जो मुझे शुरू में याद आ गया जब मैं समझ नहीं पाया कि कुछ भी क्यों नहीं दिखाया गया है - आपको कर्नेल को यह बताने की आवश्यकता है कि सिस्टम कंसोल की सामग्री को / dev / tty [x] में आउटपुट करना आवश्यक है जो fbcon को पकड़ा गया है !
तथ्य यह है कि fbcon ड्राइवर पहले उपलब्ध / dev / tty [x] को पकड़ने की कोशिश करता है, उदाहरण के लिए, tty0 । लेकिन कर्नेल वहाँ कुछ भी उत्पादन नहीं करता है, यह एक संलग्न अमूर्त नहीं है, क्योंकि यह किसी भी एप्लिकेशन को नहीं चलाता है जो आपको सिस्टम में लॉग इन करने की अनुमति देता है, न ही सिस्टम कंसोल का आउटपुट।
इस समस्या को हल करने के लिए, हमें पहले कर्नेल को बताना होगा कि हम सिस्टम कंसोल को / dev / tty0 पर देखना चाहते हैं (हालाँकि, यह वैकल्पिक है, अगर कोई व्यक्ति अचानक बूट प्रक्रिया और सिस्टम आउटपुट नहीं देखना चाहता है, तो यह आइटम छोड़ा जा सकता है ), और दूसरी बात यह बताएं कि आपको लॉगिन के लिए सॉफ्टवेयर चलाने की जरूरत है

अब हम वर्चुअल फ्रेमबफ़र के ड्राइवर के बारे में सभी तीन बिंदुओं को करेंगे, और जब हमें मेमोरी में चित्र मिल जाएगा, तो हम अपने स्वयं के लेखन पर आगे बढ़ेंगे। fbcon और framebuffer ड्राइवर को या तो स्टेटिक रूप से बनाया जा सकता है, या दोनों प्लग-इन के रूप में, या एक स्टेटिक रूप से, दूसरा गतिशील रूप से - इससे समस्याएँ नहीं आएंगी , fbcon जैसे ही इसे देखता है, फ़्रेमबफ़र को स्नैप कर देगा ।
सच है, जब vfb के साथ काम करते समय एक सूक्ष्मता होती है - इसे सक्रिय करने के लिए, आपको मॉड्यूल को vfb_enable = 1 पैरामीटर को पास करना होगा, या " वीडियो = vfb " पैरामीटर के साथ कर्नेल शुरू करना होगा। मॉड्यूल के साथ काम करना आसान होगा, इसलिए हम खुद को इसे सीमित कर लेंगे। fbcon हम एक कर्नेल में बनाएंगे।

हम kernel_menuconfig को निष्पादित करते हैं और आइटम डिवाइस ड्राइवर्स पर जाते हैं
ग्राफिक्स समर्थन चालू करें - फ्रेम बफर उपकरणों के लिए समर्थन , जिसके बाद हम स्वयं ड्राइवरों की सूची देख सकते हैं, जिसमें हम वर्चुअल फ्रेमबफ़र का चयन करते हैं।
एक स्तर पर वापस जाएं, चरित्र उपकरणों पर जाएं और इसे चालू करें

वर्चुअल टर्मिनल
कंसोल में वर्ण अनुवाद सक्षम करें
वर्चुअल टर्मिनल पर कंसोल के लिए समर्थन
कंसोल ड्राइवरों को बाइंडिंग और अनबाइंडिंग के लिए समर्थन

अंतिम दो विकल्पों के लिए धन्यवाद, हम सिस्टम कंसोल को वर्चुअल टर्मिनल पर आउटपुट कर सकते हैं, और फिर, यदि वांछित है, तो इसे फ्रेमबफ़र ड्राइवर से डिस्कनेक्ट करें, जो इसे मेमोरी से अनलोड करने की अनुमति देगा।
हम ग्राफिक्स सपोर्ट पर लौटते हैं, कंसोल डिस्प्ले ड्राइवर सपोर्ट मेन्यू पर जाते हैं, जो उपलब्ध हो गया है और वहां फ्रेमबर्नर कंसोल सपोर्ट को चालू कर देता है , फिर कंपाइल-इन फोंट आइटम को एक्टिवेट करें और वहां कुछ फॉन्ट का चयन करें - उदाहरण के लिए, वीजीए 8x8 फॉन्ट
हम मुख्य मेनू पर जाते हैं और कर्नेल हैकिंग आइटम पर ध्यान देते हैं - यदि आप वहां जाते हैं, तो आप सूची के अंत के करीब पा सकते हैं जिसमें कर्नेल बूट पैरामीटर वाला आइटम है। सामान्य तौर पर, एक बूट-लोडर उन्हें कर्नेल तक पहुंचाता है, लेकिन आप इस आइटम के साथ पैरामीटर लाइन को पूरक कर सकते हैं, या इसे फिर से परिभाषित कर सकते हैं। हम फिर से परिभाषित नहीं करेंगे, लेकिन पूरक करने के लिए - हम पूरक होंगे, क्योंकि बूटलोडर कंसोल = ttyATH0 पैरामीटर को पास करता है, जिसका अर्थ है कि सिस्टम कंसोल सीरियल पोर्ट के लिए आउटपुट है। दुर्भाग्य से, हम इसे यहीं नहीं कर सकते - प्लेटफ़ॉर्म-विशिष्ट पैच को लागू करते समय यह पैरामीटर ओवरराइड हो जाएगा, इसलिए हम वहां जाएंगे। यहां कुछ भी स्पर्श न करें, कॉन्फ़िगरेशन को बचाएं और बाहर निकलें।
जहाँ हम याद करते हैं, हम वहाँ जाते हैं, प्लेटफ़ॉर्म-विशिष्ट फ़ाइलें और पैच संग्रहीत होते हैं - लक्ष्य / linux / ar71xx / । हम जेनेरिक में जाते हैं और कॉन्फिग-डिफॉल्ट फाइल खोलते हैं। इसमें हमें एक ही लाइन दिखाई देती है, वही पैरामीटर जो हमने कर्नेल कॉन्फ़िगरेशन में देखा था:
CONFIG_CMDLINE = "रूटफ़स्टाइप = स्क्वैशफ़्स, jffs2 noinitrd"
कंसोल = tty0 और fbcon = font: <font name> को अंत में जोड़ें, कर्नेल कॉन्फ़िगरेशन में चयनित लोगों में से एक को फ़ॉन्ट नाम सेट करना। हमें कुछ ऐसा मिलता है
CONFIG_CMDLINE = "rootfstype = squashfs, jffs2 noinitrd कंसोल = tty0 fbcon = फ़ॉन्ट: ProFont6x11"

पुनर्निर्माण से पहले हमें जो आखिरी काम करना है, वह है मेन्यूकोफिग बनाने के लिए जाना और फ़ॉस्सेट उपयोगिता को व्यस्तबॉक्स विकल्पों में शामिल करना , जो हमें हमारे फ्रेमबफ़र के मापदंडों को सेट करने की अनुमति देगा। यह बेस सिस्टम - बिजीबॉक्स - लिनक्स सिस्टेम यूटिलिटीज मेनू में स्थित है।

अब आप कर्नेल का पुनर्निर्माण कर सकते हैं। Build_dir / target-mips_r2_uClibc-0.9.33.2 / linux-ar71xx_generic / linux-3.6.9 / dri में
छंद / वीडियो /
कि .ko एक्सटेंशन के साथ दूर ले जाएं
अपेक्षाओं के विपरीत, वह अकेला नहीं होगा, एक चालक का समावेश जो उपसर्ग " sys_ " के साथ फ़ंक्शन का उपयोग करता है, कई मॉड्यूल की विधानसभा को सक्रिय करता है जिसमें ये फ़ंक्शन झूठ बोलते हैं। क्या दिलचस्प है, सिद्धांत रूप में, उन्हें कर्नेल में सांख्यिकीय रूप से निर्माण करने में हस्तक्षेप नहीं करता है, ड्राइवर को प्लग-इन छोड़ देता है, लेकिन मैं मेनू से ऐसा नहीं कर सका, मुझे कॉनक्सिग फ़ाइल को संबंधित पैच लिखना था। लेकिन हम इसे बाद में करेंगे, लेकिन अब हम नए फर्मवेयर के साथ राउटर को फिर से कॉन्फ़िगर करते हैं और सभी मॉड्यूल को इसमें स्थानांतरित करते हैं।

एसएसएच पर हम राउटर पर जाते हैं और जाने के बाद / आदि। इनटैब फ़ाइल खोलें और कुछ इस तरह देखें:

::sysinit:/etc/init.d/rcS S boot ::shutdown:/etc/init.d/rcS K shutdown ttyATH0::askfirst:/bin/ash --login

अंतिम पंक्ति बस यह कहती है कि आपको ttyATH0, सीरियल पोर्ट पर लॉगिन के लिए सॉफ़्टवेयर चलाने की आवश्यकता है (इस मामले में, सभी सिस्टम बायनेरी - बिजीबॉक्स का हिस्सा)। यह संकेत दिया जाता है (आस्कफर्स्ट) कि इस कंसोल को सक्रिय करने के लिए आपको पहले एंटर दबाना होगा।
एक और पंक्ति जोड़ें:

 tty0::respawn:/bin/ash --login

देखते हैं कि कर्नेल पैरामीटर सही तरीके से निर्दिष्ट किए जाते हैं या नहीं

 cat /proc/cmdline

और राउटर को रिबूट करें।
अब, बदले में, हम vfb ड्राइवर को छोड़कर सब कुछ insmod करते हैं, और बहुत ही अंत में हम लिखते हैं

 insmod vfb.ko vfb_enable=1

उसके बाद, हमें dmesg में इन शब्दों को देखना चाहिए: कंसोल: कलर फ्रेम बफर डिवाइस पर स्विच करना 53x21
कंसोल का आकार चयनित फ़ॉन्ट के आधार पर अलग-अलग होगा। फ़्रेमबफ़र मापदंडों को सेट करें, हमारे प्रदर्शन के मापदंडों के समान:

 fbset -g 320 240 320 240 16

यह दृश्यमान और आभासी रिज़ॉल्यूशन को 320x240 पर सेट करेगा (सबसे अधिक बार वे संयोग करते हैं, लेकिन सिद्धांत रूप में, आप वर्चुअल रिज़ॉल्यूशन को आउटपुट से बड़ा फ्रेम बफर प्राप्त करके दृश्यमान से अधिक सेट कर सकते हैं और इसका उपयोग डबल बफरिंग के लिए कर सकते हैं), और रंग की गहराई 16 बिट्स है।
fbcon को इसके संकल्प और संदेश को dmesg में बदलकर इस पर प्रतिक्रिया देनी चाहिए, लेकिन यदि ऐसा नहीं होता है, तो फ्रेमबफ़र से कंसोल को डिस्कनेक्ट करें और पुनः कनेक्ट करें:

 echo "0" > /sys/class/vtconsole/vtcon1/bind echo "1" > /sys/class/vtconsole/vtcon1/bind

यह कमांड की एक उपयोगी जोड़ी है जो एक से अधिक बार हमारे काम आएगी - इसके बिना, आप फ्रेम-बफ़र ड्राइवर को अनलोड नहीं कर सकते, क्योंकि वह सांत्वना में व्यस्त रहेगा।
यह एक कीबोर्ड को राउटर से कनेक्ट करने के लिए चोट नहीं करता है - आप नेत्रहीन स्पष्ट और dmesg कमांड दर्ज कर सकते हैं यह सुनिश्चित करने के लिए कि वर्चुअल डिस्प्ले पर कुछ है।
हमें "स्क्रीनशॉट" कमांड मिलने के बाद

 cat /dev/fb0 > scrn.raw

और इसे डेस्कटॉप पर डाउनलोड करें। वहां हम जीआईएमपी या किसी अन्य सॉफ़्टवेयर के माध्यम से खोलते हैं जो आरजीबी 565 प्रारूप में कच्चे ग्राफिक डेटा को लोड कर सकते हैं - हम छवि का आकार 320x240 पर सेट करते हैं, बिटनेस के बारे में नहीं भूलते हैं, और हमें इस तरह की एक तस्वीर मिलती है (मेरा ड्राइवर उद्घाटन / समापन / देव / fb0 , आदि के लिए संदेश भेजता है)। के। मैंने वर्चुअल फ्रेमबफ़र से स्क्रीनशॉट नहीं लिया है। आभासी ऐसे मामलों के बारे में चुप है):

क्या आपने सांत्वना के सुंदर, "हैकर" हरे रंग पर ध्यान दिया है? वास्तव में, यह हमें एक गलती के बारे में बताता है, या बल्कि, एक विशेषता के बारे में है जिसके बारे में सोचने की आवश्यकता है। लेकिन हम इस बारे में बाद में बात करेंगे। मुख्य कार्रवाई पर जाने से पहले - अपने फ्रेम बफ़र ड्राइवर को लिखना - चलो उपलब्ध कंसोल फोंट की तुलना करें। ऐसा करने के लिए, मैंने छह फ़ोटो, तीन कंसोल पर और 4x4, 6x11 और 8x8 फोंट के साथ मिडनाइट कमांडर पर तैयार किए। मेरी राय में, सबसे सुविधाजनक 6x11 है:

4x4

6x11

8x8

4x4

6x11

8x8

फ़्रेमबफ़र ड्राइवर लिखना

शुरू करने के लिए - दृष्टिकोण के बारे में। एक स्पष्ट और बहुत अच्छा समाधान समय-समय पर पूरे स्क्रीन को अपडेट करने के लिए नहीं होगा - आप एक टाइमर शुरू कर सकते हैं जो यूएसबी के माध्यम से फ्रेमबफ़र की सभी सामग्रियों को पिछले लेख से हमें पहले से परिचित कमांड के माध्यम से फेंक देगा। हालांकि, एक बहुत अधिक सही समाधान है, तथाकथित आस्थगित io।
इसका सार सरल है: हमें केवल कॉलबैक फ़ंक्शन को निर्दिष्ट करने की आवश्यकता है, समय अंतराल सेट करें और हमारे फ्रेमबफ़र के लिए यह बहुत ही स्थगित आईओआर दर्ज करें। पंजीकरण के दौरान, वर्चुअल मेमोरी को कॉन्फ़िगर किया जाएगा ताकि फ्रेम बफर मेमोरी तक पहुंच एक अपवाद को बढ़ा दे, जो हमारे कॉलबैक को हमारे द्वारा निर्दिष्ट अंतराल पर प्रसंस्करण के लिए कतार में डाल देगा। इस स्थिति में, मेमोरी में राइट ऑपरेशन बाधित नहीं होगा! और जब कॉलबैक कहा जाता है, तो उन पृष्ठों की एक सूची जिसे बदल दिया गया है, उसे स्थानांतरित कर दिया जाएगा। क्या यह वास्तव में बहुत सुविधाजनक है? उपयोगकर्तास्पेस सुरक्षित रूप से वीडियो मेमोरी में बिना कुछ और बिना किसी रुकावट के लिख सकते हैं, जबकि हमारा कॉलबैक समय-समय पर मेमोरी पेजों की सूची के साथ जुड़ जाएगा, जिन्हें हमें केवल डिवाइस पर फेंकना होगा, न कि पूरे बफर पर।

चूंकि फ़्रेमबफ़र की रिहाई इतनी सरल नहीं है क्योंकि यह पहली नज़र में लगता है (यूएसबी डिवाइस पहले से ही गायब हो सकता है, लेकिन क्लाइंट अभी फ्रेमबफ़र को नहीं जाने देंगे और इस समय मेमोरी को खाली करना असंभव है), हम बहुत अच्छा नहीं करेंगे - हम बोल्ड में लिखेंगे TODO और प्रतिज्ञा सही सफाई को लागू करने और थोड़ी देर बाद डिवाइस को बंद करने का वादा करता है, लेकिन अब हम अंत में हमारे कार्यों का परिणाम देखने के लिए बाकी सब लिखेंगे। सामान्य सफाई, वीडियो कार्ड फर्मवेयर को खत्म करने के साथ (जो कम से कम दो बार एफपीएस बढ़ाएगा), हम अगले लेख में निश्चित रूप से विचार करेंगे।

आइए एक सरल के साथ शुरू करें - चूंकि हम उन पृष्ठों की एक सूची प्राप्त करेंगे, जिन्हें हमने दर्ज किया था, इसलिए पृष्ठ के शीर्ष के अनुरूप अग्रिम में स्क्रीन पर निर्देशांक को सहेजना सबसे आसान है और संबंधित मेमोरी क्षेत्र के लिए एक सूचक भी है। इसलिए, हम इन क्षेत्रों के साथ एक संरचना बनाएंगे, परमाणु ध्वज जोड़ने की भूल नहीं करेंगे जो इंगित करता है कि क्या इस पृष्ठ को अपडेट की आवश्यकता है। यह आवश्यक है क्योंकि आंतरिक फ़्रेमबफ़र संचालन, जो " sys_ " उपसर्ग के साथ फ़ंक्शंस के माध्यम से किए जाते हैं, हमारे आस्थगित io हैंडलर को कॉल नहीं करते हैं, इसलिए हमें मैन्युअल रूप से गणना करने की आवश्यकता होगी कि कौन से पृष्ठ एक्सेस किए गए थे और उन्हें अपडेट करने के लिए विषय के रूप में चिह्नित करें।

मेमोरी पेज संरचना

 struct videopage { int x, y; unsigned char *mem; unsigned long length; atomic_t toUpdate; };

यहां सब कुछ पारदर्शी है, केवल एक चीज यह है कि हम लंबाई स्टोर करते हैं, क्योंकि अंतिम पृष्ठ अधूरा हो सकता है - हमें डेटा को डिस्प्ले में भेजने की आवश्यकता नहीं है।
हम डिस्प्ले के आकार से संबंधित कई परिभाषाएँ घोषित करेंगे - पेज में पिक्सेल की संख्या, फ्रेमबफ़र में पेज की संख्या, आदि।
PAGE_SIZE कर्नेल स्रोत में हमारे लिए परिभाषित किया गया है।

हेल्पर को परिभाषित करता है

 #define WIDTH 320 #define HEIGHT 240 #define BYTE_DEPTH 2 #define FB_SIZE WIDTH*HEIGHT*BYTE_DEPTH #define FP_PAGE_COUNT PAGE_ALIGN(FB_SIZE)/PAGE_SIZE #define PIXELS_IN_PAGE PAGE_SIZE/BYTE_DEPTH

हम आवश्यक फ्रेमबफ़र कॉलबैक और हमारे आस्थगित आईओ के कॉलबैक हैंडलर की घोषणा करते हैं।

कॉलबैक

 static void display_fillrect(struct fb_info *p, const struct fb_fillrect *rect); static void display_imageblit(struct fb_info *p, const struct fb_image *image); static void display_copyarea(struct fb_info *p, const struct fb_copyarea *area); static ssize_t display_write(struct fb_info *p, const char __user *buf, size_t count, loff_t *ppos); static int display_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue, unsigned transp, struct fb_info *info); //--------------- static void display_update(struct fb_info *info, struct list_head *pagelist);

अगला अपरिवर्तनीय प्रदर्शन जानकारी के साथ एक संरचना है।

Fb_fix_screeninfo संरचना

 static struct fb_fix_screeninfo fixed_info = { .id = "STM32LCD", .type = FB_TYPE_PACKED_PIXELS, .visual = FB_VISUAL_TRUECOLOR, .accel = FB_ACCEL_NONE, .line_length = WIDTH * BYTE_DEPTH, };

सब कुछ भी सरल है - हम अपने डिस्प्ले की स्ट्रिंग आईडी सेट करते हैं, पिक्सेल का प्रकार - अन्य हमारे लिए रुचि नहीं रखते हैं, हमारे पास सबसे आम बिटमैप है, हमारे पास ट्रुकरोलर रंग है, कम से कम यह इसके करीब है और निश्चित रूप से मोनोक्रोम नहीं है और प्रत्यक्ष रंग नहीं है।
इसके बाद एक और दिलचस्प संरचना आती है (संभावित) चर जानकारी के साथ। लेकिन जब से हमें परमिट बदलने की संभावना का एहसास नहीं होगा, हमारे लिए यह पिछले ढांचे की तरह स्थिर रहेगा।

Fb_var_screeninfo संरचना

 static struct fb_var_screeninfo var_info = { .xres = WIDTH, .yres = HEIGHT, .xres_virtual = WIDTH, .yres_virtual = HEIGHT, .width = WIDTH, .height = HEIGHT, .bits_per_pixel = 16, .red = {11, 5, 0}, .green = {5, 6, 0}, .blue = {0, 5, 0}, .activate = FB_ACTIVATE_NOW, .vmode = FB_VMODE_NONINTERLACED, };

यहां हम दृश्यमान और आभासी संकल्पों को देखते हैं जो पहले से ही फ़ेसेट से परिचित हैं, मिलीमीटर में प्रदर्शन के भौतिक आयाम (आप सिद्धांत रूप में, किसी भी, मैं इसे अपने संकल्प के रूप में सेट कर सकते हैं), छवि की बिटनेस, और महत्वपूर्ण संरचनाएं - कैसे रंग का विवरण घटक बाइट्स में हैं। उनमें, पहला मान ऑफसेट है, दूसरा बिट्स में लंबाई है और तीसरा झंडा है, "दाईं ओर अर्थ बिट"।
I / O को आस्थगित करने के लिए अंतिम, आस्थगित io ।

Fb_deferred_io संरचना

 static struct fb_deferred_io display_defio = { .delay = HZ/6, .deferred_io = &display_update, };

अवधि मान का विकल्प, .delay फ़ील्ड, कार्य, अधिकांश भाग के लिए, अनुभवजन्य है - यदि आप बहुत छोटा मान चुनते हैं, तो अद्यतन उपकरण की अनुमति देने की तुलना में कम बार घटित होगा, यदि आप बहुत बड़े का चयन करते हैं, तो स्थगित नौकरियों की कतार बंद हो जाएगी। इस समय हमारा प्रदर्शन धीमी गति से चलने से अधिक है, और यह पूरी तरह से यूएसबी द्वारा निर्धारित किया जाता है, और स्क्रीन पर आउटपुट नहीं। पहले लेख के कार्यान्वयन में, स्क्रीन का एक पूर्ण पुनर्विकास 3.6 एफपीएस से अधिक नहीं की आवृत्ति के साथ संभव है। लेकिन निराशा न करें - सबसे पहले, हम हमेशा पूरी स्क्रीन को फिर से नहीं बनाएंगे, और दूसरी बात, अगले लेख में, मैं दिखाऊंगा कि हमारे उपलब्ध लोहे से सबसे अधिक कैसे प्राप्त किया जाए, ताकि एफपीएस ~ 8 तक पहुंच जाए - अधूरे रीडिंग को ध्यान में रखते हुए हम पूरी तरह से प्रयोग करने योग्य डिवाइस प्राप्त करते हैं, जैसा कि लेख की शुरुआत में वीडियो में है। इन 9 एफपीएस, वैसे, भौतिक सीमा है जो हम कच्चे वीडियो डेटा (संपीड़न के बिना) को स्थानांतरित करते समय फुल स्पीड यूएसबी पर प्राप्त कर सकते हैं। यह स्पष्ट हो जाता है यदि हम 12 एमबी / एस के एफएस यूएसबी ट्रांसफर दर सीमा को याद करते हैं। हमारा फ्रेम 320 * 240 * 16 = 1,228,800 बिट्स लेता है। इस प्रकार, एक वैक्यूम फ्रेम दर में आदर्श, गोलाकार 9.8 FPS से अधिक नहीं होगा। हमारे हेडर को यहां से बाहर फेंक दें, हमारे ड्राइवर में नुकसान, मेजबान नियंत्रक चालक में नुकसान, एसटीएमके पर चालक में नुकसान - और हमें 8-9 एफपीएस की वास्तविक सीमा मिलती है, जो हासिल करने के लिए काफी अच्छा है। लेकिन हम इसे अगले लेख में करेंगे, और अब याद रखें कि हमारी आवृत्ति लगभग 3.5 एफपीएस है, और, मेरे माप के अनुसार, अवधि दो बार के बारे में, यानी 6-7 हर्ट्ज, इष्टतम हो गई। स्रोत कोड में पूर्वनिर्धारित HZ कर्नेल का उपयोग करके हम यही पूछते हैं। वैसे, आपको ध्यान देना चाहिए - नाम के बावजूद, यह मैक्रो 1 हर्ट्ज की आवृत्ति का निर्धारण नहीं करता है, लेकिन इसी अवधि (कर्नेल क्वांटा में), इसलिए, 6 हर्ट्ज की आवृत्ति प्राप्त करने के लिए इसे गुणा नहीं किया जाना चाहिए, लेकिन छह से विभाजित किया जाना चाहिए।
अंत में, फ़्रेमबफ़र पर संचालन के कॉलबैक के साथ संरचना को भरें।

Fb_ops संरचना

 static struct fb_ops display_fbops = { .owner = THIS_MODULE, .fb_read = fb_sys_read, .fb_write = display_write, .fb_fillrect = display_fillrect, .fb_copyarea = display_copyarea, .fb_imageblit = display_imageblit, .fb_setcolreg = display_setcolreg, };

पढ़ने के लिए, हम तुरंत उन " sys_ " के कॉलबैक को लिखते हैं , हमारे पास वहां करने के लिए कुछ भी नहीं है। शेष सभी में, हमें अभी भी अपडेट करने के लिए संबंधित पृष्ठों को चिह्नित करना होगा, इसलिए हम अपना संकेत देते हैं।
हमारे डिवाइस की डिस्क्रिप्टर संरचना पिछले लेख के समय से शायद ही बदल जाएगी, हम इसका वर्णन करेंगे।

Usblcd डिस्क्रिप्टर संरचना

 struct usblcd { struct usb_device *udev; struct usb_interface *interface; struct device *gdev; struct fb_info *info; struct usb_endpoint_descriptor *bulk_out_ep; unsigned int bulk_out_packet_size; struct videopage videopages[FP_PAGE_COUNT]; unsigned long pseudo_palette[17]; };

हमारे वीडियो मेमोरी पेज डिस्क्रिप्टर की एक सरणी को इसमें जोड़ा गया है। वास्तव में, कर्नेल में बड़ी मात्रा में डेटा को सांख्यिकीय रूप से रखने की अनुशंसा नहीं की जाती है, लेकिन संरचना खुद ही छोटी हो गई है, और कुल मिलाकर केवल 38 हैं, इसलिए अतिरिक्त पॉइंटर्स के साथ बेवकूफ नहीं बनाने के लिए, इस सरणी को 760 बाइट्स पर छोड़ दें। मास्टर करेंगे।
अंतिम क्षेत्र, pseudo_palette, छद्म पैलेट के नीचे का स्थान है जिसे fbcon की आवश्यकता होती है। यह .fb_setcolreg कॉलबैक से भरा है, जिसके बिना fbcon काम करने से मना कर देता है। मेरे द्वारा देखे गए सभी फायरवुड में, यह कॉलबैक कर्नेल स्रोतों से फ़्रेमबफ़र उदाहरण फ़ाइल से कॉपी-पेस्ट किया गया है, इसलिए हमने या तो एक साइकिल का आविष्कार नहीं किया है, खासकर क्योंकि कोई भी fbcon के अलावा इसका उपयोग नहीं करता है । चलो उसके साथ शुरू करते हैं।

कॉलबैक display_setcolreg

 #define CNVT_TOHW(val,width) ((((val)<<(width))+0x7FFF-(val))>>16) static int display_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue, unsigned transp, struct fb_info *info) { int ret = 1; if (info->var.grayscale) red = green = blue = (19595 * red + 38470 * green + 7471 * blue) >> 16; switch (info->fix.visual) { case FB_VISUAL_TRUECOLOR: if (regno < 16) { u32 *pal = info->pseudo_palette; u32 value; red = CNVT_TOHW(red, info->var.red.length); green = CNVT_TOHW(green, info->var.green.length); blue = CNVT_TOHW(blue, info->var.blue.length); transp = CNVT_TOHW(transp, info->var.transp.length); value = (red << info->var.red.offset) | (green << info->var.green.offset) | (blue << info->var.blue.offset) | (transp << info->var.transp.offset); pal[regno] = value; ret = 0; } break; case FB_VISUAL_STATIC_PSEUDOCOLOR: case FB_VISUAL_PSEUDOCOLOR: break; } return ret; }

यह, जैसा कि मैंने पहले ही कहा है, ऐसे कॉलबैक के लिए मानक कोड है, जिसमें CNVT_TOHW मैक्रो भी शामिल है, जिसका उपयोग रंग घटकों के मूल्यों को प्राप्त करने के लिए किया जाता है। इसे चालक से चालक तक भी खींचा जाता है - यह पूरी तरह से स्पष्ट नहीं है कि इसे अंततः मुख्य हेडर फ़ाइल fb.h में शामिल क्यों नहीं किया जाएगा।
इस कॉलबैक का कार्य 16-रंग वाले छद्म पैलेट में भरना है, जो पहले से उल्लेख किए गए कंसोल ड्राइवर द्वारा एक्सेस किया जाएगा।
अब हम एक छोटे से कार्य की घोषणा करेंगे, जिसमें हम स्थानांतरित करेंगे, वास्तव में, उस क्षेत्र में आयत जिसमें वीडियो मेमोरी प्रभावित थी। फ़ंक्शन यह गणना करेगा कि इस आयत से वीडियो मेमोरी के कौन से पृष्ठ प्रभावित होते हैं, उन पर "अपडेट आवश्यक" फ़्लैग रखें और उसी कॉलबैक के निष्पादन को शेड्यूल करें जिसे डिफर्ड io कहा जाता है। उसके बाद, sys_ फ़ंक्शन और हमारे द्वारा लिखे गए फ़ंक्शन को कॉल करने के लिए ऑपरेशन के सभी कॉलबैक कम हो जाएंगे, जिसे हम लिनक्स में कमांड के समान स्पर्श कहेंगे।

Display_touch फ़ंक्शन

 static void display_touch(struct fb_info *info, int x, int y, int w, int h) { int firstPage; int lastPage; int i; struct usblcd *dev=info->par; firstPage=((y*WIDTH)+x)*BYTE_DEPTH/PAGE_SIZE-1; lastPage=(((y+h)*WIDTH)+x+w)*BYTE_DEPTH/PAGE_SIZE+1; if(firstPage<0) firstPage=0; if(lastPage>FP_PAGE_COUNT) lastPage=FP_PAGE_COUNT; for(i=firstPage;i<lastPage;i++) atomic_dec(&dev->videopages[i].toUpdate); schedule_delayed_work(&info->deferred_work, info->fbdefio->delay); }

मुझे लगता है कि कोड, काफी समझ में आता है - हम आसानी से गणना करते हैं कि हम संकल्प के आधार पर किन पृष्ठों को छूते हैं, हमेशा गोल करते हैं, या यूँ कहें, हम बस एक छोर से एक छोर से एक पेज लेते हैं।
अब हम अन्य सभी कॉलबैक का वर्णन करते हैं - वे बहुत सरल हो जाते हैं:

संचालन के सभी कॉलबैक

 static void display_fillrect(struct fb_info *p, const struct fb_fillrect *rect) { sys_fillrect(p, rect); display_touch(p, rect->dx, rect->dy, rect->width, rect->height); } static void display_imageblit(struct fb_info *p, const struct fb_image *image) { sys_imageblit(p, image); display_touch(p, image->dx, image->dy, image->width, image->height); } static void display_copyarea(struct fb_info *p, const struct fb_copyarea *area) { sys_copyarea(p, area); display_touch(p, area->dx, area->dy, area->width, area->height); } static ssize_t display_write(struct fb_info *p, const char __user *buf, size_t count, loff_t *ppos) { int retval; retval=fb_sys_write(p, buf, count, ppos); display_touch(p, 0, 0, p->var.xres, p->var.yres); return retval; }

अब, आखिरकार, हम आस्थगित io से हमारे कॉलबैक का वर्णन करेंगे, जो प्रदर्शन को जानकारी भेजेगा। यह मोटे तौर पर पिछले लेख से .write कॉलबैक के साथ मेल खाएगा। हम पृष्ठों पर प्रदर्शन में लिखेंगे, विशेषता के लिए नहीं भूलना, जैसा कि पिछले लेख में, उन्हें आवश्यक शीर्षक। हमारे वीडियो संरचना के लिए धन्यवाद, x, y निर्देशांक और लंबाई की गणना पहले ही की जा चुकी है, इसलिए आपको बस इतना करना है कि इसे बफर में धकेल दें और इसे USB पर छोड़ दें।

विलंबित I / O कॉलबैक

 unsigned char videobuffer[PAGE_SIZE+8]; static void display_update(struct fb_info *info, struct list_head *pagelist) { struct usblcd* dev = info->par; int retval; struct page *page; int i; int usbSent=0; list_for_each_entry(page, pagelist, lru) { atomic_dec(&dev->videopages[page->index].toUpdate); } for (i=0; i<FP_PAGE_COUNT; i++) { if(atomic_inc_and_test(&dev->videopages[i].toUpdate)) atomic_dec(&dev->videopages[i].toUpdate); else { *(unsigned short*)(videobuffer)=cpu_to_le16(dev->videopages[i].x); *(unsigned short*)(videobuffer+2)=cpu_to_le16(dev->videopages[i].y); *(unsigned long*)(videobuffer+4)=cpu_to_le32(dev->videopages[i].length>>1); memcpy(videobuffer+8,dev->videopages[i].mem,dev->videopages[i].length); retval = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 1),videobuffer, dev->videopages[i].length+8, &usbSent, HZ); if (retval) printk(KERN_INFO "usblcd: sending error!\n"); } } }

चूँकि हम इस कॉलबैक को एक ईमानदार तरीके से प्राप्त कर सकते हैं ( deferrd io के माध्यम से), या हम इसे अपनी पहल पर कर सकते हैं (प्रदर्शन शेड्यूल करके call_souch के संचालन में कॉलबैक में से एक में निष्पादित होने के लिए शेड्यूल करके), हम बस हमारे पास जाने वाले सभी पृष्ठों पर जाएंगे, यदि कोई हो, और, उन्हें अद्यतन करने के लिए विषय के रूप में चिह्नित करें।
यदि हम स्थगित I / O के माध्यम से यहां नहीं पहुंचे, तो सूची बस खाली हो जाएगी।
उसके बाद, हम बस सभी पेजों के माध्यम से परमाणु की एक अद्यतन की आवश्यकता की जांच करते हैं और USB के माध्यम से सिंक्रोनस भेजकर इस अपडेट को निष्पादित करते हैं। अगले लेख में, जब हम ड्राइवर को उसकी सामान्य स्थिति में समाप्त करते हैं, तो हम सिंक्रोनस भेजने को USB अनुरोध ब्लॉक या URB नामक अधिक सही तंत्र से बदल देंगे। यह USB होस्ट को डेटा भेजने का अनुरोध करने और तुरंत आगे की प्रक्रिया में वापस जाने की अनुमति देगा। और तथ्य यह है कि यूआरबी ने उड़ान भरी (या उड़ान नहीं भरी) प्राप्तकर्ता को हमारे बारे में बताया जाएगा। यह हमें अपने सिस्टम से थोड़ी अधिक एफपीएस को निचोड़ने की अनुमति देगा (बिना, हालांकि, सैद्धांतिक सीमा से अधिक जो मैंने ऊपर उल्लेख किया है)।
हमारे पास बस थोड़ा सा बचा था - चूंकि हमने एक बुरा काम करने और खुद को साफ न करने का फैसला किया था, इसलिए जो कुछ बचा था, वह सब कुछ जांच कॉलबैक में शुरू करना था।

कॉलबैक जांच

 static int LCDProbe(struct usb_interface *interface, const struct usb_device_id *id) { struct usblcd *dev; struct usb_host_interface *iface_desc; struct usb_endpoint_descriptor *endpoint; unsigned char *videomemory; int retval = -ENODEV; int i; dev_info(&interface->dev, "USB STM32-based LCD module connected"); dev = kzalloc(sizeof(*dev), GFP_KERNEL); if (!dev) { dev_err(&interface->dev, "Can not allocate memory for device descriptor\n"); retval = -ENOMEM; goto exit; } dev->udev=interface_to_usbdev(interface); dev->interface = interface; iface_desc = interface->cur_altsetting; for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) { endpoint = &iface_desc->endpoint[i].desc; if(usb_endpoint_is_bulk_out(endpoint)) { dev->bulk_out_ep=endpoint; dev->bulk_out_packet_size = le16_to_cpu(endpoint->wMaxPacketSize); break; } } if(!dev->bulk_out_ep) { dev_err(&interface->dev, "Can not find bulk-out endpoint!\n"); retval = -EIO; goto error_dev; } dev->gdev = &dev->udev->dev; dev->info = framebuffer_alloc(0, dev->gdev); dev->info->par = dev; dev->info->dev = dev->gdev; if (!dev->info) { dev_err(&interface->dev, "Can not allocate memory for fb_info structure\n"); retval = -ENOMEM; goto error_dev; } dev->info->fix = fixed_info; dev->info->var = var_info; dev->info->fix.smem_len=FP_PAGE_COUNT*PAGE_SIZE; dev_info(&interface->dev, "Allocating framebuffer: %d bytes [%lu pages]\n",dev->info->fix.smem_len,FP_PAGE_COUNT); videomemory=vmalloc(dev->info->fix.smem_len); if (!videomemory) { dev_err(&interface->dev, "Can not allocate memory for framebuffer\n"); retval = -ENOMEM; goto error_dev; } dev->info->fix.smem_start =(unsigned long)(videomemory); dev->info->fbops = &display_fbops; dev->info->flags = FBINFO_FLAG_DEFAULT|FBINFO_VIRTFB; dev->info->screen_base = videomemory; memset((void *)dev->info->fix.smem_start, 0, dev->info->fix.smem_len); for(i=0;i<FP_PAGE_COUNT;i++) { dev->videopages[i].mem=(void *)(dev->info->fix.smem_start+PAGE_SIZE*i); dev->videopages[i].length=PAGE_SIZE; atomic_set(&dev->videopages[i].toUpdate,-1); dev->videopages[i].y=(((unsigned long)(PAGE_SIZE*i)>>1)/WIDTH); dev->videopages[i].x=((unsigned long)(PAGE_SIZE*i)>>1)-dev->videopages[i].y*WIDTH; } dev->videopages[FP_PAGE_COUNT-1].length=FB_SIZE-(FP_PAGE_COUNT-1)*PAGE_SIZE; dev->info->pseudo_palette = &dev->pseudo_palette; dev->info->fbdefio=&display_defio; fb_deferred_io_init(dev->info); dev_info(&interface->dev, "info.fix.smem_start=%lu\ninfo.fix.smem_len=%d\ninfo.screen_size=%lu\n",dev->info->fix.smem_start,dev->info->fix.smem_len,dev->info->screen_size); usb_set_intfdata(interface, dev); retval = register_framebuffer(dev->info); if (retval < 0) { dev_err(dev->gdev,"Unable to register_frambuffer\n"); goto error_buff; } return 0; error_buff: vfree(videomemory); error_dev: kfree(dev); exit: return retval; }

यहाँ, हम पहले अपने डिवाइस डिस्क्रिप्टर के लिए मेमोरी आवंटित करते हैं, फिर फ्रेमबफ़र डिस्क्रिप्टर संरचना के लिए , और उसके बाद ही फ्रेमबफ़र के लिए। कृपया ध्यान दें - हम vmalloc के माध्यम से चयन करते हैं । Kmalloc से अंतर यह है कि vmalloc वर्चुअल मेमोरी के पेज टेबल को फिर से कॉन्फ़िगर कर सकता है, और "बफर में संग्रहित करें" जिसे आप अनुरोध करते हैं। यही है, हमारे लिए यह स्मृति के एक ही ब्लॉक की तरह दिखेगा, लेकिन शारीरिक रूप से इसमें ऐसे पृष्ठ शामिल हो सकते हैं जो एक-दूसरे के करीब भी नहीं हैं। kmalloc मैमोरी देता है, जो शारीरिक रूप से एक ब्लॉक है। चूंकि हम एक बड़े पर्याप्त टुकड़े का अनुरोध कर रहे हैं, vmalloc एक अच्छा अभ्यास है।
हम संकलन करते हैं, insmodem करते हैं, और अगर सब कुछ सही ढंग से किया जाता है, तो हम डिस्प्ले पर कंसोल देखते हैं!

निष्कर्ष

इस लेख में, हमने आखिरकार यह महत्वपूर्ण कदम उठाया - एक कस्टम डिवाइस के ड्राइवर से जो सिस्टम द्वारा उपयोग नहीं किया गया था, हम फ्रेमवर्क की बाहों में चले गए, जिसने हमें सभी अनुप्रयोगों और ड्राइवरों को यह बताने की अनुमति दी कि हमारे पास एक वास्तविक प्रदर्शन है। हां, हमने थोड़ा बुरा किया, अपने संसाधनों की सफाई नहीं की और डिवाइस को हाथ नहीं लगाया, इसलिए यूएसबी को बाहर निकालना और इसे काम करने वाले डिवाइस पर प्लग करना अभी तक अनुशंसित नहीं है।
लेकिन हम इसे अगले लेख में निश्चित रूप से ठीक करेंगे। हमें क्या करना है?

डिवाइस पर डबल बफ़रिंग के लिए समर्थन लागू करें, एफपीएस में दो गुना वृद्धि प्रदान करता है।
हमारे दोष को ठीक करने के लिए, क्योंकि कंसोल हरा है (यदि हम कंसोल के अलावा कुछ भी चलाते हैं, तो यह बहुत भयानक लगेगा। शायद किसी ने पहले ही अनुमान लगा लिया था कि मामला क्या था?)
संसाधनों की सही सफाई को लागू करें ताकि आप डिवाइस को सुरक्षित रूप से डिस्कनेक्ट और कनेक्ट कर सकें
बल्क संदेश को समकालिक रूप से भेजने के बजाय URBs के अतुल्यकालिक तंत्र का उपयोग करने के लिए स्विच करें, जिससे चालक को नुकसान कम होगा
हमारे मिनी-कंप्यूटर का पूरी तरह से आनंद लेने के लिए विभिन्न मजेदार ऐप्स संकलित करें। इसलिए, उदाहरण के लिए, हम देखेंगे कि गोबलिंस इंजन के कोड में क्या पैच करने की आवश्यकता है ताकि वे अंततः शुरू करें।

नीचे एक पुरानी खोज के साथ एक और वीडियो है (गोबलींस की तुलना में मेरे द्वारा कोई कम प्रिय नहीं), एक छोटे से चित्रमय शेल की कुछ तस्वीरें जो आसानी से डिवाइस और एलिंक्स कंसोल ब्राउज़र पर चलाई जा सकती हैं।

कंसोल ब्राउज़र (फॉन्ट VGA8x8)

शैल Gmenu2X में पहला किरंदिया हबर

अंतर्निहित फ़ाइल ब्राउज़र इसमें

सेटिंग्स

मेरे पास अब के लिए सब कुछ है। सफल कार्यान्वयन और अगले लेख तक!

OpenWRT के साथ एक राउटर से मिनीकंप्यूटर: एक फ्रेमबफ़र ड्राइवर लिखना

परिचय

कर्नेल ग्राफिक्स समर्थन सक्षम करें

फ़्रेमबफ़र ड्राइवर लिखना

निष्कर्ष

More articles: