EFI bootolható USB-Linux

Segédprogramok

Van egy hordozható Linux image-em, amit ha kiírok USB-re, akkor fel tudom bootolni a nem EFI-s gépeken, de most egy EFI-s gépen kellene.Odáig eljutottam a manualok meg a kugli alapján, hogy létrehoztam egy FAT16 partíciót, azon belül pedig egy efi/boot/ könyvtárstruktúrát. Aztán csináltam egy image-et:

grub-mkimage -o bootia32.efi -p /efi/boot -O i386-efi fat iso9660 part_gpt part_msdos normal boot linux configfile loopback chain efifwsetup efi_gop efi_uga ls search search_label search_fs_uuid search_fs_file gfxterm gfxterm_background gfxterm_menu test all_video loadenv exfat ext2 ntfs btrfs hfsplus udf

Majd a kapott fájlt bemásoltam az előbb létrehozott efi/boot/ könyvtárba. Eztán melléraktam még egy grub.cfg fájlt is, egyelőre egy minimális próbatartalommal:

set timeout=5

menuentry 'Setup firmware'
{
	fwsetup
}

Ha felhozom a gép boot menüjét, akkor megjelenik az USB kulcs és ha kiválasztom, akkor be is jön a GRUB, de csak a prompt, nem a menü.

Van valakinek valami ötlete, hogy mit csinálok rosszul?

  • 2343 megtekintés

( dzsolt v | 2019. 02. 05., k – 22:23 )

A /boot/efi strukúrába kell beilleszteni, de nem kell azon a partíción létrehozni.
https://wiki.mageia.org/mw-en/images/0/0c/EFI-solo6_1.png

Ha félreértettem, akkor bocsánat! A kernelben engedélyezve van?
KERNEL Enable support for GPT
-*- Enable the block layer --->
Partition Types --->
[*] Advanced partition selection
[*] EFI GUID Partition support
ISO8859-1 codepage must be enabled too, in order to mount the EFI partition:

KERNEL Enable ISO8859-1 codepage
-*- File Systems --->
Native Language support --->
[*] NLS ISO 8859-1 (Latin 1; Western European Languages)

By

dzsolt

Van linked a kész image-hez? (virtualizálva futtatni esetleg vagy csak belenézni az image-be hátha a /usr/src/linux alatt ott a .config?! Nem ismerek minden rendszert, de a legtöbben ez benne szokott lenni.) illetve ha amúgy nem EFI-s gépen működik akkor ott bootolj be és:

cat /proc/config.gz | gunzip |grep EFI

By

dzsolt

Így illeszd be a fájlrendszeredbe (már ha sda meg ha az első partíció az EFI):

mount /dev/sda1 /boot/efi

A grub fog rá másolni ilyesmit, amikor telepíti a boot szekciót:

EFI/linux/valami.cer
grubx64.efi

kb ennyi lesz az EFI partíción összesen, ha egy rendszered van.

Tehát a rendszered gyökerében van a /boot/efi, az EFI/linux-ot a grub csinálja, nem te. Viszont ha mbr-el van partícionálva a kulcsod, akkor hogy fog EFI indulni róla?
Nekem van egy multibootos mentő stickem efi-re, de az gpt és nem msdos, mert anélkül nem megy az efi boot. Lehet, hogy azzal kellene kezdened.

By

dzsolt

Ja, tud ha tud legacy bootot, de a tisztán efi-sek nem. Ez nem bug. Te írtad korábban, hogy nem tud legacy-t, hát akkor helyben vagyunk, próbáld gpt-n. Persze tévedhetek...

(most nézem, hogy eltévesztettem a szálat, bocsánat, nem válaszolok többet telefonról :) )
By

dzsolt

Nagyon szívesen, örülök neki!!! Annó (4 éve kb) sokat szívtam vele, mire sikerült az első gpt-s bootom hiba nélkül! A világ összes boot menedzserét kipróbáltam mire sikerült :) Azóta pár sikeres W10 Rolloutot (pár ezer gép) végigcsináltam és ott mindenféle biosokon volt alkalmam gyakorolni. Néha bugnak tűnhet pár dolog, de ha valami rendszeresen visszatérő, akkor a mintát követve kiderül mi a bibi.
By

dzsolt

( CzLaci | 2019. 02. 06., sze – 13:36 )

Arch linux alatt nekem működik:
- A pendrive formázása GPT-vel, +2 partíció felvétele, egy a boot-nak (ef02 kódú) és egy az EFI-nek (ef00 kódú).
- Partíciók felcsatolása, az EFI partíció a /boot helyére
- Rendszer felmásolása
- Majd a grub telepítése:
grub-install --target=x86_64-efi --efi-directory=/boot \
--boot-directory=/boot --bootloader-id=grub
grub-mkconfig -o /boot/grub/grub.cfg

--
Dell Latitude 5480, Arch Linux & Xfce

( bzt | 2026. 02. 18., sze – 00:03 )

Pár észrevétel:
1. mindenképp GPT. Rengeteg a bugos UEFI firmware ami nem tudja a PMBR-t legacy (UEFI CSM) nélkül
2. nem jól csinálod, nem a /boot/efi alá kell felcsatolni, hanem a /boot alá (azaz a GPT-n kell legyen egy ESP, és ezen a partíción kell legyen már az EFI könyvtár, tehát ez már a felcsatolási pont alatti struktúra része)
3. ha a grub elindul, de promptot ad, akkor valószínűleg az ESP:EFI/BOOTX64.EFI felmásolódott, de a többi grub cucc nem. Ezek NEM ebbe a mappába kell kerüljenek, hanem az ESP:grub és ESP:grub/x86_64-efi alá.

Szóval ha felcsatolod az ESP-t, akkor ilyen könyvtárstuktúrát kell láss:
GPT.ESP (FS0: UEFI szlengben)
|- EFI
|  |_ GRUB
|  |   \_ GRUBX64.EFI  (grub bináris, bitre ua. mint az alábbi fájl)
|  \_ BOOTX64.EFI      (grub bináris, bitre ua. mint a fenti fájl)
|- grub
|  |_x86_64-efi        (a grub efi-s moduljai, pl. a menü kezelő)
|  \_ grub.cfg         (szokásos grub config menuentry-kkel)
|- vmlinuz             (Linux esetén, meg más oprendszer fájlok)
\_ BOOTMGR.EFI         (Windows esetén, meg más oprendszer fájlok)
A modulok alatt mindenképp legyen grub.efi, core.efi, video.mod, gfxmenu.mod, efi_gop.mod, part_gpt.mod, fat.mod, stb. (más is kellhet, de ezek nélkül tuti meg sem fog nyikkanni). UEFI alatt nincs karakteres képernyő (se egyéb VGA / VESA támogatás), ezért kell mindenképp a grafikus menü (csak pixelalapú képernyő támogatott GOP alatt, UGA-t felejtsd el, pár ősi inteles Mac-et leszámítva semmi nem támogatja, csak a GOP-ot).

