Allgemeine Verständnisfragen

Mal eine Klarstellung: UTF-8 funktioniert nicht auf der Console!. Nur in X oder per ssh! Damit es auch auf der Console geht, benötigt man vt(4) (früher newcons genannt) [1][2]. Bei FreeBSD 10.1 sollte es, so glaube ich als Option dabei sein.

[1] https://wiki.freebsd.org/Newcons
[2] youtube.com/watch?v=XZzyTafghU0
 
Danke foxit!
Da setze ich dann das nächste Ding zum ersten Mal um.. Backup und Restore .... Das mit newcons hab ich auch schon mal gelesen, und am Kernsystem was zu machen ... da mach ich lieber mal ein Backup.... :eek:
 
Ja, in FreeBSD 10.1 wird vt(4) optional dabei sein. In wesentlich besserem und benutzbaren Zustand als noch in FreeBSD 9.3. Das einzige, was noch fehlt, ist die Möglichkeit beim VGA-Treiber die Konsolenauflösung ändern zu können. Wenn man vt(4) nutzt, muss man aber x11-drivers/xf86-input-keyboard in mindestens Version 1.8.0_3 installiert haben. Denn ansonsten schmiert X.org mit Segfault weg.
 
Ich hab auch hier
https://www.b1c1l1.com/blog/2011/05/09/using-utf-8-unicode-on-freebsd/
noch einen Link gefunden der UTF-8 (eigentlich mein bevorzugtes Encoding) zeigt. Was mir sofort hier auffällt, er setzt zuerst das charset und dann LANG ....

Das macht doch mein Stub in der .login_conf auch? Nur dass es eben iso-8859-1 anstatt UTF-8 ist…
Aber ansonsten sieht die Beschreibung im letzten Link ganz gut aus, müsste also funktionieren.
Hast du auch cap_mkdb aufgerufen, nachdem du die /etc/login.conf bearbeitet hast?
 
@mr44er:Ok, ich habe etwas herausgefunden....

"pkg delete -a" räumt wohl wirklich alles raus bis auf das Basissystem. Das habe ich aus diesem Thread zum Release von Freebsd 10.0 rausgelesen.
http://bsdforen.de/threads/freebsd-10-0-erschienen.30707/

Heute gab es wohl ein update von pkg 1.3.7 auf 1.3.8. "portmaster -a" wollte nicht loslegen upzudaten. ein "portmaster pkg" brachte dann das neue pkg ins system.

Auch mit dem charset in der /etc/login.conf habe ich kein deutsches locale. Auch auf ttyv1-8.

Nur so als Info "von einem Noob an den anderen 'Verständnisfragenhaber'" ;)

Das mit dem vidcontrol hat geklappt.
allscreens_flags="MODE_326" setzt es jetz direkt nach dem booten. 323 war sehr blass. 326 ist 32 Bit und ok.


Ich bin auch immer noch Noob, von daher passt das schon. ;)

Das wiki von Denkakrobat kenne ich auch schon, das ist ganz verständlich gemacht!
 
Heute hab ich wieder Zeit mich um das FreeBSD zu kümmern :)

Das Neubauen der xf86-input-* drivers hat den neuen xorg jetzt dazugebracht auch Eingaben zu akzeptieren ;)

Auch das Xork.0.log zeigt jetzt:
(II) [KMS] Kernel modesetting enabled.

Die Lautstärke der Grafikkarte hat sich noch nicht geändert. Hier muss ich noch graben wo die Powereinstellung sich vor mir versteckt ;) Die Grafikkarte scheint sich jetzt zu überhitzen. Der Bildschirm friert ab und an ein. Da muss ich schauen was Sache ist.

Das locale immer noch englisch.....
 
Das mit dem Powermode hab ich gefunden ...

https://wiki.freebsd.org/Graphics
Notes:
  1. Requires WITH_NEW_XORG when building ports.

  2. Radeon video cards when WITH_NEW_XORG is set:
    • AGP cards not supported
    • Features not yet working/implemented:
      • Suspend/resume
      • Hardware-assisted video decoding
      • GPGPU
      • Multiple cards sharing output connectors
      • Power management
  3. The GALLIUM backed Software renderer works.

D.h. Powermanagement bei meiner Karte geht noch nicht. Schade ....

Mal sehen ob ich eine passiv gekühlte Karte bekomme. ICh brauch sowiso keine große 3D Leistung mehr. Spielen tu ich nicht mehr ....
 
Ja, hab noch einen anderen Rechner installiert, das ist eine APU mit einer Radeon HD 6310. Bin aber froh, dass die Beschleunigung an sich funktioniert. ;)

