FBUI: GUI a Linux kernelben

Kernel

Z Smith egy levelet küldött tegnap az LKML-re, amelben bejelentette, hogy egy olyan GUI-n (grafikus felhasználói felület) dolgozik, amely a Linux kernelben van megvalósítva. A kód kicsi, lehetővé teszi, hogy ablakokat tegyünk a Frame Buffer-alapú virtuális konzolokra, képes olvasni a billentyűzet bemenetet és kezeli az egér mutatót. A fejlesztő azért indította el a GUI a kernelben projektjét, hogy megállítsa a szoftver hízás (software bloat) tendenciát. A projekt már most használható. Képernyőkép:





A szerző összehasonlította az általa készített in-kernel szoftver komponenseket a X komponenseivel:


Tétel FBUI X-Windows
Core software size 26 kilobytes 1710 kilobytes
Library software size 17 kilobytes (optional) 1370 kilobytes (that's just Xlib; required) Window manager program size 30 kilobytes (fbwm, static link) 145 kilobytes (twm, dynamic link) Terminal emulator program size 38 kilobytes (fbterm, static link) 247 kilobytes (xterm, dynamic link) Analog clock program size 23 kilobytes (fbclock, static link) 29 kilobyte (xclock, dynamic link)




Az anyag az alábbi funkciókkal bír:


* Unlike X Windows, FBUI supports windows on every virtual console.

* Programs can receive keyboard input, either in raw mode or translated to ASCII by a library routine. One process is permitted to have keyboard focus.

* Each program is permitted only one window (in the current version).

* Windows may never overlap, providing faster execution and decreasing the memory needed to maintain windows.

* Each process can access its window simultaneously without being suspended. In X, the library has to send all drawing commands to the server, which puts them in a queue and executes them whenever it has a chance. If the server is busy, the application must wait. With FBUI, the ioctl takes a list of drawing commands that go directly to be executed if the window is visible and irregardless of what any other window is doing.

* Each virtual console can have its own optional window manager process.

* There's a sufficient set of drawing routines:

o draw point, line, horizontal line, vertical line, rectangle

o draw text

o clear, fill rectangle, clear rectangle

o copy area

o put pixels (native, 3-byte RGB, and 4-byte (unsigned long) RGB)

o get event

o the window manager process can hide and unhide other processes' windows, move, resize, re-expose, and delete windows.

o read point

* FBUI is currently written for 8,16,24, and 32-bit directcolor and truecolor. Later I will add 4-bpp VGA.

* Sample programs provided (also see screenshot):

o window manager

o JPEG image viewer

o terminal emulator (based on ggiterm)

o load monitor

o analog clock




Az patch letölthető a 2.6.8.1-es Linux kernelhez. Használata:


cd /usr/src/linux-2.6.8.1

cp ... fbui*.tar.gz

tar zxfv *.gz




A projekt honlapja itt. Az LKML bejelentés és szál itt.

( fidusz | 2004. 11. 01., h – 18:11 )

Ahhoz képest. hogy GUI-t csinál, még azt sem tudja, hogy nem X Windows, hanem X Window!

Sziasztok

A DOS Navigator pascal nyelven irodott (TurboPascal) aminek a forditoja 5.5-tol tamogatta objektum-orientalt programozast. Kesobb a 6.0-hoz a borland keszitett egy TurboVision nevu szoveges ablakkezelot (amire a sajat szovegszerkesztojet is raepitette) es nyilt forraskodon kiadta. Kivalloan retegezett, jol atgondolt osztaly-hierarchiaju rendszer es peldatlanul konnyu programozni. Azota jelent meg mar C++ valtozata is, elsosorban Linux ala. Messze odavag a ncurse-nek es a newt-nek. Csodalom, h nem erre epitkeznek akik "text feluleten ablakoznak".

Egyebkent tetszik az izlesed es jo, hogy felhoztad a DOS navigatort, mert tenyleg fantasztikusan jol megirtak. Technikailag es szolgaltatasaiban is az akkori igenyeknek megfeleloen a leheto legjobbat hoztak ki. Sajna a legtobb "fejleszto" ma mar nem igy gondolkodik. Ja es persze taps a Borlandnak szol a TVision-ert (kar, h a delphi kozel sincs ilyen jol tervezve). Abban az idoben egyebkent irtam egy grafikus valtozatat a TVision-nek amibe az osztaly-elnevezesek is egyeztek meg a legtobb metodus elnevezese es parameterezese is. Igy barmely TVision-be irt progit konnyen grafikus feluletre lehetett hegeszteni. Akar a DOS navigatort is at lehetett volna. Sajat alacsonyszintu drivereket is irtam kb. 10-12 kartyahoz assemblybe es ez felett futott az osszes tobbi cullang. Az ablakkezelo, mar a grafikus kartya fennmarado memoriajaba tarolt mindent ami barmikor kellhet. Az ablakkezeloje kepes volt detektalni az alatta levo terulet objektumait is, igy ha az ablakot bezartak akkor csak ujrarajzolta azokat az objektumokat amiket lefedett, nem pedig memoriat pazarolt. Ha tul sok objektumot fedett akkor inkabb memoriat foglalt a hatternek, de azt is tudta pixelesen gorgetni. Igy siman vegig lehetett huzni egy ablakot a kepernyon egy szutyok trident kartyaval is. Lenyeg, h fullra hegyeztem az aljatol a tetejeig. Grafikus nyomtatast is tudott, meg SB16 tamogatast is irtam hozza, ami aztan sosem volt hasznalva. Sajnos aztan ido szukebe nem lett befejezve.

A kernel grafikus ablakkezelojerol pedig annyit, hogy fontos lepes ez a kernel torteneteben. Azt tudni kell az XFree86-rol, h nem csak linuxon hanem sokminden mason is fut, tehat egyfajta "grafikus-crossplatform" retegkent is lehet ra tekinteni. Ebbol kifolyolag tartalmaz olyan elemeket is amik inkabb a kozos reteg kialakitasaert felelosek. Nem kimondottan a linuxhoz keszult, csak hozza lett igazitva! A masik, h kb 3x ujra lett mar irva es ennek ellenere is egyre attekinthetetlenebb a forraskodja. Ez inkabb betudhato annak, h egyre tobb unix,unix-like platformot akarnak tamogatni vele, es igy csak dagad az egesz. Ezert, ha az illeszteset nezem, akkor kozel sem lehet ramondani, h linuxbarat. Csak a nyilt forrasa es a unix kozelisege miatt csapodott hozza a linuxhoz. Az XFree86-ra valojaban lehetne ugy gondolni, mint egy ideig kolcson vett rendszer aminek a helyere most mar be kell epiteni az igazit. Mindig is kilogott a sorbol, es talan az egyetlen olyan hivatalos csomag ami a kernel megkerulesevel matatja a hardvert. Mondjuk neha ez is kivetel, mert pl a hozzatartozo DRI cuccok a kernelbe vannak agyazva!!! Meg van egy FrameBuffer is a kernelbe ami egy masik onallo grafikus illesztesi reteg. Ez mar linuxos fejlesztes, csak meg "gyerek". Tehat fele itt fele ott. Lenyeg a lenyeg, ha muszaki szemszogbol nezzuk sokkal tobb koze van a kernelhez a grafikus alrendszernek, mint barmi mashoz.

Tobbieknek: ha egy egyszeru grafikus folyamatjelzot akartok kitenni a kepernyore amikor bootoltok akkor csak ganyolassal lehet, mert a lilo-s resze is kulon vilag, meg a kernel felallasakor is mar kulon grafikus motor fut. Ha egy mezei linux telepitot akartok epiteni, akkor viszont keves a mostani framebuffer. Tehat mindenkeppen az XFree86-t kell beepiteni ami aze nem kis veszodseggel jar. Az XFree86 a jatekfejlesztoket sem ragadja el nagyon, mert iszonyu lassu es kb 5-6 fele illesztesi reteg keszult mar direct renderinhez es meg egyik sincs kesz. A sokfele interface-nek pedig az is hatranya, h mindenki a sajat szakallara fejleszt es nem igazan konnyu szabvanyositani. Szoval ideje volt mar belevagni. :) Jo az a FrameBuffer csak epiteni kell tovabb. Ki lehet venni kodokat az X-bol is (asszem az is GPL-es mint a kernel), mint pl az elsimitott karakterek amit egyuttall mas geometriai megjeleniteseknel is lehetne alkalmazni, nem csak karaktereknel es akar kulso kernel modulkent is futhatna. Ha betoltom a modult akkor kisimulnak a karakterek es a vonalak, ha kiveszem a modult akkor megint csipkesek lesznek, kinek, h tetszik. Az OpenGL is nyugodtan mehetne kulso kernel modulkent stb. Ha ilyen iranyba megy a fejlesztes akkor mar kesobb ra lehet epiteni egy QT-t, egy GTK-t, vagy ami kell.