UEFI alatt nincs karakteres képernyő

Ez így nem pontos. UEFI alatt van szöveges konzol, ami lehet hardver karakteres, vagy GOP-on működő grafikus konzol, vagy akár soros terminál, vagy ezek multiplexelése.

https://uefi.org/specs/UEFI/2.11/12_Protocols_Console_Support.html

https://uefi.org/specs/UEFI/2.11/04_EFI_System_Table.html#id6

Az más kérdés, hogy a boot loader (mint UEFI app) tudja-e használni ezeket a protokollokat. Emlékeim szerint a grub tudja, és futólag ránézve a forrására (grub-core/commands/efi/efitextmode.c, grub-core/term/efi/console.c) ez igazoltnak tűnik.

Ez így nem pontos.
De, tökéletesen pontos.
ami lehet hardver karakteres
Nem, nem lehet. Csakis grafikus létezik, nincs már olyan képernyő üzemmód, amiben karakterek és attribútum bájtok találhatók a video memóriában (mint VGA alatt a 0xB8000-as címen, amit a grub példakernele is használna), ez a BIOS-al (pontosan VBE-vel) együtt ment a kukába.

(Megjegyzem, ez a hardver karakteres üzemmód kizárólag az IBM PC kompatíbilis CGA/EGA/VGA/VESA kártyák sajátja volt, más platformokon, például Mac-en, Amigá-n, SPARC-on, SGI-n, RaspberryPi-n soha nem is létezett.)
Emlékeim szerint a grub tudja
Nem tudja, mert nem létezik. Amit a grub efitextmode.c-je használ, az az EFI_SIMPLE_TEXT_OUTPUT protokoll, ami pedig a háztető alatt az EFI_GRAPHICS_OUTPUT_PROTOCOL-t, azaz GOP-ot. Hogy érthető legyen, teljesen szoftveresen rajzolja ki a bötűket (konkrétan a GOP Blt hívással), szó sincs semmiféle hardveres karakteres képernyőről. Ez utóbbi egyszerűen nem létezik EFI alatt.

Amit pedig a grub console.c-je használ, az meg csak a EFI_SIMPLE_TEXT_OUTPUT felett egy absztrakció, tehát vissza a kályhához, végső soron ez is GOP.

Végezetül a soros terminált egyáltalán nem tud az EFI, csak soros vonali konzolt, ami meg nem egyéb egy karakter alapú bájtfosásnál. Olyan kód, ami terminál CSI szekvenciákat értelmezne vagy állítana elő, egyáltalán sehol sincs a TianoCore-ban.
Az más kérdés, hogy a boot loader (mint UEFI app) tudja-e használni ezeket a protokollokat.
Erre van a POSIX UEFI projektem, ami POSIX interfészt biztosít az UEFI API felett. Minden olyasmi, hogy UTF-8 vagy stdout átirányítás, ebben lett implementálva, mert magától az EFI nem tud ilyent.
Ebben egyébként van példa program arra is, hogyan kell magadtól karaktereket kirajzolni EFI-n (hint: nem, nem karakterek memóriába írásával).

Laikusként azt kérdezném, hogy ha már a grub elindult, akkor miért számit hogy EFI vagy más? A grub elindulása után van szerepe az 

EFI-nek?

A régi BIOS -nál azt tanították, ha lefut a Post, és minden rendben működik,  akkor a Bios keres egy bootolhato particiot, jellemzően a merevlemez 0 vagy ? 1 szektora MBR-ből kiolvas egy aktív particiót, oda  adja a vezérlést, onnantól az OP rendszer irányítja a  boot folyamatot.

Az EFI miben más? Ésa  régebbi EFI Bios- ok, amikben még volt bekapcsolható CSM támogatás, pont úgy néztek ki,  mint egy régi karakteres  Ami Bios.

Nem tudja, mert nem létezik. Amit a grub efitextmode.c-je használ, az az EFI_SIMPLE_TEXT_OUTPUT protokoll, ami pedig a háztető alatt az EFI_GRAPHICS_OUTPUT_PROTOCOL-t, azaz GOP-ot. Hogy érthető legyen, teljesen szoftveresen rajzolja ki a bötűket (konkrétan a GOP Blt hívással), szó sincs semmiféle hardveres karakteres képernyőről. Ez utóbbi egyszerűen nem létezik EFI alatt.

Ezt is megbeszéltük már máshol; most (függetlenül) az InternalPrintGraphic dokumentációjából csak egy bekezdést emelnék ki:

  If a graphics console device is not associated with the ConsoleOutputHandle
  defined in the EFI_SYSTEM_TABLE then no string is printed, and 0 is returned.

Ez pont az az eset, amikor a ConsoleOut-on csak STO van (ami a spec minimum elvárása), GOP nincs. A függvényt felkészítették arra az esetre, amikor a UEFI konzol nem grafikus, hanem csak karakteres (ami a spec minimum elvárása). https://uefi.org/specs/UEFI/2.11/04_EFI_System_Table.html#id6

Amit pedig a grub console.c-je használ, az meg csak a EFI_SIMPLE_TEXT_OUTPUT felett egy absztrakció,

Magával a kijelentéseddel egyetértek.

A link viszont vagy mis-paste (= nem erre gondoltál), vagy irreleváns (semmiféle szükségszerű kapcsolat nincs a grub és az edk2 UefiLib között).

tehát vissza a kályhához, végső soron ez is GOP.

Ez nem így van; lásd másutt.

[...]

( lacos | 2026. 02. 21., szo – 21:03 )

Kevered az edk2-t (ami a PI (Plaform Initialization), UEFI, és részben ACPI specifikációk referencia implementációja) magukkal a specifikációkkal. UEFI applikációkat, mint pl. bootloadereket, mint pl. a grub-ot, általában véve a UEFI spec-re írnak, nem egy konkrét UEFI implementációra (pl. edk2-re). (Természetesen lehet edk2-t alkalmazásfejlesztésre is használni, nyújt egy csomó extra library-t, de a hivatalos felületet a UEFI spec adja, nem az edk2 implementáció.)