Achja, damit kannst du vorerst nur unter Xorg arbeiten. Wenn du auf ein virtuelles Terminal wechselst, schmiert dir die Kiste ab bzw. siehst du nix mehr. ;)

Eine Geforce 9400 ist günstig zu bekommen und sollte dann genügen.
 
Das mit dem versagenden virtuellen Terminal ist die Sache mit den Konsolentreiber, die weiter oben schon angedeutet wurde. Bisher nutzte (und tut es in Standardeinstellung noch immer) FreeBSD den Syscons-Konsolenrenderer, kurz sc(4). Für die Techniker unter uns ist es ein Nachbau der "SCO Color Console", welche die verschiedenen SCO-Unixe seit etwa Ende der 1980er Jahre nutzten. Nun hat sc(4) allerdings einige Nachteile:
  • Es nutzt den Textmode des VESA-BIOS der Grafikkarte. Es kann also nur Zeichen darstellen, die das BIOS der Grafikkarte auch unterstützt. Das sind in der Praxis die ISO-Zeichensätze. Sichtbares Problem davon ist beispielsweise, dass kein Unicode gerendert werden kann. Auch können keine Grafiken und ähnliches dargestellt werden.
  • Da es ein VESA-BIOS geben muss, funktioniert sc(4) auf Systemen ohne es nicht wirklich. Das betrifft einen Großteil der ARM-Systeme, aber auch viele UEFI-Implementierungen. Außerdem ist der Code sehr auf die i386-CPU optimiert. Andere Architekturen behalfen sich mit Hacks, aber eine gute Lösung war das nicht.
  • sc(4) integriert nicht mit dem Rest des Kernels. Wenn z.B. KMS die Kontrolle über die Grafikkarte übernimmt, ist sc(4) aus dem Spiel. Daher bleiben nach dem Start von X.org die virtuellen Konsolen schwarz. Im Falle einer Panic kann nicht auf die Konsole zurückgeschaltet werden. Und so weiter.
Daher wurde mit Newcons aka vt(4) ein neuer Konsolentreiber implementiert. In FreeBSD 10.1 wird er vollständig enthalten sein. Er unterstützt alle Features, lediglich das Setzen von Auflösungen ist noch sehr rudimentär. Man kann ihn dort aktivieren, in dem man in der /boot/loader.conf einen Eintrag macht und neu startet:
Code:
kern.vty=vt
Früher oder später wird vt(4) der Standardkonsolenrenderer werden und sc(4) wird dann entfernt.
 
So in etwa habe ich mir das auch gedacht, ohne näheres zu wissen.

Sag mal...dein Quake2 Client, wo find ich den in den Ports?

Als ich noch unter Linux wütete, habe ich den benutzt und Q2 mal wieder durchgespielt. :D
 
Code:
make -C /usr/ports/games quicksearch key=quake
zeigt dir alle Ports an, die mit Quake zu tun haben.
 
Den Client selbst als Port bereitszustellen, ist gar kein Problem. Das liegt eher bei der Gamedata. Man bräuchte ein Script, was aus den diversen unterschiedlichen Quellmedien (es gab mehrere CDs, DVDs, Quake II als Teil von Compilations, als Beigabe zu späteren Teilen der Serie, über Steam, über andere Downloadportale, etc) eine garantiert saubere Installation der Gamadata bastelt. Und das ist alles andere als einfach. Mein Kollege hat es mit seinen Debian-Paketen probiert und ganz böse auf die Schnauze geflogen. Was zu diversen, sinnlosen Bug-Reports durch Crashes aufgrund fehlender Dateien führte...
 
Unter debian gibts doch den gamedata-manager, der sich die pk2 ausliest und passend zurechtbiegt. Wie wird die magic dort gemacht? :)
 
Das ist ein ganz anderes Thema. Es geht nicht darum die Pak-Dateien zu extrahieren, stattdessen einen korrekt aufgebauten Verzeichnisbaum unter baseq2/ zu erstellen. Je nach Ausgabe des Spiels müssen die Dateien aus anderen Quellverzeichnissen kopiert werden, andere überflüssige Dateien gelöscht werden (das wäre noch simpel mit stumpf allem zu löschen) und eventuell gepatcht werden.