Mindettol eltekintve az X is egy nagyon jol atgondolt rendszer, es kivallo a maga crossplatform szellemeben, eszembe sincs leszolni, de sztem a Linux-nak mar ideje onallo grafikus alrendszert epiteni, ha a kindoz baberjaira akar torni a desktop szferaba.

Az otlet tetszik es bele fogom magamat asni, mint otletadokent es ha idom engedi akar fejlesztokent is. :)

bocsi, h veletlenul elkuldtem neked privibe is :)))

Tudod én nem úgy gondoltam, hogy ez akkor most megoldás még hajhullás ellen is, és bizonyos rendszereken tényleg el tudom képzelni a használatát. És azt se feedjük el, hogy valószinűleg ez még egészen új project, frissi fejlesztés.

Még bármi jó is lehe belőle, nem kellene rögtön elásni... :)

( nevergone v | 2004. 10. 31., v – 11:46 )

Mondjuk szerintem azért teljesen ne mérjük össze a kettőt... hol tud ez annyit, mint mondjuk egy Gtk, vagy egy Qt... a más grafikus rendszerekkel való kompatibilításról (vágólap, stb.) és a többiről nem is beszélve. Persze biztos lesz majd egyszer ebből is "ablakkezelő"... csak hát saját alkalmazások is kellenek hozzá. Amúgy asszem a Gtk -nak is van framebufferben futó változata, igaz az nem kernel-space -ben fut.

