Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: FlashBurn am 25. October 2010, 11:55
-
Um endlich mal wieder voran zu kommen wollte ich mein OS jetzt so gestalten das entweder nur eine Konsole (im Textmodus) oder ne richtige GUI geladen wird.
Ansich war es map geplant, das mein App-Server sich um die ganze GUI Geschichte kümmert, aber so würde ich jetzt nen App-Server und nen GUI-Server machen.
Problem ist mir will kein Grund einfallen wozu ich noch nen App-Server brauche ;)
Das einzige wäre vielleicht, wenn ich den App-Server die Konsolen verwalten lasse, so dass die Programme dann später (in 10 Jahren ;) ) auch problemlos auf der GUI laufen.
Was würde euch noch einfallen, was der App-Server machen müsste/sollte?
-
Hm, was soll denn ein App-Server überhaupt sein?
-
Hm, was soll denn ein App-Server überhaupt sein?
Naja, es war geplant das der das ganze GUI-Zeugs übernimmt (eventuell sowas wie nen WindowManager?), aber bei der jetzigen Planung brauche ich ja etwas was die Ausgabe auf dem Bildschirm übernimmt (Textmodus), aber so aufgebaut ist, dass das ganze auch unter einer GUI funktioniert.
Unter ner GUI würde ich das dann praktisch an den GUI-Server weiterleiten bzw. der App-Server übernimmt die Darstellung und Verwaltung der Konsolen in einem Fenster.
-
Warum wendet sich das Programm nicht direkt an den richtigen Server statt dass die Anfragen erst weitergeleitet werden müssen?
Standardein-/ausgabe sind ja wahrscheinlich sowieso nur zwei Pipes, bei denen es dem Programm egal sein kann, wer das andere Ende hat. Und irgendwelche speziellen GUI-Funktionen tun im Textmodus eh nicht.
-
Standardein-/ausgabe sind ja wahrscheinlich sowieso nur zwei Pipes, bei denen es dem Programm egal sein kann, wer das andere Ende hat.
Alle Dateien die per Libc geöffnet werden, werden bei mir wahrscheinlich über Pipes laufen.
Warum wendet sich das Programm nicht direkt an den richtigen Server statt dass die Anfragen erst weitergeleitet werden müssen?
Das Programm soll sich darum im Endeffekt nicht kümmern müssen bzw. soll die Daten immer an die gleiche Stelle schicken.
Es geht ja auch nur um die Initialisierung danach läuft alles über Pipes und wie du schon sagtest ist es dann egal wo die ankommen.
Es muss sich halt nur jemand finden der die Ausgabe übernimmt und am einfachsten ist es halt einen "Server" (weil der ja nicht wirklich viel macht) für die Konsole zu nutzen und einen für die GUI. Sprich intern würde ne Standardausgabe über den App-Server (Konsole) laufen und alles was etwas mit GUI zu tun hat würde über den GUI-Server laufen.
Ich dachte dann daran, das sich der GUI-Server, wenn er gestartet wurde, beim App-Server meldet und dieser dann die Daten nicht mehr ausgibt (Textmodus) sondern sie an den GUI-Server weiterreicht.
Die Performance sollte darunter nicht leiden.
Edit::
Laut dem C-Standard kann man ja eh nicht viel auf der Konsole machen, aber wie sollte man Funktionen zur Verfügung stellen um z.B. die Vorder- und Hintergrundfarbe zu ändern oder solche Sachen wie Midnight Commander zu ermöglichen?
-
Es geht ja auch nur um die Initialisierung danach läuft alles über Pipes und wie du schon sagtest ist es dann egal wo die ankommen.
Hm, wenn ich jetzt sage, der Aufrufer soll halt seine Deskriptoren vererben, mache ich mich unbeliebt, oder? ;)
Es muss sich halt nur jemand finden der die Ausgabe übernimmt und am einfachsten ist es halt einen "Server" (weil der ja nicht wirklich viel macht) für die Konsole zu nutzen und einen für die GUI. Sprich intern würde ne Standardausgabe über den App-Server (Konsole) laufen und alles was etwas mit GUI zu tun hat würde über den GUI-Server laufen.
Wenn der App-Server das sein sollte, was unter tyndur vterm ist, also die Implementierung der Textkonsole, dann stimme ich dir zu. Dann muss der aber nichts weiterleiten, sondern Programme verbinden entweder zum App-Server oder zur GUI, aber nicht beides.
Laut dem C-Standard kann man ja eh nicht viel auf der Konsole machen, aber wie sollte man Funktionen zur Verfügung stellen um z.B. die Vorder- und Hintergrundfarbe zu ändern oder solche Sachen wie Midnight Commander zu ermöglichen?
vt100-Escapesequenzen?
-
Hm, wenn ich jetzt sage, der Aufrufer soll halt seine Deskriptoren vererben, mache ich mich unbeliebt, oder?
Nope. Mit der Vererbung habe ich mich inzwischen abgefunden ;) Problem wird nur noch sein, wie ich das mit dem Vererben der Pipes mache, weil ja immer nur einer lesen und nur einer schreiben kann/darf.
Dann muss der aber nichts weiterleiten, sondern Programme verbinden entweder zum App-Server oder zur GUI, aber nicht beides.
Und genau letzteres soll halt nicht passieren, weil die App soll nicht wissen müssen ob der GUI-Server läuft oder nicht und wie würdest du es denn machen wenn du auf einer Konsole nen Programm laufen hast (meinet wegen nen Skript was gerade tyndur kompiliert) und auf ner anderen startes du den GUI-Server? Problem wäre ja dass alles was vom Skript gestartet wird, über die Konsole läuft, aber diese soll ja deiner Meinung nach die Daten nicht zum GUI-Server schicken.
vt100-Escapesequenzen?
Noch nie von gehört, muss ich doch direkt mal googlen.
-
Suche mal nach $TERM, vt100/vt102 (s/w) und vt200/vt220 (farbe) oder auch ANSI-Escape-Codesequenzen. Da wirst du hinreichend geholfen; eine ANSI-Implementation sollte hinreichen.
Du könntest natürlich auch direkt einen (primitiven) Grafiktreiber in deinen Kernel einbauen und deine Textkonsole direkt darauf aufbauen... ähnlich Linux-Framebuffer und KMS (Kernel Mode Setting). Dann sparst du dir den App-Server als Entscheidungsinstanz zwischen TUI und GUI. Wenn dein langfristiges Ziel Grafik ist, dann ist das eventuell ein gangbarer Weg.
Mit der Shadow-FB-Technik kann man übrigens auch VESA-Modi hinreichend schnell machen, ein paar zusätzliche MB RAM vorausgesetzt.
Gruß
-
Ich habe mir nochmal ein paar Gedanken gemacht und werde wahrscheinlich (wenn ihr mich nicht vom Gegenteil überzeugen könnt ;) ) nen Con-Server (oder auch Console-Server) und nen GUI-Server haben.
Ich werde, aber nicht vt100 und solche Sachen im Con-Server implementieren, sondern das muss die Shell machen (ist das unter POSIX nicht auch so?). Ich muss mir dann "nur" Gedanken machen, was ich alles zur Verfügung stellen will (Farbe setzen, Position setzen usw.).
Ich habe mir das dann so vorgestellt, das die Shell (egal welche) immer ne Pipe created und diese als Stdout für den Prozess "weitergibt". Der Prozess kann dann halt die Eigenheiten der Shell nutzen (z.B. ne vt100 Emulation) und die Shell "übersetzt" das ganze dann in "Aufrufe" für den Con-Server. So ist es möglich das ich mich weder um die Emulation (vt100) kümmern muss, noch das ich mich auf eine festlegen müsste.
Desweiter dachte ich dann daran, dass der GUI-Server sich beim Con-Server anmeldet und sagt "jetzt wird alles grafisch dargestellt" und der Con-Server kümmert sich dann um die ganze Fenster-Geschichte. So merkt das TUI-App gar nicht wo es gerade läuft, ob Text- oder Grafikmodus.
Das einzige was ich mir noch nicht überlegt habe, wie ich das dann mit der Eingabe mache, ob ich die auch über den Con-Server laufen lassen (wäre wahrscheinlich einfacher), weil sich ja im Grafikmodus auch ein wenig ändert. Da laufen ja nicht mehr nur Shell-Prozesse wo sich der Con-Server darum kümmert wer gerade im Vordergrund/Aktiv ist.
Wie groß sollte man eigentlich den Screenbuffer bei der Konsole wählen oder wie groß ist der allgemein?
-
Ich habe mir nochmal ein paar Gedanken gemacht und werde wahrscheinlich (wenn ihr mich nicht vom Gegenteil überzeugen könnt ;) ) nen Con-Server (oder auch Console-Server) und nen GUI-Server haben.
Ist auch ne Lösung, funktioniert so unter Linux, *BSD und anderen (konkret: deine GUI ist getrennt von der TUI).
Ich werde, aber nicht vt100 und solche Sachen im Con-Server implementieren, sondern das muss die Shell machen (ist das unter POSIX nicht auch so?). Ich muss mir dann "nur" Gedanken machen, was ich alles zur Verfügung stellen will (Farbe setzen, Position setzen usw.).
Nein, darum heißt die Variable auch $TERM - sie wird vom Terminal erzeugt und funktioniert daher für alle Anwendungen, die nicht Shell sind. Alternativ kannst du auch deine zur Verfügung gestellten Funktionen direkt exportieren und somit deinen eigenen Terminaltyp definieren. Du musst dann nur ncurses o.ä. erklären, wie man sie benutzt, dann sind alle ncurses-Applikationen sofort lauffähig. Die Shell hat damit garnichts zu tun, schließlich soll die Shell ja kein Fullscreen-Bunt-TUI-Programm sein, sondern der "mc". Es sei denn, du willst für JEDEN interaktiven Prozess immer die Hintergrundshell im Speicher haben...
Ich habe mir das dann so vorgestellt, das die Shell (egal welche) immer ne Pipe created und diese als Stdout für den Prozess "weitergibt". Der Prozess kann dann halt die Eigenheiten der Shell nutzen (z.B. ne vt100 Emulation) und die Shell "übersetzt" das ganze dann in "Aufrufe" für den Con-Server. So ist es möglich das ich mich weder um die Emulation (vt100) kümmern muss, noch das ich mich auf eine festlegen müsste.
Warum so kompliziert? Dein Con-Server stellt ein Terminal zur Verfügung, also sollte er auch brav announcen, von welchem Typ dieses Terminal ist. Im einfachsten Falle implementierst du deinen Con-Server so, dass er die grundlegenden ANSI/vt220-Sequenzen versteht und sparst dir den Rest der Arbeit.
Du musst ohnehin in jedem Falle Sachen wie Cursorpositition/Farbe/CLS/... implementieren und aus dem Characterstrom extrahieren. Ob die Steuerzeichen nun zu irgendwas kompatibel sind oder nicht, spielt keine Rolle.
Beachte übrigens auch, dass du nicht unbegrenzt viel Arbeit vom Kernel auf die Shell verlagern kannst oder auch solltest, schließlich möchtest du vielleicht irgendwann mal eine andere Shell haben als die erste (z.B. eine ash-Portierung)...
Desweiter dachte ich dann daran, dass der GUI-Server sich beim Con-Server anmeldet und sagt "jetzt wird alles grafisch dargestellt" und der Con-Server kümmert sich dann um die ganze Fenster-Geschichte. So merkt das TUI-App gar nicht wo es gerade läuft, ob Text- oder Grafikmodus.
Naja, wenn du virtuelle Terminals (wäre wohl ein eigener, kleiner Server bei dir) implementierst, kannst du ja jedes virtuelle Terminal entweder mit dem Con- oder dem GUI-Server verbinden. Weil: Was passiert, wenn dein GUI-Server ein Textprogramm oder ein Con-Server ein Grafikprogramm ausführen soll? Die Anwendungen sollten das schon wissen können, schließlich gibt es ja auch Anwendungen, die beides können (z.B. REGEDIT.EXE)...
Beim Umschalten des virtuellen Terminals werden dann Con- oder GUI-Server angewiesen, die Grafikhardware entsprechend so zu programmieren, dass Text- oder Grafikmodus dargestellt werden.
Randbemerkung: Textmodi gibt es nur bei (prä-)VGA und sind daher ohnehin hochgradig an die PC-Plattform gebunden / unportabel; außerdem sind Textmodi nur begrenzt UTF8-fähig und ein Relikt aus früheren Zeiten. Musst du das unterstützen? Ich denke, ich würde mir die Arbeit nicht machen wollen.
Das einzige was ich mir noch nicht überlegt habe, wie ich das dann mit der Eingabe mache, ob ich die auch über den Con-Server laufen lassen (wäre wahrscheinlich einfacher), weil sich ja im Grafikmodus auch ein wenig ändert. Da laufen ja nicht mehr nur Shell-Prozesse wo sich der Con-Server darum kümmert wer gerade im Vordergrund/Aktiv ist.
Wenn dein Con-Server sich um den Textmodus kümmert, hat er gefälligst im Grafikmodus die Finger von den Eingaben zu lassen. Denn dort gibt es so nette Erfindungen wie Fokus.
Die Eingaben solltest du bevorzugt über einen Eingabe-Server/-Multiplexer machen, denn du kannst ja auch Eingabegeräte jenseits der Tastatur anschließen (Joystick, Maus, Touchscreen, USB-Zweittastatur). Die sollten sich für das System nicht voneinander und von Tastaturen unterscheiden. Wenn du da eine gute Abstraktion einbaust, kannst du außerdem quasi-kostenlos eine Bildschirmtastatur implementieren, die dann nur in die Input-Queue injiziert.
Wie groß sollte man eigentlich den Screenbuffer bei der Konsole wählen oder wie groß ist der allgemein?
Der Screenbuffer im Textmodus ist üblicherweise (Grafikspeicher / num_virt_Terminals), wobei der Grafikspeicher bei VGA 64KB groß ist (bei MDA 4KB). Du kannst also höchstens 8 virtuelle Terminals haben, dann aber ohne HW-Scrolling und Screenbuffer.
Gruß,
Sebastian
-
Es sei denn, du willst für JEDEN interaktiven Prozess immer die Hintergrundshell im Speicher haben...
Sehr gutes Argument. Natürlich nicht.
Du musst dann nur ncurses o.ä. erklären, wie man sie benutzt, dann sind alle ncurses-Applikationen sofort lauffähig.
ncurses ist im Endeffekt genau sowas was ich gesucht habe, nur auf die schnelle konnte ich nichts finden wie das funktioniert. Ich meine damit woher weiß ncurses was es wie benutzen kann? Oder anders wenn ich bestimmte Excape-Sequenzen habe, dachte ich immer das hängt mit der benutzten Shell (deswegen mein Gedanke alles über die Shell machen zu lassen) zusammen ob da was sinnvolles am Monitor erscheint oder nicht.
Beachte übrigens auch, dass du nicht unbegrenzt viel Arbeit vom Kernel auf die Shell verlagern kannst oder auch solltest
Mit dem Kernel hat das alles rein gar nichts zu tun, aber du meinst bestimmt meinen Con-Server?!
Was passiert, wenn dein GUI-Server ein Textprogramm oder ein Con-Server ein Grafikprogramm ausführen soll?
Ich vermute mal das ist wieder zu Linux-haft gedacht ;)
Weder GUI- noch Con-Server führen ein Programm aus. Was ich meine ist, das ein Programm sich nicht darum kümmern brauchen soll, ob gerade der GUI-Server läuft oder nicht.
Ist es ein grafisches App "verbindet" es sich mit dem GUI-Server (oder gibt ne Fehlermeldung aus, das kein GUI-Server läuft) und ist es ein TUI-App verbindet es sich mit dem Con-Server, bzw. wird halt einfach alles über Stdout gemacht. Ich möchte aber nicht, das ein App sich darum kümmern muss, ob sie (sozusagen) die Ausgabe über den Con-Server oder über den GUI-Server machen soll (wenn es nur Stdout betrifft).
Randbemerkung: Textmodi gibt es nur bei (prä-)VGA und sind daher ohnehin hochgradig an die PC-Plattform gebunden / unportabel; außerdem sind Textmodi nur begrenzt UTF8-fähig und ein Relikt aus früheren Zeiten. Musst du das unterstützen? Ich denke, ich würde mir die Arbeit nicht machen wollen.
Anders gefragt, warum soll ich mir die Arbeit machen nen Grafiktreiber zu entwickeln, wenn ich erstmal nur Text habe, wenn das alles auch ohne Grafiktreiber läuft.
Mit Textmodus meine ich eigentlich das du nen Buffer hast wo du deine Zeichen und die Flags (Farben usw.) reinschreibst und das erscheint dann auf dem Bildschirm.
Gibt es das nicht auch auf anderen Plattformen?
Die Eingaben solltest du bevorzugt über einen Eingabe-Server/-Multiplexer machen, denn du kannst ja auch Eingabegeräte jenseits der Tastatur anschließen (Joystick, Maus, Touchscreen, USB-Zweittastatur). Die sollten sich für das System nicht voneinander und von Tastaturen unterscheiden. Wenn du da eine gute Abstraktion einbaust, kannst du außerdem quasi-kostenlos eine Bildschirmtastatur implementieren, die dann nur in die Input-Queue injiziert.
Genau so habe ich mir das vorgestellt. Allerdings hatte ich vorhin irgendwie nicht daran gedacht, wie man halt die Daten vom Input-Server zum richtigen Programm bekommt und daher wollte ich das über den entsprechenden Server leiten (Con oder GUI), weil der ja weiß welches "Fenster" gerade den Fokus hat.
Es wäre aber auch möglich einfach jedes Mal dem Input-Server mitzuteilen welches App gerade den Fokus hat, so spart man sich das umleiten.
Der Screenbuffer im Textmodus ist üblicherweise (Grafikspeicher / num_virt_Terminals), wobei der Grafikspeicher bei VGA 64KB groß ist (bei MDA 4KB). Du kannst also höchstens 8 virtuelle Terminals haben, dann aber ohne HW-Scrolling und Screenbuffer.
Ich denke mal du hast mich falsch verstanden. Ich meine den Softwarebuffer, sprich egal wie groß der Hardwarebuffer ist (z.B. nur eine Bildschirmseite) buffere ich das ja in Software nochmal. So dass ich dann immer, keine Ahnung vielleicht 4 Seiten habe?
Was die Anzahl der virtuellen Terminals betrifft, da wollte ich mir was einfallen lassen, dass man immer wieder ne neue/zusätzliche Shell starten kann (ich rede jetzt mal nur vom Textmodus) und dann zwischen diesen hin und her "zappen" kann.
Ich weiß nur noch nicht, wie ich das mit dem eine neue Shell starten machen soll.
-
Hallo,
ist es ein TUI-App verbindet es sich mit dem Con-Server, bzw. wird halt einfach alles über Stdout gemacht. Ich möchte aber nicht, das ein App sich darum kümmern muss, ob sie (sozusagen) die Ausgabe über den Con-Server oder über den GUI-Server machen soll (wenn es nur Stdout betrifft).
Die App erbt stdin/stdout/stderr und muss sich deswegen nicht darum kümmern woher das kommt (das trifft auch auf die Shell zu).
Was die Anzahl der virtuellen Terminals betrifft, da wollte ich mir was einfallen lassen, dass man immer wieder ne neue/zusätzliche Shell starten kann (ich rede jetzt mal nur vom Textmodus) und dann zwischen diesen hin und her "zappen" kann.
Ich weiß nur noch nicht, wie ich das mit dem eine neue Shell starten machen soll.
Das ist ein Feature das Dein "Con-Server" bieten muss. Wenn er will erstellt er eine neue Console (oder öffnet z.B. ne Serielle-Schnittstelle) und dazu neue stdin/stdout/stderr und startet dann einen Prozess für diese Console (üblicherweise ne Shell) welcher dann die 3 Streams erbt.
Also immer schön hierarchisch denken und das erben nicht vergessen. ;)
Grüße
Erik
-
Also immer schön hierarchisch denken und das erben nicht vergessen.
Was ich meine ist, ob man einfach ne Tastenkombination dafür nutzt oder ob man die Shell manuel starten muss (z.B. "/bin/bash").
Unter Windows z.B. bringt es dir gar nichts wenn du cmd.exe in der Aufgabeaufforderung aufrufst. Denn es wird kein neues Fenster erzeugt und unter Mingw bash/sh das gleiche.
-
Hallo,
Was ich meine ist, ob man einfach ne Tastenkombination dafür nutzt oder ob man die Shell manuel starten muss (z.B. "/bin/bash").
Hä, ich verstehe nicht was Du meinst.
Unter Windows z.B. bringt es dir gar nichts wenn du cmd.exe in der Aufgabeaufforderung aufrufst. Denn es wird kein neues Fenster erzeugt und unter Mingw bash/sh das gleiche.
Ist ja auch logisch, in der Eingabeaufforderung läuft bereits ne Shell (cmd.exe) und die hat stdin/stdout/stderr selber von dem Fenster geerbt bekommen (wie das ganz genau funktioniert weiß ich auch nicht aber die Doku zur WIN32-API sollte dieses Geheimnis lüften können, such dort einfach mal nach "CreateConsoleWindow" oder was ähnlichem) und vererbt das einfach an den neuen Prozess weiter. Das der neue Prozess wieder ne cmd.exe ist interessiert dabei nicht.
Grüße
Erik
-
Hä, ich verstehe nicht was Du meinst.
Ok, mein OS ist fertig gestartet und man findet sich in/auf einer Shell wieder. Jetzt will man aber noch eine Shell/"Fenster" öffnen. Wie man das lösen soll, das weiß ich halt noch nicht.
Ob man z.B. ne Tastenkombination nimmt (z.B. STRG+N) oder was mir lieber wäre, das man nen Programm aufruft und dem vllt die neue Shell als Parameter übergibt (so dass man auch verschiedene Shells starten kann).
-
Du musst dann nur ncurses o.ä. erklären, wie man sie benutzt, dann sind alle ncurses-Applikationen sofort lauffähig.
ncurses ist im Endeffekt genau sowas was ich gesucht habe, nur auf die schnelle konnte ich nichts finden wie das funktioniert. Ich meine damit woher weiß ncurses was es wie benutzen kann? Oder anders wenn ich bestimmte Excape-Sequenzen habe, dachte ich immer das hängt mit der benutzten Shell (deswegen mein Gedanke alles über die Shell machen zu lassen) zusammen ob da was sinnvolles am Monitor erscheint oder nicht.
Naja, unter Linux definiert dein Terminal $TERM und ncurses guckt dann in der Konfiguration nach, wie es mit diesem $TERM ("linux", "xterm", "vt220", ...) umzugehen hat, um möglichst effiziente Ergebnisse zu erzielen.
Weder GUI- noch Con-Server führen ein Programm aus. Was ich meine ist, das ein Programm sich nicht darum kümmern brauchen soll, ob gerade der GUI-Server läuft oder nicht.
Wieso? Wird doch eh von oberhalb vererbt.
Randbemerkung: Textmodi gibt es nur bei (prä-)VGA und sind daher ohnehin hochgradig an die PC-Plattform gebunden / unportabel; außerdem sind Textmodi nur begrenzt UTF8-fähig und ein Relikt aus früheren Zeiten. Musst du das unterstützen? Ich denke, ich würde mir die Arbeit nicht machen wollen.
Anders gefragt, warum soll ich mir die Arbeit machen nen Grafiktreiber zu entwickeln, wenn ich erstmal nur Text habe, wenn das alles auch ohne Grafiktreiber läuft.
Ein primitiver Grafiktreiber ist nicht wesentlich schwieriger (von den Textzeichen mal abgesehen) als ein guter Textmodus-Treiber, dafür aber wesentlich flexibler. Außerdem, wenn du ohnehin später eine GUI möchtest, profitieren deine Textanwendungen direkt von dessen Entwicklungen mit.
Mit Textmodus meine ich eigentlich das du nen Buffer hast wo du deine Zeichen und die Flags (Farben usw.) reinschreibst und das erscheint dann auf dem Bildschirm.
Gibt es das nicht auch auf anderen Plattformen?
Nein, die meisten Plattformen stellen dir nur einen dummen Framebuffer bereit, auf den du selbst zeichnen darfst. Oder die dortige Firmware stellt dir Funktionen zur Textausgabe bereit (oft auch für RS232). Einen VGA-ähnlichen Textmodus gibt es da normalerweise nicht.
Es wäre aber auch möglich einfach jedes Mal dem Input-Server mitzuteilen welches App gerade den Fokus hat, so spart man sich das umleiten.
Nö. Du möchtest auch systemweite Kürzel (z.B. SysRq oder virtuelles-terminal-wechseln) implementieren können, die direkt die grafische Oberfläche (den GUI-Server) betreffen. Also hat der Input-Layer an das virtuelle Terminal und damit an die gesamte grafische Oberfläche weiterzuleiten. Die darf dann selbsttätig die Inputs weiterverarbeiten. (Joystick-Eingaben gehen u.U. an andere Fenster als das mit dem Fokus, oder deine Sekundärtastatur ist nur für eine bestimmte XTerm nutzbar. Flexibilität.)
Der Screenbuffer im Textmodus ist üblicherweise (Grafikspeicher / num_virt_Terminals), wobei der Grafikspeicher bei VGA 64KB groß ist (bei MDA 4KB). Du kannst also höchstens 8 virtuelle Terminals haben, dann aber ohne HW-Scrolling und Screenbuffer.
Ich denke mal du hast mich falsch verstanden. Ich meine den Softwarebuffer, sprich egal wie groß der Hardwarebuffer ist (z.B. nur eine Bildschirmseite) buffere ich das ja in Software nochmal. So dass ich dann immer, keine Ahnung vielleicht 4 Seiten habe?
Da gibt es keine Grenzen. Im Textmodus solltest du dich aber auf den Hardwarebuffer beschränken, der ist schneller; im Grafikmodus kannst du dich auf z.B. 4 Seiten festlegen, sofern genug Grafikspeicher verfügbar ist.
Was die Anzahl der virtuellen Terminals betrifft, da wollte ich mir was einfallen lassen, dass man immer wieder ne neue/zusätzliche Shell starten kann (ich rede jetzt mal nur vom Textmodus) und dann zwischen diesen hin und her "zappen" kann.
Also die Anzahl der virtuellen Terminals kannst du auch unabhängig vom Video-RAM machen, wird dann halt nur langsamer.
Ich weiß nur noch nicht, wie ich das mit dem eine neue Shell starten machen soll.
Abstrahiere es weg und baue einen VTerm-Server, der sich um den Bildschirm kümmert und je nach Wunsch des Nutzers an einen GUI- oder einen TUI-Server weiterleitet.
In der grafischen Oberfläche musst du wissen, ob dein Programm ein Textmodusprogramm ist (Windows) und dann ein Konsolenfenster öffnen oder (Linux) du startest das Programm ohne stdin/stdout/stderr, weil es die unter der grafischen Oberfläche ja nicht gibt. Alternativ überwachst du mit einem Dummy-stdout und wenn es benutzt wird, dann startest du das Konsolenfenster bei Bedarf...
Ok, mein OS ist fertig gestartet und man findet sich in/auf einer Shell wieder. Jetzt will man aber noch eine Shell/"Fenster" öffnen. Wie man das lösen soll, das weiß ich halt noch nicht.
"man screen" ?
Ob man z.B. ne Tastenkombination nimmt (z.B. STRG+N) oder was mir lieber wäre, das man nen Programm aufruft und dem vllt die neue Shell als Parameter übergibt (so dass man auch verschiedene Shells starten kann).
Oder halt ein virtuelles Terminal (STRG+Links oder STRG+Rechts), wo du dich erneut einloggen kannst. Mittels "exec" ersetzt du die Shell dann durch dein Wunschprogramm (Posix-spezifisch).
Gruß
-
Naja, unter Linux definiert dein Terminal $TERM und ncurses guckt dann in der Konfiguration nach, wie es mit diesem $TERM ("linux", "xterm", "vt220", ...) umzugehen hat, um möglichst effiziente Ergebnisse zu erzielen.
Jetzt hast du mich komplett verwirrt ;)
Kann man unter Terminal nun eine Shell oder meinen Con-Server verstehen? Ich vermute mal eher letzteres.
Ein primitiver Grafiktreiber ist nicht wesentlich schwieriger (von den Textzeichen mal abgesehen) als ein guter Textmodus-Treiber, dafür aber wesentlich flexibler.
Ich gehe mal davon aus, das selbst Linux verdammt lange einfach nur die Ausgabe im "Textmodus" gemacht hat, weil es einfacher und schneller ist. Das ein guter Textmodus-Treiber flexibler ist, ist logisch und Portabilität steht im Moment ganz ganz weit unten auf meiner ToDo-Liste ;)
Nö. Du möchtest auch systemweite Kürzel (z.B. SysRq oder virtuelles-terminal-wechseln) implementieren können, die direkt die grafische Oberfläche (den GUI-Server) betreffen. Also hat der Input-Layer an das virtuelle Terminal und damit an die gesamte grafische Oberfläche weiterzuleiten. Die darf dann selbsttätig die Inputs weiterverarbeiten. (Joystick-Eingaben gehen u.U. an andere Fenster als das mit dem Fokus, oder deine Sekundärtastatur ist nur für eine bestimmte XTerm nutzbar. Flexibilität.)
Wenn ich dich richtig verstehe, würdest du also die Eingabe an den Con-Server und den GUI-Server (sofern dieser läuft) weiterleiten und diese sehen dann was sie damit machen, um eventuell die Daten an eine entsprechende App weiterzuleiten?
Im Textmodus solltest du dich aber auf den Hardwarebuffer beschränken, der ist schneller; im Grafikmodus kannst du dich auf z.B. 4 Seiten festlegen, sofern genug Grafikspeicher verfügbar ist.
Also ganz ehrlich, wieso sollte ich mich auf den Hardwarebuffer beschränken, das wäre ja quatsch (im Textmodus)? Wir reden hier davon 80*25*2= 4000bytes von einem Buffer irgendwo im RAM in den Hardwarebuffer zu kopieren und das sollte selbst auf nem P75 (kleinster unterstützter Pentium von mir) so schnell sein, das es nicht spürbar ist!
Was den Grafikspeicher angeht das selbe. Denn du kannst ja nicht sagen, tut mir leid noch eine Anwendung kann nicht gestartet werden, weil nicht genügend Grafikspeicher vorhanden ist, aber RAM habe ich noch verdammt viel frei!
In der grafischen Oberfläche musst du wissen, ob dein Programm ein Textmodusprogramm ist (Windows) und dann ein Konsolenfenster öffnen oder (Linux) du startest das Programm ohne stdin/stdout/stderr, weil es die unter der grafischen Oberfläche ja nicht gibt. Alternativ überwachst du mit einem Dummy-stdout und wenn es benutzt wird, dann startest du das Konsolenfenster bei Bedarf...
So ähnlich dachte ich mir das (letzteres). Nämlich das man immer Stdout/Stderr/Stdin mir gültigen Pipes versieht und der Con-Server macht erst nen neues Konsolenfenster auf, wenn auch was auf Stdout/Stderr ausgegeben wird (wird unter Windows auch gemacht, möchte ich meinen).
An das Vererben habe ich allerdings in diesem Fall wirklich nicht gedacht. Nur finde ich es einfacher wenn sich der Con-Server dann im grafischen Modus um die ganze Fenstergeschichte kümmert, als wenn ich das dann auch noch im GUI-Server machen müsste bzw. so könnte man dann auch andere Terminal-Emulationen ermöglichen ohne das ich das im GUI-Server habe.
Abstrahiere es weg und baue einen VTerm-Server, der sich um den Bildschirm kümmert und je nach Wunsch des Nutzers an einen GUI- oder einen TUI-Server weiterleitet.
Auf der einen Seite wäre es ein Server, aber ich würde es jetzt mal Programm nennen und die Idee gefällt mir, damit habe ich wieder alles aus dem Con-Server raus und in einem externen Programm drin. Somit könnte ich wieder mehrere Terminal-Emulationen zur Verfügung stellen ohne das alles an einem zentralen Ort sein müsste.
Ich weiß nicht ob es zuviel verlangt wäre, wenn ihr mir helfen könntet nen Interface bzw. die Funktionen die man benötigt (für den Con-Server, der allgemein bleiben muss um die Terminal-Emulationen zu ermöglichen) zu entwerfen?!
-
Hallo,
wieder etwas länger jetzt.
Naja, unter Linux definiert dein Terminal $TERM und ncurses guckt dann in der Konfiguration nach, wie es mit diesem $TERM ("linux", "xterm", "vt220", ...) umzugehen hat, um möglichst effiziente Ergebnisse zu erzielen.
Jetzt hast du mich komplett verwirrt ;)
Kann man unter Terminal nun eine Shell oder meinen Con-Server verstehen? Ich vermute mal eher letzteres.
Ein Terminal abstrahiert dir Tastatur und zeichenorientierten Bildschirm (guck dir ein Original DEC VT100 an, das ist ein "Terminal"). Wenn dein Con-Server das sein soll, dann abstrahiert er ein Terminal (oder mehrere). Ein Terminalemulator (z.B. xterm, rxvt, Eingabeaufforderung) stellt dir auch ein Terminal zur Verfügung. (Könnte man noch weiter ausführen, der Unterschied zwischen TTY [reales Terminal] und PTY [Pseudoterminal], aber tue ich jetzt nicht.)
Wie dieses Terminal funktioniert, meldet derjenige, der das Terminal erzeugt, an das System. Unter DOS ist das der Treiber CON (der ist dumm, es sei denn, du installierst ANSI.SYS o.ä.), unter POSIX wird dies im lokalen Environment automatisch angegeben (die Variable $TERM) - bei frühen Unixen wurde nach dem Login danach gefragt.
Die Shell ist eine Anwendung, die erstmal nur stdin/stdout/stderr kennt (also ein dummes Terminal z.B. Drucker, $TERM="dumb"). Interessant wird es erst, wenn du Programme startest, die mehr Zugriff auf den Bildschirm wollen (Cursorposition, Funktionstasten, Farbe und Attribute). Allein diese müssen nämlich mehr Informationen über den Terminaltypen bekommen - und den bekommen sie aus $TERM.
Ein primitiver Grafiktreiber ist nicht wesentlich schwieriger (von den Textzeichen mal abgesehen) als ein guter Textmodus-Treiber, dafür aber wesentlich flexibler.
Ich gehe mal davon aus, das selbst Linux verdammt lange einfach nur die Ausgabe im "Textmodus" gemacht hat, weil es einfacher und schneller ist. Das ein guter Textmodus-Treiber flexibler ist, ist logisch und Portabilität steht im Moment ganz ganz weit unten auf meiner ToDo-Liste ;)
Naja, inzwischen wird KMS eingeführt, weil man damit einmal einen moduswechselfreien Boot bis zur grafischen Oberfläche bekommt, außerdem kann man damit auch gleich die Kommunikation mit der Grafikkarte einbeziehen, da die unter Linux ohnehin über den Kernel läuft und Hardware-spezifisch ist.
Und es ist ein Zeichen, dass der Textmodus langsam überholt ist. Du findest so gut wie kein Linux, auf dem keine grafische Oberfläche installiert ist, sofern Tastatur und Bildschirm angeschlossen sind (d.h. reine Server mal ausgenommen).
Richtig ist, dass der Textmodus schneller ist, v.a. weil er weniger Speicher (und ~bandbreite frisst und Scrolling in Hardware funktioniert. Allerdings sind die Speicherbandbreiten stark gewachsen, die Grafikkarten haben genug Speicher und System-RAM ist auch genug da, dass man Double Buffering tun kann. Dann ist selbst ein VESA-Treiber hinreichend schnell. (Die meisten heutigen generischen VESA-Treiber machen kein Double Buffering, das gilt für den Windows-Standardtreiber und auch für 'vesa'. Darum sind die so langsam, vgl. hier (http://blog.fefe.de/?ts=b66558fc).)
Außerdem schrieb ich, dass der Grafiktreiber flexibler ist als der Textmodustreiber, denn der kann Grafik und andere Fonts und vernünftige Auflösungen. Schließlich ist 80x50 auch nicht das Ende der Geschichte gewesen. ;-)
Also hat der Input-Layer an das virtuelle Terminal und damit an die gesamte grafische Oberfläche weiterzuleiten. Die darf dann selbsttätig die Inputs weiterverarbeiten. (Joystick-Eingaben gehen u.U. an andere Fenster als das mit dem Fokus, oder deine Sekundärtastatur ist nur für eine bestimmte XTerm nutzbar. Flexibilität.)
Wenn ich dich richtig verstehe, würdest du also die Eingabe an den Con-Server und den GUI-Server (sofern dieser läuft) weiterleiten und diese sehen dann was sie damit machen, um eventuell die Daten an eine entsprechende App weiterzuleiten?
Jein, wenn dein Con-Server und dein GUI-Server gleichzeitig laufen, muss klar erkennbar sein, welcher jetzt gerade aktiv ist. Nur an den darf weitergeleitet werden. Ansonsten: exakt.
Im Textmodus solltest du dich aber auf den Hardwarebuffer beschränken, der ist schneller; im Grafikmodus kannst du dich auf z.B. 4 Seiten festlegen, sofern genug Grafikspeicher verfügbar ist.
Also ganz ehrlich, wieso sollte ich mich auf den Hardwarebuffer beschränken, das wäre ja quatsch (im Textmodus)? Wir reden hier davon 80*25*2= 4000bytes von einem Buffer irgendwo im RAM in den Hardwarebuffer zu kopieren und das sollte selbst auf nem P75 (kleinster unterstützter Pentium von mir) so schnell sein, das es nicht spürbar ist!
Korrekt, aber das wird dann umständlicher. ;-)
Was den Grafikspeicher angeht das selbe. Denn du kannst ja nicht sagen, tut mir leid noch eine Anwendung kann nicht gestartet werden, weil nicht genügend Grafikspeicher vorhanden ist, aber RAM habe ich noch verdammt viel frei!
Willst du also beliebig viele virtuelle Terminals installieren? Das wäre meiner Meinung nach überflüssig, denn (a) gibt es Programme wie "screen", welche dir auf einem virtuellen Terminal mehrere Terminals simulieren und per Tastendruck OS-unabhängig umschalten und diverse andere Magie machen, (b) brauchst du eigentlich nur 3-4 virtuelle Text-Terminals und ein GUI-Terminal und (c) werden sämtliche Text-Terminals überflüssig, wenn du eine Terminalemulation unter einer GUI laufen hast [und dadrin kannst du wieder "screen" aufrufen].
Der Textmodus ist eigentlich schon immer eine Krücke gewesen, seit es gebrauchbare 2D-Beschleuniger gibt.
In der grafischen Oberfläche musst du wissen, ob dein Programm ein Textmodusprogramm ist (Windows) und dann ein Konsolenfenster öffnen oder (Linux) du startest das Programm ohne stdin/stdout/stderr, weil es die unter der grafischen Oberfläche ja nicht gibt. Alternativ überwachst du mit einem Dummy-stdout und wenn es benutzt wird, dann startest du das Konsolenfenster bei Bedarf...
So ähnlich dachte ich mir das (letzteres). Nämlich das man immer Stdout/Stderr/Stdin mir gültigen Pipes versieht und der Con-Server macht erst nen neues Konsolenfenster auf, wenn auch was auf Stdout/Stderr ausgegeben wird (wird unter Windows auch gemacht, möchte ich meinen).
Der Con-Server sollte keine Fenster öffnen, sondern der GUI-Server. Der Con-Server könnte höchstens ein neues virtuelles Terminal öffnen, aber das fände ich etwas übertrieben. Textanwendungen haben ihr Terminal ja bereits.
An das Vererben habe ich allerdings in diesem Fall wirklich nicht gedacht. Nur finde ich es einfacher wenn sich der Con-Server dann im grafischen Modus um die ganze Fenstergeschichte kümmert, als wenn ich das dann auch noch im GUI-Server machen müsste bzw. so könnte man dann auch andere Terminal-Emulationen ermöglichen ohne das ich das im GUI-Server habe.
Ähm... der Con-Server hat sich aus der grafischen Umgebung rauszuhalten. Da gelten andere Konzepte. Der GUI-Server wiederum sollte keine Terminalemulation bieten, das ist Aufgabe einer Terminalemulator-Anwendung, die für den GUI-Server ein Fenster mit Fokus ist, für die Anwendung darunter ein (Pseudo-)Terminal.
Abstrahiere es weg und baue einen VTerm-Server, der sich um den Bildschirm kümmert und je nach Wunsch des Nutzers an einen GUI- oder einen TUI-Server weiterleitet.
Auf der einen Seite wäre es ein Server, aber ich würde es jetzt mal Programm nennen und die Idee gefällt mir, damit habe ich wieder alles aus dem Con-Server raus und in einem externen Programm drin. Somit könnte ich wieder mehrere Terminal-Emulationen zur Verfügung stellen ohne das alles an einem zentralen Ort sein müsste.
Löse dich von den verschiedenen Terminalemulationen. Die brauchst du nicht. Das betrifft einmal nur Textprogramme mit Bildschirmzugriff, und die nutzen entweder ncurses oder termcap oder sowas. Konfigurierst du einmal, tun alle Programme. Außerdem sind die bekannten Terminalemulationen größtenteils kompatibel zueinander. Implementiere ANSI (vgl. ANSI.SYS unter DOS, das Linuxterminal ist etwa kompatibel) oder vt220 (*BSD) im Kernel/Con-Server und gut ist. Alle anderen, nie benutzten Terminalemulationen implementierst du in einem Terminalemulator, der dann unter der grafischen Oberfläche läuft. (Dann kannst du auch erst was mit Textcodierungen anfangen, die z.B. Japanisch oder so darstellen, denn die passen so schlecht in den Standard-VGA-Font...)
Ich weiß nicht ob es zuviel verlangt wäre, wenn ihr mir helfen könntet nen Interface bzw. die Funktionen die man benötigt (für den Con-Server, der allgemein bleiben muss um die Terminal-Emulationen zu ermöglichen) zu entwerfen?!
Ich würde dir die ANSI-Escape-Codesequenzen ans Herz legen. Das ist hinreichend vollständig.
Soweit ich informiert bin, setzen alle Vollbild-Textmodusprogramme nur ein "CLS" voraus, und nutzen "Curserposition setzen"-Funktionen sehr extensiv aus, wenn diese vorhanden sind.
Wichtig ist, dass du dir eine Schnittstelle ausdenkst, wie du die Informationen über das Terminal an die darunterliegende Anwendung übergibst. Linux hat $TERM, aber auch $COLUMNS und $LINES für die Größenangaben, außerdem gibt es zu jedem Terminal eine Datei (wird angezeigt von "tty", sowas wie /dev/tty2 [terminal] oder /dev/pts/1 [pseudoterminal] oder /dev/tts/1 [serielle leitung]), auf die man dann Terminal-ioctls anwenden kann.
Gruß,
Svenska
-
Und es ist ein Zeichen, dass der Textmodus langsam überholt ist. Du findest so gut wie kein Linux, auf dem keine grafische Oberfläche installiert ist, sofern Tastatur und Bildschirm angeschlossen sind (d.h. reine Server mal ausgenommen).
Bitte nicht vergessen, das wir hier über ein Hobby-OS reden, das irgendwann mal auch nen GUI haben möchte und auf allem laufen soll ab P75 (mit ein paar Ausnahmen).
Von daher ist der Textmodus bzw. max grafischer Textmodus fürs erste das höchste der Gefühle (auch wenn man bei einem OS am liebsten mit der GUI anfangen würde ;) ).
Jein, wenn dein Con-Server und dein GUI-Server gleichzeitig laufen, muss klar erkennbar sein, welcher jetzt gerade aktiv ist. Nur an den darf weitergeleitet werden. Ansonsten: exakt.
Ok, sprich der GUI-Server meldet sich nicht nur beim Con-Server an, sondern auch beim Input-Server und dieser schickt alle Daten an den GUI-Server, welcher die Daten entsprechend weiterleitet.
Der Con-Server sollte keine Fenster öffnen, sondern der GUI-Server. Der Con-Server könnte höchstens ein neues virtuelles Terminal öffnen, aber das fände ich etwas übertrieben. Textanwendungen haben ihr Terminal ja bereits.
Das ist jetzt der Punkt wo ich schwanke. Auf der einen Seite wäre es schön, wenn ich sage das der Con-Server sich um die komplette Fensterverwaltung kümmert (damit meine ich nicht das er das Fenster "erstellen" soll, sondern er "zeichnet" sozusagen die Zeichen in das Fenster). Auf der anderen Seite, könnte ich den Con-Server komplett beenden wenn der GUI-Server erstmal läuft. Nur wird es dann auch schwieriger andere Dinge als Zeichen auszugeben (oder könnte man Funktionen wie CLS oder Cursor-Sachen auch als Escape-Sequenzen implementieren?). Auch würde es den Con-Server schlanker machen. Von daher wäre diese Variante eigentlich zu favorisieren!
Ähm... der Con-Server hat sich aus der grafischen Umgebung rauszuhalten. Da gelten andere Konzepte. Der GUI-Server wiederum sollte keine Terminalemulation bieten, das ist Aufgabe einer Terminalemulator-Anwendung, die für den GUI-Server ein Fenster mit Fokus ist, für die Anwendung darunter ein (Pseudo-)Terminal.
Jetzt wirds wieder unverständlich. Das Problem welches ich habe ist, das ich zwischen einem normalen Fenster und einem Konsolenfenster schon unterscheide und Vereinfachungen vornehmen würde. Deswegen ja die ganze Geschichte mit dem Con-Server zusammen.
Auch würde ich es nicht wollen, das die Terminal-Emulations-Anwendung zwischen TUI und GUI unterscheiden muss. Am liebsten würde ich das so transparent wie möglich halten. Also entweder übernimmt der Con-Server die Fenster-Sachen oder halt der GUI-Server.
Eine andere Frage wäre, wie läuft das denn unter Linux, kann man da auf ein Programm welches ncurses benutzt einfach nen Doppel-Klick machen und der richtige Terminal-Emulator wird aufgerufen oder klappt es nur so, das man nen Terminal-Emulator öffnet und dann erst das Programm starten kann?
Ist der erste Fall richtig, dann müsste ich ja die Terminal-Emulation schon in den Con-Server und/oder den GUI-Server packen, weil ich ja nicht ohne weiteres jedes Programm mit einem bestimmen Terminal-Emulator verbinden kann.
Oder verstehe ich da jetzt wieder was total falsch?
außerdem gibt es zu jedem Terminal eine Datei (wird angezeigt von "tty", sowas wie /dev/tty2 [terminal] oder /dev/pts/1 [pseudoterminal] oder /dev/tts/1 [serielle leitung]), auf die man dann Terminal-ioctls anwenden kann.
Blöd gefragt, was kann man denn alles mit den Terminal-ioctls machen? Oder anders wofür ist das gut (ich will ja eigentlich nicht das Konzept "alles ist eine Datei" umsetzen)?
-
Hallo,
jetzt wirds sehr lang.
Bitte nicht vergessen, das wir hier über ein Hobby-OS reden, das irgendwann mal auch nen GUI haben möchte und auf allem laufen soll ab P75 (mit ein paar Ausnahmen).
Von daher ist der Textmodus bzw. max grafischer Textmodus fürs erste das höchste der Gefühle (auch wenn man bei einem OS am liebsten mit der GUI anfangen würde ;) ).
Richtig: grafischer Textmodus. Drunter finde ich heutzutage unnötig.
Also dein Kernel startet den GUI-Server, dieser lädt einen Grafiktreiber (VESA). Dieser GUI-Server ist jetzt Eigentümer eines Bildschirms und stellt diesen bereit. Wenn du möchtest, kannst du die Fensterverwaltung (also Erzeugen/Zerstören von Fenstern, Verschieben, Fensterdekoration ...) auch im GUI-Server erledigen, wobei die primitive Variante einfach ein einziges Fenster über den gesamten Bildschirm erzeugt und darin eine Terminalemulation startet. Später kannst du daraus einen Full-Feature Window Manager machen.
Diese Terminalemulation stellt jetzt den Anwendungen ein Terminal nebst Informationen über dasselbige zur Verfügung, also vor allem Typ und Größe. Deine Shell wird nun von der Terminalemulation dort hineingeladen und erhält von ihr stdin/stdout/stderr, welche von der Terminalemulation abgefangen werden. Das Text-Zeichnen kannst du nach Wahl in der Terminalemulation oder im GUI-Server machen.
Das ganze Konzept kommt ohne einen Con-Server aus, da es keine reinen Text-Terminals (VGA-Textmodus) gibt. Die Terminals werden von einem Programm - dem Terminalemulator - zur Verfügung gestellt.
Für die Eingabegeräte gibt es einen Input-Server, der sämtliche Eingabegeräte abfragt und die Informationen an den GUI-Server weiterleitet. Dieser leitet die Eingaben, die nicht für ihn sind, in der primitiven Variante an den einzigen Terminalemulator weiter. (Wenn der GUI-Server zu einem Window Manager erweitert wird, leitet er z.B. an das Vordergrundfenster weiter.)
Mit diesem Ansatz sparst du dir zuerst mal das Hickhack, was du unter *BSD/Linux hast, wenn die grafische Oberfläche dem Textmodus ins Handwerk pfuschst und nebenher auch noch mehrere Terminalemulationen ("linux" im Textmodus, "xterm" in der Terminalemulation) und mehrere Grafiktreiber (VGA-Textmode oder vesafb oder KMS im Textmodus, der X11-Treiber im Grafikmodus) hast, die irgendwie verwaltet werden müssen. Das Konzept ist somit eine Mischung und am Anfang recht einfach umzusetzen, aber halt später auf eine GUI ausgerichtet.
Außerdem kämpfen dann nicht zwei Server um begrenzte Ressourcen (Con-/GUI-Server kämpfen sonst um Tastatur und Bildschirm) - es ist nur einer zuständig.
Ok, sprich der GUI-Server meldet sich nicht nur beim Con-Server an, sondern auch beim Input-Server und dieser schickt alle Daten an den GUI-Server, welcher die Daten entsprechend weiterleitet.
Ja. Beziehungsweise du klemmst dir den Con-Server komplett. (Wobei ich nicht wüsste, warum sich der GUI-Server beim Con-Server anmelden müsste. Es kann eh nur einer aktiv sein oder das Umschalten muss von extern geregelt sein.)
Das ist jetzt der Punkt wo ich schwanke. Auf der einen Seite wäre es schön, wenn ich sage das der Con-Server sich um die komplette Fensterverwaltung kümmert (damit meine ich nicht das er das Fenster "erstellen" soll, sondern er "zeichnet" sozusagen die Zeichen in das Fenster).
Das ist Aufgabe des GUI-Servers, denn der hat die Hoheit über den Grafiktreiber und je nach Grafikhardware lässt sich das Zeichenzeichnen hardwareseitig beschleunigen.
Auf der anderen Seite, könnte ich den Con-Server komplett beenden wenn der GUI-Server erstmal läuft. Nur wird es dann auch schwieriger andere Dinge als Zeichen auszugeben (oder könnte man Funktionen wie CLS oder Cursor-Sachen auch als Escape-Sequenzen implementieren?).
Genau diese Funktionen sind Steuerzeichen des Terminals und werden nicht direkt dargestellt, sondern ausgeführt. Guck dir mal ANSI-Sequenzen an und was man damit tun kann (z.B. hier (http://en.wikipedia.org/wiki/ANSI_escape_code), auch die Beispiele).
Auch würde es den Con-Server schlanker machen. Von daher wäre diese Variante eigentlich zu favorisieren!
Bei mir so schlank bis auf Null. Du kannst ja später zu Debugzwecken trotzdem einen CON-Server implementieren, der im VGA-Textmodus genau ein Terminal (80x25, ANSI) simuliert. In dem Moment, wo du den GUI-Server startest, sollte dieser inklusive aller enthaltenen Anwendungen beendet werden, da der GUI-Server einen eigenen Grafiktreiber lädt.
Wenn du das so hochziehst - also CON-Server für VGA-Textmodus und GUI-Server für Grafikmodus - bist du insofern auch von der Ausgabeschnittstelle unabhängig. Schließlich kannst du ja auch weitere Server starten, z.B. einen X-Server oder ein serielles Terminal, die dann natürlich unabhängig von CON- und GUI-Server sind.
Jetzt wirds wieder unverständlich. Das Problem welches ich habe ist, das ich zwischen einem normalen Fenster und einem Konsolenfenster schon unterscheide und Vereinfachungen vornehmen würde. Deswegen ja die ganze Geschichte mit dem Con-Server zusammen.
Ich würde da keine Unterscheidung vornehmen. Wenn du ein Textmodus-Programm ohne stdin/stdout/stderr startest, hat es halt keine Möglichkeit, damit zu arbeiten und gut. Für Hintergrundprogramme ist das durchaus gängige Praxis (Eingaben via Konfigdateien und Ausgaben via System-Log-Mechanismen).
Auch würde ich es nicht wollen, das die Terminal-Emulations-Anwendung zwischen TUI und GUI unterscheiden muss. Am liebsten würde ich das so transparent wie möglich halten. Also entweder übernimmt der Con-Server die Fenster-Sachen oder halt der GUI-Server.
Der Terminalemulator ist ein grafisches Programm, in ihm laufen Textprogramme. Wenn du grafische Programme darin startest, dann müssen diese sich selbst darum kümmern, ein Fenster zu erzeugen (indem sie sich z.B. beim GUI-Server melden). Das ist dann nicht mehr Aufgabe der Terminalemulation.
Ich unterscheide übrigens zwischen dem Terminal und dem Terminalemulator. Ersteres ist z.B. der VGA-Textmodus im CON-Server oder eine serielle Leitung mit vt100-Protokoll, auf der ausschließlich Textmodus stattfindet (und stdin/stdout/stderr immer existieren). Letzteres ist ein grafisches Programm, welches ein Terminal zur Verfügung stellt.
Eine andere Frage wäre, wie läuft das denn unter Linux, kann man da auf ein Programm welches ncurses benutzt einfach nen Doppel-Klick machen und der richtige Terminal-Emulator wird aufgerufen oder klappt es nur so, das man nen Terminal-Emulator öffnet und dann erst das Programm starten kann?
Nein. Startest du ein Textprogramm wie "mc" ohne Terminalemulator unter X11, dann läuft der zwar, kann aber nichts ausgeben, da er kein stdout hat. Da sämtliche Cursorbewegungen als Steuerzeichen im Terminal codiert sind, unterscheidet sich ein ncurses-Programm nicht von einem primitiven Programm wie "ls": beide nutzen stdout, um ihre Darstellung zu erledigen.
Du könntest natürlich ein Dummy-stdout bereitstellen und wenn da Daten auflaufen automatisch einen Terminalemulator starten und dem das stdout der Anwendung übergeben. Das wäre praktisch.
Programme, die grafisch sind, melden sich unter Linux beim X-Server an. Welcher das ist, erfahren sie wieder über eine Umgebungsvariable, in diesem Fall $DISPLAY. (Das geht auch über IP und somit quer durch ein Netzwerk, ich kann also meinen Firefox auf dem grafikkartenlosen Server in der Ecke starten und sehe das Fenster auf meinem kleinem Notebook.) Bei dir wäre das dann der GUI-Server.
Ist der erste Fall richtig, dann müsste ich ja die Terminal-Emulation schon in den Con-Server und/oder den GUI-Server packen, weil ich ja nicht ohne weiteres jedes Programm mit einem bestimmen Terminal-Emulator verbinden kann.
Die Terminalemulation ist Teil des Terminalemulators. Du kannst ja mehrere davon haben, einen der nur ANSI macht, einen der vt220 kann und einen dritten für IBM-Großrechner. Ergo hat die Terminalemulation im GUI-Server nichts zu tun.
Der sollte nur das Rendering selbst erledigen. (Alternativ lässt du das die Anwendungen selbst machen, das kannst du dir aussuchen. Dann muss der GUI-Server aber die Möglichkeiten bereitstellen, da gewisse Sachen ja hardwarebeschleunigt sein könnten.)
Oder verstehe ich da jetzt wieder was total falsch?
Ich hoffe, ich hab mein Konzept hinreichend ausführlich beschrieben und nicht wieder mit der Anlehnung an die mir bekannten Systeme alles verbrannt. ;-) Ich glaube, das Konzept ist auch hinreichend generisch/flexibel.
außerdem gibt es zu jedem Terminal eine Datei (wird angezeigt von "tty", sowas wie /dev/tty2 [terminal] oder /dev/pts/1 [pseudoterminal] oder /dev/tts/1 [serielle leitung]), auf die man dann Terminal-ioctls anwenden kann.
Blöd gefragt, was kann man denn alles mit den Terminal-ioctls machen? Oder anders wofür ist das gut (ich will ja eigentlich nicht das Konzept "alles ist eine Datei" umsetzen)?
"Alles ist eine Datei" ist aber praktisch. :-P
Allerdings kann ich dir diese Frage nicht beantworten. Wie da die Interna sind, weiß ich nicht.
Gruß,
Svenska
-
Das ist Aufgabe des GUI-Servers, denn der hat die Hoheit über den Grafiktreiber und je nach Grafikhardware lässt sich das Zeichenzeichnen hardwareseitig beschleunigen.
Da drücke ich mich wahrscheinlich falsch aus. Ich meine nicht das der Con-Server die Fenster zeichnet, sondern dass er sich um die ganzen Sachen kümmert die ein GUI-App so machen muss. Sprich es kommt ne Msg vom GUI-Server das mit der Maus in das Fenster geklickt wurde, diese Msg soll dann vom Con-Server bearbeitet werden usw. (was es da halt noch so alles an Msgs geben kann z.B. Fenstergröße hat sich geändert).
Diese ganze GUI-App Geschichte würde ich halt am liebsten von einem Terminal-Emulator fern halten, damit der im Textmodus und im Grafikmodus benutzt werden kann ohne das er sich darum selber kümmern muss.
Ich stelle mir den Terminal-Emulator so vor, das der Stdout zum Con-Server (oder GUI-Server) schickt und als Stdin bekommt er Daten von der Shell/dem Textmodus-App. Das einzige was er (der Emulator) machen soll ist die Escape-Sequenzen zu übersetzen, mehr nicht und dann kann er nämlich einfach als Vermittler im Text- und im Grafikmodus eingesetzt werden.
Solch eine Flexibilität wäre halt net bzw. Wiederverwendbarkeit.
Außerdem kämpfen dann nicht zwei Server um begrenzte Ressourcen (Con-/GUI-Server kämpfen sonst um Tastatur und Bildschirm) - es ist nur einer zuständig.
Deswegen ja die Anmeldesequenz des GUI-Servers. Der meldet sich beim Input-Server, dass er jetzt zuständig ist und nicht mehr der Con-Server und dem Con-Server sagt er das auch nochmal (bzw. (siehst du das dann weiter unten) "ersetzt" er den Con-Server für den Textmodus mit dem Con-Server für den Grafikmodus).
Wenn du ein Textmodus-Programm ohne stdin/stdout/stderr startest, hat es halt keine Möglichkeit, damit zu arbeiten und gut. Für Hintergrundprogramme ist das durchaus gängige Praxis (Eingaben via Konfigdateien und Ausgaben via System-Log-Mechanismen).
Ich weiß nicht wie das unter Linux läuft, aber unter Windows funktioniert es das man einfach nen Doppel-Klick auf nen Textmodus-App macht und dann öffnet sich ne Textkonsole (im Hintergrund läuft dann unter W7 conhost.exe, glaub ich).
Deswegen überlege ich halt wie ich das am besten Umsetze, da so eine Funktionalität schon nicht schlecht wäre, ich das aber auch gerne schon vorher geplant haben will, damit ich nachher nicht nen Rewrite machen muss.
Wenn ich deine Variante umsetze, dann muss ich im Grafikmodus immer erst nen Terminal-Emulator öffnen damit ich ein Textmodus-App ausführen kann (und auch was sehe) und dieser muss sich bewusst sein das er gerade im Grafikmodus läuft und das er dann die ganzen Fenster-Msgs handlen muss.
(Was mir in dem Zusammenhang noch einfällt, hat man unter Linux eigentlich ne Umgebungsvariable wo drinsteht welche Shell benutzt werden soll? Weil die müsste ja immer vom Terminal-Emulator mitgestartet werden.)
In dem Moment, wo du den GUI-Server startest, sollte dieser inklusive aller enthaltenen Anwendungen beendet werden, da der GUI-Server einen eigenen Grafiktreiber lädt.
Das hätte ich dann halt so lösen wollen, das der Con-Server dann (deswegen soll sich der GUI-Server beim Con-Server anmelden) für jede laufende Terminal-Emulation ein Konsolenfenster aufmacht und die Programme da drin dann einfach weiterlaufen als wäre nichts gewesen (deswegen auch Doublebuffering in Software).
Du könntest natürlich ein Dummy-stdout bereitstellen und wenn da Daten auflaufen automatisch einen Terminalemulator starten und dem das stdout der Anwendung übergeben. Das wäre praktisch.
Genau sowas wollte ich machen.
Also nochmal (nach dem ich hoffentlich geklärt habe was ich mit Fensterverwaltung meine).
Mein Problem ist einfach das ich den Con-Server gerne so gestalten würde, dass er keinen Code hat der was mit dem Grafischenmodus zu tun hat, aber ich will auch nicht das der GUI-Server sich um alles was mit nem Konsolenfenster zutun hat kümmern muss.
Der GUI-Server soll einfach nur Fenster verwalten und er soll zu jedem Fenster (ob nun Konsolenfenster oder "normales" Fenster) einen "Ansprechpartner" haben und genau den habe ich halt für Konsolen-Apps noch nicht gefunden.
Der Terminal-Emulator (wie oben geschrieben) soll einfach nur die Escape-Sequenzen übersetzen mehr nicht! Stell dir den Terminal-Emulator wie nen Druckertreiber vor, der keine "Ausgabe" (in dem Sinne das er nen Fenster oder sowas bräuchte) macht, sondern einfach nur von einer Sprache in eine andere Übersetzt. Das hätte auch den Vorteil, das ich dann einfach nur nen Doppel-Klick auf nen Terminal-Emulator machen muss (der so auch im Textmodus funktioniert) und der halt als Stdout ne Leitung zum Con-Server bekommt und ein neues Fenster aufgeht bzw. im Textmodus, würde dann halt ne neue virtuelle Konsole "aufgehen".
Das ganze würde jetzt darauf hinauslaufen, das ich einen Con-Server für den Textmodus habe (wo ich mir auch noch nicht sicher bin, wie dieser mit dem VGA-Treiber/Textmodus-Treiber kommuniziert) und einen Con-Server für den Grafikmodus habe, welcher dann halt dem GUI-Server sagt, dass er nen neues Fenster braucht und das sich dieser Con-Server (für den Grafikmodus) dann um die ganzen Msgs, die da so vom GUI-Server kommen, kümmert.
Ich könnte beim Terminal-Emulator sogar noch ums Vererben drumrum kommen, indem ich sage, der muss sich grundsätzlich erstmal beim gerade laufenden Con-Server melden und sich seine Stdout/Stdin holen.
-
Da drücke ich mich wahrscheinlich falsch aus. Ich meine nicht das der Con-Server die Fenster zeichnet, sondern dass er sich um die ganzen Sachen kümmert die ein GUI-App so machen muss. Sprich es kommt ne Msg vom GUI-Server das mit der Maus in das Fenster geklickt wurde, diese Msg soll dann vom Con-Server bearbeitet werden usw. (was es da halt noch so alles an Msgs geben kann z.B. Fenstergröße hat sich geändert).
Was hat der Con-Server denn mit der GUI zu tun? Ist das Entgegennehmen von Tastendrücken und Mausbewegungen nicht eher Aufgabe vom Terminalemulator?
Ich stelle mir den Terminal-Emulator so vor, das der Stdout zum Con-Server (oder GUI-Server) schickt und als Stdin bekommt er Daten von der Shell/dem Textmodus-App. Das einzige was er (der Emulator) machen soll ist die Escape-Sequenzen zu übersetzen, mehr nicht und dann kann er nämlich einfach als Vermittler im Text- und im Grafikmodus eingesetzt werden.
Genau. Aber für den Con-Server bleibt dann keine Aufgabe mehr, der müsste ja nur noch stdin/out an den Terminalemulator durchreichen. Das geht auch direkter.
Wie ich es mir am Anfang vorgestellt hatte, und wie ich denke, dass es Sinn ergibt, ist, dass der Con-Server sozusagen ein Textmodus-Terminalemulator mit eingebautem Textmodus-Grafiktreiber ist. ;)
Wenn ich deine Variante umsetze, dann muss ich im Grafikmodus immer erst nen Terminal-Emulator öffnen damit ich ein Textmodus-App ausführen kann (und auch was sehe) und dieser muss sich bewusst sein das er gerade im Grafikmodus läuft und das er dann die ganzen Fenster-Msgs handlen muss.
Das ist kaputt. Von den GUI-Nachrichten sollte die Anwendung überhaupt nichts mitbekommen. Der Terminalemulator soll daraus irgendwas vernünftiges machen, z.B. in Escapesequenzen umwandeln oder Signale schicken.
(Was mir in dem Zusammenhang noch einfällt, hat man unter Linux eigentlich ne Umgebungsvariable wo drinsteht welche Shell benutzt werden soll? Weil die müsste ja immer vom Terminal-Emulator mitgestartet werden.)
Man kann üblicherweise im Terminalemulator einstellen, welches Programm er starten soll. Und ansonsten hat ja jeder Benutzer in der /etc/passwd noch seine Defaultshell.
Der GUI-Server soll einfach nur Fenster verwalten und er soll zu jedem Fenster (ob nun Konsolenfenster oder "normales" Fenster) einen "Ansprechpartner" haben und genau den habe ich halt für Konsolen-Apps noch nicht gefunden.
Das ist der Terminalemulator, ein ganz normales GUI-Programm.
Der Terminal-Emulator (wie oben geschrieben) soll einfach nur die Escape-Sequenzen übersetzen mehr nicht! Stell dir den Terminal-Emulator wie nen Druckertreiber vor, der keine "Ausgabe" (in dem Sinne das er nen Fenster oder sowas bräuchte) macht, sondern einfach nur von einer Sprache in eine andere Übersetzt
Benenn das Ding um, unter Terminalemulator versteht keiner das, was du hier beschreibst. Ich sehe auch nicht, in welche Sprache dieser "Terminalemulator" übersetzen sollte. Auf der einen Seite vt100, klar, aber auf der anderen? Der Ansatz kommt mir im Moment wenig sinnvoll vor.
Das ganze würde jetzt darauf hinauslaufen, das ich einen Con-Server für den Textmodus habe (wo ich mir auch noch nicht sicher bin, wie dieser mit dem VGA-Treiber/Textmodus-Treiber kommuniziert) und einen Con-Server für den Grafikmodus habe, welcher dann halt dem GUI-Server sagt, dass er nen neues Fenster braucht und das sich dieser Con-Server (für den Grafikmodus) dann um die ganzen Msgs, die da so vom GUI-Server kommen, kümmert.
Wie gesagt, Con-Server für die GUI ergibt in meinen Augen keinen Sinn. Der Con-Server ist das, was im Textmodus das Terminal implementiert, in der GUI brauchst du sowas nicht.
-
Genau. Aber für den Con-Server bleibt dann keine Aufgabe mehr, der müsste ja nur noch stdin/out an den Terminalemulator durchreichen. Das geht auch direkter.
Ich will mir halt "ersparen" 2mal den selben Code zu schreiben. Deswegen soll der Terminal-Emulator ja auch nur so "wenig" können.
Der Con-Server hätte halt eine allgmeine "Sprache" in die übersetzt werden muss und der Con-Server verwaltet die ganzen Konsolen, sprich er weiß welche gerade im Vordergrund ist und leitet die Daten vom Intput-Server entsprechend weiter und er macht das ganze Double-Buffering.
Wie ich es mir am Anfang vorgestellt hatte, und wie ich denke, dass es Sinn ergibt, ist, dass der Con-Server sozusagen ein Textmodus-Terminalemulator mit eingebautem Textmodus-Grafiktreiber ist.
Den Terminal-Emulator will ich halt da raus halten und das der den Textmodus-Grafiktreiber mit integriert hat wird unter meinem OS nicht funktionieren.
Von den GUI-Nachrichten sollte die Anwendung überhaupt nichts mitbekommen. Der Terminalemulator soll daraus irgendwas vernünftiges machen, z.B. in Escapesequenzen umwandeln oder Signale schicken.
Die Anwendung bekommt davon auch nichts mit, es ging mir alleine um den Terminal-Emulator, dass dieser wissen muss ob er gerade im Textmodus läuft oder im Grafikmodus und läuft er im Grafikmodus müsste er sich um die ganzen Fenster-Msgs kümmern.
Das ist der Terminalemulator, ein ganz normales GUI-Programm.
Und genau das will ich halt so nicht machen. Für mich soll der Terminal-Emulator immer nur eine Art Übersetzer sein, nicht mehr und nicht weniger.
Ich sehe auch nicht, in welche Sprache dieser "Terminalemulator" übersetzen sollte. Auf der einen Seite vt100, klar, aber auf der anderen? Der Ansatz kommt mir im Moment wenig sinnvoll vor.
Der Terminal-Emulator soll von z.B. vt100 in eine allgemeine vom Con-Server unterstützte "Sprache" übersetzen. So halte ich mir halt die Möglichkeit offen noch andere Sachen als vt100 zu unterstützen ohne das ich das alles in ein Programm packen müsste. Ob das sinnvoll ist sei erstmal dahin gestellt.
Wie gesagt, Con-Server für die GUI ergibt in meinen Augen keinen Sinn. Der Con-Server ist das, was im Textmodus das Terminal implementiert, in der GUI brauchst du sowas nicht.
Ok, um es anders zu sagen. Ihr habt doch bei tyndur auch nen Terminal-Emulator (vterm), oder? Wie soll das dann irgendwann mal mit einer GUI laufen? Wollt ihr dann noch nen Terminal-Emulator für die GUI schreiben oder erweitert ihr euren bisherigen?
Worauf ich hinaus will, entweder man muss mehrere Terminal-Emulatoren schreiben, einen für den Textmodus und einen für den GUI-Modus oder man erweitert sein vorhanden Textmodus mit dem Code für den Grafikmodus.
Letzteres will ich nicht, da ich im Moment so plane, das man mein OS auch einfach nur als Konsolenvariante starten kann (so wie Linux ohne GUI-Krams). Ersteres will ich auch vermeiden, weil mal davon ausgehend, dass ich wirklich (ob das je so sein wird, ist mir erstmal egal) mehrere Terminal-Emulatoren habe, dann müsste ich ja für jeden 2 Varianten schreiben und beide Varianten hätten einen Teil des gleichen Codes (der "Übersetzer") und alle Terminal-Emulatoren hätten auch den gleichen Code (die ganze Fenster-Msgs Geschichte) und ich sehe es da halt so, einfach den gemeinsamen Teil von beiden Varianten in eine Stecken und den gemeinsamen Teil aller Emulatoren in etwas anderes auslagern (Con-Server).
Ich hoffe du kannst jetzt meine Motivation für dieses "Design" nachvollziehen.
-
Hallo,
Ich meine nicht das der Con-Server die Fenster zeichnet, sondern dass er sich um die ganzen Sachen kümmert die ein GUI-App so machen muss.
Was soll der Con-Server denn sein? Entweder die Benennung ist falsch oder ich kann nicht nachvollziehen, was er tun soll.
Entweder er kümmert sich um den Textmodus, oder er kümmert sich um den Textmodus und die Kommunikation mit dem GUI-Server. In letzterem Falle ist das Design kaputt. Oder soll er im Textmodus einen Textmodus-Treiber besitzen (und die Grafikkarte ansteuern und das Terminal bereitstellen und Escapesequenzen verarbeiten) und im Grafikmodus ein Terminalemulator sein (der dem GUI-Server sagt "mach ein Fenster", dadrin selbst die Zeichen malt, ein Terminal bereitstellt und die Escapesequenzen verarbeitet)?
Das ist unelegant, weil du damit den Terminalemulator auf exakt den gleichen Terminaltyp beschränkst, wie den Textmodus-eigenen und außerdem müsste dein Con-Server dann zusätzlich noch Ahnung von Grafik UND vom GUI-Server haben. Damit baust du Abhängigkeiten so zusammen, dass du später die einzelnen Module nicht mehr ersetzen kannst (was ja ein Hauptvorteil von meinem System ist). Plus: Der Con-Server wird wesentlich komplexer.
Sprich es kommt ne Msg vom GUI-Server das mit der Maus in das Fenster geklickt wurde, diese Msg soll dann vom Con-Server bearbeitet werden usw. (was es da halt noch so alles an Msgs geben kann z.B. Fenstergröße hat sich geändert).
Der GUI-Server sollte sich um die Fenster kümmern, nicht der Con-Server. Außerdem sollte der Input-Server seine Daten an den Server senden, der gerade für den Bildschirm zuständig ist - also entweder den Con-Server, wenn du im Textmodus bist, oder dem GUI-Server, wenn du im Grafikmodus bist.
Diese ganze GUI-App Geschichte würde ich halt am liebsten von einem Terminal-Emulator fern halten, damit der im Textmodus und im Grafikmodus benutzt werden kann ohne das er sich darum selber kümmern muss.
Ist deine Entscheidung. Genau das würde ich anders lösen - der Terminalemulator ist eine GUI-App.
Ich stelle mir den Terminal-Emulator so vor, das der Stdout zum Con-Server (oder GUI-Server) schickt und als Stdin bekommt er Daten von der Shell/dem Textmodus-App. Das einzige was er (der Emulator) machen soll ist die Escape-Sequenzen zu übersetzen, mehr nicht und dann kann er nämlich einfach als Vermittler im Text- und im Grafikmodus eingesetzt werden.
Also dein Textmodus (d.h. Con-Server) sollte garkeinen Terminalemulator besitzen, sondern direkt ANSI o.ä. implementieren. Das ist dann eine solide Basis, die auch gut auf die vorhandenen Hardwaremöglichkeiten mappt.
Im GUI sind zuviele Sachen anders, daher solltest du den Textmodus vom Grafikmodus vollständig trennen. (Du kannst ja meinetwegen eine von beiden Servern verwendete Lib bauen, die ANSI spricht.) Der Terminalemulator ist dann eine Anwendung für den Grafikmodus, der ein Terminal emuliert (daher der Name). Beide Terminaltypen (im Text- oder im Grafikmodus) sind übrigens nicht identisch: Im Grafikmodus kannst du vt100-Features wie doppeltbreite Schriftzeichen, fett, unterstrichen usw. verwenden, die du im Textmodus garnicht implementieren kannst.
Zumal dein GUI-Server sich primär um die GUI kümmern sollte und nicht um Textmodusprogramme. Das ist Aufgabe des Terminalemulators. Und dein Con-Server hat sich gefälligst um den reinen Textmodus zu kümmern und nicht um Textanwendungen, die in einem Fenster (verantwortlich: GUI-Server fürs Fenster, Terminalemulator für den Text dadrin) laufen. Das hängt vor allem mit dem Rendering zusammen, denn rendern tun entweder die Anwendungen selbst oder aber der GUI-Server. Niemand sonst.
Solch eine Flexibilität wäre halt net bzw. Wiederverwendbarkeit.
Naja, wenn du eine ANSI-Schnittstelle implementierst, dann kannst du die an beiden Stellen verwenden.
Außerdem kämpfen dann nicht zwei Server um begrenzte Ressourcen (Con-/GUI-Server kämpfen sonst um Tastatur und Bildschirm) - es ist nur einer zuständig.
Deswegen ja die Anmeldesequenz des GUI-Servers. Der meldet sich beim Input-Server, dass er jetzt zuständig ist und nicht mehr der Con-Server und dem Con-Server sagt er das auch nochmal (bzw. (siehst du das dann weiter unten) "ersetzt" er den Con-Server für den Textmodus mit dem Con-Server für den Grafikmodus).
Warum so kompliziert? Erstens sind dann Textmodus und Grafikmodus voneinander abhängig und zweitens muss dein Con-Server, der ja nur für den Textmodus zuständig sein sollte, auch noch Ahnung vom Grafikmodus haben. Wie willst du später TrueType-Fonts rendern - soll das auch der Con-Server machen? Da mappen dann Zeichenanzahlen nicht mehr auf Pixelbreite, was du bei jedem Textmodusprogramm aber als gegeben annehmen kannst. Du würdest den GUI-Server zur Fensterverwaltung und den Con-Server zum Rendering einsetzen, das ist doof.
Ich weiß nicht wie das unter Linux läuft, aber unter Windows funktioniert es das man einfach nen Doppel-Klick auf nen Textmodus-App macht und dann öffnet sich ne Textkonsole (im Hintergrund läuft dann unter W7 conhost.exe, glaub ich).
Unter Linux öffnet sich da nichts. stdin/stdout werden auf /dev/null gemappt, fertig. Bei Windows wird automatisch ein Terminalemulator geöffnet. Das kannst du halten, wie du möchtest.
Deswegen überlege ich halt wie ich das am besten Umsetze, da so eine Funktionalität schon nicht schlecht wäre, ich das aber auch gerne schon vorher geplant haben will, damit ich nachher nicht nen Rewrite machen muss.
Hatte ich beschrieben, du öffnest ein Fenster, wenn ein Textmodusprogramm ohne vorhandenes Fenster (also mit dummy-stdout) etwas ausgibt...
Wenn ich deine Variante umsetze, dann muss ich im Grafikmodus immer erst nen Terminal-Emulator öffnen damit ich ein Textmodus-App ausführen kann (und auch was sehe) und dieser muss sich bewusst sein das er gerade im Grafikmodus läuft und das er dann die ganzen Fenster-Msgs handlen muss.
Genau das ist Aufgabe eines Terminalemulators. Er ist kein Terminal, er emuliert eins. Außerdem ist der Terminalemulator ein Grafikprogramm und funktioniert ohne Grafikmodus garnicht erst. => Eingabeaufforderung oder xterm.
(Was mir in dem Zusammenhang noch einfällt, hat man unter Linux eigentlich ne Umgebungsvariable wo drinsteht welche Shell benutzt werden soll? Weil die müsste ja immer vom Terminal-Emulator mitgestartet werden.)
Wird sie auch. Entweder es wird die Standardshell des Benutzers verwendet (steht in /etc/passwd) oder es wird im Terminalemulator eine Anwendung konfiguriert (bei xterm mit "-e").
In dem Moment, wo du den GUI-Server startest, sollte dieser inklusive aller enthaltenen Anwendungen beendet werden, da der GUI-Server einen eigenen Grafiktreiber lädt.
Das hätte ich dann halt so lösen wollen, das der Con-Server dann (deswegen soll sich der GUI-Server beim Con-Server anmelden) für jede laufende Terminal-Emulation ein Konsolenfenster aufmacht und die Programme da drin dann einfach weiterlaufen als wäre nichts gewesen (deswegen auch Doublebuffering in Software).
Unhandlich, weil dann dein Con-Server (a) was von Grafik verstehen muss (b) mit dem GUI-Server kommunizieren muss.
Du könntest allerdings eine Schnittstelle definieren, über die der Con-Server bei seinem Ende sämtliche stdin/stdout/stderr-Tripel an den GUI-Server übermittelt und der sich dann darum kümmert, dass dafür neue Fenster geöffnet werden. Oder auch nicht, wenn bestimmte Programme nur im Hintergrund laufen und eh kein Fenster kriegen sollen (z.B. das Textmodus-Uhrzeit-Widget, was oben rechts die aktuelle Uhrzeit anzeigt - dafür brauchts kein Fenster).
Mein Problem ist einfach das ich den Con-Server gerne so gestalten würde, dass er keinen Code hat der was mit dem Grafischenmodus zu tun hat, aber ich will auch nicht das der GUI-Server sich um alles was mit nem Konsolenfenster zutun hat kümmern muss.
Das Konsolenfenster ist für den GUI-Server ein Fenster wie jedes andere und für das System eine Anwendung wie jede andere. Was da drin ist, ist Aufgabe des Terminalemulators. Fertig.
Der GUI-Server soll einfach nur Fenster verwalten und er soll zu jedem Fenster (ob nun Konsolenfenster oder "normales" Fenster) einen "Ansprechpartner" haben und genau den habe ich halt für Konsolen-Apps noch nicht gefunden.
Wer wäre es denn für nicht-konsolen-Apps?
Der Terminal-Emulator (wie oben geschrieben) soll einfach nur die Escape-Sequenzen übersetzen mehr nicht! Stell dir den Terminal-Emulator wie nen Druckertreiber vor, der keine "Ausgabe" (in dem Sinne das er nen Fenster oder sowas bräuchte) macht, sondern einfach nur von einer Sprache in eine andere Übersetzt.
Er soll also ANSI/vt100 in ... ja, in was eigentlich übersetzen? Im Textmodus in VGA-Speicherzugriffe und im Grafikmodus in Anweisungen für den GUI-Server? Würde ich trennen.
Das hätte auch den Vorteil, das ich dann einfach nur nen Doppel-Klick auf nen Terminal-Emulator machen muss (der so auch im Textmodus funktioniert) und der halt als Stdout ne Leitung zum Con-Server bekommt und ein neues Fenster aufgeht bzw. im Textmodus, würde dann halt ne neue virtuelle Konsole "aufgehen".
Definier lieber ein Protokoll zur korrekten Übergabe von Textanwendungen von einem Server zum anderen. Zumal du eh nur einen Server zu jedem Zeitpunkt aktiv hast (deine Grafikkarte kann gleichzeitig nur entweder Text oder Grafik ausgeben, außerdem ist das Umschalten bei speziellen Grafiktreibern schwierig) und du wahrscheinlich zwar viel mit Textanwendungen in Terminalemulatoren arbeitest (xterm, Eingabeaufforderung), aber eher selten gleichzeitig(!) noch mit Fullscreen-Textmodusanwendungen arbeitest (unter Windows nicht möglich, da es keinen Textmodus gibt; unter Linux wären das die 6 virtuellen Terminals auf Strg+Alt+F1-F6, auf der 7 läuft meist der X-Server).
Das ganze würde jetzt darauf hinauslaufen, das ich einen Con-Server für den Textmodus habe (wo ich mir auch noch nicht sicher bin, wie dieser mit dem VGA-Treiber/Textmodus-Treiber kommuniziert) und einen Con-Server für den Grafikmodus habe, welcher dann halt dem GUI-Server sagt, dass er nen neues Fenster braucht und das sich dieser Con-Server (für den Grafikmodus) dann um die ganzen Msgs, die da so vom GUI-Server kommen, kümmert.
Dann mach einen Con-Server, der ausschließlich Textmodus macht und den VGA-Textmodus-Treiber gleich integriert hat und einen GUI-Server, der sich ausschließlich um den Grafikmodus kümmert und den VGA-Grafikmodus-Treiber integriert hat und einen Terminal-Emulator, der Textmodus auf einer grafischen Oberfläche emuliert.
Was hat der Con-Server denn mit der GUI zu tun? Ist das Entgegennehmen von Tastendrücken und Mausbewegungen nicht eher Aufgabe vom Terminalemulator?
Naja, das sollte der Input-Server tun, die Ereignisse werden dann vom GUI-Server durchgekaut und an den Terminalemulator weitergereicht.
Wie ich es mir am Anfang vorgestellt hatte, und wie ich denke, dass es Sinn ergibt, ist, dass der Con-Server sozusagen ein Textmodus-Terminalemulator mit eingebautem Textmodus-Grafiktreiber ist. ;)
So meinte ich das.
Ich will mir halt "ersparen" 2mal den selben Code zu schreiben. Deswegen soll der Terminal-Emulator ja auch nur so "wenig" können.
Du hast im Grafikmodus aber wesentlich mehr Möglichkeiten, die eine eigene Implementation rechtfertigen können ("unterstrichen" geht bei VGA-Karten nunmal nicht).
Der Con-Server hätte halt eine allgmeine "Sprache" in die übersetzt werden muss und der Con-Server verwaltet die ganzen Konsolen, sprich er weiß welche gerade im Vordergrund ist und leitet die Daten vom Intput-Server entsprechend weiter und er macht das ganze Double-Buffering.
Oh, eine allgemeine Sprache. Noch eine. Warum nicht ANSI? Alle Anwendungen sprechen ohnehin ANSI (oder lassen sich mit ncurses so konfigurieren) und wenn dein Terminal nur ANSI versteht, dann reicht das doch aus. Du müsstest in dem Moment nur zwei Übersetzer bauen: ANSI=>VGAText und ANSI=>Framebuffer. Das erste macht dein Con-Server, das zweite macht dein Terminalemulator (der Fensterinhalt selbst ist ja ein Framebuffer mit z.B. 200x150px). Ich bezweifle, dass du da großartig Code teilen kannst.
Das ist der Terminalemulator, ein ganz normales GUI-Programm.
Und genau das will ich halt so nicht machen. Für mich soll der Terminal-Emulator immer nur eine Art Übersetzer sein, nicht mehr und nicht weniger.
Dann nenn ihn anders. Ein Terminalemulator ist ein GUI-Programm, welches in seinem Fenster ein Terminal emuliert. Nicht weniger.
Der Terminal-Emulator soll von z.B. vt100 in eine allgemeine vom Con-Server unterstützte "Sprache" übersetzen. So halte ich mir halt die Möglichkeit offen noch andere Sachen als vt100 zu unterstützen ohne das ich das alles in ein Programm packen müsste. Ob das sinnvoll ist sei erstmal dahin gestellt.
Ist es nicht. Deine Anwendungen sprechen durch die Bank weg ANSI/vt100 und das musst du darstellen. Wenn du plötzlich Anwendungen hast, die IBM3270 sprechen, dann musst du die auch darstellen. Also schreibst du am besten einen Wrapper von IBM3270 auf ANSI (was u.U. nur mit Einschränkungen möglich ist) oder aber du verzichtest für den VGA-Textmodus/Con-Server auf diese Möglichkeit. Für den Grafikmodus schreibst du dir dann einen Terminalemulator (die App!), welcher IBM3270 in sein Fenster rendert, weil dort kannst du es komplett flexibel machen. Und es dann als App umzusetzen, ist ohnehin sinnvoller.
Bedenke, dass du außer ANSI eigentlich nichts brauchst. Alle halbwegs modernen Textmodusanwendungen sprechen ANSI und etwas Neues wird es in dem Bereich nicht mehr geben, da der Textmodus durch den Grafikmodus ersetzt wurde. Windows unterstützt bis heute nur ein halbfertiges ANSI plus eine unvollständige Implementation der VGA-Textmodusregister in den Eingabeaufforderungen.
[...]
Ich hoffe du kannst jetzt meine Motivation für dieses "Design" nachvollziehen.
Ja, und ich halte es für relativ kompliziert, mit schlecht abgesteckten Aufgabenbereichen. Und vor allem zugeschnitten auf Textanwendungen, also unflexibel.
Ich kann verstehen, dass du "alles" anders machen möchtest als der Rest, aber manche Sachen sind halt einfach sinnvoll, wie sie anderswo eingesetzt werden.
Gruß,
Svenska
-
Ein Terminalemulator ist ein GUI-Programm, welches in seinem Fenster ein Terminal emuliert. Nicht weniger.
Dann hätten wir das also schonmal geklärt!
Da ich denke dich jetzt endlich verstanden zu haben, werd ich es einfach so machen, das ich nen "Terminal-Emulator" für den Textmodus schreibe (der ANSI kann) und dann viel später einen für den GUI-Server und damit fällt der Con-Server komplett weg.
Mein Textmodus-Terminal muss dann halt trotzdem ein wenig mehr können, sprich Double-Buffering und mehrere virtuelle Terminals.
Jetzt sollte ich (bzw. vorallem svenska ;) ) doch alles schön vereinfacht haben und ihr habt dem nichts mehr hinzuzufügen, oder?
Was auf keinen Fall geht, ist dass ein Programm nen Treiber enthällt, das wiederspricht absolut dem was ich mit meinem Treibermanagement vorhabe!
-
Hallo,
dein "Terminal-Emulator für den Textmodus" ist dein Con-Server, zumindest hatte ich das bisher so verstanden. Ob du den jetzt Terminal-Emulator nennst oder Con-Server, ist ja egal. Da der (in meiner Welt :-P) nur als Notnagel existiert, braucht der auch nicht viele nifty features, d.h. er lebt ausschließlich im VGA-RAM (64KB) und unterstützt (max) 6 virtuelle Terminals, je nach gewünschter Größe des Screen-Buffers, außerdem braucht er kein Double Buffering. ;-)
Was mir grad einfällt... wenn du den Terminal-Emulator als Anwendung realisierst, auch für den Textmodus, dann kannst du ihn später auch auf serielle Leitungen oder Telnet-/SSH-Verbindungen ansetzen. Diese sind ja auch "nur" Terminals (bzw. Pseudo-Terminals unter Linux). Das würde ihn auch vom VGA-Textmodus-Grafiktreiber trennen.
Andererseits hätte ich die Terminals wahrscheinlich direkt im VGA-Textmodus-Grafiktreiber erzeugt, d.h. im Textmodus läuft kein Terminalemulator, sondern der Grafiktreiber (Con-Server) IST das Terminal (bzw. die virtuellen Terminals). Das sind aber Implementierungsdetails.
Es macht Spaß, dich zu überzeugen. Besonders, wenn es auch mal klappt. ;-)
Gruß,
Svenska
-
d.h. er lebt ausschließlich im VGA-RAM (64KB) und unterstützt (max) 6 virtuelle Terminals, je nach gewünschter Größe des Screen-Buffers, außerdem braucht er kein Double Buffering.
Das ist meiner Meinung nach aber nicht wirklich portabel bzw. verlangst du dann ja vom VGA-Treiber (oder sonst was Treiber z.B. seriell) das er es ermöglicht das man mehrere Screenpages hat und auch mal zurück (nach oben) scrollen kann (was ich eigentlich schon gerne drin hätte).
Was mir grad einfällt... wenn du den Terminal-Emulator als Anwendung realisierst, auch für den Textmodus, dann kannst du ihn später auch auf serielle Leitungen oder Telnet-/SSH-Verbindungen ansetzen. Diese sind ja auch "nur" Terminals (bzw. Pseudo-Terminals unter Linux).
Ich dachte mir das dann so, das man dem Programm irgendwie sagen muss welches Gerät er für die Eingabe und welches er für die Ausgabe nutzt.
Da fällt mir gerade auf, das es schwierig wird mit den mehreren virtuellen Terminals das alles in einer Anwendung zu haben. Denn es wäre ja auch net, wenn eins von den virtuellen Terminals die Ein- und Ausgabe über ne serielle Schnittstelle macht, aber da ja schon die File-Handles 0-2 vergeben sind wird das nicht so einfach.
Hast du da vllt noch eine Idee? ;)
-
Gehst du nicht immer entweder auf ein richtiges Terminal oder auf die serielle Schnittstelle? Du brauchst doch nicht beides gleichzeitig?
Und Svenskas Vorgaben, dass das Textmodusterminal nichts können darf, halte ich auch für Blödsinn. ;)
-
Ich dachte, dass du am einfachsten für jedes reale Terminal (welches entweder vom VGA-Textmodustreiber oder vom seriellen Treiber oder vom graf. Terminalemulator bereitgestellt wird) einen neuen virtual-Terminal-Serverprozess startest. Jeder dieser Prozesse hat ein eigenes stdin/stdout und kann das somit auch verwalten.
Das Programm darf nicht wissen müssen, auf welchem Gerät es ausgeführt wird: Terminal ist Terminal, egal ob Emulator in der GUI, Serielle oder VGA-Textkonsole.
Wenn der VGA-Treiber mehrere virtuelle Terminals bereitstellt, darf er das gerne tun. Der Treiber für die seriellen Terminals stellt halt nur ein virtuelles Terminal bereit, das heißt es gibt keine Umschaltung. Und Scrollback findet bei seriellen Leitungen immer auf der Gegenseite statt, wird also auch nicht gefordert.
Das wäre eine Abstraktion "Terminal", die auf verschiedene Basistreiber (VGA, Seriell, "Pseudo") zugreift.
Ich schrieb übrigens nichts von "nicht können dürfen", sondern eher "nichts können müssen". ;-)
Gruß ^^
-
Gehst du nicht immer entweder auf ein richtiges Terminal oder auf die serielle Schnittstelle? Du brauchst doch nicht beides gleichzeitig?
Naja, ich dachte halt an die Situation, dass im virtuellen Terminal 1 ne normale Shell läuft und auf dem virtuellen Terminal 2 läuft halt irgendeine Session über die serielle Schnittstelle (wo die Ausgabe von der seriellen Schnittstelle auf dem Bildschirm erscheint und die Eingabe die du im Terminal machst wird halt ans andere Ende der seriellen Verbindung geschickt und auf dem Bildschirm gezeigt).
Genauso sollte es dann auch möglich sein mit einem Headless System (eins ohne Bildschirm oder Ausgabe auf diesem) über ne serielle Schnittstelle zu interagieren (dazu muss ja trotzdem nen Terminal laufen).
Und Svenskas Vorgaben, dass das Textmodusterminal nichts können darf, halte ich auch für Blödsinn.
Ich weiß schon gar nicht mehr was er damit meinte, aber sowas wie Farbe und ANSI-Codes soll es schon können.
-
Ich dachte, dass du am einfachsten für jedes reale Terminal (welches entweder vom VGA-Textmodustreiber oder vom seriellen Treiber oder vom graf. Terminalemulator bereitgestellt wird) einen neuen virtual-Terminal-Serverprozess startest. Jeder dieser Prozesse hat ein eigenes stdin/stdout und kann das somit auch verwalten.
Ich will eigentlich nicht das der serielle Treiber (als Bsp.) nen Terminal bereitstellt, sondern der soll nur Daten empfangen oder senden, nicht mehr.
Das selbe gilt für den VGA-Textmodetreiber. Solange ich mich im Textmodus befinde, soll der nur 16-bit Wörter erhalten die er dann einfach in den Hardwarebuffer kopiert. Dazu muss er noch die Möglichkeit bieten, CLS und ein paar Cursor-Sachen machen zu können, aber die Terminalverwaltung soll er nicht machen.
Die Lösung zwecks des Eingabe/Ausgabe Problems könnte folgendes sein. In jedem virtuellen Terminal läuft irgendein Programm (also auch in dem das über die serielle Schnittstelle kommuniziert). Ich würde jetzt einfach ne neue Pipe für jeweils Stdout/Stderr/Stdin aufmachen und die an den Prozess als Stdout/Stderr/Stdin weiterreichen.
So kann ich einfach die serielle Schnittstelle öffnen und die Daten in die Pipe für Stdin reinschreiben und die Daten die aus der Pipe für Stdout kommen, werden einmal auf dem Bildschirm ausgegeben und einmal an die serielle Schnittstelle geschickt (bzw. umgedreht bin da gerade etwas verwirrt).
Das gleiche mit nem normalen Terminal. So kann ich auch Double-Buffering betreiben und kann die Verwaltung übernehmen (welches Terminal die Eingabe bekommt, also im Vordergrund ist usw.) und muss das nicht in irgendeinem Treiber haben.
Das liese sich auch alles wunderbar parallelisieren (in Threads) und die Ausgabe läuft weiter ohne dass das Terminal im Vordergrund sein muss.
-
Naja, ich dachte halt an die Situation, dass im virtuellen Terminal 1 ne normale Shell läuft und auf dem virtuellen Terminal 2 läuft halt irgendeine Session über die serielle Schnittstelle (wo die Ausgabe von der seriellen Schnittstelle auf dem Bildschirm erscheint und die Eingabe die du im Terminal machst wird halt ans andere Ende der seriellen Verbindung geschickt und auf dem Bildschirm gezeigt).
Nope, das ist Unfug. Wenn du auf deinem Rechner eine Terminalemulation möchtest, die mit der seriellen Schnittstelle agiert, dann hat das gefälligst ein Programm zu tun, was die serielle Schnittstelle und ihre Eigenheiten kennt (Baudrate konfigurieren kann, ...), zum Beispiel "minicom", ein Terminal, welches dir Tastatur und Bildschirm mit einem externen Programm verbindet. Der umgekehrte Fall (das Terminal verbindet sich mit deinem System) ist interessant.
Genauso sollte es dann auch möglich sein mit einem Headless System (eins ohne Bildschirm oder Ausgabe auf diesem) über ne serielle Schnittstelle zu interagieren (dazu muss ja trotzdem nen Terminal laufen).
Richtig, das wäre dann - um bei deiner Terminologie zu bleiben - der Seriell-Server. Der Con-Server stellt dir ein (oder mehrere) Terminals auf der VGA-Grafikkarte im Zusammenspiel mit dem Input-Server zur Verfügung, der GUI-Server stellt dir eine grafische Oberfläche im Zusammenspiel mit dem Input-Server zur Verfügung (er stellt dir kein Terminal zur Verfügung, das macht der Terminalemulator!), der Seriell-Server stellt dir ein Terminal auf der seriellen Leitung (ohne Input-Server) zur Verfügung.
Und Svenskas Vorgaben, dass das Textmodusterminal nichts können darf, halte ich auch für Blödsinn.
Ich weiß schon gar nicht mehr was er damit meinte, aber sowas wie Farbe und ANSI-Codes soll es schon können.
Hauptsächlich, dass du kein Double-Buffering und beliebig viele virtuelle Terminals brauchst. (Ich nutze im Extremfall, wenn die grafische Oberfläche kaputt ist, maximal drei bis vier.) Wenn du mehr brauchst, dann benutzt man ein Spezialprogramm wie "screen", welches auf sowas zugeschnitten ist und auch Sachen wie "detach in den Hintergrund" und eine Aufteilung in mehrere Fenster erlaubt.
Solche Sachen in den Con-Server zu integrieren ist unnötig (wird in dem Umfang nur selten benutzt), schwierig umzusetzen und erhöht die Komplexität enorm.
Ich dachte, dass du am einfachsten für jedes reale Terminal (welches entweder vom VGA-Textmodustreiber oder vom seriellen Treiber oder vom graf. Terminalemulator bereitgestellt wird) einen neuen virtual-Terminal-Serverprozess startest. Jeder dieser Prozesse hat ein eigenes stdin/stdout und kann das somit auch verwalten.
Ich will eigentlich nicht das der serielle Treiber (als Bsp.) nen Terminal bereitstellt, sondern der soll nur Daten empfangen oder senden, nicht mehr.
Exakt, den reinen seriellen Treiber sehe ich da getrennt, der muss wirklich nur senden/empfangen/konfigurieren/Steuerleitungen können. Schließlich möchtest du ja auch Dateiprotokolle wie Kermit verwenden können und nicht nur Login.
Das selbe gilt für den VGA-Textmodetreiber. Solange ich mich im Textmodus befinde, soll der nur 16-bit Wörter erhalten die er dann einfach in den Hardwarebuffer kopiert. Dazu muss er noch die Möglichkeit bieten, CLS und ein paar Cursor-Sachen machen zu können, aber die Terminalverwaltung soll er nicht machen.
Genau, das ist der Optimalfall. Auf diese grundlegenden Funktionen setzt du dann "das ANSI-Terminal" an.
Ich würde wahrscheinlich das Terminal trotzdem in den VGA-Textmodustreiber einbinden und es als Speziallösung betrachten. :-P
Die Lösung zwecks des Eingabe/Ausgabe Problems könnte folgendes sein. In jedem virtuellen Terminal läuft irgendein Programm (also auch in dem das über die serielle Schnittstelle kommuniziert). Ich würde jetzt einfach ne neue Pipe für jeweils Stdout/Stderr/Stdin aufmachen und die an den Prozess als Stdout/Stderr/Stdin weiterreichen.
Klingt gut. Wenn jetzt Daten ankommen, entscheidet der Treiber des zugehörigen Terminals, was mit den Daten jetzt gemacht wird (hast du mehrere VGA-Textterminals, wird es nur angezeigt, wenn es das aktive Terminal trifft, sonst nur in einen Hintergrundpuffer - beim seriellen Terminal wird stdout an die serielle Schnittstelle weitergereicht - im GUI-Fall startest du entweder einen Terminalemulator (=Fenster) oder nutzt den schon vorhandenen).
So kann ich einfach die serielle Schnittstelle öffnen und die Daten in die Pipe für Stdin reinschreiben und die Daten die aus der Pipe für Stdout kommen, werden einmal auf dem Bildschirm ausgegeben und einmal an die serielle Schnittstelle geschickt (bzw. umgedreht bin da gerade etwas verwirrt).
Die serielle Schnittstelle als Terminal redet nur mit dem dort angeschlossenen Gerät, nicht mit Tastatur/Bildschirm.
Das gleiche mit nem normalen Terminal. So kann ich auch Double-Buffering betreiben und kann die Verwaltung übernehmen (welches Terminal die Eingabe bekommt, also im Vordergrund ist usw.) und muss das nicht in irgendeinem Treiber haben.
Die Verwaltung der einzelnen Terminals (also Eingabe/Ausgabe) obliegt im VGA-Textmodus dem Programm, welches die virtuellen Terminals (evtl. in Hardware) implementiert, in der grafischen Oberfläche dem Fensterverwalter (GUI-Server) und im seriellen Terminal dem seriellen Treiber.
Das liese sich auch alles wunderbar parallelisieren (in Threads) und die Ausgabe läuft weiter ohne dass das Terminal im Vordergrund sein muss.
Das sind (für mich) sogar unabhängige Prozesse/Tasks.
Einen für die gemeinsamen VGA-Textterminals (Con-Server, du hast nur eine VGA-Karte = nur einen Treiber = nur ein Prozess), einen für jede serielle Schnittstelle, die als Terminal dienen soll und einen Terminalemulator für jedes Konsolenfenster in der GUI.
-
Um die Sache mal ein wenig zu vereinfachen lassen wir die GUI Lösung jetzt mal außen vor. Denn wir hatten uns ja geeinigt dass das ein Terminalemulator alles macht.
Wenn du auf deinem Rechner eine Terminalemulation möchtest, die mit der seriellen Schnittstelle agiert, dann hat das gefälligst ein Programm zu tun, was die serielle Schnittstelle und ihre Eigenheiten kennt (Baudrate konfigurieren kann, ...), zum Beispiel "minicom", ein Terminal, welches dir Tastatur und Bildschirm mit einem externen Programm verbindet.
Ok, vereinfacht die Sache schonmal weiter.
Der Con-Server stellt dir ein (oder mehrere) Terminals auf der VGA-Grafikkarte im Zusammenspiel mit dem Input-Server zur Verfügung
Mir ist ein neuer Name eingefallen, der besser passt ... TUI-Server (hat nichts mit dem Reiseunternehmen zu tun ;) ).
Denn er emuliert ja nicht nur einfach ein Terminal, sondern viele und kümmert sich auch darum welches gerade im Vordergrund ist. Man kann sagen das es im weitesten Sinne ein WindowManager für den Textmodus ist.
Richtig, das wäre dann - um bei deiner Terminologie zu bleiben - der Seriell-Server.
Zwecks Terminologie, so lange du nicht alles in den Kernel packst kann ich mit Linux-Begriffen leben, aber ich mache nicht aus allem nen Server ;)
In dem Fall würdest du dich beim Device-Server melden und nach einer seriellen Schnittstelle fragen und wirst dann direkt mit dem Treiber kommunizieren.
Solche Sachen in den Con-Server zu integrieren ist unnötig (wird in dem Umfang nur selten benutzt), schwierig umzusetzen und erhöht die Komplexität enorm.
Kann sein das meine Unwissenheit mir jetzt was falsches sagt, aber ich sehe da keine Schwierigkeit und auch keine Komplexität.
Du erstellst einfach für jedes neue virtuelle Terminal nen Buffer mit der Größe 4000bytes*Anzahl der Bildschirmseiten und schreibst einmal dort alles rein und wenn das Terminal im Vordergrund ist, schickst du die Daten noch zusätzlich an den VGA-Textmodustreiber.
Genau das ist auch das was ich meinte das es sich gut parallelisieren lässt. Man hat einfach einen Thread pro virtuellem Terminal im TUI-Server. Denn so eine Pipe fasst ja auch nicht unendlich an Daten.
Kommt ein anderes Terminal in den Vordergrund "kopierst" du einfach den Buffer (die Cursorposition muss natürlich mit einbezogen werden) zum VGA-Treiber und fertig. Einfach und ausreichend schnell.
Die serielle Schnittstelle als Terminal redet nur mit dem dort angeschlossenen Gerät, nicht mit Tastatur/Bildschirm.
Ich habe sowas noch nie gemacht und daher bin ich dabei noch etwas unsicher.
Also läuft das im Prinzip so ab, das ich Stdin an die serielle Schnittstelle weiterleite und was von der seriellen Schnittstelle kommt leite ich an Stdout weiter?
So muss ich auch nichts bei mir (da wo das Terminal läuft mit Bildschirm) auf den Monitor ausgeben, was ich über die Tastatur eingegeben habe, weil das kommt ja eh von der seriellen Schnittstelle zurück und wird dann auf meinem Monitor ausgegeben.
Falls jemand schonmal so eine "Session" gemacht hat und das so läuft wie ich es oben beschrieben habe, merkt man da ein Lag (weil ja erst zum Empfänger gesendet wird und dann kommt das Zeichen wieder zurück und wird erst dann auf dem Bildschirm erscheinen)?
Einen für die gemeinsamen VGA-Textterminals (Con-Server, du hast nur eine VGA-Karte = nur einen Treiber = nur ein Prozess)
Ich hatte ja oben schon was dazu geschrieben, aber so wie du es schreibst wird es schwierig. Erstmal implementiere ich das nicht im VGA-Treiber und wenn du dann nur einen Thread für viele Terminals hast, wird das schwierig. Denn dann müsstest du ja immer der Reihe nach alle Pipes aller virtuellen Terminals (deren Stdout) abfragen ob Daten da sind und mit meiner Thread-Variante wird das wesentlich einfacher und auch sauberer.
-
Der Con-Server stellt dir ein (oder mehrere) Terminals auf der VGA-Grafikkarte im Zusammenspiel mit dem Input-Server zur Verfügung
Mir ist ein neuer Name eingefallen, der besser passt ... TUI-Server (hat nichts mit dem Reiseunternehmen zu tun ;) ).
Denn er emuliert ja nicht nur einfach ein Terminal, sondern viele und kümmert sich auch darum welches gerade im Vordergrund ist. Man kann sagen das es im weitesten Sinne ein WindowManager für den Textmodus ist.
Joa, das kann man so sehen.
Solche Sachen in den Con-Server zu integrieren ist unnötig (wird in dem Umfang nur selten benutzt), schwierig umzusetzen und erhöht die Komplexität enorm.
Kann sein das meine Unwissenheit mir jetzt was falsches sagt, aber ich sehe da keine Schwierigkeit und auch keine Komplexität.
Naja, guck dir mal "screen" an und überlege dann, ob du das nicht einfach benutzen möchtest (es ist ein ncurses-Programm), statt alles nochmal selbst zu implementieren. Es geht mir hier um alles, was man mit 4 gleichzeitigen Textterminals nicht mehr abbilden kann.
Du erstellst einfach für jedes neue virtuelle Terminal nen Buffer mit der Größe 4000bytes*Anzahl der Bildschirmseiten und schreibst einmal dort alles rein und wenn das Terminal im Vordergrund ist, schickst du die Daten noch zusätzlich an den VGA-Textmodustreiber.
Oder du legst einfach 13107 Bytes (64K/5 Terminals) für jedes Terminal im Grafikspeicher fest und schreibst, wenn von stdout Daten kommen in den entsprechenden Bereich im Grafikspeicher (und kümmerst dich um das Scrolling). Damit hast du in jedem Terminal über 2 volle Bildschirme als Scrollback-Buffer und es kostet nichtmal RAM. ;-)
Bei einem Wechsel des Terminals sagst du der Grafikkarte die Offsetadresse im Grafikspeicher und sie stellt dann von diesem Offset bis Offset+4000 Bytes es direkt auf dem Bildschirm dar. Spart das Kopieren.
Genau das ist auch das was ich meinte das es sich gut parallelisieren lässt. Man hat einfach einen Thread pro virtuellem Terminal im TUI-Server. Denn so eine Pipe fasst ja auch nicht unendlich an Daten.
Kommt ein anderes Terminal in den Vordergrund "kopierst" du einfach den Buffer (die Cursorposition muss natürlich mit einbezogen werden) zum VGA-Treiber und fertig. Einfach und ausreichend schnell.
Speicherbandbreite ist im Textmodus kein Thema, von daher ist alles "sehr schnell". Die ganzen Pipes für die einzelnen Terminals kannst du auch mittels AIO verwenden (also ein poll() = WaitForManyPipes() ). Du musst halt nur via Lock dafür sorgen, dass immer nur ein Pipe-Request gleichzeitig in den Grafikspeicher gehen kann und dass du beim Scrollen nicht in fremde Terminalseiten schreibst. AIO verwendet nur einen Thread, das spart das Locking.
Also läuft das im Prinzip so ab, das ich Stdin an die serielle Schnittstelle weiterleite und was von der seriellen Schnittstelle kommt leite ich an Stdout weiter?
Deine Anwendung will Zeug darstellen, schreibt also nach "stdout". Das Terminal sei seriell, also leitest du "stdout" auf die Serielle weiter, dass die Zeichen gesendet werden. Die Umwandlung von ANSI auf Darstellung erledigt das Fremdgerät (DEC-Terminal oder PuTTY-Seriell oder HyperTerminal oder minicom oder...).
Wenn das Fremdgerät irgendwelche Zeichen schickt, so soll die Anwendung diese erhalten (die Umwandlung in ANSI erledigt auch hier das Fremdgerät), also leitest du eingehende Daten von der Seriellen nach stdin weiter.
So muss ich auch nichts bei mir (da wo das Terminal läuft mit Bildschirm) auf den Monitor ausgeben, was ich über die Tastatur eingegeben habe, weil das kommt ja eh von der seriellen Schnittstelle zurück und wird dann auf meinem Monitor ausgegeben.
Von welcher Seite sprichst du jetzt? Wenn du jedes Zeichen wieder zurücksendest, dann nennt man das "remote echo", das Gegenteil davon ist lokales Echo, wenn dir das Terminal die gesendeten Zeichen auch auf den Bildschirm spult. Ist konfigurierbar.
Falls jemand schonmal so eine "Session" gemacht hat und das so läuft wie ich es oben beschrieben habe, merkt man da ein Lag (weil ja erst zum Empfänger gesendet wird und dann kommt das Zeichen wieder zurück und wird erst dann auf dem Bildschirm erscheinen)?
Bei 110 Baud sicherlich. Für 9600 Baud musst du aber schon verdammt schnell tippen. Allerdings merkt man eine 9600-Baud-Leitung schon recht deutlich, wenn man viele Kontrollsequenzen übertragen muss (z.B. mc in bunt). Man kann damit aber schon arbeiten. Als Vergleich: Das Linux-/BSD-Textterminal wird meist mit 38400 Baud betrieben. (Wobei ich nicht weiß, ob das auch die reale Geschwindigkeit ist; vermute aber zumindest bei den BSDs ja.)
Ich hatte ja oben schon was dazu geschrieben, aber so wie du es schreibst wird es schwierig. Erstmal implementiere ich das nicht im VGA-Treiber und wenn du dann nur einen Thread für viele Terminals hast, wird das schwierig. Denn dann müsstest du ja immer der Reihe nach alle Pipes aller virtuellen Terminals (deren Stdout) abfragen ob Daten da sind und mit meiner Thread-Variante wird das wesentlich einfacher und auch sauberer.
Naja, du hast halt nur eine VGA-Karte mit mehreren Terminals. Entweder dein VGA-Treiber implementiert das direkt, wie von mir beschrieben, oder du legst einen Layer oben drüber. Da der Treiber aber direkt auf die Hardware (ausschließlich VGA, evtl. EGA oder früher) zugeschnitten ist und auch nur eine Funktion (Terminal bereitstellen) hat, braucht man das mMn nicht wegabstrahieren. Für alles, was höhere Funktionen angeht, nutzt du ja den GUI-Server.
Was die Pipes angeht, würde ich AIO verwenden. Dann hast du einen Thread, der aber kein busy waiting macht. Wie gesagt, ich mag Threads irgendwie nicht. ;-)
Grüßle, ich geh ins Bett.
-
Oder du legst einfach 13107 Bytes (64K/5 Terminals) für jedes Terminal im Grafikspeicher fest und schreibst, wenn von stdout Daten kommen in den entsprechenden Bereich im Grafikspeicher (und kümmerst dich um das Scrolling). Damit hast du in jedem Terminal über 2 volle Bildschirme als Scrollback-Buffer und es kostet nichtmal RAM.
Ich behaupte mal was die Portabilität angeht ist meine Variante wesentlich einfacher umzusetzen! Zumal ich so auch die Anzahl der Bildschirmseiten die gebuffert werden dynamisch festlegen kann und auf jeder Plattform funktioniert alles gleich (ich meine damit das auf jeder Plattform die gleiche Anzahl an Terminals genutzt werden kann ohne ein externes Programm wie screen zu nutzen).
Die ganzen Pipes für die einzelnen Terminals kannst du auch mittels AIO verwenden (also ein poll() = WaitForManyPipes() ). Du musst halt nur via Lock dafür sorgen, dass immer nur ein Pipe-Request gleichzeitig in den Grafikspeicher gehen kann und dass du beim Scrollen nicht in fremde Terminalseiten schreibst. AIO verwendet nur einen Thread, das spart das Locking.
AIO habe ich noch nicht und steht auf meiner ToDo-Liste auch ganz weit unten. Busy-Waiting benutzen meine Pipes auch nicht (zumal meine Pipes ja ein wenig anders funktionieren als "normale" Pipes).
-
Oder du legst einfach 13107 Bytes (64K/5 Terminals) für jedes Terminal im Grafikspeicher fest und schreibst, wenn von stdout Daten kommen in den entsprechenden Bereich im Grafikspeicher (und kümmerst dich um das Scrolling). Damit hast du in jedem Terminal über 2 volle Bildschirme als Scrollback-Buffer und es kostet nichtmal RAM.
Ich behaupte mal was die Portabilität angeht ist meine Variante wesentlich einfacher umzusetzen! Zumal ich so auch die Anzahl der Bildschirmseiten die gebuffert werden dynamisch festlegen kann und auf jeder Plattform funktioniert alles gleich (ich meine damit das auf jeder Plattform die gleiche Anzahl an Terminals genutzt werden kann ohne ein externes Programm wie screen zu nutzen).
Naja, es gibt halt zugeschnittene, weitverbreitete Programme dafuer. Und der VGA-Textmodus ist ohnehin komplett unportabel, denn den gibt es auf anderen Architekturen nicht. Dort gibt es entweder von der Firmware ein dumb-Terminal oder ausschließlich einen Framebuffer, der von deinem GUI-Server benutzt würde. In jedem Falle hast du dort nur ein Terminal, solange du nicht mehrere Terminals auf einem emulierst (und das können externe Programme eh viel besser).
Die ganzen Pipes für die einzelnen Terminals kannst du auch mittels AIO verwenden (also ein poll() = WaitForManyPipes() ). Du musst halt nur via Lock dafür sorgen, dass immer nur ein Pipe-Request gleichzeitig in den Grafikspeicher gehen kann und dass du beim Scrollen nicht in fremde Terminalseiten schreibst. AIO verwendet nur einen Thread, das spart das Locking.
AIO habe ich noch nicht und steht auf meiner ToDo-Liste auch ganz weit unten. Busy-Waiting benutzen meine Pipes auch nicht (zumal meine Pipes ja ein wenig anders funktionieren als "normale" Pipes).
Wenn kein AIO, dann eben ein Thread pro Terminal und ein Lock für den Grafikspeicher. ;-)
Der Thread bräuchte dann nur zwei Zahlen als Parameter: Den Offset im Grafikspeicher (also das wievielte Terminal er ist, erfährst du beim Starten der Threads) und die Größe des Terminalspeichers (die erwähnten 13107 Bytes bei fünf Terminals). Plus natürlich Zeiger auf stdin/stdout/stderr.
Gruß,
Svenska
-
Hallo,
ich hab mir Euren Thread jetzt mindestens 2 mal komplett durchgelesen und muss sagen das er sehr interessant und aufschlussreich ist (bis her zumindest). Aber mir ist auch aufgefallen das Ihr (FlashBurn und Svenska) recht häufig wirr aneinander vorbei geschrieben habt. Ich glaube (nicht wissen) das FlashBurn an ein paar Stellen den Host (auf dem FlashBurn sein OS laufen soll mitsamt seinen Programmen) und den Client (auf dem irgendein OS mit irgendeinem Terminal-Programm läuft) verwechselt hat. Ansonsten bietet der Thread aber schon einige Denkimpulse.
@Svenska:
screen ist aber schon ein recht umfangreiches Programm vom dem ich vermute das es ne Dicke Menge an POSIX-Zeugs benutzt und daher vermute ich das es noch nicht mal auf tyndur portiert wurde und man daher davon ausgehen kann das eine Portierung entweder sehr umfangreich wird oder eben eine umfangreiche POSIX-Unterstützung voraussetzt. Ich kann gut verstehen das FlashBurn mehrere TUI-Terminals lieber mit einer eigenen Schicht anbieten möchte wobei ich auch nicht der Meinung bin dass das Umschalten ein performancekritischer Aspekt ist. Die Frage ist nur wie die Schnittstelle nach unten (zum VGA-Text-Modus-Treiber) aussehen sollte. Wenn die sich an VGA orientiert dann wird sie wahrscheinlich kaum portierbar.
Basierend auf Euren Beiträgen hab ich mir mal ein paar eigene Gedanken gemacht wie man Terminal geschickt umsetzen könnte,
ich erzähle einfach mal:
Ein Programm bekommt von seinem Ersteller immer stdin/stdout/stderr mit (vererbt) und es ist ihm grundsätzlich egal was am anderen Ende ist. Wenn ein Programm z.B. ncurses benutzt dann sollte das andere Ende in der Lage sein das sauber dar zu stellen (wie ich das mit der Umgebungsvariable machen will weiß ich noch nicht so ganz).
Fürs erste werde ich nur eine RS232-Schnittstelle haben so das mein init-Prozess ein Programm starten muss das einen RS232-Port öffnet und daraus eben stdin/stdout/stderr erstellt und damit dann eine Shell startet. Die Shell bekommt dann alles was per RS232 rein kommt auf stdin übergeben und was die Shell (oder einer der Kind-Prozesse) auf stdout/stderr ausgibt wird eben per RS232 nach draußen gesendet. Dieses Umleitungsprogramm muss sich um ANSI-Sequenzen u.ä. keine Gedanken machen, das ist Aufgabe des Terminal-Programms auf dem Client-System am anderen Ende der RS232-Leitung (z.B. minicom).
Als nächstes käme dann ein telnet-Server der einen TCP-Server-Socket erstellt und für jede ankommende Verbindung dann einen TCP-Stream bekommt und mit dem es das selbe macht wie das andere Programm mit der RS232-Verbindung (eine TCP-Verbindung ist aus dieser Sicht exakt das selbe wie eine RS232-Verbindung: eine bidirektionale volldublex Byte-Strom-Schnittstelle), also ein neues Set stdin/stdout/stderr erstellt und damit dann eine neue Shell startet. Auch dieses Programm muss sich nicht um ANSI & Co kümmern, ist dafür aber ein Multithreading-Programm das eine unbegrenzte Anzahl an Konsolen öffnen kann (eben so viele wie TCP-Verbindungen entstehen).
Falls ich jemals bis zu einer GUI komme (eine lokale TUI wie beim VGA wird es bei mir nicht geben) werde ich wohl Svenskas Vorschlag mit den Default-Pipes und einem eigenständigen Terminal-Emulator-Programm umsetzen. Diesen Terminal-Emulator kann man entweder manuell starten und muss ihm dann sagen welches Programm unter seiner Obhut laufen soll oder das GUI-System startet dieses Programm automatisch immer dann wenn ein Programm seine stdin/stdout/stderr benutzt während diese noch in einem Dummy-System hängen (also z.B. bei Konsolen-Programmen die vom graphischen Dateimanager per Mausklick gestartet werden). Dieses Terminal-Emulations-Programm wird dann ein Fenster erstellen und da drin dann die Ausgaben von stdout/stderr (vom Client-Prozess) darstellen und (wenn es den Fokus hat) Tastatureingaben an stdin (vom Client-Prozess) weiterleiten. Es ist also ein vollwertiges GUI-Programm das selber kein stdin/stdout/stderr besitzt. Für die Darstellung muss dann natürlich ANSI usw. unterstützt werden, aber dafür gibt es Librarys hab ich gesehen. Dieses Terminal-Emulations-Programm erstellt entweder selber stdin/stdout/stderr um das an einen neuen Kindprozess weiter zu geben (falls es manuell gestartet wurde) oder es bekommt stdin/stdout/stderr eines bereits existierenden Programms übergeben (falls es vom GUI-System automatisch gestartet wurde).
Was denkt ihr darüber?
Grüße
Erik
-
Ich glaube (nicht wissen) das FlashBurn an ein paar Stellen den Host (auf dem FlashBurn sein OS laufen soll mitsamt seinen Programmen) und den Client (auf dem irgendein OS mit irgendeinem Terminal-Programm läuft) verwechselt hat.
Oder du vergisst das mein OS auf nem PC mit Bildschirm und ohne laufen kann/wird. Ich wollte schon das ich von meinem OS aus mit meinem OS auf einem Headless-System kommuniziere!
Die Frage ist nur wie die Schnittstelle nach unten (zum VGA-Text-Modus-Treiber) aussehen sollte. Wenn die sich an VGA orientiert dann wird sie wahrscheinlich kaum portierbar.
Selbst wenn es sowas wie den Textmodus unter x86 nicht auf anderen Plattformen gibt, dann will ich nen Treiber der auch den Textmodus darstellt (auch wenn das eigentlich grafisch ist) und dieser Treiber soll nur die Zeichen die du ihm gibst, eins nach dem anderen auf dem Bildschirm ausgeben und dann halt noch so Sachen wie CLS und Cursor-Sachen.
Das sollte ziemlich portabel sein.
Die Idee das man dann über TCP auch wie über RS232 kommunizieren kann gefällt mir besonders :-)
-
Hallo,
Ich glaube (nicht wissen) das FlashBurn an ein paar Stellen den Host (auf dem FlashBurn sein OS laufen soll mitsamt seinen Programmen) und den Client (auf dem irgendein OS mit irgendeinem Terminal-Programm läuft) verwechselt hat.
Ja, das Gefühl habe ich auch immer wieder. Wobei das auch daran liegen kann, dass ich manchmal zu wirr antworte und es dann selbst vergesse.
screen ist aber schon ein recht umfangreiches Programm vom dem ich vermute das es ne Dicke Menge an POSIX-Zeugs benutzt und daher vermute ich das es noch nicht mal auf tyndur portiert wurde und man daher davon ausgehen kann das eine Portierung entweder sehr umfangreich wird oder eben eine umfangreiche POSIX-Unterstützung voraussetzt.
Ich benutze es nicht, daher weiß ich auch nicht, welche Funktionalität es unterstützt. Grundsätzlich kann man auch eine eingeschränkte Fassung davon (die nur virtuelle Terminals simuliert) bauen, das sollte mit einer Bildschirm-Bibliothek wie ncurses recht simpel machbar sein - und nimmt Komplexität aus dem Treiber (was mMn gut ist).
Ich kann gut verstehen das FlashBurn mehrere TUI-Terminals lieber mit einer eigenen Schicht anbieten möchte wobei ich auch nicht der Meinung bin dass das Umschalten ein performancekritischer Aspekt ist. Die Frage ist nur wie die Schnittstelle nach unten (zum VGA-Text-Modus-Treiber) aussehen sollte. Wenn die sich an VGA orientiert dann wird sie wahrscheinlich kaum portierbar.
Die Frage ist, ob es sich lohnt, TUI-Terminals zu abstrahieren. Die Schnittstelle (reinen Textmodus) gibt es ja auf anderen Architekturen nicht und in einer grafischen Umgebung gibt es mehr Möglichkeiten, die der VGA-Textmodus (an dem man sich orientieren würde) nicht bereitstellt. Wenn man mit der GUI-Variante anfängt, diese sauber abstrahiert und dann die TUI-Variante darauf aufsetzt, dürfte das die saubere Lösung sein, aber nicht leicht umsetzbar. Außerdem kann man, wenn man mit der TUI-Variante anfängt, schonmal lernen und es in der GUI-Variante dann richtig umsetzen.
Ein Programm bekommt von seinem Ersteller immer stdin/stdout/stderr mit (vererbt) und es ist ihm grundsätzlich egal was am anderen Ende ist. Wenn ein Programm z.B. ncurses benutzt dann sollte das andere Ende in der Lage sein das sauber dar zu stellen (wie ich das mit der Umgebungsvariable machen will weiß ich noch nicht so ganz).
Nur einem reines zeilenbasiertem Programm kann das egal sein. Andere Programme müssen den Terminaltyp und dessen Fähigkeiten erfahren können ("mc" verweigert auf "dumb"-Terminals den Start); das kann man allerdings auch in ncurses fest eincodieren.
Fürs erste werde ich nur eine RS232-Schnittstelle haben so das mein init-Prozess ein Programm starten muss das einen RS232-Port öffnet und daraus eben stdin/stdout/stderr erstellt und damit dann eine Shell startet. Die Shell bekommt dann alles was per RS232 rein kommt auf stdin übergeben und was die Shell (oder einer der Kind-Prozesse) auf stdout/stderr ausgibt wird eben per RS232 nach draußen gesendet. Dieses Umleitungsprogramm muss sich um ANSI-Sequenzen u.ä. keine Gedanken machen, das ist Aufgabe des Terminal-Programms auf dem Client-System am anderen Ende der RS232-Leitung (z.B. minicom).
Genau.
Als nächstes käme dann ein telnet-Server der einen TCP-Server-Socket erstellt und für jede ankommende Verbindung dann einen TCP-Stream bekommt und mit dem es das selbe macht wie das andere Programm mit der RS232-Verbindung (eine TCP-Verbindung ist aus dieser Sicht exakt das selbe wie eine RS232-Verbindung: eine bidirektionale volldublex Byte-Strom-Schnittstelle), also ein neues Set stdin/stdout/stderr erstellt und damit dann eine neue Shell startet. Auch dieses Programm muss sich nicht um ANSI & Co kümmern, ist dafür aber ein Multithreading-Programm das eine unbegrenzte Anzahl an Konsolen öffnen kann (eben so viele wie TCP-Verbindungen entstehen).
Oder es ist ein simples Singlethreading-Programm, welches für jede ankommende TCP-Verbindung extra gestartet wird - wie einfache telnetd-Implementationen. Aber: vollkommen richtig.
Falls ich jemals bis zu einer GUI komme (eine lokale TUI wie beim VGA wird es bei mir nicht geben) werde ich wohl Svenskas Vorschlag mit den Default-Pipes und einem eigenständigen Terminal-Emulator-Programm umsetzen. Diesen Terminal-Emulator kann man entweder manuell starten und muss ihm dann sagen welches Programm unter seiner Obhut laufen soll oder das GUI-System startet dieses Programm automatisch immer dann wenn ein Programm seine stdin/stdout/stderr benutzt während diese noch in einem Dummy-System hängen (also z.B. bei Konsolen-Programmen die vom graphischen Dateimanager per Mausklick gestartet werden). Dieses Terminal-Emulations-Programm wird dann ein Fenster erstellen und da drin dann die Ausgaben von stdout/stderr (vom Client-Prozess) darstellen und (wenn es den Fokus hat) Tastatureingaben an stdin (vom Client-Prozess) weiterleiten. Es ist also ein vollwertiges GUI-Programm das selber kein stdin/stdout/stderr besitzt.
Es gibt bei dieser Herangehensweise ein Problem, welches unter POSIX-Programmen auftritt. Dort gibt es keine reinen GUI-Programme, jedes Programm besitzt stdout/stderr (starte mal einen Firefox unter Linux aus einem Terminalemulator, dort erhältst du dann Debug-Ausgaben). Um eine Rekursion zu vermeiden, musst du entweder dafür sorgen, dass der Terminalemulator sein stdout/stderr nie benutzt (und damit kein neuer gestartet wird) oder du setzt ein Flag, welches das Fenster-Erzeugen verhindert. Im Textmodus ist dieses Flag auch nützlich, denn es könnte die Ausgabe komplett verhindern (und z.B. in ein syslog umleiten).
Zu stdin könnte man ja die Überlegung anstellen, dass das Dummy-stdin nur EOFs liest, solange kein Terminalemulator (GUI) gestartet ist oder wenn dieses Flag im Textmodus beim Programmstart gesetzt war.
Für die Darstellung muss dann natürlich ANSI usw. unterstützt werden, aber dafür gibt es Librarys hab ich gesehen. Dieses Terminal-Emulations-Programm erstellt entweder selber stdin/stdout/stderr um das an einen neuen Kindprozess weiter zu geben (falls es manuell gestartet wurde) oder es bekommt stdin/stdout/stderr eines bereits existierenden Programms übergeben (falls es vom GUI-System automatisch gestartet wurde).
Die ANSI-Sequenzen kann ein Programm selbst erzeugen oder nutzt eine fertige Library (eben ncurses), die auch andere Terminaltypen unterstützt.
Was denkt ihr darüber?
Das ist die meiner Meinung nach einzig sinnvolle Lösung. ;-)
Was den Terminaltypen angeht, so gibt es zwei Sachen zu beachten:
(a) die Übergabe des Terminaltypens an die Anwendung (läuft bei POSIX über das Environment)
(b) die Ermittlung des Terminaltypens
Der zweite Fall hängt von dem Prozess ab, welches das Terminal bereitstellt. Der VGA-Textmodus-Treiber hat genau einen Typen fest implementiert (z.B. ANSI), den er bereitstellt und an das System meldet. Der Telnet-Daemon stellt auch einen Typen bereit, der aber mit dem Telnet-Client aushandelbar ist und davon abhängig an die Anwendung gemeldet werden muss. Für RS232-Verbindungen gibt es keine Lösung, da müsste entweder ein Standardwert benutzt werden oder der Nutzer gefragt werden.
Die Frage ist nur wie die Schnittstelle nach unten (zum VGA-Text-Modus-Treiber) aussehen sollte. Wenn die sich an VGA orientiert dann wird sie wahrscheinlich kaum portierbar.
Selbst wenn es sowas wie den Textmodus unter x86 nicht auf anderen Plattformen gibt, dann will ich nen Treiber der auch den Textmodus darstellt (auch wenn das eigentlich grafisch ist) und dieser Treiber soll nur die Zeichen die du ihm gibst, eins nach dem anderen auf dem Bildschirm ausgeben und dann halt noch so Sachen wie CLS und Cursor-Sachen.
Der Treiber, der Textmodus darstellt, ist ein VGA-Treiber, also unportabel. Und der muss aus einem Zeichenstrom die Cursor-/Farb-/CLS-Geschichten extrahieren und den Rest darstellen.
Die eigentliche Darstellung (also das "Verstehen" der Terminalsequenzen) ist nur für den VGA-Textmodustreiber oder den Terminalemulator im GUI erforderlich, für die RS232-/Telnet-Verbindung übernimmt das die Gegenseite - also das Terminal.
Gruß,
Svenska
-
Der Treiber, der Textmodus darstellt, ist ein VGA-Treiber, also unportabel. Und der muss aus einem Zeichenstrom die Cursor-/Farb-/CLS-Geschichten extrahieren und den Rest darstellen.
Das ist mir schon klar! Ich meine das ich dann einen Textmode-Treiber für die jeweilige Platform schreiben will/muss und diese Treiber stellen auf allen Platformen das selbe Interface zur Verfügung.
Ich denke einfach das ein Textmode-Treiber einfacher und schneller geschrieben ist als ein komplett grafischer Treiber. Auch das Interface will erstmal designt werden und da ich erstmal nur mit einer Text-Oberfläche plane ist das halt einfacher.
-
Auch wenn es noch in weiter Ferne liegt würde ich mal ein paar Ideen zu einem GUI Konzept sammeln/austauschen wollen.
Also erstmal muss ich sagen, das ich von grafischer Programmierung noch gar keine Ahnung habe.
Aus aktuellem Anlass ("Untergang" vom X-Server) muss ich wohl mein geplantes Konzept nochmal überdenken.
Ich wollte es eigentlich auch so machen, das man alles was man zeichnen will als Anfrage an den Server formuliert, aber das produziert natürlich overhead.
Die andere Lösung ist halt, den Fensterinhalt als Bitmap an den GUI-Server zu "schicken" und dieser stellt die Bitmap dann als Fensterinhalt dar (sowas wie Fensterrand und Titelleiste, werden weiterhin vom GUI-Server dargestellt/erstellt).
Welches Konzept ist besser und warum? Vielleicht hat jemand noch eine ganz andere Idee?
Mir geht es vorallem darum, das man ohne großen Aufwand jede App so schreiben kann, das der GUI-Code vom restlichen Code getrennt ist, so dass es nicht passieren kann, dass der Fensterinhalt nicht gezeichnet wird bzw. sich nicht änder/keine Eingaben angenommen werden, nur weil der eigentliche App-Code gerade ausgeführt wird.
Bei der Lösung mit der Bitmap würde ich dann ne Art SDK (so wie die Kits bei Haiku) zur Verfügung stellen, damit alle Programme halbwegs gleich aussehen. Außerdem ist es so einfacher und schneller Fehler in allen Programmen, was die GUI betrifft, zu beseitigen.
-
Es gibt grundsätzlich zwei Möglichkeiten: Indirektes Rendering (X11, der Grafiktreiber/X-Server/... zeichnet den Bildschirm) oder direktes Rendering (Wayland oder DRM/DRI, die Applikation zeichnet den Inhalt selbst). Indirektes Rendering ist überholt. Damit kann man nämlich keine Form der Hardwarebeschleunigung machen. Es bleibt direktes Rendering übrig, also die Anwendungen zeichnen selbst.
Fensterverwaltung sollte man mMn dem System überlassen, denn es muss sich um Dinge wie Fokus kümmern.
Fensterdekoration kann man im System oder in den Anwendungen machen. Machst du es im System, sehen alle Fenster gleich aus, sind zentral konfigurierbar und immer rechteckig (bzw. nicht vollkommen frei in ihrer Form). Machen die Anwendungen es selbst, dann sehen alle Programme unter Umständen verschieden aus, was hässlich ist. Als dritte Möglichkeit baust du eine Library, die die Fensterdekorationen zeichnet und von allen Anwendungen verwendet wird, damit hast du dann wieder ein einheitliches Look & Feel. Da alle Anwendungen ohnehin ein Toolkit (Qt, GTK) benutzen sollten (nicht müssen), kann man das da auch mit einbauen.
Wichtig ist vor überhaupt allem, dass die Fensterdekoration und -verwaltung in einem anderen Task geschieht. Wenn du nämlich Tasks stoppst (oder sie hängen), musst du in der Fensterdekoration auf das X klicken können, um das Fenster zu schließen/den Prozess zu killen und du musst immer in der Lage sein, Fenster zu verschieben. Das kann man in der Dekorationsbibliothek ja direkt abfangen und diese über eine zentrale Konfigurationsdatei auch steuern.
Die grafische Oberfläche implementierst du dann sinnvollerweise als ein eventbasiertes System, die Anwendungen können (müssen aber nicht) dann einen eigenen Thread haben, der dem App-Code die Ereignisse aufbereitet und zuspielt.
Du kannst dir ja mal die Wayland-Mailingliste anschauen, da wird sowas auch diskutiert. Oder du portierst Wayland auf dein OS und beweist damit (a) die Portabilität von Wayland und (b) bist du gleich bleeding edge, was moderne Technologien angeht. ;-)
Ich bin ein Freund der Idee des direkten Renderns, der systemeigenen Fensterverwaltung, der anwendungseigenen Fensterdekoration mit Bibliothek.
;-)
-
Indirektes Rendering ist überholt. Damit kann man nämlich keine Form der Hardwarebeschleunigung machen. Es bleibt direktes Rendering übrig, also die Anwendungen zeichnen selbst.
Das verstehe ich nicht, denn ich hätte gedacht das es genau umgedreht ist.
Denn bei direktem Rendering zeichnest du immer in eine Bitmap und "sendest" die an den GUI-Server und der blittet die dann in die große Bildschirm-Bitmap.
Bei indirektem Rendering können aber irgendwelche, vorhandenen, Hardwarefunktionen genutzt werden (Linienzeichnen und Co.).
Auch bietet indirektes Rendering den Vorteil, das man als GUI-Server die Kontrolle über viele Sachen hat und damit sollte sich sowas wie einheitliche Schriftgröße (zwecks Skalierung) einfacher umsetzen lassen.
Ich habe sowieso noch gar keine Vorstellung wie man sowas wie OpenGL am besten umsetzt. Denn das ist ja auch Hardwarebeschleunigung in dem Programm, aber eigentlich ja auch indirektes Rendering, weil du ja der Grafikkarte sagst was wie und wo gezeichnet werden soll und hast damit wieder nen gewissen Overhead, weil du die Daten ja erstmal zum Treiber und der dann zur Grafikkarten senden muss.
Edit::
Einen Vorteil den ich noch für indirektes Rendering sehe, ist dass man keine Nachrichten verschicken muss, wenn sich z.B. die Fenstergröße ändert (oder doch?). Denn eigentlich hat man ja alle Infos die man braucht und kann das Fenster dann vom GUI-Server neu zeichnen lassen.
Ich stelle mir das so vor, das man nicht nur sagt was wo und wie gezeichnet werden soll, sondern das man ne Art Beschreibung wie der Fensterinhalt aussehen soll (ich denke da z.B. an Vektorgrafik) und das alles was mit Verschiebung und Größenänderung zu tun hat, kann der GUI-Server machen.
Oder würde das zu kompliziert, umständlich und langsamen werden?
-
Indirektes Rendering ist überholt. Damit kann man nämlich keine Form der Hardwarebeschleunigung machen. Es bleibt direktes Rendering übrig, also die Anwendungen zeichnen selbst.
Denn bei direktem Rendering zeichnest du immer in eine Bitmap und "sendest" die an den GUI-Server und der blittet die dann in die große Bildschirm-Bitmap.
Du zeichnest keine Bitmap und sendest die an den GUI-Server, sondern du zeichnest in einen Puffer, der dir vom GUI-Server zur Verfügung gestellt wurde und nutzt dazu Funktionen, die dir vom Grafiktreiber (DRI/DRM) zur Verfügung gestellt werden. Diese Funktionen sind im Prinzip ein OpenGL- (oder DirectX-)Kommandostrom, der von der Grafikkarte direkt verarbeitet wird.
Bei indirektem Rendering können aber irgendwelche, vorhandenen, Hardwarefunktionen genutzt werden (Linienzeichnen und Co.).
Ja, sofern du jede mögliche Hardwarefunktion im Protokoll zwischen GUI-Server und Anwendung definierst. Für einfache 2D-Dinge ist das vollkommen hinreichend (und geht auch bei X11 indirekt), aber für kompliziertere Dinge wie 3D ist das nicht mehr möglich. Insbesondere 3D-Spiele wollen ja die Grafikkarte ausreizen und müssen somit zwangsweise direkt mit dem Grafiktreiber sprechen.
Auch bietet indirektes Rendering den Vorteil, das man als GUI-Server die Kontrolle über viele Sachen hat und damit sollte sich sowas wie einheitliche Schriftgröße (zwecks Skalierung) einfacher umsetzen lassen.
Das kann der GUI-Server durchaus anbieten, aber das Zeichnen sollten die Anwendungen selbst machen. Es geht ja ausschließlich um den Fensterinhalt. Zumal manche Anwendungen durchaus absichtlich keine einheitlichen Schriftgrößen nutzen können oder wollen (v.a. Spiele mit eigener Oberfläche, aber Dinge wie Java-Anwendungen, wo die gesamte Darstellung von der JVM erledigt wird und daher gewisse Randbedingungen gelten müssen).
Ich habe sowieso noch gar keine Vorstellung wie man sowas wie OpenGL am besten umsetzt. Denn das ist ja auch Hardwarebeschleunigung in dem Programm, aber eigentlich ja auch indirektes Rendering, weil du ja der Grafikkarte sagst was wie und wo gezeichnet werden soll und hast damit wieder nen gewissen Overhead, weil du die Daten ja erstmal zum Treiber und der dann zur Grafikkarten senden muss.
Eben darum wird direktes Rendering benutzt. Du bekommst vom GUI-Server nur noch einen Puffer, wo du "reinrendern" musst. Die Daten kannst du mit Pixelschubsen oder 2D-beschleunigten Funktionen da reinkriegen, oder du steuerst die Grafikkarte direkt an.
Edit::
Einen Vorteil den ich noch für indirektes Rendering sehe, ist dass man keine Nachrichten verschicken muss, wenn sich z.B. die Fenstergröße ändert (oder doch?). Denn eigentlich hat man ja alle Infos die man braucht und kann das Fenster dann vom GUI-Server neu zeichnen lassen.
Das hieße, dass du enorme Informationen (Puffer) über den Fensterinhalt im GUI-Server behalten musst. Und zwar für jedes Fenster, egal ob es verdeckt oder außerhalb des Bildschirms ist. Heutzutage möglich, im Falle von X11 war es nicht möglich (zuwenig RAM in den Rechnern).
Kein windowing-System garantiert den Inhalt des Fensters; die Anwendung bekommt immer ein Event, welcher Teil jetzt neu gezeichnet werden muss. Das trifft sowohl direktes als auch indirektes Rendering.
Ich stelle mir das so vor, das man nicht nur sagt was wo und wie gezeichnet werden soll, sondern das man ne Art Beschreibung wie der Fensterinhalt aussehen soll (ich denke da z.B. an Vektorgrafik) und das alles was mit Verschiebung und Größenänderung zu tun hat, kann der GUI-Server machen.
Das erledigt das Toolkit, wie z.B. Qt/GTK oder das wird mit Techniken wie XUL (XML User Interfaces) erschlagen, der GUI-Server sollte an sich kein Toolkit voraussetzen.
Oder würde das zu kompliziert, umständlich und langsamen werden?
Indirektes Rendering ist hardwarebeschleunigt nur möglich, wenn der GUI-Server gleichzeitig der Grafiktreiber ist (und somit alle Funktionen kennt), was Anwendungen damit an den GUI-Server bindet (also von der Grafikhardware abhängig ist) oder wenn jede Anfrage vom GUI-Server an die Grafikkarte geleitet wird, wenn er sie selbst nicht erfüllen kann (was Overhead ist).
Direktes Rendering ist gut.
Gruß,
Svenska
-
Du zeichnest keine Bitmap und sendest die an den GUI-Server, sondern du zeichnest in einen Puffer, der dir vom GUI-Server zur Verfügung gestellt wurde und nutzt dazu Funktionen, die dir vom Grafiktreiber (DRI/DRM) zur Verfügung gestellt werden. Diese Funktionen sind im Prinzip ein OpenGL- (oder DirectX-)Kommandostrom, der von der Grafikkarte direkt verarbeitet wird.
Dieser Puffer liegt ja optimaler Weise im Graka RAM oder?
Wie funktioniert das eigentlich mit den beschleunigten Funktionen der Graka, kann man die für jede Art von RAM (Board oder Graka) nutzen oder sind die irgendwie beschränkt?
Insbesondere 3D-Spiele wollen ja die Grafikkarte ausreizen und müssen somit zwangsweise direkt mit dem Grafiktreiber sprechen.
Bzw. "sprechen" sie mit der OpenGL Implementierung des Treibers.
Mal ganz blöd zu OpenGL gefragt, kann ich mir das dann wir RPC vorstellen? Bzw. wimre dann haben die ganzen OpenGL (bzw. die meisten) Funktionen keinen Rückgabewert, da lohnt es sich ja dann so richtig, einfach nen RingBuffer zu nehmen und da die Daten an den OpenGL-Treiber zu schicken.
Was noch wichtig ist, sollte man komplett auf OpenGL setzen (also auch einfache Fenster-Sachen und sowas) oder sollte man ein paar grundlegende 2D Funktionen anbieten und dann halt wer will OpenGL?
Wenn ich alles mit OpenGL erschlage, dann ist es natürlich auch (sofern unterstützt) beschleunigt, aber ich habe natürlich auch nen ganz schönen Aufwand erstmal nen Treiber und die GUI zum Laufen zu bringen.
-
Du zeichnest keine Bitmap und sendest die an den GUI-Server, sondern du zeichnest in einen Puffer, der dir vom GUI-Server zur Verfügung gestellt wurde und nutzt dazu Funktionen, die dir vom Grafiktreiber (DRI/DRM) zur Verfügung gestellt werden. Diese Funktionen sind im Prinzip ein OpenGL- (oder DirectX-)Kommandostrom, der von der Grafikkarte direkt verarbeitet wird.
Dieser Puffer liegt ja optimaler Weise im Graka RAM oder?
Für Bitmaps ja, für OpenGL-Kommandoströme nein (die werden vom Grafiktreiber in hardwareabhängige Shadersprache umgesetzt).
Wie funktioniert das eigentlich mit den beschleunigten Funktionen der Graka, kann man die für jede Art von RAM (Board oder Graka) nutzen oder sind die irgendwie beschränkt?
Keine Ahnung. Hängt wahrscheinlich auch konkret von der Hardware ab (und ist damit Teil des Treibers). edit: PCI-Grafikkarten haben keinen Zugriff auf den RAM und die AGP Aperture Size ist auch immer begrenzt. Für Shared Memory-Grafik gibt es nur einen festen Bereich im RAM, der genutzt wird; wäre es egal, könnte der Treiber das festlegen. Also in der Allgemeinheit geht das nicht.
Umgekehrt kann man aber drüber nachdenken: Der Amiga hat verschiedene Arten von RAM mit verschiedenen Geschwindigkeiten und unterschiedlicher Adressierung. Linux auf dem Amiga nutzt nur den ChipRAM und stellt den restlichen Speicher (FastRAM, SlowRAM) als Blockdevice zur Verfügung. Dieses Blockdevice wird dann als Swapspace mit unterschiedlicher Priorität, je nach Zugriffsgeschwindigkeit, genutzt. Sowas könnte man natürlich auch mit dem Grafikspeicher auf modernen Grafikkarten machen, wenn man den Speicher dort eh nicht nutzt.
Insbesondere 3D-Spiele wollen ja die Grafikkarte ausreizen und müssen somit zwangsweise direkt mit dem Grafiktreiber sprechen.
Bzw. "sprechen" sie mit der OpenGL Implementierung des Treibers.
Richtig, die ist aber prinzipiell kartenabhängig wegen der ganzen Erweiterungen.
Mal ganz blöd zu OpenGL gefragt, kann ich mir das dann wir RPC vorstellen? Bzw. wimre dann haben die ganzen OpenGL (bzw. die meisten) Funktionen keinen Rückgabewert, da lohnt es sich ja dann so richtig, einfach nen RingBuffer zu nehmen und da die Daten an den OpenGL-Treiber zu schicken.
Was noch wichtig ist, sollte man komplett auf OpenGL setzen (also auch einfache Fenster-Sachen und sowas) oder sollte man ein paar grundlegende 2D Funktionen anbieten und dann halt wer will OpenGL?
Also wenn man sich Cairo, GTK oder Qt anschaut, dann sind das in erster Linie Toolkits für 2D. Diese sind aber so programmiert, dass sie verschiedene Backends nutzen, konkret gibt es da mindestens was für Xlib (indirekt/via Netzwerk), Xshm (indirekt/via shared memory), XRENDER (2D-beschleunigter X-Server) und GL (OpenGL).
Wenn ich alles mit OpenGL erschlage, dann ist es natürlich auch (sofern unterstützt) beschleunigt, aber ich habe natürlich auch nen ganz schönen Aufwand erstmal nen Treiber und die GUI zum Laufen zu bringen.
Du kannst das aber in einem Wrapper - eben dem Toolkit - machen. Das existiert bereits.
Mal abgesehen davon muss deine Hardware hinreichend schnell sein, damit du ohne großen Performanceverlust dein 2D über die 3D-Engine machen kannst. Das schließt sämtliche nicht-3D-fähige Hardware aus (da müsstest du 3D emulieren) und langsame/alte 3D-Karten (ATI Rage, NVidia TNT) sind in jedem Fall wesentlich langsamer im 3D-Modus als im 2D-Modus.
edit: Wenn du dir es einfach machen möchtest, ohne Grafiktreiberentwickler mit Ahnung zu engagieren, dann solltest du KMS/DRI/TTM und Freunde von Linux portieren und darauf die fertigen Gallium3D-Treiber aufsetzen. Das ist trotzdem eine Mordsarbeit. ;-) Ich würde mir den Stress mit 3D eher nicht machen.
Gruß,
Svenska
-
Für Bitmaps ja, für OpenGL-Kommandoströme nein (die werden vom Grafiktreiber in hardwareabhängige Shadersprache umgesetzt).
Genau hier habe ich jetzt so meine Verständnisprobleme. Ansich zeichnen die OpenGL Befehle doch auch nur in eine Bitmap rein oder?
Denn ich frage mich gerade wie es sonst möglich ist, das jede Anwendung die Hardwarebeschleunigten Funktionen zu nutzen, ohne das die Graka weiß in welcher Reihenfolge die Fenster gezeichnet werden oder welche Fenster sich wo überlappen?
Mal abgesehen davon muss deine Hardware hinreichend schnell sein, damit du ohne großen Performanceverlust dein 2D über die 3D-Engine machen kannst. Das schließt sämtliche nicht-3D-fähige Hardware aus (da müsstest du 3D emulieren) und langsame/alte 3D-Karten (ATI Rage, NVidia TNT) sind in jedem Fall wesentlich langsamer im 3D-Modus als im 2D-Modus.
Also wird wohl, vorallem in meinem Fall (älter Hardware >= P75), eine Unterteilung in einen 2D- und einen 3D-Treiber besser sein. Zumal es so auch einfacher wird, denn ich denke mal einen 2D-Treiber (z.B. Vesa) hat mal wesentlich schneller "geschrieben" als nen 3D-Treiber und somit könnte man dann einfach den Treiber regeln lassen, ob die Graka schnell genug ist, das alles im 3D-Modus gerendert werden kann.
Was ich mir auch noch nicht so richtig vorstellen kann, wie funktioniert das eigentlich wenn man mehrere Grakas und mehrere Bildschirme oder eine Graka für 2D und eine für 3D (z.B. alte Voodoo) hat?
Denn so wie ich mir das denke, muss man erstmal alle RPC Anfragen an den GUI-Server schicken und der schickt die dann weiter an den entsprechenden Treiber (zwecks anderer Bildschirm oder zur Unterscheidung 2D/3D).
-
Für Bitmaps ja, für OpenGL-Kommandoströme nein (die werden vom Grafiktreiber in hardwareabhängige Shadersprache umgesetzt).
Genau hier habe ich jetzt so meine Verständnisprobleme. Ansich zeichnen die OpenGL Befehle doch auch nur in eine Bitmap rein oder?
Nein. Die OpenGL-Befehle zeichnen nicht, sondern sie Steuern den Ablauf der Grafikkarte. Am Ende taucht etwas in einem Puffer auf.
Denn ich frage mich gerade wie es sonst möglich ist, das jede Anwendung die Hardwarebeschleunigten Funktionen zu nutzen, ohne das die Graka weiß in welcher Reihenfolge die Fenster gezeichnet werden oder welche Fenster sich wo überlappen?
Du hast zwei Ebenen... einmal zeichnet jede Anwendung in einen Puffer. Die Fensterverwaltung weiß nun, welche Puffer zu irgendwelchen Fenstern gehören, wie die sich überlappen und erzeugt dann Bereiche auf dem Bildschirm (z.B. Rechtecke), die dann mit den nicht-überlappenden Puffern hinterlegt werden.
Also wird wohl, vorallem in meinem Fall (älter Hardware >= P75), eine Unterteilung in einen 2D- und einen 3D-Treiber besser sein. Zumal es so auch einfacher wird, denn ich denke mal einen 2D-Treiber (z.B. Vesa) hat mal wesentlich schneller "geschrieben" als nen 3D-Treiber und somit könnte man dann einfach den Treiber regeln lassen, ob die Graka schnell genug ist, das alles im 3D-Modus gerendert werden kann.
Ich behaupte, dass aus dem Forum maximal eine Handvoll Personen in der Lage sind, einen gebrauchbaren 3D-Treiber für eine real existierende Grafikkarte zu schreiben.
Was ich mir auch noch nicht so richtig vorstellen kann, wie funktioniert das eigentlich wenn man mehrere Grakas und mehrere Bildschirme oder eine Graka für 2D und eine für 3D (z.B. alte Voodoo) hat?
Die reinen 3D-Karten zeichnen nicht in einen Puffer, sondern direkt in das VGA-Signal. Wo hingezeichnet werden soll, entscheidet der Treiber - und der bekommt von der Fensterverwaltung die Informationen zu Position und Überlappungszustand des entsprechenden Fensters. Wobei solche Geräte fast nicht mehr existieren.
Anwendungen brauchen für 3D-Darstellung einen Puffer. Dieser Puffer wird einer Grafikkarte zugeordnet. Wenn das Fenster, was den Pufferinhalt darstellen soll, auf einer anderen Grafikkarte angezeigt werden soll, dann musst du das Rendering-Ergebnis in jedem Frame von einem Grafikspeicher in einen anderen Grafikspeicher kopieren. Oder du kannst diesen Puffer von einer Grafikkarte auf eine andere "umziehen" (das ist Voraussetzung für dynamisch abschaltbare Grafikkarten, wie Intel&NVidia in Notebooks) - das setzt aber voraus, dass die Anwendung darüber informiert werden und zustimmen muss. Schließlich darf die Anwendung ja hardwareabhängige (OpenGL-)Befehle ausführen, die es auf der anderen Karte nicht gibt.
Denn so wie ich mir das denke, muss man erstmal alle RPC Anfragen an den GUI-Server schicken und der schickt die dann weiter an den entsprechenden Treiber (zwecks anderer Bildschirm oder zur Unterscheidung 2D/3D).
-
Du hast zwei Ebenen... einmal zeichnet jede Anwendung in einen Puffer. Die Fensterverwaltung weiß nun, welche Puffer zu irgendwelchen Fenstern gehören, wie die sich überlappen und erzeugt dann Bereiche auf dem Bildschirm (z.B. Rechtecke), die dann mit den nicht-überlappenden Puffern hinterlegt werden.
So weit mein vorhanden Wissen richtig ist, gibt es die Möglichkeit normalen RAM für die Graka zu nutzen erst seit AGP oder?
Denn es stellt sich mir schon die Frage, was passiert wenn man so viele Fenster offen hat das die nicht mehr alle in den Graka RAM passen oder als anderes Bsp. was ist mit den ganzen Tabs die man in einem Webbrowser offen haben kann, im Prinzip sind das doch eigenständige Fenster oder?
Ich behaupte, dass aus dem Forum maximal eine Handvoll Personen in der Lage sind, einen gebrauchbaren 3D-Treiber für eine real existierende Grafikkarte zu schreiben.
Ich denke mal es ist nicht mal so schwer nen 3D-Treiber zu schreiben, aber die Dokumentation (die nicht vorhanden ist) macht es einem ja unmöglich.
Anwendungen brauchen für 3D-Darstellung einen Puffer. Dieser Puffer wird einer Grafikkarte zugeordnet. Wenn das Fenster, was den Pufferinhalt darstellen soll, auf einer anderen Grafikkarte angezeigt werden soll, dann musst du das Rendering-Ergebnis in jedem Frame von einem Grafikspeicher in einen anderen Grafikspeicher kopieren. Oder du kannst diesen Puffer von einer Grafikkarte auf eine andere "umziehen" (das ist Voraussetzung für dynamisch abschaltbare Grafikkarten, wie Intel&NVidia in Notebooks) - das setzt aber voraus, dass die Anwendung darüber informiert werden und zustimmen muss. Schließlich darf die Anwendung ja hardwareabhängige (OpenGL-)Befehle ausführen, die es auf der anderen Karte nicht gibt.
Das die Anwendung informiert werden muss gilt doch aber nur für 3D-Anwendungen oder?
Ich selbst habe kein Multi-Monitoring, aber wenn ich an einer Graka mehrere Monitore angeschlossen habe, dann läuft alles über den Treiber, welcher Teil vom Fenster auf welchem Monitor dargestellt wird oder?
Interessant wird es erst, wenn man mehrere Grakas und dort jeweils nen Monitor dran hat. Der Einfachheit halber würde ich sagen, das ein Fenster nicht teilweise auf 2 Monitoren gleichzeitg (und damit auf 2 Grakas gleichzeit) sein kann, aber könnte man das machen?
Bei so einem Fall wäre es dann auch besser, wenn man die Befehle grundsätzliche erstmal zum GUI-Server sendet und der die dann an die entsprechende Graka weitersendet. Für den normalen Fall, das nur eine Graka vorhanden ist (was ja auf modernen Notebooks auch nicht mehr zutrifft) kann man ja einfach diesen Schritt weglassen und die Daten werden gleich zum Treiber gesendet.
-
Du hast zwei Ebenen... einmal zeichnet jede Anwendung in einen Puffer. Die Fensterverwaltung weiß nun, welche Puffer zu irgendwelchen Fenstern gehören, wie die sich überlappen und erzeugt dann Bereiche auf dem Bildschirm (z.B. Rechtecke), die dann mit den nicht-überlappenden Puffern hinterlegt werden.
So weit mein vorhanden Wissen richtig ist, gibt es die Möglichkeit normalen RAM für die Graka zu nutzen erst seit AGP oder?
Ja, aber auch da nicht universell, sondern (soweit ich weiß) nur für Texturen.
Denn es stellt sich mir schon die Frage, was passiert wenn man so viele Fenster offen hat das die nicht mehr alle in den Graka RAM passen oder als anderes Bsp. was ist mit den ganzen Tabs die man in einem Webbrowser offen haben kann, im Prinzip sind das doch eigenständige Fenster oder?
Naja, deine Bildschirmauflösung sind z.B. 1920x1080x4 ergibt etwa 8 MB. Dinge, die gerendert, aber nicht angezeigt werden, brauchen im Grafikspeicher nicht vorliegen. Jedes Mal, wenn du ein Fenster in den Vordergrund holst oder von außen auf den Bildschirm zurückschiebst, wird vom GUI-Server ein Ereignis "Please Repaint" an das Fenster geschickt. Das ist Voraussetzung. Wenn du Bildschirminhalte cachen möchtest, dann tust du das und sparst dir diese Ereignisse. Ist der Grafikspeicher voll, werden nicht angezeigte Inhalte halt verworfen.
Ich behaupte, dass aus dem Forum maximal eine Handvoll Personen in der Lage sind, einen gebrauchbaren 3D-Treiber für eine real existierende Grafikkarte zu schreiben.
Ich denke mal es ist nicht mal so schwer nen 3D-Treiber zu schreiben, aber die Dokumentation (die nicht vorhanden ist) macht es einem ja unmöglich.
Seh ich anders, allein schon die Diskussionen um die Implementierung der vielen OpenGL-Erweiterungen usw. zeigen mir das. Die Doku ist nur noch ein "layer of problems".
Das die Anwendung informiert werden muss gilt doch aber nur für 3D-Anwendungen oder?
Würde ich auch für 2D machen. Schließlich kannst du die 2D-Beschleunigung ähnlich implementieren. ;-) Im engeren Sinne hast du aber Recht (GUI-Server macht 2D, für 3D gibt es einen Durchgriff in die Hardware/den Treiber).
Ich selbst habe kein Multi-Monitoring, aber wenn ich an einer Graka mehrere Monitore angeschlossen habe, dann läuft alles über den Treiber, welcher Teil vom Fenster auf welchem Monitor dargestellt wird oder?
Jain. Sinnvoll ist es, den Bildschirm zu abstrahieren. Eine Grafikhardware stellt dir dann einen (oder mehrere) Bildschirme zur Verfügung; jeder Bildschirm gehört genau einer Grafikkarte.
Interessant wird es erst, wenn man mehrere Grakas und dort jeweils nen Monitor dran hat. Der Einfachheit halber würde ich sagen, das ein Fenster nicht teilweise auf 2 Monitoren gleichzeitg (und damit auf 2 Grakas gleichzeit) sein kann, aber könnte man das machen?
Kann man, ist aber nicht unbedingt sinnvoll. Wenn du ein Video (beschleunigt) oder ein 3D-Inhaltsfenster über zwei Monitore verteilst, hängt es von der Kombination ab, auf welchem Bildschirm Inhalt auftaucht und auf welchem Bildschirm nur schwarz angezeigt wird.
Ich habe bei einem Kumpel unter Windows XP eine S3 Trio64 zusätzlich zu einer ATI Radeon installiert. Wenn du einen VLC vollständig(!) auf die S3 verschiebst (also nicht dort öffnest), stürzt er ab. Bei 3D-Spielen genauso. Schiebst du das Fenster zwischen den beiden Monitoren der Radeon hin und her, so wird das Video auf beiden dargestellt, aber das 3D-Spiel ist auf dem Bildschirm schwarz, der nicht die obere linke Ecke des Spiels besitzt. ;-)
Bei so einem Fall wäre es dann auch besser, wenn man die Befehle grundsätzliche erstmal zum GUI-Server sendet und der die dann an die entsprechende Graka weitersendet. Für den normalen Fall, das nur eine Graka vorhanden ist (was ja auf modernen Notebooks auch nicht mehr zutrifft) kann man ja einfach diesen Schritt weglassen und die Daten werden gleich zum Treiber gesendet.
Du bindest einfach ein Fenster an einen Bildschirm. Verlässt das Fenster teilweise den Bildschirm, so ist es "draußen". Erst, wenn das Fenster vollständig auf einem anderen Bildschirm ist, musst du die Datenstrukturen umziehen.
Da kann man noch viel überlegen und überdenken.
Gruß,
Svenska
-
Jain. Sinnvoll ist es, den Bildschirm zu abstrahieren. Eine Grafikhardware stellt dir dann einen (oder mehrere) Bildschirme zur Verfügung; jeder Bildschirm gehört genau einer Grafikkarte.
Jein, würde ich etwas anders machen. Jeder Desktop darf nur auf einer Graka sein, über wieviele Bildschirme sich der Desktop dann erstreckt ist Sache des Treibers/der Graka.
Du bindest einfach ein Fenster an einen Bildschirm. Verlässt das Fenster teilweise den Bildschirm, so ist es "draußen". Erst, wenn das Fenster vollständig auf einem anderen Bildschirm ist, musst du die Datenstrukturen umziehen.
Wie gesagt, würde ich das pro Desktop machen, aber ansonsten macht man halt die Vereinfachung das ein Fenster nur komplett auf einem Desktop sein kann und nicht teilweise auf mehreren.
Ich bezog mich aber darauf, das du auch die jeweilige Graka in den Puffer schreiben lässt und nicht alles eine Graka machen lässt.
Was mich auch dazu bringt, das entweder alle Puffer der Fenster im Graka RAM sein müssen oder die Graka in den gesamten RAM schreiben kann.
-
Jain. Sinnvoll ist es, den Bildschirm zu abstrahieren. Eine Grafikhardware stellt dir dann einen (oder mehrere) Bildschirme zur Verfügung; jeder Bildschirm gehört genau einer Grafikkarte.
Jein, würde ich etwas anders machen. Jeder Desktop darf nur auf einer Graka sein, über wieviele Bildschirme sich der Desktop dann erstreckt ist Sache des Treibers/der Graka.
Definiere "Desktop". Meinst du das Root-Window? Das ist ein Fenster wie jedes andere und erstreckt sich vollständig über einen Bildschirm (im Sinne meiner Abstraktion). Du hast also für jeden Bildschirm ein eigenes Root-Window.
Du bindest einfach ein Fenster an einen Bildschirm. Verlässt das Fenster teilweise den Bildschirm, so ist es "draußen". Erst, wenn das Fenster vollständig auf einem anderen Bildschirm ist, musst du die Datenstrukturen umziehen.
Wie gesagt, würde ich das pro Desktop machen, aber ansonsten macht man halt die Vereinfachung das ein Fenster nur komplett auf einem Desktop sein kann und nicht teilweise auf mehreren.
Richtig. Du kannst ja das Fenster selbst auf mehreren Desktops anzeigen lassen, das Rendering (der Inhalt) geschieht aber nur auf dem Bildschirm, der das Fenster "besitzt". Ein 2D-Fenster umzuziehen ist kein Problem (du schickst der Anwendung ein Repaint-Event), bei 3D wird das schwieriger, weil du dort Zustände hast, die mit umziehen müssten. Dort kann man das aber auch komplett verbieten (oder durch Kopieren/Frame langsam aber möglich machen).
Ich bezog mich aber darauf, das du auch die jeweilige Graka in den Puffer schreiben lässt und nicht alles eine Graka machen lässt.
Was mich auch dazu bringt, das entweder alle Puffer der Fenster im Graka RAM sein müssen oder die Graka in den gesamten RAM schreiben kann.
Eine Graka kann nicht in den gesamten RAM schreiben, weil sie keinen Zugriff hat (insbesondere nicht auf den Grafikspeicher einer anderen Grafikkarte.
Du ordnest jedem Fenster einen Puffer zu, in den der Fensterinhalt gerendert wird. Zusätzlich besitzt jeder Puffer eine Grafikkarte, der er zugeordnet ist. Damit hast du indirekt alle Fenster einer Grafikkarte (und damit allen Bildschirmen, die an dieser Grafikkarte hängen!) zugeordnet. Das Umziehen im 2D ist kein Problem.
Es gibt aber bei der ganzen Diskussion einen Punkt zu beachten... und zwar die Initialisierung. Du kannst zwar mit VGA/VESA einen einfachen Grafiktreiber bauen, aber der funktioniert über den int 10h. Um Multimonitoring zu ermöglichen, musst du die Grafikkarten aber selbst ohne Hilfe des BIOS initialisieren und das ist recht kompliziert. Das führt z.B. auch dazu, dass in meinem Testfall die S3 Trio64 nur funktioniert, wenn sie im BIOS als primäre Grafikkarte eingetragen ist - der Windows-Bootscreen und BIOS-Meldungen tauchen nur auf dem dritten Bildschirm auf. Der Windows-Treiber für S3-Grafikkarten macht die Initialisierung jedenfalls nur über das Video-BIOS. Es gibt auch Grafikkarten die dies erfordern (ich habe eine S3 Trio32, die im BIOS primär sein muss, sonst hängt sich das BIOS direkt ohne Ausgabe weg!). In jedem Fall brauchst du einen direkt zugeschnittenen Hardwaretreiber, um soetwas zu ermöglichen.
Von daher kann man sich zwar ein paar Gedanken machen, aber die Implementierung ist weit, weit weg. ;-) Für ein Hobby-OS sinnvoll ist ein VESA-Treiber und eine darauf basierende 2D-Oberfläche; wenn man weiter ist, sind BitBlt und Videobeschleunigung (YUV -> RGB geht ab S3 Savage und ähnlich) noch wichtig.
Gruß,
Svenska
-
Definiere "Desktop". Meinst du das Root-Window? Das ist ein Fenster wie jedes andere und erstreckt sich vollständig über einen Bildschirm (im Sinne meiner Abstraktion). Du hast also für jeden Bildschirm ein eigenes Root-Window.
Definiere "Root-Window" ;)
Mit Desktop meine ich einen Desktop wie du ihn unter Windows kennst. Unter KDE und Konsorten ist es üblich mehrere virtuelle Desktops zu haben. Ich will darauf hinaus, das der Treiber ja einen großen Desktop dem System gegenüber anbieten kann, dieser wird aber z.B. auf 3 Monitore verteilt dargestellt, ohne das sich außer dem Treiber jemand darüber Gedanken machen muss.
Eine Graka kann nicht in den gesamten RAM schreiben, weil sie keinen Zugriff hat (insbesondere nicht auf den Grafikspeicher einer anderen Grafikkarte.
Deswegen meine Idee das die Daten erst an den GUI-Server geschickt werden und der ne Art Vermittler ist und die Daten an den richtigen Treiber weitersendet.
Du ordnest jedem Fenster einen Puffer zu, in den der Fensterinhalt gerendert wird. Zusätzlich besitzt jeder Puffer eine Grafikkarte, der er zugeordnet ist. Damit hast du indirekt alle Fenster einer Grafikkarte (und damit allen Bildschirmen, die an dieser Grafikkarte hängen!) zugeordnet. Das Umziehen im 2D ist kein Problem.
Ist ja alles richtig, aber wie du weiter oben schon sagtest kann eine Graka nicht auf den gesamten RAM zugreifen. Meine Frage ist dann halt, was macht man wenn der RAM auf den die Graka zugreifen kann voll ist?
Eine Lösung wäre das der Puffer vom Fenster in den Graka RAM kopiert wird, dort wird dann "gezeichnet" und dann kopierst du den Puffer wieder zurück in den normalen RAM. Der GUI-Server erstellt dann den fertigen Frame und kopiert das wieder in den Graka RAM.
Diese Variante ist aber verdammt langsam. Gibt es denn noch eine andere Möglichkeit?
Von daher kann man sich zwar ein paar Gedanken machen, aber die Implementierung ist weit, weit weg. wink Für ein Hobby-OS sinnvoll ist ein VESA-Treiber und eine darauf basierende 2D-Oberfläche; wenn man weiter ist, sind BitBlt und Videobeschleunigung (YUV -> RGB geht ab S3 Savage und ähnlich) noch wichtig.
Ich wollte meine Interfaces was das betrifft so flexibel wie möglich halten, vielleicht will ich ja irgendwann mal mit solchen Sachen rumspielen und da will ich nicht alles neuschreiben müssen.
-
Definiere "Desktop". Meinst du das Root-Window? Das ist ein Fenster wie jedes andere und erstreckt sich vollständig über einen Bildschirm (im Sinne meiner Abstraktion). Du hast also für jeden Bildschirm ein eigenes Root-Window.
Definiere "Root-Window" ;)
Das war der X11-Sinn. Es handelt sich um das einzige Fenster (auf einem X11-Screen), welches kein "parent window" hat, was die Position (0|0) und die maximale Größe des Screens hat.
Wenn man allerdings mit Xinerama und XRandR betrachtet, ist das Root-Window das Fenster, welches über alle Bildschirme geht, also bei 3 1024x768-Bildschirmen nebeneinander 3072x768 groß ist und oben links auf dem linken Bildschirm beginnt. ;-)
Mit Desktop meine ich einen Desktop wie du ihn unter Windows kennst. Unter KDE und Konsorten ist es üblich mehrere virtuelle Desktops zu haben. Ich will darauf hinaus, das der Treiber ja einen großen Desktop dem System gegenüber anbieten kann, dieser wird aber z.B. auf 3 Monitore verteilt dargestellt, ohne das sich außer dem Treiber jemand darüber Gedanken machen muss.
Das ist das Xinerama-Prinzip. Dein Desktop ist somit das Root-Window und alle Fenster sind Kinder dieses Fensters (und können auch nur innerhalb dessen Abmessungen liegen).
Eine Graka kann nicht in den gesamten RAM schreiben, weil sie keinen Zugriff hat (insbesondere nicht auf den Grafikspeicher einer anderen Grafikkarte.
Deswegen meine Idee das die Daten erst an den GUI-Server geschickt werden und der ne Art Vermittler ist und die Daten an den richtigen Treiber weitersendet.
Ja, das wäre aber wieder indirektes Rendering. Wenn dein Treiber Multimonitoring kann, dann ist 3D-Fähigkeit nicht weit (es gibt kaum Grafikkarten mit mehreren Heads, aber ohne 3D-Hardware) und um das sinnvoll zu ermöglichen, braucht man direktes Rendering.
Du ordnest jedem Fenster einen Puffer zu, in den der Fensterinhalt gerendert wird. Zusätzlich besitzt jeder Puffer eine Grafikkarte, der er zugeordnet ist. Damit hast du indirekt alle Fenster einer Grafikkarte (und damit allen Bildschirmen, die an dieser Grafikkarte hängen!) zugeordnet. Das Umziehen im 2D ist kein Problem.
Ist ja alles richtig, aber wie du weiter oben schon sagtest kann eine Graka nicht auf den gesamten RAM zugreifen. Meine Frage ist dann halt, was macht man wenn der RAM auf den die Graka zugreifen kann voll ist?
Für 2D-Anwendungen wirfst du einfach alles nicht dargestellte weg. Ein FullHD-Schirm belegt 8 MB, alles weitere brauchst du nicht cachen. Die Anwendung muss neuzeichnen, wenn du ein Fenster in den Vordergrund bringst.
Bei 3D-Anwendungen ist das komplizierter, allerdings haben Spiele immer eine Mindestanforderung an den Grafikspeicher, weil man bei einem bestimmten Verbrauch halt keine Texturen o.ä. hochladen kann und das ist für Spiele schädlich. "Grafikspeicher voll" ist eine Bedingung, die ich nicht als Problem sehe. Zumal 2D-Anwendungen fast keinen brauchen.
Eine Lösung wäre das der Puffer vom Fenster in den Graka RAM kopiert wird, dort wird dann "gezeichnet" und dann kopierst du den Puffer wieder zurück in den normalen RAM. Der GUI-Server erstellt dann den fertigen Frame und kopiert das wieder in den Graka RAM.
Diese Variante ist aber verdammt langsam. Gibt es denn noch eine andere Möglichkeit?
Also Double Buffering (der gesamte dargestellte Bildschirminhalt) ist eine Möglichkeit, den VESA-Treiber enorm zu beschleunigen. Wenn du nämlich die MTRRs entsprechend gesetzt hast, ist ein Bulk-Upload der 8 MB Framebuffer wesentlich schneller, als viele Zugriffe (z.B. jedes Pixel) auf den Grafikspeicher einzeln durchzuführen.
Du hast definitiv genug Platz im Grafikspeicher, um den aktuellen Bildschirminhalt anzuzeigen (der wird vom CRTC ausgelesen, muss also im GrafikRAM liegen). Im Zweifelsfall kannst du immer direkt auf diesem Bereich arbeiten, um die gerenderten Fenster darzustellen. Der Puffer, den du der Anwendung bereitstellst, kann ja direkt im Framebuffer liegen. Allerdings verlierst du damit die Möglichkeit des VSync (führt zu tearing).
Ich wollte meine Interfaces was das betrifft so flexibel wie möglich halten, vielleicht will ich ja irgendwann mal mit solchen Sachen rumspielen und da will ich nicht alles neuschreiben müssen.
X11 war auch nie mit 3D im Gedanken entwickelt worden. Wenn du das wirklich implementieren möchtest, dann schau dir mal Wayland an, zumindest die Konzepte.
Für ein Hobby-OS halte ich gebrauchbare 3D-Beschleunigung jedenfalls für unrealistisch. Dazu ist die Hardware definitiv zu kompliziert (und für NVidia oder VIA auch viel zu schlecht dokumentiert).
Gruß,
Svenska
-
Ja, das wäre aber wieder indirektes Rendering. Wenn dein Treiber Multimonitoring kann, dann ist 3D-Fähigkeit nicht weit (es gibt kaum Grafikkarten mit mehreren Heads, aber ohne 3D-Hardware) und um das sinnvoll zu ermöglichen, braucht man direktes Rendering.
Ich meine das anders, stell dir den GUI-Server in dem Moment vor wir nen Switch, der GUI-Server guckt sich nicht den Inhalt der Daten an, sondern er leitet sie einfach nur an den richtigen Treiber weiter.
Also Double Buffering (der gesamte dargestellte Bildschirminhalt) ist eine Möglichkeit, den VESA-Treiber enorm zu beschleunigen. Wenn du nämlich die MTRRs entsprechend gesetzt hast, ist ein Bulk-Upload der 8 MB Framebuffer wesentlich schneller, als viele Zugriffe (z.B. jedes Pixel) auf den Grafikspeicher einzeln durchzuführen.
Sprich für den VESA-Treiber, der sowieso keine Hardwarebeschleunigung hat, lohnt es sich, einen Frame erst im normalen RAM zusammenzustellen und ihn dann mit einmal in den Framebuffer zu kopieren?
Wenn ich dann nen Treiber habe für ne einfache Graka, die nicht alzu viel Speicher hat, würde ich das dann so machen, das ich 2 Puffer im RAM habe, jeweils ein Frame und immer in den Puffer zeichnen lasse der nicht gerade angezeigt wird (ist bestimmt auch die gängige Methode für DoubleBuffering oder?).
Für ein Hobby-OS halte ich gebrauchbare 3D-Beschleunigung jedenfalls für unrealistisch. Dazu ist die Hardware definitiv zu kompliziert (und für NVidia oder VIA auch viel zu schlecht dokumentiert).
Ich muss mit mal Gallium3D angucken, vllt lohnt es sich das zu portieren. Ansonsten ist so ein 3D-Treiber natürlich eine schöne Beschäftigung wenn man zu viel Zeit hat ;)
Edit::
Die Frage die sich mir stellt ist, warum wird eigentlich nicht jedes Fenster im Graka RAM (so fern genug verfügbar) gespeichert und wenn ein neuer Frame erstellt wird, wird einfach aus diesem Puffer gelesen? Ich meine dass das Neuzeichnen in dem Fall wegfällt und es wird nur neugezeichnet, wenn sich etwas im Fensterinhalt geändert hat.
Der einzige Grund der mir spontan einfällt das nicht zu machen ist, dass es "billiger" ist nur neuzuzeichnen, wenn das Fenster oder ein Teil davon zu sehen ist und ansonsten wird das Zeichnen einfach nicht gemacht.
-
Ja, das wäre aber wieder indirektes Rendering. Wenn dein Treiber Multimonitoring kann, dann ist 3D-Fähigkeit nicht weit (es gibt kaum Grafikkarten mit mehreren Heads, aber ohne 3D-Hardware) und um das sinnvoll zu ermöglichen, braucht man direktes Rendering.
Ich meine das anders, stell dir den GUI-Server in dem Moment vor wir nen Switch, der GUI-Server guckt sich nicht den Inhalt der Daten an, sondern er leitet sie einfach nur an den richtigen Treiber weiter.
Achso. Naja, wenn du für jedes Fenster eh einen eigenen Puffer brauchst, kannst du die Puffer direkt den Treibern zuordnen. Damit rendert eine Anwendung in "ihren" Puffer und redet somit direkt mit dem Treiber. Der GUI-Server ist nur für das Erzeugen und Zuordnen der Puffer zuständig. ;-)
Also Double Buffering (der gesamte dargestellte Bildschirminhalt) ist eine Möglichkeit, den VESA-Treiber enorm zu beschleunigen. Wenn du nämlich die MTRRs entsprechend gesetzt hast, ist ein Bulk-Upload der 8 MB Framebuffer wesentlich schneller, als viele Zugriffe (z.B. jedes Pixel) auf den Grafikspeicher einzeln durchzuführen.
Sprich für den VESA-Treiber, der sowieso keine Hardwarebeschleunigung hat, lohnt es sich, einen Frame erst im normalen RAM zusammenzustellen und ihn dann mit einmal in den Framebuffer zu kopieren?
Ja.
Wenn ich dann nen Treiber habe für ne einfache Graka, die nicht alzu viel Speicher hat, würde ich das dann so machen, das ich 2 Puffer im RAM habe, jeweils ein Frame und immer in den Puffer zeichnen lasse der nicht gerade angezeigt wird (ist bestimmt auch die gängige Methode für DoubleBuffering oder?).
Genau so. Das ist übrigens nicht abhängig vom Speicher, den die Grafikkarte hat, sondern von dem Speicher, der in der Grafikkarte genutzt ist, also für VESA oder unbeschleunigte Treiber exakt Höhe*Breite*Farbtiefe.
Ich muss mit mal Gallium3D angucken, vllt lohnt es sich das zu portieren. Ansonsten ist so ein 3D-Treiber natürlich eine schöne Beschäftigung wenn man zu viel Zeit hat ;)
Richtig. Wobei ein Gallium3D-Treiber höchstwahrscheinlich POSIX voraussetzt (wahrscheinlich implizit), du also eine solche Umgebung für den Treiber brauchst.
Die Frage die sich mir stellt ist, warum wird eigentlich nicht jedes Fenster im Graka RAM (so fern genug verfügbar) gespeichert und wenn ein neuer Frame erstellt wird, wird einfach aus diesem Puffer gelesen? Ich meine dass das Neuzeichnen in dem Fall wegfällt und es wird nur neugezeichnet, wenn sich etwas im Fensterinhalt geändert hat.
Frühe Grafikkarten waren dumme Framebuffer (z.B. ISA-Karten mit 256-512 KB) mit wenig Speicher, da passt dann exakt ein Frame rein. Inzwischen kannst du den Fensterinhalt cachen (d.h. du speicherst den Fensterinhalt im RAM), das erspart dir das Neuzeichnen, wenn du ein Fenster in den sichtbaren Bereich verschiebst oder in den Vordergrund holst. Das Fenster direkt im Grafikspeicher zu speichern ist möglich, aber nicht unbedingt schnell (man denke an VESA 1.x, wo der Grafikspeicher nicht linear im Adressraum liegt!), außerdem ist der Lesezugriff auf Grafikspeicher wesentlich langsamer, als auf Systemspeicher - Grafikspeicher ist normalerweise langsamer getaktet, evtl. zeitweise gesperrt (während das CRTC gerade drin liest) und liegt nur über ein vergleichsweise langsames Interface, wie z.B. ISA oder PCI an.
Wenn du von einer modernen Grafikkarte mit AGP-/PCIe-Anbindung ausgehst, ist der Unterschied nicht mehr so beträchtlich, aber dann brauchst du (eigentlich) auch einen eigenen Treiber, damit das schnell ist.
Der einzige Grund der mir spontan einfällt das nicht zu machen ist, dass es "billiger" ist nur neuzuzeichnen, wenn das Fenster oder ein Teil davon zu sehen ist und ansonsten wird das Zeichnen einfach nicht gemacht.
Du kannst auf den Grafikspeicher nur indirekt (VESA 1.x) oder langsam (VESA 2.0/3.0) zugreifen. Den Effekt siehst du, wenn du mit dem VESA-Treiber für X11 oder Windows (kein Grafiktreiber) arbeitest und dann Fenster mitsamt Inhalt verschiebst. Das dauert und nervt. Im RAM geht das sehr schnell und die Daten dann in wenigen Zugriffen in die Grafikkarte stopfen ist schneller, als das in vielen kleinen Zugriffen zu machen.
Mit der Redraw-Logik, also welche Teile neu gezeichnet werden müssen, hat das nichts zu tun. Das erledigt auch nicht der GUI-Server. Die Anwendung bekommt ein Ereignis, welches nicht nur besagt "zeichne neu", sondern auch exakt die Bereiche angibt, welche neu gezeichnet werden müssen - das muss nicht das gesamte Fenster sein. Es gibt schließlich auch Anwendungen, die nicht neuzeichnen können (weil sie ihren Fensterinhalt nicht cachen) und einfach Teile des Inhalts (z.B. Graphen, Text, Benutzeroberfläche) neu berechnen und dann darstellen.
Gruß,
Svenska
-
Achso. Naja, wenn du für jedes Fenster eh einen eigenen Puffer brauchst, kannst du die Puffer direkt den Treibern zuordnen. Damit rendert eine Anwendung in "ihren" Puffer und redet somit direkt mit dem Treiber. Der GUI-Server ist nur für das Erzeugen und Zuordnen der Puffer zuständig.
Wir waren uns ja einig, das die Graka nur in ihrem eigenen Speicher schreiben kann (Hardwarebeschleunigung) und da wäre es dann besser, wenn der GUI-Server sich um den ganzen Kram kümmert auf welchem Treiber das Fenster gerade läuft und das sollte auch den Umzug eines Fenster von einem Desktop zu einem anderen erleichtern.
Also wenn Hardwarebeschleunigung vorhanden ist, werde ich höchstwahrscheinlich auch genug Graka RAM haben um DoubleBuffering im Graka RAM zu machen und das würde heißen das jedes Mal neugezeichnet werden muss für ein Frame.
Ist die Graka so alt (oder ich habe keinen Treiber -> VESA), das ich nur nen Framebuffer habe, dann mache ich DoubleBuffering im RAM, aber es wird trotzdem für jedes Frame neugezeichnet.
Bei dieser Methode wäre doch aber eine sehr hohe CPU Belastung vorhanden, wegen dem ständigen Neuzeichnen oder?
Irgendwie muss man ja noch den Fall abfangen, das sich gar nichts geändert hat.
Richtig. Wobei ein Gallium3D-Treiber höchstwahrscheinlich POSIX voraussetzt (wahrscheinlich implizit), du also eine solche Umgebung für den Treiber brauchst.
Ich spiele immerhin schon mit dem Gedanken, meinem Kernel noch nen fork() hinzuzufügen (exec() brauche ich ja nicht explizit, dafür habe ich nen createTask()) und damit sollte ja die größte Hürde für POSIX genommen sein und eventuell kann man auch einiges anpassen.
Mit der Redraw-Logik, also welche Teile neu gezeichnet werden müssen, hat das nichts zu tun. Das erledigt auch nicht der GUI-Server. Die Anwendung bekommt ein Ereignis, welches nicht nur besagt "zeichne neu", sondern auch exakt die Bereiche angibt, welche neu gezeichnet werden müssen - das muss nicht das gesamte Fenster sein. Es gibt schließlich auch Anwendungen, die nicht neuzeichnen können (weil sie ihren Fensterinhalt nicht cachen) und einfach Teile des Inhalts (z.B. Graphen, Text, Benutzeroberfläche) neu berechnen und dann darstellen.
Es geht im Endeffekt um die Zeichenfunktionen, die müssen ja dann insoweit optimiert sein, das wirklich nur in dem Bereich der benötigt wird auch gezeichnet wird, sprich ist das Ende des Bereichs erreicht wird auch kein Code mehr ausgeführt (mal vereinfacht gesagt).
-
Wir waren uns ja einig, das die Graka nur in ihrem eigenen Speicher schreiben kann (Hardwarebeschleunigung) und da wäre es dann besser, wenn der GUI-Server sich um den ganzen Kram kümmert auf welchem Treiber das Fenster gerade läuft und das sollte auch den Umzug eines Fenster von einem Desktop zu einem anderen erleichtern.
Ja. Der GUI-Server erzeugt den Puffer, ordnet ihn einer Grafikkarte zu und verwaltet alle im System existierenden Puffer.
Also wenn Hardwarebeschleunigung vorhanden ist, werde ich höchstwahrscheinlich auch genug Graka RAM haben um DoubleBuffering im Graka RAM zu machen und das würde heißen das jedes Mal neugezeichnet werden muss für ein Frame.
Auch Trident, WD90Cxx oder S3 Trio können Hardwarebeschleunigung (2D) und haben sehr wenig Grafikspeicher. Ist also ein schlechtes Kriterium. ;-) DoubleBuffering würde ich im hardwarespezifischen Treiber regeln, da der die Hardware kennt.
Bei dieser Methode wäre doch aber eine sehr hohe CPU Belastung vorhanden, wegen dem ständigen Neuzeichnen oder?
Irgendwie muss man ja noch den Fall abfangen, das sich gar nichts geändert hat.
Du kannst in der Schnittstelle zu Anwendungen festlegen, dass eine Anwendung den GUI-Server informieren muss, dass sich im Puffer etwas geändert hat. Das ist sinnvoll, weil wenn sich nichts ändert, brauchst du dir keinen Aufwand machen und Anwendungen können so eine große Menge an Änderungen durchführen, ehe es dargestellt wird (man bedenke Netzwerklatenz oder so).
Konkret zum VESA-Treiber: Du hast den Framebufferinhalt (z.B. 1024*768*4 Byte) genau zweimal, einmal im Grafikspeicher (wird vom CRTC ausgelesen und auf dem Bildschirm dargestellt) und eine Kopie davon im RAM.
Jede Anwendung ändert nun ihren eigenen Puffer (im unbeschleunigten Fall ist das also ein "Framebuffer" des Fensterinhalts) und meldet das an den GUI-Server.
Der GUI-Server meldet nun, da er die Übersicht über die Puffer hat, an den VESA-Treiber, welche seiner Puffer (verdeckte Fenster sind unnötig) er aktualisieren muss.
Der VESA-Treiber baut nun aus allen Puffern einen Frame in der Schattenkopie zusammen und kopiert den "im Block" in den Grafikspeicher. Kopierst du nur während VSYNC, hast du kein Tearing oder so und sparst dir einen Puffer. Bis zum nächsten Ereignis brauchst du nichts mehr kopieren, kostet also bis dann auch keine CPU-Zeit.
Damit brauchst du eine Schattenkopie des Framebuffers im System-RAM und hast trotzdem kein Tearing (der Grund für Double-Buffering), und da du nur auf der Schattenkopie im RAM arbeitest, hast du auch den Performancevorteil.
Es geht im Endeffekt um die Zeichenfunktionen, die müssen ja dann insoweit optimiert sein, das wirklich nur in dem Bereich der benötigt wird auch gezeichnet wird, sprich ist das Ende des Bereichs erreicht wird auch kein Code mehr ausgeführt (mal vereinfacht gesagt).
Das Neuzeichnen ist Aufgabe der Anwendung. Diese weiß am allerbesten, welche Teile wie neugezeichnet werden müssen und welche Objekte/Widgets davon betroffen sind. Im Endeffekt guckt die Anwendung nach, welche Widgets in dem vom OS genannten Bereich drin sind und ruft für jedes Widget eine Anweisung "zeichne dich neu". Das Widget wird von einem Toolkit (Qt, GTK) bereitgestellt und dort findet auch die Implementation statt, ob nun 2D- oder 3D-Beschleunigung genutzt wird oder auch nicht.
Die Zeichenfunktionen selbst haben von Bereichen keine Ahnung, sondern liegen eher in der Kategorie "gefülltes Rechteck in grün von (50|75) bis (90|105)". Diese Funktionen mit geeigneten Parametern optimal aufzurufen, ist wieder Aufgabe der Anwendung. Der GUI-Server hat damit nichts zu tun.
Gruß,
Svenska
-
Nochmal zu dem Neuzeichnen.
Ein wenig Grafikprogrammierung habe ich schon mit Java gemacht (dank an die Uni ;) ).
Dir als Fenster wird ja eine Nachricht geschickt, das sich etwas geändert hat und man bekommt gleich noch einen Clipping Bereich dazu wo das war.
Ich dachte jetzt eigentlich das wenn man diesen Clipping Bereich als aktuellen Zeichenbereich nutzt, das dann ein Aufruf an RechteckFüllen() auch nur das "zeichnet" was in dem Clipping Bereich liegt?
Ich weiß auch aus Beobachtungen von Windows, dass dort die Fenster irgendwo gecacht werden. Denn wenn man bei einem Java Programm nicht neuzeichnet, aber ein Fenster einen Teil meines Fensters überdeckt und dann wieder "eggenommen" wird. Dann wird dieser Teil (der verdeckt war) zwar nicht neugezeichnet, aber der restliche Fensterinhalt ist noch da.
Da gibt es jetzt 2 Möglichkeiten, entweder wird jedes Fenster irgendwo gecacht oder Windows weiß sehr genau was sich wo geändert hat und dann wird auch der alte Frame weiterbenutzt und es wird nur das geändert was geändert werden muss.
(Wobei das Fenster cachen zwar mehr Speicher verbraucht, aber auch wesentlich schneller sein dürfte)
-
Was du meinst, ist gerade kein Cachen des Bildschirminhalts, denn die Teile, die überdeckt wurden, sind kaputt. Der GUI-Server darf natürlich auch einfach schwarze Rechtecke darübermalen, aber das ist ja an sich egal.
Windows Vista/7 cachen übrigens den gesamten Fensterinhalt, um auch nicht-dargestellte Fenster als Vorschau in der Taskleiste anbieten zu können und außerdem bei Anwendungen, die gerade nicht reagieren, trotzdem das Fenster in den Vordergrund holen zu können.
Wird der Speicher knapp (wo auch immer), wirfst du nicht-dargestellte Fenster einfach weg und verlierst für dieses Fenster das Caching.
-
Ich muss nochmal ein paar Sachen nachfragen :-D
Also nochmal zu den Buffern. Sagen wir mal ich habe keinen VESA Treiber sondern einen "richtigen" Treiber. Schreiben da dann die Programme normalerweise direkt in den Graka-RAM (direkt in den Buffer des Frames) oder schreiben sie direkt in den Graka-RAM (direkt in den Buffer ihres Windows) oder schreiben sie in einen Buffer im normalen RAM und dann holt sich der Graka-Treiber die Daten aus den Buffern bzw. der GUI-Server schickt die Daten aus den Buffern an den Graka-Treiber?
Dann mal zur direkten Implementation.
Ich möchte es jetzt so machen, das der GUI-Server die "Dekoration" (Titelleise + Rahmen eines Fensters) übernimmt und die Anwendung direkt im Fenster alles selber machen muss.
Jedes Ereignis welches innerhalb des Fensters (also der Bereich den die Anwendung bearbeitet) passier (z.B. Maus-Klick, Tastatur-Eingabe, Maus-Bewegung usw.) wird als Nachricht an das Fenster geschickt, aber nicht mit den globalen Koordinaten, sondern mit den Fenster-lokalen Koordinaten. Ist das soweit in Ordnung oder wird es damit Probleme geben (Performance und andere)?
Ich möchte dann ein paar Standard-Bibliotheken schreiben (z.B. wären das bei Haiku die Kits) mit denen es ziemlich einfach werden sollte eine GUI zu schreiben, das ganze in C++, weil sich Objektiorientierung ja praktisch anbietet.
Das Fenster hat eine "Liste" (ich denke man sollte das nicht wortwörtlich nehmen, ansonsten könnte das sehr langsam werden) mit allen Objekten im Fenster (z.B. Buttons, Labels und was es nicht noch alles gibt). Diese "Liste" wird durchgegangen und geschaut, welche Objekte die Nachricht/das Event betrifft.
Von diesen Objekten wird dann jeweils eine "processMsg(msg_t msg)" aufgerufen und bei diesen Objekten kann es dann wieder passieren das diese auch wieder mehrere unter Objekte haben und das selbe durchführen müssen.
Was ist davon zu halten? Zu langsam, zu umständlich?
Was ich auf keinen Fall möchte, ist alles als Fenster betrachten und auch so beim GUI-Server zu registrieren. Denn das würde die ganze komplexität auf den GUI-Server übertragen und das will ich nicht, auch macht es bestimmte Anwendungen schwieriger (ich denke da an Tabs, wo man dann ja bei einem Tab-wechsel alles "Fenster" aus dem alten Tab "löschen" müsste und alle "Fenster" von dem neuem Tab registrieren müsste).
-
Was ich auf keinen Fall möchte, ist alles als Fenster betrachten und auch so beim GUI-Server zu registrieren. Denn das würde die ganze komplexität auf den GUI-Server übertragen und das will ich nicht, auch macht es bestimmte Anwendungen schwieriger (ich denke da an Tabs, wo man dann ja bei einem Tab-wechsel alles "Fenster" aus dem alten Tab "löschen" müsste und alle "Fenster" von dem neuem Tab registrieren müsste).
Nein, das Fenster des einen Tabs würde in den Hintergrund kommen und dafür das des neuen Tabs in der Vordergrund. Kein Anlass, irgendwas zu löschen oder neu anzulegen.
-
Nein, das Fenster des einen Tabs würde in den Hintergrund kommen und dafür das des neuen Tabs in der Vordergrund. Kein Anlass, irgendwas zu löschen oder neu anzulegen.
Auch eine Möglichkeit, aber ich will das ja eh nicht so machen ;)
-
Naja, ob auf Server- oder auf Clientseite, irgendwo musst du es machen. ;)
-
Naja, ob auf Server- oder auf Clientseite, irgendwo musst du es machen.
Lieber auf Clientseite, weil das lässt sich leichter parallelisieren. Denn es ist einfacher gleichzeitig auf mehreren Listen zu arbeiten als gleichzeitig auf einer.
Zumal ich noch andere Gründe habe, warum ich das auf Clientseite haben will (Systemressourcen).
-
Schreiben da dann die Programme normalerweise direkt in den Graka-RAM (direkt in den Buffer des Frames) oder schreiben sie direkt in den Graka-RAM (direkt in den Buffer ihres Windows) oder schreiben sie in einen Buffer im normalen RAM und dann holt sich der Graka-Treiber die Daten aus den Buffern bzw. der GUI-Server schickt die Daten aus den Buffern an den Graka-Treiber?
Grundsätzlich ein konkretes Implementierungsdetail. ;-) Fenster sollte allerdings nicht in den Gesamtbildschirm rendern, denn wenn sie im Hintergrund sind (z.B. fürs Vorschaufenster), werden sie ja nicht dargestellt. Das setzt natürlich insgesamt genug Speicher voraus.
Sie rendern also in einen Window-Buffer, der im Grafikspeicher liegen kann (Bedingung für 3D), aber der auch im System-RAM liegen kann (wenn nicht genug Grafikspeicher vorhanden ist, z.B. alte 2D-Grafikkarte; oder für Netzwerktransparenz).
Jedes Ereignis welches innerhalb des Fensters (also der Bereich den die Anwendung bearbeitet) passier (z.B. Maus-Klick, Tastatur-Eingabe, Maus-Bewegung usw.) wird als Nachricht an das Fenster geschickt, aber nicht mit den globalen Koordinaten, sondern mit den Fenster-lokalen Koordinaten. Ist das soweit in Ordnung oder wird es damit Probleme geben (Performance und andere)?
Klingt vernünftig. Beachte, dass du systemweite Shortcuts auch definieren können solltest. Außerdem sinnvoll wäre, dass du vom Fenster eine Rückmeldung bekommst, ob das Ereignis auch verarbeitet werden konnte (bzw. Fenster müssen Ereignisse zum Empfang anmelden).
Grund: Wenn du als Hauptprogramm ein kleines Unterfenster erzeugst, dann möchtest du nicht einen vollständigen Event-Handler da reinbauen, sondern dich nebenbei auch darum kümmern können. Das heißt, dein GUI-Server leitet das an das Fenster weiter, welches das Ereignis möchte. Will es das nicht, geht das Ereignis an das nächsthöhere Fenster, bis du schlussendlich beim Root-Fenster ankommst. Beispiel: Widgets reagieren nicht auf Rechtsklick, da soll dann das System-Kontextmenü kommen. Oder so ähnlich.
Dazu müssen Ereignisse immer auch eine Window-ID haben zu dem Fenster, auf das sie sich beziehen.
Ich möchte dann ein paar Standard-Bibliotheken schreiben (z.B. wären das bei Haiku die Kits) mit denen es ziemlich einfach werden sollte eine GUI zu schreiben, das ganze in C++, weil sich Objektiorientierung ja praktisch anbietet.
Klingt gut.
Das Fenster hat eine "Liste" (ich denke man sollte das nicht wortwörtlich nehmen, ansonsten könnte das sehr langsam werden) mit allen Objekten im Fenster (z.B. Buttons, Labels und was es nicht noch alles gibt). Diese "Liste" wird durchgegangen und geschaut, welche Objekte die Nachricht/das Event betrifft.
Ich denke, das sollte der Anwendung überlassen werden, wie sie darauf reagiert. Grundsätzlich klingt das gut.
Von diesen Objekten wird dann jeweils eine "processMsg(msg_t msg)" aufgerufen und bei diesen Objekten kann es dann wieder passieren das diese auch wieder mehrere unter Objekte haben und das selbe durchführen müssen.
Ja, ist machbar. Manche Steuerelemente haben halt einen Zustandsautomaten (du nanntest Tab-Container) und stellen selbst wieder Fenster dar.
Was ich auf keinen Fall möchte, ist alles als Fenster betrachten und auch so beim GUI-Server zu registrieren. Denn das würde die ganze komplexität auf den GUI-Server übertragen und das will ich nicht, auch macht es bestimmte Anwendungen schwieriger (ich denke da an Tabs, wo man dann ja bei einem Tab-wechsel alles "Fenster" aus dem alten Tab "löschen" müsste und alle "Fenster" von dem neuem Tab registrieren müsste).
Warum nicht?
Dein Tab-Container erstellt für jeden Tab ein "Fenster ohne Dekoration" und macht die halt sichtbar/unsichtbar oder verschiebt sie in seinem lokalen Z-Puffer in den Vorder-/Hintergrund. Das liegt schon nahe.
Außerdem könntest du dann wieder GUI-Server-zentral die Daten cachen, sofern du den Speicher übrig hast. Das ist bei GUI-via-Netzwerk wieder von Vorteil, da du auch Dinge, die nicht dargestellt werden, zwischenspeichern kannst (im Gegensatz zu z.B. VNC). Bei einem lokalen GUI-Server musst du das nicht durchführen, aber ein GUI-Server-Port für X11 könnte/sollte da schon aggressiv cachen. ;-)
Gruß,
Svenska
-
Um nochmal auf die Buffer zu kommen. Die beiden Varianten Buffer (des Fensters) im Graka oder normalen RAM sind mir klar, aber gibt es auch GUIs die direkt in den Frame-Buffer (damit meine ich direkt den Buffer den die Graka dann als nächsten Frame darstellt) schreiben? Weil ich da dann halt das Problem sehe, das dieser Buffer nicht zusammenhängend sein kann. Dafür gibt es mehrere Gründe z.B. dass das Fenster nicht den ganzen Bildschirm einnimmt oder der Offscreen-Speicher (sprich eine Zeile nimmt mehr Speicher ein als sie eigentlich müsste).
Beachte, dass du systemweite Shortcuts auch definieren können solltest.
Was genau meinst du damit? Meinst du damit sowas wie STRG+ALT+ENTF, das dann der Taskmanager aufgerufen wird oder das die Windows-Taste das Startmenü öffnet?
Solche Events würde ich gar nicht erst an ein Fenster weitersenden (oder doch?).
Außerdem sinnvoll wäre, dass du vom Fenster eine Rückmeldung bekommst, ob das Ereignis auch verarbeitet werden konnte (bzw. Fenster müssen Ereignisse zum Empfang anmelden).
Meinst du sowas wie eine Empfangsbestätigung? Wenn ja, das würde den IPC-Overhead ganz schön in die Höhe treiben und man müsste dann festlegen was eine angemessene Zeitspanne (für alle Systeme!) ist um eine Bestätigung zu bekommen.
Welchen Vorteil siehst du darin, wenn Fenster Ereignisse erst zum Empfang anmelden müssen (du meinst ja sicherlich, das sie nur Events bekommen, die sie auch bekommen wollen?)?
Spontan sehe ich nur den Vorteil, das ein wenig IPC wegfällt.
Wenn du als Hauptprogramm ein kleines Unterfenster erzeugst, dann möchtest du nicht einen vollständigen Event-Handler da reinbauen, sondern dich nebenbei auch darum kümmern können. Das heißt, dein GUI-Server leitet das an das Fenster weiter, welches das Ereignis möchte. Will es das nicht, geht das Ereignis an das nächsthöhere Fenster, bis du schlussendlich beim Root-Fenster ankommst. Beispiel: Widgets reagieren nicht auf Rechtsklick, da soll dann das System-Kontextmenü kommen. Oder so ähnlich.
Also erstmal gutes Bsp. mit den Unterfenstern, daran habe ich noch gar nicht gedacht :( Meine momentane Planung sieht es vor dass das alles vom Clienten gemacht werden muss (warum auch nicht, passiert ja schließlich innerhalb seines Fensters), aber da sehe ich dann jetzt spontan Probleme mit der Konsistenz des Designs.
Wenn ich sowas aber zulassen würde, öffnet das dem Prinzip "alles ist ein Fenster" wieder die Türen und das wollte ich eigentlich vermeiden.
Ich denke, das sollte der Anwendung überlassen werden, wie sie darauf reagiert. Grundsätzlich klingt das gut.
Ich bin mir nicht sicher ob ich verstanden habe was du meinst, aber ich meinte damit das meine Standard-Bibliotheken das so handhaben sollen. Dem Programmierer steht es frei komplett alles von Hand zu schreiben, aber meine Bibliotheken werden es dann so machen.
Manche Steuerelemente haben halt einen Zustandsautomaten (du nanntest Tab-Container) und stellen selbst wieder Fenster dar.
Naja, so sehe ich das halt (noch) nicht. Bei mir gibt es per Anwendung nur ein Fenster alles was da drin ist, sind Objekte und interessieren den GUI-Server nicht mehr.
Warum nicht?
Mein momentanes Problem mit "alles ist ein Fenster" ist, das jedes Fenster einen IPC-Port hat, wo dann Events hingeschickt werden und unter Umständen können das miteinmal verdammt viele Ports werden (was auch Kernel-Speicher kostet, den ich eigentlich nicht auslagern können will) und ich brauche für viele andere Dinge auch noch Ports und wenn ich mir da z.B. so ne Webpage angucke, wo man dann ja auch sagen könnte, ok jeder Button ist ein Fenster, dann jede TextArea usw. Da kommt man schnell auf verdammt viele Ports (vorallem wenn man dann viele Tabs offen hat) und da ich ja meine Ports auch noch beschränke (128k) könnte das problematisch werden.
-
Die beiden Varianten Buffer (des Fensters) im Graka oder normalen RAM sind mir klar, aber gibt es auch GUIs die direkt in den Frame-Buffer (damit meine ich direkt den Buffer den die Graka dann als nächsten Frame darstellt) schreiben?
Ja, siehe DirectFB oder das, was Windows CE macht.
Weil ich da dann halt das Problem sehe, das dieser Buffer nicht zusammenhängend sein kann. Dafür gibt es mehrere Gründe z.B. dass das Fenster nicht den ganzen Bildschirm einnimmt oder der Offscreen-Speicher (sprich eine Zeile nimmt mehr Speicher ein als sie eigentlich müsste).
Richtig. Bei DirectFB/WinCE geht es auch eher um Vollbildanwendungen. Die wichtigen Parameter dafür sind Auflösung (Zahl der Pixel), Farbtiefe (Bit pro Pixel), Zeilen- und Spaltenpitch (Abstand in Bytes von Zeile zu Zeile bzw. Spalte zu Spalte).
Beachte, dass du systemweite Shortcuts auch definieren können solltest.
Was genau meinst du damit? Meinst du damit sowas wie STRG+ALT+ENTF, das dann der Taskmanager aufgerufen wird oder das die Windows-Taste das Startmenü öffnet?
Solche Events würde ich gar nicht erst an ein Fenster weitersenden (oder doch?).
Genau. Also hast du eine zentrale Instanz in deinem GUI-Server (oder im clientseitigen Root-Window, je nachdem, was du eher magst), wo Events erstmal gefiltert werden, ehe sie dann unter Umständen an Fenster weitergeleitet werden.
Welchen Vorteil siehst du darin, wenn Fenster Ereignisse erst zum Empfang anmelden müssen (du meinst ja sicherlich, das sie nur Events bekommen, die sie auch bekommen wollen?)?
Wenn ich ein kleines Dialogfenster erzeuge, z.B. ein Fenster zur Dateiauswahl, dann möchte ich keinen vollwertigen Eventhandler für dieses Fenster implementieren, sondern ich habe im Hauptprogramm bereits einen, der das mit erledigen kann. Das spart Code und Aufwand in den Anwendungen.
Zweitens kannst du beim Anmelden von Events ja auch mitgeben, dass du für die Maus z.B. absolute Koordinaten möchtest (Standardfall) oder eben relative Events (für Vollbildspiele wichtig). Oder, dass du eine anwendungsseitige Tastaturbelegung haben möchtest und darum die Tastaturevents in "roh" haben möchtest (Bildschirmtastatur für fremde Sprachen).
Viele dieser Flags sind im Normalfall uninteressant, aber für Spiele sehr wichtig.
Wenn ich sowas aber zulassen würde, öffnet das dem Prinzip "alles ist ein Fenster" wieder die Türen und das wollte ich eigentlich vermeiden.
Naja, dieses Prinzip ist für manche Anwendungsfälle aber schon sehr praktisch, darum solltest du es nicht grundsätzlich verbieten.
Und der GUI-Server ist ja eigentlich der Fensterverwalter des Grafiksystems, also sollte er wenigstens das effizient können.
Naja, so sehe ich das halt (noch) nicht. Bei mir gibt es per Anwendung nur ein Fenster alles was da drin ist, sind Objekte und interessieren den GUI-Server nicht mehr.
Was machst du mit GIMP? ;-)
Mein momentanes Problem mit "alles ist ein Fenster" ist, das jedes Fenster einen IPC-Port hat, wo dann Events hingeschickt werden
Aua. Wie wäre es mit einem IPC-Port pro Anwendung, den sie zugeteilt kriegt, wenn sie das erste Fenster erzeugen möchte?
Gruß,
Svenska
-
Genau. Also hast du eine zentrale Instanz in deinem GUI-Server (oder im clientseitigen Root-Window, je nachdem, was du eher magst), wo Events erstmal gefiltert werden, ehe sie dann unter Umständen an Fenster weitergeleitet werden.
Naja, dafür ist doch, unter anderem, der GUI-Server da ;)
Wenn ich ein kleines Dialogfenster erzeuge, z.B. ein Fenster zur Dateiauswahl, dann möchte ich keinen vollwertigen Eventhandler für dieses Fenster implementieren, sondern ich habe im Hauptprogramm bereits einen, der das mit erledigen kann. Das spart Code und Aufwand in den Anwendungen.
Genau dafür ist doch meine Standard-Bibliothek da. Die stellt den ganzen Code bereit und du überlagerst nur den Code/Methoden die du anders haben willst.
So bleibt der Code für jedes Fenster (so lange es sich am Standard orientiert) gleich und ist auch (theoretisch) nur einmal im Speicher, da es ja eine Shared-Library ist.
An was für Events denkst du da eigentlich wenn es welche sein sollen, die auch das Hauptprogramm bearbeiten kann?
Zweitens kannst du beim Anmelden von Events ja auch mitgeben, dass du für die Maus z.B. absolute Koordinaten möchtest (Standardfall) oder eben relative Events (für Vollbildspiele wichtig). Oder, dass du eine anwendungsseitige Tastaturbelegung haben möchtest und darum die Tastaturevents in "roh" haben möchtest (Bildschirmtastatur für fremde Sprachen).
Ok, sowas könnte man so lösen, das man Events zwar nicht anmelden kann, aber das man bestimmen kann was für Daten die Events enthalten (z.B. relative oder absolute Maus-Koordinaten). Denn ich wüsste auch nicht wo das Problem liegt das man ein Event bekommt, das gerade ein rechts-Klick gemacht wurde und man das nicht wissen will. Dann wird die Nachricht halt einfach verworfen (gut man könnte IPC sparen).
Was machst du mit GIMP?
Ok, aber das würde sich nicht mit meinem Konzept beißen. Ich hätte mich besser ausdrücken sollen, was ich im Moment noch nicht sehe das es der GUI-Server macht, ist es sowas wie Unter-Fenster (also Fenster die nur innerhalb eines anderen Fensters sind und dieses auch nicht verlassen können) durch den GUI-Server verwalten zu lassen.
Das eigentliche Problem sind halt die Ports, ok ich könnte deren Anzahl erhöhen, aber so ist der GUI-Server einfacher, weil er sich nicht darum kümmern muss ob ein Fenster auch außerhalb eines anderen Fensters darstellbar ist.
Aua. Wie wäre es mit einem IPC-Port pro Anwendung, den sie zugeteilt kriegt, wenn sie das erste Fenster erzeugen möchte?
Einen pro Anwendung halte ich für zu wenig. Mein Ziel ist es durch meine Standard-Bibliothek den GUI-Code automatisch zu "threaden" (Multithreading) und da macht ein Port pro Fenster einfach mehr Sinn. Das würde dann halt alles in meiner Window-Klasse gemacht werden.
-
An was für Events denkst du da eigentlich wenn es welche sein sollen, die auch das Hauptprogramm bearbeiten kann?
WindowSizeChange, Redraw, KeyPress, LostFocus, GotFocus, ...
Denn ich wüsste auch nicht wo das Problem liegt das man ein Event bekommt, das gerade ein rechts-Klick gemacht wurde und man das nicht wissen will. Dann wird die Nachricht halt einfach verworfen (gut man könnte IPC sparen).
Richtig; bei X11 liegt das daran, dass das IPC mit sehr hoher Latenz verbunden sein kann (Netzwerk).
Einen pro Anwendung halte ich für zu wenig. Mein Ziel ist es durch meine Standard-Bibliothek den GUI-Code automatisch zu "threaden" (Multithreading) und da macht ein Port pro Fenster einfach mehr Sinn. Das würde dann halt alles in meiner Window-Klasse gemacht werden.
Hmm, Geschmackssache. Achte nur darauf, dass du dich nicht zu sehr limitierst.
Gruß
-
WindowSizeChange, Redraw, KeyPress, LostFocus, GotFocus, ...
Ok, aber du musst doch die Events auch für nen Öffnen-Dialog implementieren, da doch dort was ganz anderes passieren kann, wenn eine Taste gedrückt wurde.
Hinzu kommt noch, das der Code ja im Endeffekt der gleiche ist, wie gesagt, was man nicht implementiert da wird dann der Standard-Code ausgeführt und der ist eh immer vorhanden. Du hast ja nur ein Objekt und die Variablen haben andere Werte aber der Code der Methoden ist der gleiche (z.B. bei einem Redraw).
Am Bsp. von KeyPress, ich würde dieses Event sogar gar nicht implementieren bzw. dies den Clienten machen lassen. Bei mir würde es dann nur ein Event KeyDown und KeyUp geben und wenn der Client will kann er sich selbst ein Event KeyPress schicken (ohne das IPC dazu genutzt wird), wenn das KeyUp für eine Taste kommt, wo vorher ein KeyDown kam.
Hmm, Geschmackssache. Achte nur darauf, dass du dich nicht zu sehr limitierst.
Wo limitiere ich mich denn? Meinst du das ich eventuell nicht genügend Ports habe? Dagegen habe ich etwas geplant (eine Idee von erik), so dass weniger Sachen einen Port voraussetzen.
-
Ok, aber du musst doch die Events auch für nen Öffnen-Dialog implementieren, da doch dort was ganz anderes passieren kann, wenn eine Taste gedrückt wurde.
Du schreibst richtig: kann, nicht muss.