Hallo LUG,
ich habe ein ganz seltsames Problem mit meinem Netscape- Browser. Es handelt sich um die aktuelle Version 4.77. Nach der Installation in /usr/local/netscape/ zeigt der Navigator nach dem Starten seine Icons nur in schwarzen Umrissen - also nicht farbig wie sonst üblich. Außerdem kann er sein Plugin-Verzeichnis nicht finden, obwohl MOZILLA_HOME gesetzt und exportiert ist. Mein System: Kernel 2.4.3, Framebuffer-Console, Framebuffer- X-Server 3.3.6
Hat jemand schon die Version 4.77 ausprobiert und hat ähnliche Probleme?
Gruß, Matthias
On Sat, Apr 14, 2001 at 09:31:19PM +0200, Matthias Petermann wrote:
Hallo LUG,
ich habe ein ganz seltsames Problem mit meinem Netscape- Browser. Es handelt sich um die aktuelle Version 4.77. Nach der Installation in /usr/local/netscape/ zeigt der Navigator nach dem Starten seine Icons nur in schwarzen Umrissen - also nicht farbig wie sonst üblich. Außerdem
Das Problem besteht nicht erst ab 4.77. Wennder X-Server auf 24 Bit Farbtiefe gestellt ist kann das Netscape die Pixmaps nicht richtig darstellen. Stell mal 32 ein. (DefaultColorDepth 32 oder so etwa)
Reinhard
Hallo Reinhard,
vielen Dank für Deinen Tipp :) Jetzt klappts wirklich wieder. Mir kam das nur so vor, weil ich zeitgleich mit dem Netscape auch mein System auf Framebuffer-Betrieb umgestellt habe. (wegen der schönen großen Konsole).
Matthias
On Sun, Apr 15, 2001 at 12:04:21PM +0200, Reinhard Foerster wrote:
Das Problem besteht nicht erst ab 4.77. Wennder X-Server auf 24 Bit
On Sun, Apr 15, 2001 at 09:53:28PM +0200, Matthias Petermann wrote:
Hallo Reinhard,
vielen Dank für Deinen Tipp :) Jetzt klappts wirklich wieder. Mir kam das nur so vor, weil ich zeitgleich mit dem Netscape auch mein System auf Framebuffer-Betrieb umgestellt habe. (wegen der schönen großen Konsole).
Da sehnt man sich nach den guten alten ET-4000-GraKas zurück. Die hatten mit 132x80 einen genialen Textmodus und man brauchte diesen FB-Kram auf PCs nicht.
Reinhard
On Monday 16 April 2001 01:34, Sebastian Roth wrote:
Da sehnt man sich nach den guten alten ET-4000-GraKas zurück. Die hatten mit 132x80 einen genialen Textmodus und man brauchte diesen FB-Kram auf PCs nicht.
Wofür sind Framebuffer eigentlich gut? Bessere Performance?
Vereinfacht stellt es sich so dar:
FB's sind für die Vereinheitlichung der Schnittstellen da. Ohne FB hat ein Grafikprogrammierer nur die Wahl zwischen X (langsam) und den Zugriff selbst programmieren (wie unter DOS, extrem gefährlich). Mit Framebuffer hat er die Möglichkeit recht schnell auf die Grafikhardware zuzugreifen ohne die Treiber selbst schreiben zu müssen und das auch noch architekturübergreifend (zumindest in der Theorie, in der der LinuxFB auch einigermaßen kompatibel zum Solaris-FB sein sollte).
Konrad
On Mon, Apr 16, 2001 at 10:10:54AM +0200, Konrad Rosenbaum wrote:
Wofür sind Framebuffer eigentlich gut? Bessere Performance?
Vereinfacht stellt es sich so dar:
FB's sind für die Vereinheitlichung der Schnittstellen da. Ohne FB hat ein Grafikprogrammierer nur die Wahl zwischen X (langsam) und den Zugriff selbst programmieren (wie unter DOS, extrem gefährlich). Mit Framebuffer hat er die Möglichkeit recht schnell auf die Grafikhardware zuzugreifen ohne die Treiber selbst schreiben zu müssen und das auch noch architekturübergreifend (zumindest in der Theorie, in der der LinuxFB auch einigermaßen kompatibel zum Solaris-FB sein sollte).
Das war jetzt die linuxistische Erklärung. Normalerweise ist ein Framebuffer einfach das, was man hier im allgemeinen mit Grafikkarte bezeichnet. Was Konrad bescheibt ist die Software-Schnittstelle zu dieser Hardware.
Reinhard, der die Textmodi von GraKas in PCS zum Textanzeigen auf einer GraKa eines PCs gut findet und irgendwelche Unterstützung von speziellen Grafikkarten IM KERN doof findet. Für ein plattform- übergreifendes dev für die Console tun es auch VGA + VESA.
Am Montag, 16. April 2001 11:11 schrieb Reinhard Foerster:
Reinhard, der die Textmodi von GraKas in PCS zum Textanzeigen auf einer GraKa eines PCs gut findet und irgendwelche Unterstützung von speziellen Grafikkarten IM KERN doof findet. Für ein plattform- übergreifendes dev für die Console tun es auch VGA + VESA.
Das ist aber dann auch nur ein Kompromiss, z.B. müssen Programme, die die SVGAlib nutzen, suid installiert werden. Der Sinn des Kernels ist es ja, dafür zu sorgen, daß der Hardwarezugriff geregelt abläuft. Ein /dev/ttyS1 ist Kernelsache, also sollte es ein /dev/fb* auch sein. Es geht ja nicht nur um die Konsole, sondern z.B. auch um diese netten kleinen Handhelds, die es jetzt (fast) überall gibt. Un plattformübergreifend ist VESA auch nicht, zumindest in der Spezifikation von v1.2/v2.0 hat es noch Interrupts gehagelt ohne Ende.
Die Performance auf X11-Systemen ist auch trotz aller erdenklichen Erfindungen noch nicht optimal, und genaugenommen benötigt die DRI auch wieder direkten Zugriff auf die Hardware. Und in Zukunft ist nicht Remote-Administration, sondern Entertainment die Hauptanwendung für die grafische Oberfläche von Pinguinen.
Josef Spillner (sich in die Diskussion einhängend)
P.S. Richtig plattformübergreifend ist doch nur ein OS: Unununium :) (uuu.sourceforge.net)
On Mon, Apr 16, 2001 at 10:40:10AM +0200, Josef Spillner wrote:
Das ist aber dann auch nur ein Kompromiss, z.B. müssen Programme, die die SVGAlib nutzen, suid installiert werden. Der Sinn des Kernels ist es ja, dafür zu sorgen, daß der Hardwarezugriff geregelt abläuft. Ein /dev/ttyS1 ist Kernelsache, also sollte es ein /dev/fb* auch sein.
So einfach ist das nicht. Der größte Teil des fbdev-Kodes und auch des Treibers für ttyS* hat übrigens nichts mit der hardware zu tun. Ausserdem ist es ein riesiger Unterschied, ob ein Stück Software dummerweise als root laufen muß oder gleich im Kern steckt.
Es geht ja nicht nur um die Konsole, sondern z.B. auch um diese netten kleinen Handhelds, die es jetzt (fast) überall gibt.
siehe unten
Un plattformübergreifend ist VESA auch nicht,
stimmt, hat auch keiner gesagt
zumindest in der Spezifikation von v1.2/v2.0 hat es noch Interrupts gehagelt ohne Ende.
häh? Interrupts in der Spezifikation?
Die Performance auf X11-Systemen ist auch trotz aller erdenklichen Erfindungen noch nicht optimal,
stimmt. Aber bevor man X oder irgendwelche komplexen Grafikoperationen für die oben genannten Handhelds benötigt, muss die Kiste erstmal booten und dabei dem Nutzer ein paar Textzeichen präsentieren - MEHR NICHT. Dazu ist fbdev einfach Overkill, findest du nicht? Die OpenBSDler mit ihrem wscons machen das meiner Meinung nach schlauer, weil minimalistischer.
Das Thema fbdev kam ja deshalb auf, weil sich jemand uber die tolle Konsole damit freute.
Reinhard
On Monday 16 April 2001 15:22, Reinhard Foerster wrote:
On Mon, Apr 16, 2001 at 10:40:10AM +0200, Josef Spillner wrote:
Das ist aber dann auch nur ein Kompromiss, z.B. müssen Programme, die die SVGAlib nutzen, suid installiert werden. Der Sinn des Kernels ist es ja, dafür zu sorgen, daß der Hardwarezugriff geregelt abläuft. Ein /dev/ttyS1 ist Kernelsache, also sollte es ein /dev/fb* auch sein.
So einfach ist das nicht. Der größte Teil des fbdev-Kodes und auch des Treibers für ttyS* hat übrigens nichts mit der hardware zu tun. Ausserdem ist es ein riesiger Unterschied, ob ein Stück Software dummerweise als root laufen muß oder gleich im Kern steckt.
So gross ist der auch wieder nicht: root muss Ressourcen anfordern - bekommt sie aber immer, im Kern bekommt man sie auf dem Silbertrablett.
Der Vorteil ist jetzt: nur noch der eigentliche Treiber steckt im Kern, die Applikationslogik kann mit Nutzerrechten laufen und damit nix mehr kaputtmachen.
zumindest in der Spezifikation von v1.2/v2.0 hat es noch Interrupts gehagelt ohne Ende.
häh? Interrupts in der Spezifikation?
VESA, Nicht IGHS v.5.7 (IGHS=IdealGrafikHardwareSpezifikation).
Die Performance auf X11-Systemen ist auch trotz aller erdenklichen Erfindungen noch nicht optimal,
stimmt. Aber bevor man X oder irgendwelche komplexen Grafikoperationen für die oben genannten Handhelds benötigt, muss die Kiste erstmal booten
tut sie. (Schau Dir mal die c't Artikel von der CeBit an!)
und dabei dem Nutzer ein paar Textzeichen präsentieren - MEHR NICHT. Dazu ist fbdev einfach Overkill, findest du nicht?
Wie bitte? Textkonsole auf einem Handheld?
Punkt 1: AFAIK bietet Dir ein Handheld nix anderes, als ein "Pixeldevice", Du _mußt_ also einen FB programmieren, da Du sonst keine Chance hast auch nur Text darzustellen. Das Display eines Handheld ist keine automagische VGA-Karte, die die ASCII Codes in Speicherecke XY in bunte Pixel verwandelt, die ein Mensch lesen kann.
Punkt 2: geh mal irgendwohin, wo die Leute Handhelds mit sich rumschleppen und zähle durch wer das ist. Nach meiner Erfahrung sind das 80% BWL'er und andere Graphik-Junkies, der Rest benutzt tatsächlich nur eine Textkonsole, um die Server per serieller Konsole zu warten - und das auch nur, weil sie sonst nix mit soeinem "Spielzeug" anzufangen wissen.
Punkt 3: da X11 einfach zu groß ist (Speicher) braucht man eine kleinere Alternative. Da ein mindestens minimalistischer FB sowieso da sein muss kann man ihn ja auch gleich nehmen - oder? Was dabei rauskommt hört zB. auf den netten Namen Qt/embedded (ok, verbrät auch Speicher, aber weniger als Qt/X11).
Die OpenBSDler mit ihrem wscons machen das meiner Meinung nach schlauer, weil minimalistischer.
Funktioniert wie? Kernel? Userspace? Welche Operationen? Overhead?
Das Thema fbdev kam ja deshalb auf, weil sich jemand uber die tolle Konsole damit freute.
Na und? Hat der Beginn eines Threads uns jemals von Flamewars über ganz andere Dinge abgehalten? Meines Wissens nicht. ;-)
Konrad
On Mon, Apr 16, 2001 at 04:01:35PM +0200, Konrad Rosenbaum wrote:
Ausserdem ist es ein riesiger Unterschied, ob ein Stück Software dummerweise als root laufen muß oder gleich im Kern steckt.
So gross ist der auch wieder nicht: root muss Ressourcen anfordern - bekommt sie aber immer, im Kern bekommt man sie auf dem Silbertrablett.
*lol* Frau root ist ein Nichts im Vergleich zu Kode im Kern
stimmt. Aber bevor man X oder irgendwelche komplexen Grafikoperationen für die oben genannten Handhelds benötigt, muss die Kiste erstmal booten
tut sie. (Schau Dir mal die c't Artikel von der CeBit an!)
Ja, tut sie. Ein BMW-850i bringt mich auch die 1,5 km zu Aldi.
und dabei dem Nutzer ein paar Textzeichen präsentieren - MEHR NICHT. Dazu ist fbdev einfach Overkill, findest du nicht?
Wie bitte? Textkonsole auf einem Handheld?
Na willst du die bootinfos als bunte Tortengrafik angezeigt bekommen oder als Sammlung von Buchstaben (=text)? Ob die Hardware nun einen PC-mäßigen textmode hat oder nicht spielt dabei keine Rolle.
Punkt 1: AFAIK bietet Dir ein Handheld nix anderes, als ein "Pixeldevice", Du _mußt_ also einen FB programmieren, da Du sonst keine Chance hast auch nur Text darzustellen. Das Display eines Handheld ist keine automagische VGA-Karte, die die ASCII Codes in Speicherecke XY in bunte Pixel verwandelt, die ein Mensch lesen kann.
Warum erzählt du den Urschleim hier. Abgesehen von PCs hat heutzutage wahrscheinelich kaum eine Hardware einen Textmodus. Das ist doch jedem klar.
Punkt 2: geh mal irgendwohin, wo die Leute Handhelds mit sich rumschleppen und zähle durch wer das ist. Nach meiner Erfahrung sind das 80% BWL'er und andere Graphik-Junkies, der Rest benutzt tatsächlich nur eine Textkonsole, um die Server per serieller Konsole zu warten - und das auch nur, weil sie sonst nix mit soeinem "Spielzeug" anzufangen wissen.
Punkt 3: da X11 einfach zu groß ist (Speicher) braucht man eine kleinere Alternative. Da ein mindestens minimalistischer FB sowieso da sein muss kann man ihn ja auch gleich nehmen - oder? Was dabei rauskommt hört zB. auf den netten Namen Qt/embedded (ok, verbrät auch Speicher, aber weniger als Qt/X11).
Ist doch alles unbestritten. Ich habe nur gesagt, dass ich fbdev für bloated halte. Sicher braucht man sowas wie fbdev im Linux, aber meiner Meinung nach als OPTIONALEN Zusatz NEBEN einem minimalen virtuellen Gerät, welches nur text darstellen kann (fürs booten + ggf. textconsolen mir emuliertem vt-xxx Terminal). Und das für alle Plattformen, auf denen es Sinn macht.
Die OpenBSDler mit ihrem wscons machen das meiner Meinung nach schlauer, weil minimalistischer.
Funktioniert wie? Kernel? Userspace? Welche Operationen? Overhead?
man wscons (geht auch auf deren webserver) Das ding macht IMHO notfalls auch Grafik, auf der man eine X-server aufsetzten kann.
Das Thema fbdev kam ja deshalb auf, weil sich jemand uber die tolle Konsole damit freute.
Na und? Hat der Beginn eines Threads uns jemals von Flamewars über ganz andere Dinge abgehalten? Meines Wissens nicht. ;-)
nein, nur muß man nicht vom 100. ins 1000. kommen und Urschleimerklärungen kommen meist am besten an, wenn man sie wegläßt. Das ist aber ein gutes Thema fürs nächste Treffen. Ich schaue mir mal fbdev noch etwas genauer an.
Reinhard
On Tuesday 17 April 2001 02:21, Reinhard Foerster wrote:
On Mon, Apr 16, 2001 at 04:01:35PM +0200, Konrad Rosenbaum wrote:
Punkt 1: AFAIK bietet Dir ein Handheld nix anderes, als ein "Pixeldevice", Du _mußt_ also einen FB programmieren, da Du sonst keine Chance hast auch nur Text darzustellen. Das Display eines Handheld ist keine automagische VGA-Karte, die die ASCII Codes in Speicherecke XY in bunte Pixel verwandelt, die ein Mensch lesen kann.
Warum erzählt du den Urschleim hier. Abgesehen von PCs hat heutzutage wahrscheinelich kaum eine Hardware einen Textmodus. Das ist doch jedem klar.
Eben, und deswegen hat der PC auch als letzter einen FB bekommen.
Punkt 2: geh mal irgendwohin, wo die Leute Handhelds mit sich rumschleppen und zähle durch wer das ist. Nach meiner Erfahrung sind das 80% BWL'er und andere Graphik-Junkies, der Rest benutzt tatsächlich nur eine Textkonsole, um die Server per serieller Konsole zu warten - und das auch nur, weil sie sonst nix mit soeinem "Spielzeug" anzufangen wissen.
Punkt 3: da X11 einfach zu groß ist (Speicher) braucht man eine kleinere Alternative. Da ein mindestens minimalistischer FB sowieso da sein muss kann man ihn ja auch gleich nehmen - oder? Was dabei rauskommt hört zB. auf den netten Namen Qt/embedded (ok, verbrät auch Speicher, aber weniger als Qt/X11).
Ist doch alles unbestritten. Ich habe nur gesagt, dass ich fbdev für bloated halte. Sicher braucht man sowas wie fbdev im Linux, aber meiner Meinung nach als OPTIONALEN Zusatz NEBEN einem minimalen virtuellen Gerät, welches nur text darstellen kann (fürs booten + ggf. textconsolen mir emuliertem vt-xxx Terminal). Und das für alle Plattformen, auf denen es Sinn macht.
Entschuldige, aber bisher dachte ich FB wäre was minimales: es weiss lediglich, wie man zwischen den Modi schaltet und den Pixelspeicher per mmap auf ein Console-Proggy mappt. Die aufwändigen Sachen (2D- und 3D-Beschleunigung) müssen über Userspace-Module gemacht werden, die mit dem FB über Timing und so abstimmen (X sagt in den neueren Versionen einfach "lieber FB gib mir doch bitte jetzt die Kontrolle über die GraKa!", es sei denn es läuft auf dem FB, dann greift es direkt drauf zu, aber kann halt nicht beschleunigen).
Zugegeben, der Matrox-FB hat dutzende zusätzliche ioctl's, aber das sollte Dich auf einem Handheld kaum jucken, da Du dort einen anderen _kleineren_ FB verwendest. Und wer in einem PC eine Matrox einsetzt hat mit Sicherheit auch genug Speicher, um 20kB Kernel-Code mitzuschleppen, der u.U. nie aktiviert werden wird.
Die OpenBSDler mit ihrem wscons machen das meiner Meinung nach schlauer, weil minimalistischer.
Funktioniert wie? Kernel? Userspace? Welche Operationen? Overhead?
man wscons (geht auch auf deren webserver) Das ding macht IMHO notfalls auch Grafik, auf der man eine X-server aufsetzten kann.
Danke, jetzt weiss ich wo ich die Befehlssyntax finde. Erklärt mir auch jemand, wie das funktioniert? Bisher sieht das für mich genauso wie fbset aus.
Konrad
Hallo,
On Mon, Apr 16, 2001 at 03:22:46PM +0200, Reinhard Foerster wrote:
Das Thema fbdev kam ja deshalb auf, weil sich jemand uber die tolle Konsole damit freute.
...stimmt. Es ist nun mal ein schöneres Arbeiten mit 100x38 Zeichen bei 100Hz Bildwiederholfrequenz :)
Was das Technische betrifft hab ich mich damit noch gar nicht so richtig befasst - hab nur gemerkt, dass X darunter schreck- lich langsam ist, aber so oft brauch ich das nicht.
Matthias
Am Mon den 16 Apr 2001 um 11:11:09AM +0200 schrieb Reinhard Foerster:
On Mon, Apr 16, 2001 at 10:10:54AM +0200, Konrad Rosenbaum wrote:
Das war jetzt die linuxistische Erklärung. Normalerweise ist ein Framebuffer einfach das, was man hier im allgemeinen mit Grafikkarte bezeichnet. Was Konrad bescheibt ist die Software-Schnittstelle zu dieser Hardware.
Man kann noch hinzufügen, daß es sowas wie einen Text Modus, also wo man der Karte sagt, welchen Buchstaben sie darzustellen hat (im Gegensatz zu einem Punktmuster) nur bei PC's gibt. Der Rest der Welt hat immer mit einem Bildspeicher gearbeitet (eben Framebuffer).
Reinhard, der die Textmodi von GraKas in PCS zum Textanzeigen auf einer GraKa eines PCs gut findet und irgendwelche Unterstützung von speziellen Grafikkarten IM KERN doof findet. Für ein plattform- übergreifendes dev für die Console tun es auch VGA + VESA.
Nun ist aber der VGA Text Modus nicht gerade Stand der Technik. Was meinst du mit VGA + VESA - den VESA Framebuffer? Der Vesa-FB ist eine wirklich goile Sache, womit man alte VT100 Freaks echt beeindrucken kann. Es geht nicht nur wie Konrad gepostet hat, um einen einfachen Zugriff auf den Grafikspeicher der Karte, sondern auch Ergonomie. Eine Console mit 85 Hz und einem vernünftigen Font ist nun mal nicht verachten.
-- helft der Aktion: "Tetris in den Linux-Kern!" http://www.LiTetris.de/
Was Reinhard noch mehr freuen wird: es gibt ein Projekt, welches Tetris in den fsck eingebaut hat, damit es nicht so langweilig wird - ist auf 9600/8N1 sicher ne tolle Sache ;-) (irgendwo auf freshmeat zu finden)
andre
lug-dd@mailman.schlittermann.de
-
Andre Schulze -
Josef Spillner -
konrad.rosenbaum＠t-online.de -
Matthias Petermann -
Reinhard Foerster -
Sebastian Roth