De amúgy ötletesnek tartom, akinek kell, vigye... :)

Nem. :) Ez a TGViews. Nem publikaltam, abban az idobe meg maskepp gondolkodtam. Hmm... szep nagy penztarcam lesz... majd eladom. :) Aztan nem lett belole semmi mas csak nehany helybeli valalkozasba irt progikhoz adta a grafikus feluletet, koztuk volt egy vektorgrafikus progi is, ami aztan soha nem keszult el, mivel robbant a Win95 es egyket ev alatt jottek a "jobbnal jobb" progik, magyarul: buktam egy rendeset. A TWall-rol nem hallottam.

( anr | 2004. 10. 31., v – 12:55 )

Ez az igazi lightweight dekstop;-)))

Kérdés mikor sikerül annyira körbehackolni, hogy egy openoffice-t el lehessen rajta indítani.

Nem kunyerálni követelőzni a fejlesztők töl !!!

Hanem tanulni és csatlakozni kell közéjük. Azután be indíthatod a saját projektedet.!!!

Mindenki a saját ötletének vagy ami neki tetszik azzal van elfoglalva.

Éljen a szabad Demokratikus szoftver fejlesztő társadalom.

( godot v | 2004. 10. 31., v – 14:21 )

Ennek mi értelme.....

www.directfb.org

Gtk val, meg hw accel


Üdv

Godot

( drojid | 2004. 10. 31., v – 14:29 )

Ez... hogy is mondjam... szánalmas?

Mi ez? Egy másik win 1.0, power kernellel? Egy Linuxosított MenuetOS? Kb annyi értelmét látom, mint a grafikus, egérrel használható BIOSnak, szerintem már az is kihalt... A grafikus környezetek nem véletlenül nagyok... A racionálisabb cél inkább azok méretének és erőforráshasználatának normális beállítása, nem egy ilyen új izé fejlesztgetése... Házi feladatnak elmegy, ötöst adnék rá, de magyarázatokat gyártani, hogy ez azért kell, mert nagy az X... miserable...

Nem kizárt, hogy az embedded system fejlesztők erőforrás szükében szívesen használnának valami ilyesmit. Én is úgy gondolom, hogy ha valakinek ezzel van kedve szórakozni, akkor tegye :) Engem nem nagyon zavarna ha a kernel úgy támogatná a videokártyámat mint most a hang vagy hálókártyát, és nem kellene az óriási X a grafikus felület használatához. Az más kérdés, hogy a grafikus felület jelentősebb része ezzel nem lesz kisebb, hisz az ablakkezelők és a desktop környezetek továbbra is mammutok maradnak. A világnak össze kellene dobni egy nagyobb összeget, és felfogadni a DOS Navigátor fejlesztőit (remélem van itt valaki, akinek ez még mond valamit), hogy csináljanak egy rendes grafikus felületet. Nem tudom, hogy kik voltak, de az ő hozzáállásukat állítanám minden fejlesztő elé példaként :)

üdv

atya

OK, van egy pici géped, és ezt a dolgot használod... Mire?

Szövegxerkeszteni nem fogsz tudni, mert azoknak is nagy az erőforrásigénye (hacsak nem tesz a kernelbe emberünk egy mai formátumokat kezelni tudó irodai programcsomagot is), képnézegetéshez nem kell teljes grafikus felület egérrel, és folytathatnám még.