A spec szerint az EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL a UEFI konzolnak a kanonikus megközelítési módja. Hogy ezt a protokollt konkrétan mi implementálja, és hogyan, az firmware belsőleges / implementációs kérdés; a UEFI app-nak, mint például grub-nak, nem igazán van hozzá köze. Az edk2-ben valóban a GraphicsConsoleDxe az egyik driver, amely ebben a stack-ben részt tud venni; GOP felett nyújt EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL-t. Egy másik driver a stack-ben pedig a ConSplitterDxe. Az utóbbi végzi a multiplexelést. Így lehetséges az, hogy amit a grub2 megnyit mint EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL-t (akár közvetlenül, akár valamilyen edk2 library segítségével), és amire karakteresen ír, az egyidőben jelenik meg akár több GOP-on (több különböző grafikus kártyán / monitoron) és több soros porti terminálon is (TerminalDxe).

Például QEMU/KVM virtualizációval és VFIO-val lehet olyat csinálni, hogy futtatsz egy virtuális gépet, amelyhez VFIO device assignment-tel hozzárendelsz egy fizikai GPU-t, ami a host-ba van bedugva, és amin egy külön monitor lóg. A guest-ben az OVMF (az edk2 egyik virtuális platformja) nyújtja a firmware-t. A grub menüje egyszerre, egyidejűleg fog megjelenni

  • a fizikai GPU-n / monitoron (amihez az OVMF a fizikai GPU-nak a PCI expansion ROM BAR-jában tárolt UEFI driver-ét használja),
  • a QEMU által emulált virtuális videokártyán és kijelzőn (pl. QemuVideoDxe vagy VirtioGpuDxe használatával),
  • és a QEMU által emulált soros porton.
                         SimpleTextOut
                        [ConSplitterDxe]
                               ^
                               |
   ----------------------------+-------------------------
   SimpleTextOut         SimpleTextOut      SimpleTextOut
[GraphicsConsoleDxe]  [GraphicsConsoleDxe]  [TerminalDxe]
         ^                     ^                  ^
         |                     |                  |
   GraphicsOutput       GraphicsOutput         SerialIo
   [GpuDriver.efi]      [QemuVideoDxe]      [PciSioSerialDxe]
        ^                      ^                  ^
        |                      |                  |
        |                      |                 Sio
        |                      |              [SioBusDxe]
        |                      |                  ^
        |                      |                  |
      PciIo                  PciIo              PciIo
      -------------------------+---------------------
                           [PciBusDxe]
                               ^
                               |
                          PciRootBridgeIo
                         [PciHostBridgeDxe]

 

Ezzel párhuzamosan a grub-ot a UEFI konzol EFI_SIMPLE_TEXT_INPUT_PROTOCOL-ján keresztül lehet vezérelni, ami pedig pl. a következőkből táplálkozik:

  • mondjuk egy (szintén assign-olt) fizikai USB billentyűzet,
  • és egy QEMU által emulált USB vagy PS/2 billentyűzet.

(Ezt már nem rajzolom fel.)

 

Emlékeim szerint a grub tudja

Nem tudja, mert nem létezik. Amit a grub efitextmode.c-je használ, az az EFI_SIMPLE_TEXT_OUTPUT protokoll

Igen, pontosan ezt írtam: Az más kérdés, hogy a boot loader (mint UEFI app) tudja-e használni ezeket a protokollokat. Emlékeim szerint a grub tudja

Az "ezeket a protokollokat" pedig erre a linkre vonatkozott: https://uefi.org/specs/UEFI/2.11/12_Protocols_Console_Support.html

 

Más: az UefiLib-re való hivatkozások érdektelenek illetve tévesek a grub szempontjából; a grub egy olyan UEFI app, amely nem az edk2-re épül. Nem használ edk2 library-ket.

 

teljesen szoftveresen rajzolja ki a bötűket (konkrétan a GOP Blt hívással), szó sincs semmiféle hardveres karakteres képernyőről. Ez utóbbi egyszerűen nem létezik EFI alatt.

Ismétlem, kevered.

  • A GraphicsConsoleDxe az edk2-ben egy olyan simple text out implementációt nyújt, amely GOP-ra rajzol, GOP "metódusokkal".
  • Ettől függetlenül a spec tökéletesen lehetővé teszi, hogy olyan UEFI implementáció legyen valamely platformon, ahol a UEFI konzolhoz olyan simple text output tartozik, amely hardveres karakteres implementáció (ad abszurdum még egy plotter is lehetne). Ha egy ilyen platformon futtatod a grub-ot, akkor "végső soron" GOP nem fog szükségszerűen szerepelni az érintett driver stack-ben.

Végezetül a soros terminált egyáltalán nem tud az EFI, csak soros vonali konzolt, ami meg nem egyéb egy karakter alapú bájtfosásnál. Olyan kód, ami terminál CSI szekvenciákat értelmezne vagy állítana elő, egyáltalán sehol sincs a TianoCore-ban.

https://en.wikipedia.org/wiki/ANSI_escape_code#Control_Sequence_Introducer_commands