Das Grundproblem ist, dass Quake II keine Konsistenzprüfung der Gamedata durchführt. Es geht einfach davon aus, dass die korrekten Dateien vorhanden sind. Fehlen welche oder sind in der falschen Version dort, crasht das Spiel stumpf. Da kann man auch nicht viel gegen machen. Selbst wenn man jede Datei auf Existenz prüfen würde - was durch gefühlt 100.000 hardgecodete Pfade eine Sisyphusarbeit wäre - fehlt noch immer die Schnittstelle zwischen Game und Client zum Auslösen eines sauberen Abbruchs. Die einzubauen wäre ein API-Bruch, wodurch ältere Mods nicht mehr funktionieren würden. Außer man gönnt sich da noch einen Kompatibilitätsmechanismus.
 
So, langsam gewöhne ich mich an Freebsd und die Unterschiede zum großen Bruder ;)

Nach einigem ausprobieren bin ich auf die Lösung meiner locale Probleme gekommen. Es scheint ganz einfach, dass die Pakete wie xfce4 und Co die login.conf nicht berücksichtigen oder vorher die Environment ausräumen. Also hab ich in meiner .xinitrc jetzt praktisch dasselbe drin wie in meiner .login_conf. ssh beachtet die login_conf, aber wohl X Anwendungen nicht. Eventuell ist das mit der Linuxdesktop Geschichte verwandt ...

Ich hab jetzt alles erstmal in einer VM geübt, dann konnte ich parallel im Internet Dokumentation einfacher lesen und per snapshot einfach wieder zurück wenn ich was total verbuckselt hatte...

Mein Upgrade auf 10.1-RELEASE vom 10.0-RELEASE ging recht problemlos. Nur die Ports haben gemuckst. Hier hab ich per "pkg delete -a" alles ausgeräumt und anschliessend noch /usr/local komplett geleert. Danach hab ich die Ports bzw Pakete neu installiert und alles war wieder i.O. Vermutlich ist das die totale Holzhammermethode, hat aber geklappt. Ich hatte Probleme mit den port gettext 0.18 auf 0.19 . Auch werde ich jetzt erstmal bei den Paketen bleiben. Zwar weniger Kontrolle, aber mein Wissen ist hier noch mehr als ausbaufähig. *hust* ;) Evetuell kann mir hier jemand eine elegantere Methode sagen.... Ich hab aber nochzuerst under /usr/ports/UPGRADING gelesen, bzw nach gettext gesucht. Ich habs dann mit "pkg delete -d gettext" (alo nur das eine Paket ohne Abhängigkeiten) entfernt und mit portmaster wieder versucht alles wieder auf Stand zu bringen, aber war nicht erfolgreich.....

Auf meiner Baremetal Installation hab ich noch Probleme mit der xorg.conf. Ich kann zwar auf beiden Monitoren ein Bild anzeigen, aber nicht gleichzeitig Xinerama bzw. xrandr nutzen. xrandr erkennt dass beide Monitore an DVI-0 und DVI-1 angeschlossen sind, aber ein Xinerama/Xrandr/TwinView Ergebnis hab ich noch nicht hinbekommen. Als Ausgangspunkt habe ich meine xorg.conf von der Linuxplatte genommen.... Mal sehen was sich hier tut. Aber die Lautstärke der Karte ist jetzt absolut i.O. Auch scheint sie sich nicht mehr zu überhitzen. Ein ähnliches Problem hatte ich unter Linux mit einem RT Kernel. Hier war die fehlende Firmware die Ursache, welche nicht geladen wurde. Der Lüfter lief Vollgas, aber er hat die Wärme trotzdem nicht weggebracht.... Das aber nur als Brotkrume für andere Noobs wie mich.

Achja eine Frage hätte ich da noch: Gibt es bei den Ports auch branches den man folgen kann wie eben 10.1-RELEASE (also stable) oder gibt es hier keine Unterschiede?

Gruß
Georg
 
Nach einigem ausprobieren bin ich auf die Lösung meiner locale Probleme gekommen. Es scheint ganz einfach, dass die Pakete wie xfce4 und Co die login.conf nicht berücksichtigen oder vorher die Environment ausräumen.
Kann es sein dass du als Loginmanager den Slim benutzt? Der ist nicht richtig angepasst und berücksichtigt die login.conf nicht. An dem Problem bin ich auch mal halb verzweifelt. Daher nehme ich jetzt lieber den guten alten xdm, auch wenn der nicht so schön aussieht. Aber man loggt sich ja nicht so oft ein. ;-)
 
Ich setze seit einiger Zeit in allen möglichen Startscripten LANG neu. Sei es nun .xinitrc, .cshrc, .login, etc... Ich hab das Gefühl da wertet jeder irgendwie was anderes aus.
 
Zurück
Oben