Én nagyon szeretem a beágyazott rendszereket, csodálom a pici rendszereket, én is építgetek ilyeneket, de ebből a szemszögből sem látom értelmét. Ha ablakozás, akkor legyen minél többet tudó, akkor is, ha nagy :-D Kicsi és beágyazott rendszerekre , amik nem bírják, ablakokat tenni... Nekem ez kicsit olyan, mint biciklire fotelt rakni. Persze lehet...

Aha. Más dolog kívülröl csodálni a beágyazott rendszereket, és más dolog dolgozni velük, használni őket. Szerintem, most igy jobban belegondolva megvan a maga létjogosultsága. El kellene felejteni azt a téveszmét, hogy ha grafikus felület, akkor az szövegszerkesztés, pasziánsz, meg hasonlók. Ilyet legfeljebb csak a "puhapöcsü" M$ "szakemberek" mondanak, mikor parasztvakításra kerül a sor. Igen, a mai egyre nagyobb tudású hardverelemektől fojtogató hatású légkörben is megvan az ilyen "minimalista" projectek szerepe. Aki pedig elhiszi az M$ szavát, az még nem dolgozott pl. a BusyBox -szal.

Szóval, jópárszor lehet olyan, mikor a grafikus megjelenítés bőven elég pár nyomógombból, keretekből, stb. De ezt minél kevesebb erőforrás felhasználásával kell ezt megalkotni. Az ilyen helyeken ez tökéletes lehet.

Nem tudom, Te el tudsz képzelni 100x100px képernyőn ablakos-tologatós-kattintgatós rendszert? Én bár el tudnék, nem akarok :-)

Én ezt most tényleg nem értem. Én úgy értettem, hogy az FBUI desktop gépeket céloz meg. Egy mobiltelefonba célszoftver kell, ami sokkal hatékonyabb és kisebb jó esetben, mint egy komplett linux kernel+fbui+ilyenolyan widgetek plusz alkalmazások. Szép és gyors és kattintgatós ezek nélkül is lehet.

Érdemes lenne gondolkodásban és "világnézetben" elszakadnod a PC -től , és a "klasszikus" x86 architektúrától. Pl. egy 100x100 -as (ami egy mobiltelefonnál vagy ipari berenedezésnél már jóval nagyobb, a PDA -król nem is beszélve) kijelzőn miért ne lehetne egy kis alap, minimalista, de mindenképpen grafikus rendszer...?

Szerintem te ennek nem akarod érteni a lényegét...

( Polesz v | 2004. 11. 01., h – 10:32 )

Minimális kernel jó kis fb-vel meg mplayer. Igazi multimédia központ :)

( arpi_esp v | 2004. 11. 01., h – 10:33 )

ez mindenkinek elkerulte figyelmet: ?

"Windows may never overlap"

azaz kb semmi ertelme az egesznek...

A'rpi

( Polesz v | 2004. 11. 01., h – 10:34 )

Jelen pillanatban az anyag nem tölthető le sajnos :(


"Hey folks, I'm in the process of revising FBUI to permit >1 windows per process, so please be patient and I'll have something to download in a couple days. Thanks."

Nem kerülte el, ezért hasonlítottam a win1.0-hoz.

Nevergone, Te terveztél már beágyazott rendszert, hogy ennyire hajtogatod, hogy szakadjak el az x86tól, mert az fbuinak ott van értelme? Én igen, és így mondom, hogy oda nem tennék, mert felesleges, óriási overhead. És attól még lehet grafikus...

(Csendben jegyzem meg, hogy a C64es GEOS felülete grafikus volt. Átfedő ablakokkal. >1 MHz-en. >64K RAMban. Biztos meg lehetne írni úgy is az FBUIt, hogy értelme legyen, csak az a fajta gondolkodás a szoftverfejlesztők többségéből kihalt, ami a C64es korszakban még megvolt.)

Abba gondolj már bele, hogy a project lényege beletenni az ablakozós rendszert a kernelbe, ezzel adva egy teljesen semmit sem tudó ablakozós rendszert. Nincsenek átfedő ablakok, mert nem akar memóriát pazarolni erre. Írhatsz hozzá pici alkalmazásokat, jaj de jó. Ha ügyes vagy, akkor fogsz írni egy 12k-s calculatort? Klassz, akkor a pici alkalmazások száma 7re nő.

Na mind1, szerintem sincs semmi értelme az egésznek.