... Az MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c file-ban elég sok ESC [ szekvencia szerepel.

Az UEFI-ben egyébként van UTF-8 termináltípusra támogatás (és az edk2 implementálja is):

https://uefi.org/specs/UEFI/2.11/10_Protocols_Device_Path_Protocol.html#vendor-defined-messaging-device-path

https://uefi.org/specs/UEFI/2.11/Apx_B_Console.html

VTUTF8RawDataToUnicode függvény a TerminalDxe-ben (pl).

Hüllyeségeket beszélsz. Azt ugye tudod, kinek próbálod itt osztani az észt?
Kevered az edk2-t (ami a PI (Plaform Initialization), UEFI, és részben ACPI specifikációk referencia implementációja) magukkal a specifikációkkal.
Dehogy keverem, te beszélsz baromságokat. Az UEFI referencia implementációja a TianoCore, az EDK ahogy a neve is mondja (EFI Development Kit) pedig a fejlesztői környezete, interfész definíciókkal és segédfüggvénykönyvtárakkal meg minden.
Az, hogy mindkettőt ugyanaz a konzurcium adja ki, ne tévesszen meg. Nem én keverem itt a dolgokat.
UEFI applikációkat, mint pl. bootloadereket, mint pl. a grub-ot, általában véve a UEFI spec-re írnak
Hogy beszélhetsz ekkora baromságokat? Ezeket az UEFI app-okat mindig SDK-ra írják, ami az EFI esetén az EDK2, vagy a GNU-EFI, vagy az általam fejlesztett POSIX-UEFI. Nem is lehet másként, mert olyan az ABI (kellenek a GUID-ok meg a struct-ok, annélkül nem megyen).

Írtál te már bootloadert egyáltalán? Vagy EFI SDK-t? Én - veled ellentétben - mindkettőt írtam már.
A spec szerint az EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL a UEFI konzolnak a kanonikus megközelítési módja. Hogy ezt a protokollt konkrétan mi implementálja, és hogyan, az firmware belsőleges / implementációs kérdés
Ööö, nem, megint hülyeségeket beszélsz. Nyilván nem hasznáhat akármit, csak másik UEFI protokollt (pl. UGA vagy GOP), márpedig az alacsony szintű video protokollok között egyetlen olyan sincs, mi támogatná a karakteres képernyőbuffert. Így hiába, ha a hardver driver nem tudja, mert nincs olyan interfész, amin keresztül tudhatná, akkor az EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL sem lesz képes rá. Ez tök evidens.
Ismétlem, kevered.
Ismétlem, hülyeségeket beszélsz. Ott van az orrod előtt a forrás, látod benne a GOP-os Blt hívást, mégis tagadni próbálod amit a két szemeddel látsz?
Ettől függetlenül a spec tökéletesen lehetővé teszi, hogy olyan UEFI implementáció legyen valamely platformon, ahol a UEFI konzolhoz olyan simple text output tartozik, amely hardveres karakteres implementáció
Aha, elméletben. De a gyakorlatban mutass akár csak egyetlen olyan UEFI firmware-t, amin az STO ténylegesen külön implementáció (és nemcsak az UGA/GOP fölé csapott wrapper). Csak egyetlen egy ilyent mutass!

Ezen kívül a mai PC-s videokártyák nem is tudják hardveresen, a nem PC-s platformok meg soha nem is tudták a karakter+attribútum üzemmódot. Megismétlem: nem létezik hardveres támogatás, így hiába engedi a spec, nem létezik ilyen implementáció.
Az MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c file-ban elég sok ESC [ szekvencia szerepel.
És még azt is kevered, hogy mi az MdePkg és az MdeModulePkg. A kettő baromira nem ugyanaz, utóbbi NEM része az UEFI specifikációnak, és egyáltalán nem is biztos, hogy egy adott gyártó firmware-ében implementálva van. Mégis mit gondoltál, az, hogy "vendor specific" és az, hogy csak az "Appendix" említi, miért van?
VTUTF8RawDataToUnicode függvény a TerminalDxe-ben (pl).
Meséld már el, mi köze van ennek az EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL-hoz? Legalább annyit nyálazzál már ki a speckóból, hogy a "Dxe" mit jelent!
Nagyképűség nélkül ki merem jelenteni, hogy nem túl sok nálam jártasabb EFI szakértő lézeng a HUP-on. Nem sokan készítettek ugyanis komplett SDK-t nulláról EFI-re, még világviszonylatban sem, nemhogy HUP viszonylatban.
Olyan meg, aki Assembly-ben is írt EFI SDK-t, konkrétan csak egyetlen egy ember van rajtam kívül a világon (nem a POSIX-UEFI az egyetlen EFI SDK, amit írtam).

De ne azért hidd el, mert én mondom, hanem ezért, mert leellenőrzöd, amit mondok. Látni fogod, hogy igazam van (tudom, a hozzád hasonló TROLLoknak kimosták az agyát, hogy ne ellenőrizék az állítások igazságtartalmát, de azért próbáld csak meg, meg fogsz lepődni).

Soha nem vontam kétségbe a szakmai hozzáértésedet, ellentétben a közéleti mindenszrizmusoddal. A második bekezdés alapján viszont úgy látom, hogy az Orbán fóbiád már hitelteleníti a szakmaiságodat is.

Életem azon szakaszába léptem, amikor ha azt mondod nekem, hogy 1+1=5, akkor én elfogadom és leszarom, hogy hülye vagy.

Hüllyeségeket beszélsz. Azt ugye tudod, kinek próbálod itt osztani az észt?

Írtál te már bootloadert egyáltalán? Vagy EFI SDK-t? Én - veled ellentétben - mindkettőt írtam már.

Kifejezetten nemtelennek találom, hogy személyeskedni kezdtél; de legyen.

  • A Red Hat-en keresztül több évig UEFI Forum (és több munkacsoport) tag voltam (observing member, saját választásom szerint).
  • (Szintén a Red Hat-nél) az edk2-ben (főállásban) voltam:
    • több mint egy évtizedig fejlesztő,
    • jó pár évig évig több alrendszer co-maintainer-e,
    • jó pár évig a négy "community steward"-nak az egyike.
  • Amikor a projektből (először) kiléptem 2021 nyarán, akkor az én nevemet viselte a git history-ban a legtöbb commit (commit darabszámra), valamint én voltam az egyik top reviewer (szintén commit darabszámra).
  • Az edk2 wikibe több cikket is írtam, köztük olyan git workflow bemutatást is, amelyből a proprietary contributor cégek fejlesztői rendszeresen képezték magukat (és meg is szokták köszönni).
  • A Red Hat-nél heti-havi szinten egyeztettem a shim és a grub mindenkori fejlesztőivel.
  • Az edk2-ben (OVMF-ben) lévő virtio driver-ek és egyéb virtio infrastruktúra nagy részét én írtam, illetve én vezettem be. (A részleteket megnézheted a linkedin profilomon a Projects szekcióban. Ez a szakasz a CV-mnek egy kivonata; a CV-mben konkrét commit range-ek szerepelnek.)

git log --reverse -S lersek Maintainers.txt

Itt köszönjünk el egymástól. Köszönöm a beszélgetést; tanulságos volt.

Kifejezetten nemtelennek találom, hogy személyeskedni kezdtél; de legyen.
Egyetértek, csak épp te kezdted. Komolyan, azzal próbáltál vádolni, hogy keverem a dolgokat, mikor a hülye is látja, hogy az EDK az nem a referenciaimplementáció, hanem az EFI Development KIT rövidítése?

Az meg, hogy olyant próbáltál tagadni, amit az általam linkelt forrásban te magad is látsz, mindent elmond rólad.

Ahogy az is, hogy állításaidat - pl. EFI-s hardveres karakteres üzemmód létezhet - képtelen voltál alátámasztani, csak össze-vissza vádaskodtál. Hol a bizonyíték? Mutass egyetlen egy UEFI firmware-t, vagy akár csak egyetlen video kártya UEFI protokollt, ami támogatja a karakter+attribútum üzemmódot!

Akkor most személyeskedés nélkül is menni fog az ellenvélemény?

Íme olyan összeállítás, amit EFI-s és garantáltan karakteres felülete van / volt:

HP rx2600 és rx2620(*), valamilyen relatív korai iLO-kártya, rádugva HP 700/96-os soros terminál. És ezen a terminálom keresztül indítjuk az Itanium processzoros, HP-UX-et futtató gépeket.

Igen, EFI - és nem UEFI. Azaz még az U előtt. Szóval van, volt ilyen. (És hogy egyértelmű legyen, az újabb és kicsit komolyabb Itaniumos gépekben már UEFI volt, de a soros "konzol" azokon is eléggé elterjedt volt.)

(*) Ezek belépő szintű szerverecskék a maguk 2U magas rackesíthető, vagy álló űrhajóvá átalakítható kivitelükkel.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Kifejezetten nemtelennek találom, hogy személyeskedni kezdtél; de legyen.

Egyetértek, csak épp te kezdted. Komolyan, azzal próbáltál vádolni, hogy keverem a dolgokat

Az a kijelentés, hogy "tévedsz", vagy "kevered", nem személyeskedés; nem állít a személyedről semmit, nem téged minősít részemről. Nyelvtanilag egyes szám második személyben hangzik el, de a tartalma nem rád, hanem az általad közölt információra vonatkozik. Senki nem vádaskodott. Személyeskedni te kezdtél, amikor a tekintélyedre próbáltál hivatkozni:

kinek próbálod itt osztani az észt

illetve kétségbe vontad, hogy nekem milyen szakmai múltam lehet a UEFI kapcsán:

Írtál te már bootloadert egyáltalán? Vagy EFI SDK-t? Én - veled ellentétben - mindkettőt írtam már

A spec és az edk2 tárgyalásánál teljesen mindegy, hogy neked vagy nekem milyen UEFI-beli múltunk van.

Az meg, hogy olyant próbáltál tagadni, amit az általam linkelt forrásban te magad is látsz, mindent elmond rólad.

Az általad linkelt forrásban látottakat nem tagadtam; a linkelt forrás relevanciáját cáfoltam meg. Legfeljebb annyit mondhatunk el, hogy a legelső egyet nem értésemet nem fejtettem ki azonnal cáfolattá.

Ahogy az is, hogy állításaidat - pl. EFI-s hardveres karakteres üzemmód létezhet - képtelen voltál alátámasztani, csak össze-vissza vádaskodtál. Hol a bizonyíték? Mutass egyetlen egy UEFI firmware-t

Úgy számolom, hogy akkor ezen már túl vagyunk. (Fogj bármilyen szerver- vagy munkaállomás-osztályú gépet, amin van RS/232 port, és lehetőleg nem szándékosan lebutított platform firmware, és fogod tudni használni a UEFI Setup utility-t soros terminálról.)

vagy akár csak egyetlen video kártya UEFI protokollt, ami támogatja a karakter+attribútum üzemmódot

Ilyet természetesen nem tudok mutatni, de nincs is rá szükség.

Az interneten fennáll a veszélye annak, hogy a harsányan közölt, cáfolatlanul hagyott téves információkat a témában kevésbé jártas olvasók elhiszik. Így meggondoltam magam, és igyekszem -- tőlem telhetően tárgyilagosan -- cáfolni, ahol -- meggyőződése szerint -- téves információt közöltél.

Dehogy keverem, te beszélsz baromságokat. Az UEFI referencia implementációja a TianoCore, az EDK ahogy a neve is mondja (EFI Development Kit) pedig a fejlesztői környezete, interfész definíciókkal és segédfüggvénykönyvtárakkal meg minden.

A TianoCore és az EDK II egy és ugyanaz. Az elsőt főleg a közösség megnevezésére használják, az utóbbit főleg a kódbázis megnevezésére.

https://www.tianocore.org/

https://en.wikipedia.org/wiki/TianoCore_EDK_II

Az EDK II valóban azt jelenti, hogy EFI Development Kit II. A nevével összhangban ("Kit") különböző jellegű modulokat tartalmaz:

  • architektúra-, ISA-, platform-specifikus modulokat (könyvtárak, driver-ek),
  • ipari szabványoknak, specifikációknak közvetlenül megfelelő header-eket,
  • ipari szabványokban definiált viselkedésekhez referencia-implementációt (driver-ek, core modulok, appok),
  • általános utility-k (ezek is lehetnek driver-ek, library-k, appok),
  • kivételes esetekben teljes platform firmware-t is (pl. OvmfPkg).

Az, hogy mindkettőt ugyanaz a konzurcium adja ki, ne tévesszen meg. Nem én keverem itt a dolgokat.

Az "ugyanaz a konzorcium" kifejezés számomra értelmezhetetlen.

  • A UEFI Forum egy a UEFI specifikációt (és néhány rokon specifikációt) gondozó, szabványosítással foglalkozó testület.
  • A TianoCore közösség az EDK II (és arra épülő) projektek fejlesztésén, dokumentálásán dolgozik.

A két közösség metszete nem üres, de egyik sem részhalmaza a másiknak. Vannak cégek (főleg proprietary cégek), amelyek nagyon aktívak a UEFI Forum-ban (a szabványosításban), de az EDK II-t legjobb esetben is csak fogyasztják (vagy akár még azt sem), de nem fejlesztik. És vannak olyanok, akik az EDK II-t gőzerővel fejlesztik és/vagy használják, de a UEFI Forum-ban alig, vagy egyáltalán nem vesznek részt. Ez a különbség még az Intel fejlesztői csapatában is jól megfigyelhető; vannak, akik az EDK II-t fejlesztik koncentráltan, mások pedig főleg a UEFI Forum-ban, a spec. fejlesztésében dolgoznak leginkább. Nyilván az a legjobb, ha az ember/cég mindkettőben benne van.

Az EDK II egyébként rendelkezik nagy mennyiségű és részletes saját dokumentációval / specifikációkkal / whitepaper-ekkel, azonban ezek mind az EDK II-re vonatkoznak specifikusan, és függetlenek a UEFI Forum hivatalos specifikációitól.

A UEFI Forum mint szervezet a githubon a https://github.com/UEFI címen található meg. UEFI Forum-beli tagság nélkül -- ill. annak megfelelő github szervezeti tagság nélkül -- a szervezet legtöbb repója nem elérhető; mindenesetre itt folyik (most már) a specifikációk szerkesztése. A hivatalos spec-ek hibakövetése itt történik: https://mantis.uefi.org/. Amikor megnézed pl. a UEFI spec elején a Revision History-t, akkor az Issue # oszlopban szereplő azonosítók a Mantis hibajegyeket jelentik.

A TianoCore közösség mint szervezet a githubon a https://github.com/tianocore címen érhető el. Sok repójuk van, ezek közül a legfontosabb az EDK II. Az EDK II hibakövetője az idők során költözött. Hosszú ideig a bugzilla.tianocore.org domain-en élt; az ma már nincs, a githubon van az issue tracker; ma is láthatók benne a bugzilla migrációra utaló generált kommentek.

Az EDK II és a UEFI spec / PI spec / ACPI spec között létezik olyan átfedés, hogy pl. az MdePkg-be nem nagyon lehetet sokáig olyasmit betenni, amelyet először a UEFI Forum-ban nem standardizáltak. Ugyanakkor bármilyen szabványosítási törekvésnek csak akkor van értelme, ha létezik hozzá referencia implementáció. Ez így egy nehézkes, körkörös függőség volt; erre találták ki a Code First kezdeményezést.

UEFI applikációkat, mint pl. bootloadereket, mint pl. a grub-ot, általában véve a UEFI spec-re írnak, nem egy konkrét UEFI implementációra

az UEFI app-okat mindig SDK-ra írják, ami az EFI esetén az EDK2, vagy a GNU-EFI, vagy az általam fejlesztett POSIX-UEFI

Félreértettél. Én a driver-eknek / app-oknak nem a fejlesztői környezetéről beszéltem ("SDK"), hanem a futtató környezetéről. Az EDK II kódbázis -- mivel "Kit" -- tartalmaz mind driver- / app-fejlesztést támogató modulokat, mind UEFI referencia-implementációt (pl. Dxe Core). Én azt mondtam, hogy egy olyan app-ot, mint pl. a grub, a UEFI spec-ben megadott absztrakt interface-ekre fejlesztik, függetlenül attól, hogy a futtató környezetben a Boot Service-eket, Runtime Service-eket stb. egy edk2-alapú platform firmware fogja-e biztosítani, vagy valami teljesen független. Az teljesen más kérdés, hogy fejlesztéshez EDK2-t, GNU-EFI-t, vagy valami egészen mást használnak. Az UEFI egy ABI (bináris interfész).

A spec szerint az EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL a UEFI konzolnak a kanonikus megközelítési módja. Hogy ezt a protokollt konkrétan mi implementálja, és hogyan, az firmware belsőleges / implementációs kérdés

Nyilván nem hasznáhat akármit, csak másik UEFI protokollt (pl. UGA vagy GOP),

Nem értek egyet. A UEFI spec tudtommal semmilyen megkötést nem ad arra, hogy a platform firmware valamelyi DXE vagy UEFI driver-e, vagy esetleg egy device oprom-ból származó, hasonló driver milyen módon implementálhatja a Simple Text Out-ot. Pontosan ez a lényege a kiterjeszthetőségnek (az "E" betű a "UEFI"-ból): a viselkedés és a hívási konvenció specifikált, az implementáció a szállítótól függ.

ha a hardver driver nem tudja, mert nincs olyan interfész, amin keresztül tudhatná, akkor az EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL sem lesz képes rá

Én úgy látom, hogy következetesen figyelmen kívül hagytad eddig a soros terminálok kérdését, amelyek pedig működnek, és széles körben használhatók. Szerverosztályú platformokon lehet RS/232 porton (esetleg Serial-over-LAN-on) keresztül a UEFI Setup utility-t interaktívan használni. Volt olyan, hogy nekem itthon az irodámban 2-3 ilyen munkaállomás volt egyszerre; mindegyik "headless" módban, billentyűzet és monitor nélkül. A laptop-omba be volt dugva 3db USB-Serial adapter, és a screen-nel kapcsolódtam a /dev/ttyUSBx-re ahhoz, hogy az adott munkaállomáson a UEFI Setup-ot használjam. A másik hozzászólásomban lerajzoltam egy lehetséges protocol / driver stack-et, amely ilyet tud csinálni; a lényege annyi (már ha edk2-alapú platform firmware-ről beszélünk), hogy a TerminalDxe nyújt egy SimpleTextOut-ot a konzolt író/olvasó alkalmazás vagy driver számára, az adott SimpleTextOut implementációja pedig soros porti.

Ott van az orrod előtt a forrás, látod benne a GOP-os Blt hívást

Remélem, hogy nem vesztem el a hivatkozások között; ha jól értem, erre utalsz:

Amit a grub efitextmode.c-je használ, az az EFI_SIMPLE_TEXT_OUTPUT protokoll, ami pedig a háztető alatt az EFI_GRAPHICS_OUTPUT_PROTOCOL-t, azaz GOP-ot

Abban akkor megegyezhetünk, hogy a grub a SimpleTextOut-ot használja (pontosan ezt állítottam én is).

Viszont a link, amire a továbbiakban hivatkozol, irreleváns. Te egy UefiLib belső függvényre hivatkozol, aminek a grub-hoz semmi köze. A grub nem használ `UefiLib`-et, mivel (SDK értelemben) edk2-t sem használ egyáltalán. Az persze nem lehetetlen, hogy a nevezett UefiLib függvény valamilyen protokollnak az edk2 általi implementációjában is meghívásra kerül, a grub szempontjából ez viszont teljesen lényegtelen. A grub a SimpleTextOut-ot használja, amely pedig a UEFI spec szerint egy karakteres, absztrakt interfész. Hogy ennek a protokollnak adott platformon lehet GOP-ra épülő implementációja, az a grub szempontjából mindegy.

a gyakorlatban mutass akár csak egyetlen olyan UEFI firmware-t, amin az STO ténylegesen külön implementáció (és nemcsak az UGA/GOP fölé csapott wrapper

Rengeteg ilyen platform firmware létezik; jellemzően -- ha edk2 alapúról beszélünk -- a TerminalDxe produkálja a SimpleTextOut-ot, SerialIo-ra építve. Hogy aztán a SerialIo miféle (valódi soros port, vagy Serial-over-LAN), hogy konkrétan ilyen driver publikálja, az más tészta.

a mai PC-s videokártyák nem is tudják hardveresen, a nem PC-s platformok meg soha nem is tudták a karakter+attribútum üzemmódot. Megismétlem: nem létezik hardveres támogatás, így hiába engedi a spec, nem létezik ilyen implementáció

A videokártyákra vonatkozó állításodat nem tagadom, de egyszerűen nincs jelentősége. Sehol sincs megkövetelve, hogy SimpleTextOut alatt végső soron GPU-jellegű hardvert találjunk.

És még azt is kevered, hogy mi az MdePkg és az MdeModulePkg. A kettő baromira nem ugyanaz, utóbbi NEM része az UEFI specifikációnak, és egyáltalán nem is biztos, hogy egy adott gyártó firmware-ében implementálva van.

Természetesen nem keverem, hogy melyik mire való. De álljon itt két link a saját wiki-jükből:

Az MdePkg jellemzően az a package, amely a "minimális SDK" értelemmel bír; valóban szigorúan ragaszkodik az ipari szabványokhoz. Az MdeModulePkg pedig jellemzően a referencia-implementációja annak a funkcionalitásnak (jó pár extrával is, persze), amelyet a specifikációk (UEFI, PI) elvárnak.

Honnan is kanyarodtunk ide: azt írtad, hogy

Olyan kód, ami terminál CSI szekvenciákat értelmezne vagy állítana elő, egyáltalán sehol sincs a TianoCore-ban

Én ezt cáfoltam azzal, hogy

Az MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c file-ban elég sok ESC [ szekvencia szerepel

Teljes mértékben érvényes cáfolat. Az MdeModulePkg referencia implementáció a TianoCore-on (= EDK II-n) belül, a TerminalDxe egy olyan driver, amely SerialIo tetején nyújt SimpleTextOut-ot; más szóval: soros terminál. A forráskódja alapján pedig fel tud dolgozni jó pár CSI parancsot. A kérdéses függvény a UnicodeToEfiKey, és a dokumentációja úgy kezdődik, hogy

  Converts a stream of Unicode characters from a terminal input device into EFI Keys that
  can be read through the Simple Input Protocol.

  The table below shows the keyboard input mappings that this function supports.
  If the ESC sequence listed in one of the columns is presented, then it is translated
  into the corresponding EFI Scan Code.  If a matching sequence is not found, then the raw
  key strokes are converted into EFI Keys.

  2 seconds are allowed for an ESC sequence to be completed.  If the ESC sequence is not
  completed in 2 seconds, then the raw key strokes of the partial ESC sequence are
  converted into EFI Keys.
  There is one special input sequence that will force the system to reset.
  This is ESC R ESC r ESC R.

Folytatom:

Az UEFI-ben egyébként van UTF-8 termináltípusra támogatás (és az edk2 implementálja is):

https://uefi.org/specs/UEFI/2.11/10_Protocols_Device_Path_Protocol.html#vendor-defined-messaging-device-path

Mégis mit gondoltál, az, hogy "vendor specific"

Én úgy látom, hogy tévesen értelmezed a hivatkozott részt. A UEFI-ben rendszeresen előfordul, hogy valamilyen GUID mezővel lehetőséget adnak a vendor-nak, hogy valamiféle módon kiterjessze a rendszert. (Ezt egyébként az OVMF-ben és máshol gyakran használjuk is.) Ugyanakkor a specifikáció gyakran él azzal a lehetőséggel, hogy bevezet (mintegy "lefoglal") néhány GUID-ot szabványos célokra. Ebben az esetben is ez történik; a EFI_VT_UTF8_GUID egy ilyen GUID.

Rengeteg példa van erre a gyakorlatra; csak hogy kettőt említsek:

https://uefi.org/specs/UEFI/2.11/Apx_B_Console.html

 és az, hogy csak az "Appendix" említi, miért van?

Itt bizonyára arra célzol, hogy a függelék az nem normatív, hanem informatív. (Például a C szabványról ez elmondható; ott a függelékek egy része normatív, más része informatív.) Az UEFI spec-nél azonban nem ez a helyzet; a bevezető rész felsorolja a függelékeket is, és én nem látom jelét annak, hogy a függelékek ne lennének normatívak: https://uefi.org/specs/UEFI/2.11/01_Introduction.html#organization: Console requirements for a basic text-based console required by EFI-conformant systems to provide communication capabilities

Egyébként van a spec-ben egy olyan szakasz, amely kifejezetten az UEFI implementációra vonatkozó követelményekkel foglalkozik: https://uefi.org/specs/UEFI/2.11/02_Overview.html#platform-specific-elements

Itt azt írják, hogy amennyiben a rendszer nyújt konzol-eszközöket, akkor a SimpleTextIn, SimpleTextInEx, és SimpleTextOut kötelezőek.

VTUTF8RawDataToUnicode függvény a TerminalDxe-ben (pl).

Meséld már el, mi köze van ennek az EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL-hoz?

A SimpleTextOut-hoz valóban nem sok, az inputhoz viszont van. Ugyanis másik kommentedben írtad:

Minden olyasmi, hogy UTF-8 vagy stdout átirányítás, ebben lett implementálva, mert magától az EFI nem tud ilyent

A TerminalConInTimerHandler -> TranslateRawDataToEfiKey hívás során a soros FIFO-ban lévő byte-okat először unicode-ra, majd onnan EFI_INPUT_KEY-re alakítjuk. Az első lépés (FIFO -> unicode) függ a terminál típusától. Ha EFI_VT_UTF8_GUID szerepel a terminálhoz vezető device path-ban, akkor a FIFO -> unicode konverzió során UTF-8 szekvenciákat parse-olunk; ezt végzi a VTUTF8RawDataToUnicode.

Ezzel a megjegyzéssel azt kívántam jelezni, hogy tévedés az, hogy "magától az EFI nem tud UTF-8-at". Mert tud, mind a UEFI spec, mind az edk2 ref.impl. kezel UTF-8-at.

Legalább annyit nyálazzál már ki a speckóból, hogy a "Dxe" mit jelent!

Tudom, hogy mit jelent a Dxe; nem értem, miért hivatkozol itt rá ellenvetésként. Az EDK II-ben a nevezéktan része, hogy a futtatható modulokat megjelöljük az azokat futtató Platform Init fázisnak a nevével, esetleg a PI specben definiált modultípusukkal. A TerminalDxe driver a DXE fázisban töltődik be (mivel jellemzően a platform firmware része). A TerminalDxe ugyanakkor nem DXE driver, hanem egy UEFI driver, amely a UEFI driver modellt követi. Ez utóbbi azt jelenti, hogy az entry point függvényében csak a Component Name és Driver Binding protokollokat telepíti a driver, és a BDS (Boot Device Selection) fázisban, amikor a UEFI boot manager / Platform BDS, esetleg egy 3rd party driver vagy app, meghívja a ConnectController Boot Service-t, akkor kötődik eszközhöz, akkor kezd eszközt meghajtani.

De azt nem értem, hogy ez szerinted hol ütközik azzal, amit írtam.

Az interneten fennáll a veszélye annak, hogy a szándékosan keltett, harsány zajban a téves információkat a témában kevésbé jártas olvasók elhiszik.

Röviden: a sok hűhó ellenére egyetlen érvvel sem tudtad alátámasztani azon állításod, miszerint létezne hardveres karakter+attribútum képernyő üzemmód EFI alatt. Én állítom, hogy nincs, te pedig nem voltál képes ezt cáfolni.
(Nem mellesleg azért vagyok ennyire biztos a dolgomban, mert tapasztalatból tudom, hogy már jóval az EFI előtt, a VBE 2.0 idején kukázták a karakteres üzemmódot a VESA-ból. Ja, és ott áll feketén-fehéren az UEFI spec elején, hogy az 1024 x 768 pixeles üzemmód a minimum, azt mindenképp minden UEFI platformnak tudnia kell.)

Amit meg a terminálokról írsz, ad egy: mindvégig képernyő kimenetről volt szó, mi köze ennek bármiféle bemenethez? Ad kettő: a TerminalDxe nem arra van, hogy terminál emulátorként szolgáljon, hanem arra, hogy teminálokat szolgáljon ki (azaz megint, ebben is összekeverted a dolgokat, ez ugyanis a tty szerver és nem pedig a tty kliens). Ad három: ennek sincs semmi köze az EFI_SIMPLE_TEXT_OUTPUT-hoz, ami továbbra sem képes UTF-8-at értelmezni, sem pedig nem létező hardveres karakter+attribútum üzemmódot használni.

ps: és az ég szerelmére, nézz már utánna, mi a különbség a DevicePath és a protokoll között! Nem akarlak megbántani, de ha ennyire fogalmatlan emberek dolgoznak az edk2-n, az sok mindent megmagyaráz a minőségét illetően.

azon állításod, miszerint létezne hardveres karakter+attribútum képernyő üzemmód EFI alatt

Én sehol nem állítottam ilyet. A "karakter+attribútum" módszeren te pörögsz folyamatosan.

Amit az elején írtál, az annyi volt, hogy "UEFI alatt nincs karakteres képernyő", én pedig azzal reagáltam, hogy "Ez így nem pontos. UEFI alatt van szöveges konzol, ami lehet hardver karakteres". Ezt most is tartom, szó szerint: lehet hardver karakteres. A SerialIo felett implementált SimpleTextOutput-ot én hardver karakteresnek tekintem. De elvi akadálya annak sincs, hogy az általad ismételgetett "karakter+attribútum" módszert valaki visszahozza. A te kategorikus kijelentésed, hogy "UEFI alatt nincs karakteres képernyő", egyszerűen nem igaz, mert a UEFI spec egy ilyen "karakteres képernyő" lehetőségét szándékosan megengedi.

mindvégig képernyő kimenetről volt szó, mi köze ennek bármiféle bemenethez

Egy másik kategorikus kijelentésedhez kapcsoltam (lazán); ezt is idéztem már:

Minden olyasmi, hogy UTF-8 vagy stdout átirányítás, ebben lett implementálva, mert magától az EFI nem tud ilyent

Az, hogy "az EFI nem tud UTF-8-at", kategorikusan kijelentve nem állja meg a helyét.

ez ugyanis a tty szerver és nem pedig a tty kliens

Nem vitatom. (Mindenesetre a TerminalDxe.inf "Terminal module"-nak nevezi magát.)

mi a különbség a DevicePath és a protokoll között

Történetesen a device path is egy protokoll; mindenesetre értem, hogy mire gondolsz:

Ami esetleg elkerülte a figyelmedet, az az, hogy mielőtt a TerminalDxe installálja a SimpleTextOut-ot az új (és egyetlen egyetlen) child handle-re, akkor megvizsgálja (ahogy egy UEFI bus driver-től elvárjuk), hogy milyen device path protokollal rendelkező child handle előállítását várja tőle a hívó. Ebben a kért device path-ban van kódolva a terminál típusa, amely befolyásolni fogja a parser működését. A hívó így tudja explicite kérni (bár nem kötelező neki) a terminál típusát.

És akkor:

ha ennyire fogalmatlan emberek dolgoznak az edk2-n, az sok mindent megmagyaráz a minőségét illetően

Rendben; én kérek elnézést.

Arról nem is beszélve, hogy ha egy videókártya nem implmentálja a karakteres módot, akkor nem tekinthető VGA kompatibilis kártyának, ugyanis meglepő módon a VGA az egy szabvány, aminek konkrétan része a standard szöveges mód is.

Amúgy nem látom be, miért ne implementálná egy videókártya ezt a módot. Abszolút semmibe nem kerül, pixelszámban sehol nincs az átlag felbontáshoz képest, legfeljebb azt tudom elképzelni, hogy a mostani monitorok egy része kifreakel a rákba, ha kiváltasz konzol üzembe. De ez már nem a videókártyán műlik. Mivel a videókártya és a monitor amúgy elvi síkon képesek egymással megbeszélni, hogy ki milyen felbontást támogat, ezért lehet, hogy ha a monitor nem támogatja, nem abban indulunk el. De még csak fel sem kell találni a melegvizet újra, hiszen ez a felbontás amúgy közel negyven éve a szabvány része, és még az előtt is gyártottak videókártyát ilyen felbontással. Tehát a mai kártyák tudják legfeljebb nem használják, ami egy másik mondat.

(abba bele se menjünk, hogy semmibe se kerül emulálni egy alacsonyabb felbontást egy magasabbon...)

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-