M src/blog/index.md => src/blog/index.md +1 -0
@@ 2,5 2,6 @@
pagetitle: "pv's Blog"
---
+- The Hunt for a UEFI Graphics Bug ([iq](/blog/uefi-graphics-bug/iq.html))
- The Curious Case of LenovoRuntimePassword ([iq](/blog/lenovoruntimepassword/iq.html))
- Hello World! ([en](/blog/hello/en.html), [iq](/blog/hello/iq.html))
A src/blog/uefi-graphics-bug/16f.png => src/blog/uefi-graphics-bug/16f.png +0 -0
A src/blog/uefi-graphics-bug/bigqemu.png => src/blog/uefi-graphics-bug/bigqemu.png +0 -0
A src/blog/uefi-graphics-bug/blt.webp => src/blog/uefi-graphics-bug/blt.webp +0 -0
A src/blog/uefi-graphics-bug/bootcon.png => src/blog/uefi-graphics-bug/bootcon.png +0 -0
A src/blog/uefi-graphics-bug/c0.png => src/blog/uefi-graphics-bug/c0.png +0 -0
A src/blog/uefi-graphics-bug/decomp-nice.webp => src/blog/uefi-graphics-bug/decomp-nice.webp +0 -0
A src/blog/uefi-graphics-bug/decomp.webp => src/blog/uefi-graphics-bug/decomp.webp +0 -0
A src/blog/uefi-graphics-bug/fferror.png => src/blog/uefi-graphics-bug/fferror.png +0 -0
A src/blog/uefi-graphics-bug/garbled.png => src/blog/uefi-graphics-bug/garbled.png +0 -0
A src/blog/uefi-graphics-bug/gop2.png => src/blog/uefi-graphics-bug/gop2.png +0 -0
A src/blog/uefi-graphics-bug/guidsearch.webp => src/blog/uefi-graphics-bug/guidsearch.webp +0 -0
A src/blog/uefi-graphics-bug/iq.md => src/blog/uefi-graphics-bug/iq.md +255 -0
@@ 0,0 1,255 @@
+---
+title: The Hunt for a UEFI Graphics Bug
+date: 2022-07-03
+---
+
+>How much did God guide?
+>
+>God said 640x480 16 color in 2004.
+>
+>God said single audio voice which I assume means one frequency at a time.
+>
+>God said no child windows.
+>
+>I had an editor side bar. God said no.
+>
+>It became clear He was guiding the work when things worked out really well.
+
+— Terry Davis.
+
+---
+
+::: {dir="rtl"}
+راح افترض انت قاري المقال السابق، [The Curious Case of LenovoRuntimePassword](/blog/lenovoruntimepassword/iq.html).
+
+قبل فترة ردت انصب OpenBSD (نظام Unix-like، مثل لينكس) على لابتوبي (Lenovo B470e) اللي يشتغل كDNS server (لحظر الاعلانات) وRADIUS server ([للوايفاي](https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configuration)).
+
+نزلت النظام، وحطيته بفلاش، وشغلته وطلعلي هيچ:
+
+![محاكاة باستخدام QEMU](garbled.png)
+
+بالبداية اعتقدت انه صار crash، بس جربت ادوس بالكيبورد وشفت دتصير تغييرات على الخرابيش، فيعني المشكلة تخص الgraphics.
+
+قبل ما طلعت هالخرابيش، طلعتلي prompt مال البوتلودر، اذا مادوس شي خلال كم ثانية راح يتلود الkernel تلقائيا.
+
+![](bootcon.png)
+
+اول شي جربت اسويه هو أتأكد من انه الimage مكتوبه للفلاش بشكل صحيح، بس طلع مابيها شي. وراها جربت اختار الفلاش يدويا عن طريق الboot menu اللي تطلع لمن ادوس F12 (گلت بلكي يفرق بشي)، وهم بقت.
+
+جتي ببالي فكرة اعتقدت انه ماراح تجيب اي نتيجة بس گلت خالأجربها ليش لا: ربطت الmonitor مال حاسبتي (1920x1080) باللابتوب و... اشتغل طبيعي!
+
+![محاكاة باستخدام QEMU](monboot.png)
+
+زاد فضولي، فجربت اشغل الimage بQEMU بوضع الUEFI عن طريق هذا الcommand:
+
+`qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -m 500M -enable-kvm -drive file=install71.img`
+
+والاغرب انه بعد ما اختفت الprompt، صارت الresolution مال الVirtual machine اعلى من مال الmonitor مالتي بهوايه:
+
+![](bigqemu.png)
+
+---
+
+راح اختصر هوايه، كالعادة.
+
+البوتلودر هو عبارة عن UEFI application، الmain function مالته شكلها كالاتي:
+
+`EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *systab)`
+
+الSystem table هي البوابة الرئيسية اللي تگدر من خلالها تتواصل ويه الUEFI. يعني مثلا بيها pointer للBoot Services، اللي تگدر من خلالها تلعب بالprotocols عن طريق functions مثل `LocateProtocol` `وInstallMultipleProtocolInterfaces` (حچيت عنهن بالمقال الفات).
+
+كذلك بيها pointers لل`ConIn` وال`ConOut`، اللي منهن تگدر تحصل على functions مثل `OutputString` و`ClearScreen` و`ReadKeyStroke`.
+
+البوتلودر يسوي هوايه شغلات خلال حياته القصيرة، اهمها تحميل الkernel للذاكرة و[اعطائه الarguments اللي يحتاجها](https://github.com/openbsd/src/blob/a0ea63c151bcac0bec153912d76e8f12bceb38a9/sys/arch/amd64/include/biosvar.h#L207) (مثل الSystem table والMemory map وال[Configuration tables](https://docs.rs/uefi/latest/uefi/table/cfg/index.html) اضافة الى الframebuffer pointer وتفاصيله مثل الdimensions والsize، الخ).
+
+قبل ما البوتلودر يشغل الkernel حيسوي call ل`ExitBootServices`، وراها بعد ماكو Boot Services: لا Handles ولا Timers ولا Events ولا Memory management ولا ConOut ولا ConIn ولا بطيخ، الkernel بعد حيحير بروحه بدون دلال الUEFI. على عكس الأهل اللي يطردون اطفالهم لمن يصير عمرهم 18 سنة، الUEFI عنده شوية حنيه وحيبقي الRuntime Drivers والRuntime Services (اللي تگدر منها تطفي/ترست الحاسبة وتتلاعب بالUEFI variables، الخ) وشكم شغله لخ.
+
+واضح من الأمثلة الشفناها فوگ انه لازم نطلع على الresolutions ونشوف شنو سالفتها. فخلي نفصل الشاشة الخارجية ونجرب نلعب بالprompt مال البوتلودر.
+
+منا وجاي، سكرينات البوتلودر حتكون مأخوذه من اللابتوب مباشرة عن طريق أمر `machine screenshot` اللي ضفته يدويا علمود هالمقال. حشرح طريقة عمله بعدين.
+
+![اكو فد شي كلش غريب بهالصورة، همممم](modes.png)
+
+اكو أمرين يهمونا هنا: `machine gop` و`machine video`. ال`gop` مو معناه الحزب الجمهوري الأمريكي وانما Graphics Output Protocol. الأمر يستعرضلنا الmodes (يعني الresolutions) المتوفرة للframebuffer ويخلينا نغيرها اذا نكتب `machine gop n` (ال`n` تمثل رقم الmode اللي نريده).
+
+ال`video` يستعرضلنا ال[text modes](https://en.wikipedia.org/wiki/Text_mode) المتوفرة للConOut، يعني 80x25 معناها هالmode ينطيك 25 سطر كل واحد يكفي 80 حرف، وهم يخلينا نغير الmodes بنفس الصيغة الفوگ.
+
+تغيير الtext mode ممكن يغير الGOP mode وبالعكس.
+
+خلي نجرب نكتب `machine gop 2` ونشوف شيصير:
+
+![](gop2.png)
+
+لاحظوا انه كأنه كلشي ما تغير بعد ما دخلنا الأمر. جديات، قارنوا الصورتين الفوگ وحتشوفون ماكو اي فرق بحجم الحروف. اصلا اذا انتوا فضوليين كلش، ممكن لاحظتوا انه الصورة القبل هاي الresolution مالتها 800x600، مع انه المفروض چنه بmode 0 اللي الresolution مالته 1024x768! اذا نستمر بالاقلاع، هالمرة حيشتغل النظام عادي بدون اي خرابيش.
+
+اعتقد المشكلة صارت واضحة: النظام عباله الresolution هي 1024x768 بس بالحقيقة هي 800x600، وهالشي ديخربط كل الحسابات.
+
+رستت وجربت اكتب `machine gop 0` حتى اشوف اذا حيحول لmode 0 من صدگ، بس مصار شي، عالاكثر لأن اكو checks بالfirmware تمنع التحويل لنفس الmode. فحولت لغير mode ورجعت ل0 وهالمرة صارت 1024x768 من صدگ واشتغل بدون خرابيش.
+
+زين لمن ربطت monitor خارجي ليش اشتغل طبيعي؟ خلي نربطه من جديد ونشوف الmodes الموجودة:
+
+![](mongop.png)
+
+اذا المستخدم ممختار mode محدد عن طريق `machine gop`، [البوتلودر حيختار الmode صاحب اعلى resolution](https://github.com/openbsd/src/blob/147ac6c235575f6ba7cfa96bdd00a7d4ea866309/sys/arch/amd64/stand/efiboot/efiboot.c#L856)، ومثل مدتشوفون بالصورة اكو mode اعلى من 1024x768 للmonitor. وهذا نفس السبب اللي يخلي الresolution تصير كلش چبيرة لمن تجرب تشغل النظام بQEMU، لأن QEMU يوفر 29 mode، اكبر resolution بيها هي 2560x1600، وشاشتي 1920x1080.
+
+زين ليش هيچ ديصير؟ ليش مواجهتني هالمشكلة ويه لينكس مثلا؟ اخذت فرة بالcode، و[لگيت هالfunction المثيرة للاهتمام](https://github.com/openbsd/src/blob/147ac6c235575f6ba7cfa96bdd00a7d4ea866309/sys/arch/amd64/stand/efiboot/efiboot.c#L440). شغلتها تحول الtext mode الى 100x31، واذا ماكو هالmode تحول ل80x25. مثل مشفنا فوگ، الtext mode بالفعل صاير 100x31.
+
+ تتذكرون شلون قبل گلت انه تغيير الtext modes ممكن يأثر على الGOP modes وبالعكس؟ احتمال اللي ديصير هنا هو انه اللابتوب ديشتغل بmode 0 (وهالشي وارد، خصوصا انه الsplash screen اللي تطلع اول ما يشتغل دقتها عالية) وراها تغيير الtext mode ديحول الGOP mode داخليا الى mode 2 بدون ما يحَدث المعلومات مال الmode الحالي.
+
+فحتى نأكد هالنظرية نحتاج نبني الbootloader بدون الcode مال تغيير الtext mode.
+
+---
+
+قبل ما اشتغل على الbootloader، احتاج طريقة ابنيه بيها على لينكس (للconvenience) واحتاج طريقة اجرب بيها تغييراتي بسرعة (اكيد ما راح اگعد اشيل فلاش واودي فلاش على اقل تعديل).
+
+حتى نبنيه بOpenBSD، نحتاج ننزل [sys.tar.gz](https://cdn.openbsd.org/pub/OpenBSD/7.1/sys.tar.gz) ونروح لsys/arch/amd64/stand/efiboot/bootx64 ونسوي `make`. اذا نجرب نفس الشي بلينكس ف`make` راح يعيط لأن اكو اختلافات بالsyntax بين OpenBSD make و GNU make. جربت `bmake` (اللي هو الNetBSD make، وpackaged بDebian) بس هم گعد يصيح.
+
+فأهنا جتي ببالي فكرة احسن: make (بأغلب الMakefiles) يكتب كل امر ينفذه، مثل هيچ:
+
+![](make.png)
+
+فأخذت الoutput [وسويته script](https://git.sr.ht/~paravoid/Demos/tree/6995ed61cfd6772b58621385b1135ddf4a313cc0/item/efigop/build/build.sh). صح هالشي معناه راح يصير rebuild كل ما اشغل السكربت حتى لو ماكو اي تغيير، بس الrebuild ميطول ثانيتين بالزايد فمو هلگد مهم. حطيت [`set -e`](https://git.sr.ht/~paravoid/Demos/commit/84aa34ff0e0582a4d5fd44f236264073bc374f26) ببداية الscript حتى اذا صار اي خطأ يوگف الbuild، وراها [استبدلت `cc` ب`clang`](https://git.sr.ht/~paravoid/Demos/commit/b48c8e69cfa590990216c9e8686d88ce84fbe241) (لأن بDebian، `cc` هو `gcc` بينما بOpenBSD هو `clang`) و[عدلت المسارات](https://git.sr.ht/~paravoid/Demos/commit/3a63b8cf5d50c08411241f434ed8492bb4ffefeb) باستخدام sed (هوايه ميعرفون انه [تگدر تستخدم اي delimiter يعجبك](https://www.grymoire.com/Unix/Sed.html#uh-2) ويه sed، مو شرط `/`. هالشي مفيد بهالحالة حتى لتضطر تحط `\` قبل اي `/` ضمن الpath). اخير شي [استبدلت الlinker](https://git.sr.ht/~paravoid/Demos/commit/c3252479e4d87e89df983710349c9daab7e8c977) بالLLVM linker.
+
+شغلته وطلعلي هالerror:
+
+![](machineerror.png)
+
+`make` شكله ما طبع فد خطوة من العملية، نگدر بسهولة نقارن قبل وبعد `make` ونشوف شنو الفروقات اللي بيها machine:
+
+![](makemachine.png)
+
+اها! شكله ديسوي symlink لinclude directory حسب الarchitecture.
+
+بعد ما سويت الsymlink، اخيرا انبنه البوتلودر بداخل لينكس وصار عندي ملف BOOTX64.EFI. بقه اشد الnetwork booting حتى اگدر اجرب تغييراتي بسرعة.
+
+نزلت [iPXE](https://ipxe.org/) وجربت اشغله، بس لاحظت انه دياخذ هوايه وكت على ما يشتغل بدون داعي (يعصى على iPXE initializing devices)، بس المهم اشتغل وگدرت انزل البوتلودر من http server على حاسبتي واشغله (عن طريق كتابة الرابط يدويا بالcommand line).
+
+حتى اوفر وكت، ضربت عصفورين بحجر: بنيته بس ويه الethernet drivers اللي احتاجها (لأن شكيت انه ديعصى على شي يخص الوايفاي) وخليتله embedded script يخليه ينزل البوتلودر تلقائيا اول ما يشتغل:
+
+`make bin-x86_64-efi/realtek.efi EMBED=script.ipxe`
+
+محتوى script.ipxe:
+
+::: {dir="ltr"}
+```
+#!ipxe
+dhcp
+chain http://link/to/BOOTX64.EFI
+```
+:::
+
+البوتلودر حيشتغل طبيعي وراها، بس اذا تريد تكمل الاقلاع لازم يكون عندك پارتشن بي ملف الkernel (تگدر تستخدم فلاش بي OpenBSD image خام، حيتعرف عليه عادي. او [تگدر تجهز واحد يدويا](https://www.cambus.net/booting-openbsd-kernels-in-efi-mode-with-qemu/)) وراها مجرد گول للبوتلودر وين الkernel (مثلا `boot hd1a:/bsd`).
+
+---
+
+بعد ما جهزنا كلشي، خلي نجرب [نمسح الcode](https://git.sr.ht/~paravoid/Demos/commit/05d08a2be2858c16f37476ed67868c0907ceae2e) اللي يغير الtext mode ونشغل البوتلودر:
+
+![](notextdirect.png)
+
+الدقة شكلها صح والمشكلة انحلت، مو؟ خلي نجرب نشغله عن طريق الF12 boot menu:
+
+![](notextf12.png)
+
+هالمرة الboot menu شكلها دتغير الtext mode الى 0 واللي ديغير الGOP mode الى 1 داخليا هم بدون ما يحدث معلومات الcurrent mode، يعني نفس المهزلة بس هالمرة مو البوتلودر مصدرها. هسه شسوي؟
+
+اول شي اجه ببالي هو انه احسب حجم الframebuffer من الابعاد (الطول * العرض (أو Pixels Per Scan Line) * عدد البايتات لكل بكسل (4)) [واقارنه ويه الFrameBufferSize الجاهز](https://git.sr.ht/~paravoid/Demos/commit/990eaf662f9faa7997c8a4c9aa4f00cc2aafebbf) واذا طلع اكو اختلاف اغير الmode، عسى ولعل يطلع الFrameBufferSize صحيح.
+
+جربته بQEMU، وطلع الحجم المحسوب 1920000 بايت بينما الحجم الreported هو 1921024، صار عندي فضول اعرف شنو قصة هال1024 الاضافية، شكلها فد نوع من الalignment، فرحت ادور بالcode مال OVMF (اللي هو الUEFI firmware مال QEMU) [ولگيت هالcommit](https://github.com/tianocore/edk2/commit/dd7760470fcefc31acd439b5e6e314839d45f358). جربته باللابتوب والحجم الreported بقه ثابت (67043328 بايت) ومَتغير لو شمسويت.
+
+---
+
+::: {dir="ltr"}
+> Try to be like the turtle—at ease in your own shell.
+
+— Bill Copeland.
+:::
+
+وره ما شفت الحجم الreported بقه ثابت، واهسي بالسالفة نزل، فعفتها مؤقتا. ثاني يوم چنت بالحمام واجه ببالي الUEFI shell، اللي تگدر تتخيله مثل الDOS بنكهة الUEFI وبي هوايه سوالف تفيد الtroubleshooting، فگلت خلي اجربه.
+
+نزلت نسخة حديثة وجربت اشغلها بس بقت الشاشة سودة، طلعت النسخ الجديدة [بس تدعم UEFI 2.3 وفوگ](https://narkive.com/zCN4CEnb.9)، بينما لابتوبي الUEFI implementation مالته 2.0. نزلت نسخة اقدم [منا](https://github.com/tianocore/edk/raw/master/Other/Maintained/Application/UefiShell/bin/x64/Shell_Full.efi) واشتغلت.
+
+استخدمت `dh` حتى اشوف رقم الhandle اللي بيها الGOP instance و... طلع اكو ثنين! هاي أول وحدة (واللي `LocateProtocol` تستعملها):
+
+![](c0.png)
+
+وهاي الثانية:
+
+![](16f.png)
+
+الGOP instance الثانية اكو بالhandle مالتها Device Path بينما الاولى لا، بمعنى ثاني، هي "فيزيائية" اكثر من الاولى.
+
+[جربت استخدم ثاني](https://git.sr.ht/~paravoid/Demos/commit/40e5574b2b22de0a00de4be533ee3b4dc635ec3b) GOP instance بدل الاولى وانحلت كل المشاكل like a charm!
+
+زين شلون وليش؟ سويت جلسة بحث مطولة ولگيت [هالمقال](https://uefi.blogspot.com/2017/02/the-uefi-maze-game-part-4.html) مال شخص ديكتب Maze game للUEFI، ذني المقتطفات اللي تهمنا:
+
+::: {dir="ltr"}
+>Find all instances of the Graphics Output protocol that are available in the system. There can be one instance per graphical device in the system. Each one of the instances can be set to a different resolution and support a different number of colors. Rather than requiring the application to manage all of the devices, most systems use the Console Splitter driver, which acts as a meta-driver, aggregating the information from all of the drivers and drawing all bitmaps on all displays. The LocateHandleBuffer() function in the UEFI Boot Services allocates a buffer to hold all of the handles that support a specified protocol
+>
+>Now that we have found handles for all drivers that support the Graphics Output protocol, we examine each handle to see if it also has an instance of the Device Path protocol. Why? Because the one way to distinguish the Console Splitter from all other graphical devices in the system is that it is not actually a hardware device. Since it is not a hardware device, it does not have a Device Path protocol associated with it, since the Device Path protocol used to describe how a device is attached to the system. If we find a handle that doesn't have an instance, the pointer to that instance of the Graphics Output protocol is saved in a global variable.
+:::
+
+شنو المشكلة بالConsole Splitter؟ ليش ملازم نستعمله؟
+
+جلسة بحث ثانية ودتني لهل[email thread](https://edk2-devel.narkive.com/6Sv2VpKH/edk2-conout-protocol) و[هالcode من الEFISTUB مال لينكس](https://github.com/torvalds/linux/blob/34074da5424c08542d197396757cc3194ef754b4/drivers/firmware/efi/libstub/gop.c#L493). اتوقع چان اكو فترة الGOP instance مال الConsole Splitter چانت buggy ولابتوبي من ضمن هالفترة.
+
+زين منو هذا الشحص صاحب المقال؟ صار عندي فضول فدورت على [الLinkedIn](https://www.linkedin.com/in/tim-lewis-82581921) مالته:
+
+![](linkedin.webp)
+
+Phoenix Technologies هي الشركة اللي "صنعت" الfirmware مال لابتوبي.
+
+صار عندي فضول، يا ترى سالفة التأكد من الDevice Path ديتم استخدامها بداحل الfirmware بنفسه؟ خلي نبحث عن كل مكان موجود بي الGOP GUID:
+
+![](guidsearch.webp)
+
+اختاريت SystemImageDisplayDxe وحطيتها بGhidra، هنا ديتم استعمال الGOP GUID بيها:
+
+![](decomp.webp)
+
+خلي نرتب شوية:
+
+![](decomp-nice.webp)
+
+زين عرفنا انه المشاكل اللي تطلع لمن نشغل النظام باستخدام F12 مو صوچ البوتلودر، هل هذا معناه انه المشاريع المشهورة اللي تدعم UEFI هم حتواجه مشاكل لمن اشغلها بهالطريقة؟ جربت كم وحدة وهاي النتائج:
+
+- NetBSD: نفس مشاكل OpenBSD.
+- iPXE (بوضع الCONSOLE_FRAMEBUFFER): نفس مشاكل OpenBSD.
+- rEFInd: الشاشة تبقى اغلبها سودة ويه 3 صور من الواجهة مشمرة بأماكن مختلفة.
+- GRUB (بوضع الgfxterm): الشاشة تصير سودة كليا.
+- لينكس بوضع الEFISTUB: لا، مثل ما شفنا ليفوگ، حيختار اول GOP instance اللي الhandle مالتها بي ConOut protocol instance.
+- FreeBSD: [نفس وضعية لينكس](https://github.com/freebsd/freebsd-src/blob/221376db0cb77035e325baf8b54d6224925b41f8/stand/efi/loader/framebuffer.c#L567).
+
+انحل اللغز، كتبت patch هم يختار اول GOP instance الhandle مالها بي Device Path instance واذا ماكو يختار اول وحدة، [دزيته](https://marc.info/?l=openbsd-bugs&m=165087969227708&w=2) (وحطيت روابط كم منشور مال اشخاص عانوا نفس المشكلة ويه الايميل حتى ابين انه السالفة مو بس يمي) ب2022-04-25 وتم [قبوله](https://marc.info/?l=openbsd-bugs&m=165569262021786&w=2) ب06-20.
+
+---
+
+ردت اسوي خرابيش homemade حتى اگدر احصل صورة نظيفة من داخل QEMU واحطها بهالمقال، [فسويت الdimensions](https://git.sr.ht/~paravoid/Demos/commit/50cd50e1b6f477840510c95d1b0d2a1d33a61df8) مال الframebuffer اللي يتم تمريرها للkernel نفسها مال mode 0 باللابتوب (1024x768)، الdefault mode مال QEMU الresolution مالته 800x600 (نفسها مال mode 2)، فمحتاجيت اغيرها.
+
+حتى اگدر اصور البوتلودر لهالمقالة، [ضفت code](https://git.sr.ht/~paravoid/Demos/commit/070005db5d7f96e0ee3964c4bb43f60548a9237e) يخزن الframebuffer بملف وخليت مكان الخزن hardcoded لFAT32 partition بالهارد. ردت اخلي اسم الملف ينأخذ من الarguments، بس المشكلة انه الarguments دتجي `char` وال`FileName` لازم يكون `CHAR16` (لأن UCS-2). ملگيت function تحول بينهن، فمجرد اخذت اول حرف من الargument.
+
+بالنسبة لوجود `EFI_FILE_MODE_READ` فهذا مجبور احطه:
+
+![ص515 من ال[UEFI 2.9 Specification](https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf)](openmodes.webp)
+
+جربته بQEMU واشتغل، رحت للابتوب وشغلته بس بقه عاصي وكتب ملف فارغ. شكيت انه ملازم اقره من الframebuffer مباشرة فرحت اگلب بالspec ولگيت function اسمها `Blt`، هذا جزء من وصفها:
+
+![ص492](blt.webp)
+
+[فعدلت الcode](https://git.sr.ht/~paravoid/Demos/commit/32870e00e6cf3ab664f70cfcc903ff129b3efaca) حتى يستخدم `Blt` ويه ال`BltVideoToBltBuffer` operation، جربته وحصلت على ملف. جربت احوله لpng باستخدام `ffmpeg` (عرفنا الpixel format من الshell فوگ):
+
+`ffmpeg -f rawvideo -pixel_format bgr0 -s 800x600 -i x x.png`
+
+بس طلعلي هالخطأ:
+
+![](fferror.png)
+
+شصار هنا؟ احنا حجم الملف اللي دنخزنه حسبناه باستخدام المعادلة الفوگ، المشكلة انه اخذنا الأبعاد من الGOP instance الاولى التعبانة اللي عبالها الresolution هي 1024x768، فصار حجم الملف الناتج 3145728 بايت. احنا گلنا لffmpeg انه الresolution هي 800x600، فعباله انه الحجم هو 1920000 بايت. فالتهم اول 1920000 بايت بس بقه 1225728 بايت وراها، شيسوي؟ گال هاي اكيد جزء من frame ثاني، راد يلتهمها عالواهس بس شاف انه 1225728 اقل من حجم الframe المتوقع (1920000) فگام يعيط. مو مشكلة، حنگله نريد frame واحد:
+
+`ffmpeg -f rawvideo -pixel_format bgr0 -s 800x600 -i x -vframes 1 x.png`
+
+
+فتحت الصورة وطلعت سودة، فتحت الملف اللي اخذناه من اللابتوب وطلع كله صفارة. شكلها الGOP instance الاولى حتى الBlt ما تدعمه عدل، [فعدلت الcode](https://git.sr.ht/~paravoid/Demos/commit/129d62ff7563b6d162531da14bf4a5281e890719) حتى يستعمل الثانية بس للscreenshot و(أكيد [مننسى](https://git.sr.ht/~paravoid/Demos/commit/4957e09f763d3c03da83221ca223c3d5bdcc501f) `FreePool` ;)) وصارت عندي صور تمام.
+
+حتى اطگطگ سكرينات للUEFI shell، مجرد اخذت الcode مال الscreenshot function وحطيته بالبداية وحطيت return (تعاجزت اسوي ملف من الصفر :p)، اسم الoutput file بقيته ثابت لأن تعاجزت اخذه من الarguments.
+
+:::<
\ No newline at end of file
A src/blog/uefi-graphics-bug/linkedin.webp => src/blog/uefi-graphics-bug/linkedin.webp +0 -0
A src/blog/uefi-graphics-bug/machineerror.png => src/blog/uefi-graphics-bug/machineerror.png +0 -0
A src/blog/uefi-graphics-bug/make.png => src/blog/uefi-graphics-bug/make.png +0 -0
A src/blog/uefi-graphics-bug/makemachine.png => src/blog/uefi-graphics-bug/makemachine.png +0 -0
A src/blog/uefi-graphics-bug/modes.png => src/blog/uefi-graphics-bug/modes.png +0 -0
A src/blog/uefi-graphics-bug/monboot.png => src/blog/uefi-graphics-bug/monboot.png +0 -0
A src/blog/uefi-graphics-bug/mongop.png => src/blog/uefi-graphics-bug/mongop.png +0 -0
A src/blog/uefi-graphics-bug/notextdirect.png => src/blog/uefi-graphics-bug/notextdirect.png +0 -0
A src/blog/uefi-graphics-bug/notextf12.png => src/blog/uefi-graphics-bug/notextf12.png +0 -0
A src/blog/uefi-graphics-bug/openmodes.webp => src/blog/uefi-graphics-bug/openmodes.webp +0 -0