Xorg Konfiguration - mutmaßlich Treiberprobleme

Seemann

Greenhorn
Hallo FreeBSD-Freunde!

Nach dem ersten Test von Xorg (7.7_3) auf einem neu installierten 10.3 (mit 11.0 hatte ich bereits bei der Installation schon Grafikprobleme) hatte ich nur noch ein weiß/schwarz-gestreiftes Bild auf allen VTs.
Da ich Xorg über die Ports installierte, habe ich evtl. hierbei nicht die richtigen Treiber ausgewählt. Denn auch nach etlichen Versuchen mittels xorg.conf habe ich noch immer Probleme mit der Tastatur und Auflösung der Anzeige, soll heißen, die Auflösung von 1600x1200 wird nicht angenommen und die [Strg]+[Alt]+[<-] funktioniert auch nicht. Jedoch hald und dbus sind in /etc/rc.conf aktiviert. Eine Analyse der Logdatei ließ mich zu dem Schluß kommen, daß hier wohl die Treiber nicht zu meiner HW passen.
Auch im Internet bin ich nicht fündig geworden. Deshalb liegt nun meine ganze Hoffnung bei Euch. Wahrscheinlich werde ich etwas beim Xorg-Port umkonfigurieren müssen; aber da gab es so viel auszuwählen, und ich wußte meist nicht, was alles bedeutet - ohne etwas Hilfestellung bin ich in diesem Konfigurationsdschungel absolut verloren.

Die relevante Hardware ist:
- Tastatur: MICROSOFT® Wired Keyboard 600 (Model: 1366)
- Prozessor: Intel® Core i3-3240 3,40GHz
- Grafikchipsatz Prozessorintegriert: Intel® HD Graphics 2500
- Bildschirm: SONY Multiscan G520


Ein Auszug von /var/log/Xorg.0.log - und falls der nicht genügen sollte auch die Originaldatei - sind der Größe wegen als Textdatei im Anhang zu finden.

~/xorg.conf.new (Auszug):
Code:
...
Section "InputDevice"
    Identifier    "Keyboard0"
    Driver        "kbd"
    Option        "XkbModel" "pc105"
    Option        "XkdLayout" "de"
    Option        "XkbVariant" "NoDeadkeys"
    Option        "XkbOptions" "Compose:lwin,terminate:ctrl_alt_bksp"
EndSection
...
Section "Monitor"
    Identifier    "Monitor0"
    VendorName    "SNY" #Funktioniert unter Linux! Voreinstellung: "Monitor Vendor"
    ModelName    "SONY CPD G520" #"Monitor Model" (Voreinstellung)
    HorizSync    30-130
    VertRefresh    48-170
EndSection

Section "Device"
    Identifier    "Card0"
    Driver        "vesa" #("intel" Funktioniert unter Linux - hier leider nicht!)
    BusID        "PCI:0:2:0"
EndSection

Section "Screen"
    Identifier    "Screen0"
    Device        "Card0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection "Display"
        Viewport    0 0
        Depth        1
        Modes        "1600x1200"
    EndSubSection
    SubSection "Display"
        Viewport    0 0
        Depth        4
                Modes        "1600x1200"
    EndSubSection
    SubSection "Display"
        Viewport    0 0
        Depth        8
                Modes        "1600x1200"
    EndSubSection
    SubSection "Display"
        Viewport    0 0
        Depth        15
                Modes        "1600x1200"
    EndSubSection
    SubSection "Display"
        Viewport    0 0
        Depth        16
                Modes        "1600x1200"
    EndSubSection
    SubSection "Display"
        Viewport    0 0
        Depth        24
                Modes        "1600x1200"
    EndSubSection
EndSection


Gruß
Seemann
 

Anhänge

  • Xorg.0.log.Auszug.txt
    15,5 KB · Aufrufe: 226
  • Xorg.0.log.txt
    72,2 KB · Aufrufe: 247
Auszug aus Deinem Logfile

Code:
47777.255] (**) Option "Protocol" "standard"
[ 47777.255] (WW) Option "Device" requires a string value
[ 47777.255] (**) Option "XkbRules" "base"
[ 47777.255] (**) Option "XkbModel" "pc105"
[ 47777.255] (**) Option "XkbLayout" "us"   <----------- Guckst Du hier

Zum Beheben einfach die folgenden Sectionen unter /usr/local/etc/X11/xorg.conf./ abspeichern. Wie die dort von Dir benannt werden ist im Prinzip wurst Hautsache sie enden auf .conf den Rest von Deiner xorg.conf würde ich erstmal weg lassen. Warum:

-- Zitat
it is recommended to let Xorg auto-configure itself. If you need to override part of the configuration, create a config file under /usr/local/etc/X11/xorg.conf.d/ containing only the relevant section.:

Code:
Section "ServerLayout"
......................... snip ................
Option "AutoAddDevices" "False"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbRules" "xorg"
Option "Xkbmodel" "pc105"
Option "XkbLayout" "de"
Option "XkbVariant" "nodeadkeys"
EndSection
solltest Du HAL benutzen und das sieht laut Log so aus, zusätzlich unter
/usr/local/etc/hal/fdi/policy/
die Datei x11-input.fdi anlegen

Code:
<?xml version="1.0" encoding="iso-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keyboard">
<merge key="input.x11_options.XkbModel" type="string">pc105</merge>
<merge key="input.x11_options.XkbRules" type="string">xorg</merge>
<merge key="input.x11_options.XkbLayout" type="string">de</merge>
</match>
</device>
</deviceinfo>

ich hoffe das hilft Dir!
 
Zuletzt bearbeitet:
Danke Igsh!

Aber leider funktioniert es noch immer nicht. Nachdem die Werte übernommen wurden, steht in der Logdatei:
Code:
...
[  8902.804] (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD, id 7)
[  8902.827] (EE) Error loading keymap /usr/local/share/X11/xkb/compiled/server-0.xkm
[  8902.827] (EE) XKB: Failed to load keymap. Loading default keymap instead.
...
Da fehlt doch noch etwas auf meinem Rechner, wie es scheint, oder?

Auch meine Bildschirm-Auflösungseinstellungen werden noch nicht übernommen. Wie in der Logdatei ersichtlich ist, werden die Monitordaten zwar alle gut erkannt, aber von xorg dann auskommentiert! :confused:
 
Mal so nebenbei gefragt den Port x11-drivers/xorg-drivers hast Du installiert?
Habe das mal gecheckt, da ich diesen nicht explizit installierte: ja, dieser Port war (und ist) installiert.

Hast Du denn jetzt wenigstens ein Bild auf dem Monitor, die Auflösung mal jetzt ausser Acht gelassen!?
Ja, ein Bild habe ich, das gleiche wie zuvor, mit einer 1280er Auflösung, die ich eben nicht als Standardauflösung haben möchte (mein alter Röhrer hat noch das altbewährte 4:3-Format!).

Aber ich glaube, ich muß von weiter vorne beginnen:
Zunächst hatte ich - soweit ich mich entsinne (jetzt bastle ich schon so lange daran herum, daß ich es nicht mehr mit 100%iger Sicherheit sagen kann; ich hatte mich ja zuvor schon mit der 11er-Version herumgeschlagen) - zwar ein Bild (könnte aber auch schwarz gewesen sein/Monitorausgang deaktiviert) und auf allen anderen Konsolen hatte ich einen weißen Bildschirm mit schwarzen Streifen. Also zunächst mal eine xorg.conf.new erstellt und mit Hilfe meiner Linux-Konfiguration modifiziert...und siehe da - endlich war auch das ,,schöne" graue Fenster mit dem X als Mauszeiger zu sehen, und der Wechsel zu den anderen Konsolen machte nun auch keine Probleme mehr. Die Maus funktionierte jedoch erst, nachdem ich hald und dsub aktiviert habe. Aber die eingestellte Auflösung wurde nicht übernommen, und das 3-Finger-Tripel hatte keinen Effekt.
Anstatt intel, wie beim Linux, muß ich hier vesa als Treiber für meinen Grafikchipsatz auswählen. Unter Linux funktionieren diese Einstellungen hervorragend: das graue Fenster hat die eingestellte Auflösung von 1600x1200 und mit [Strg]+[Alt]+[<-] konnte ich diesen Test dann wieder beenden. Nach der anschließenden Installation von openbox hatte diese dann auch gleich nach dem starten die gewünschte Auflösung von 1600x1200
OK, FreeBSD ist zwar kein Linux, aber Xorg sollte doch auf beiden Plattformen gleich gut funktionieren, oder?!
Die Zeiten, in denen man ausschließlich - und etwas später immer noch hauptsächlich - im Komandozeilen-Modus operierte, sind schon lange vorbei; mal ganz davon abgesehen, daß das SW-Sortiment an Anwendungen hierfür sehr mager geworden ist, kommt man heute ohne grafische Benutzeroberfläche wohl kaum noch aus. Deshalb möchte ich baldig ein gut funktionierendes Window-System haben (nach Mölichkeit KDE4). Doch wenn nicht einmal die Basis stimmt (Xorg), wie kann man dann darauf solide aufbauen?!

Noch ein Wort zu 11.0 (vielleicht stehen ja beide Probleme in Relation zueinander):
Die Installation erfolgte in einem miserablen Grafikmodus; es gab diesbezüglich auch keine Wahlmöglichkeit! Die Schrift war schwer lesbar, das Schriftbild verwaschen. Meine Hoffnung war, daß nach der Installation das dann besser sei, aber da hatte ich mich schwer getäuscht. Auch eine Umstellung mit vidcontrol scheiterte und vidcontrol -i mode brachte nur eine leere Liste zum Vorschein. Auch eine Neuinstallation mit der DVD (meine Hoffnung war, das da evtl. auch mehr Treiber dabei währen), brachte keine Besserung. Deshalb nun 10.3, das auch soweit prächtig läuft und alles bestens funktioniert - im Text(/Halbtext)-Modus jedenfalls.
Das die aktuelle Release ältere HW (aber jedoch keinesfalls veraltete) nicht mehr unterstützt, finde ich sehr schwach - da kann ich nur hoffen, daß die 10er nicht so bald eol wird.
 
beiden Plattformen gleich gut funktionieren, oder?
Leider nicht. Wir sind in FreeBSD in vielen Dingen eher konservativ und es wird selten ein pragmatischer Weg gegangen.
Zudem investieren viele Linux-Distributionen sehr in HW Erkennung und daraus abgeleitet auch Unterstützung. Da werden oft auch Dinge eingebaut und angeboten, die nicht offiziell und nicht Frei sind.

Deshalb glaube ich auch eher daran, dass es ein Problem mangelnder Unterstützung ist und weniger ein Problem deiner unzureichenden Konfiguration.

Trotzdem einige grundsätzliche Dinge, wenn schon nichts besseres.
Warum Eigenbau? Pakete sind doch sehr komfortabel und vor allem, wenn es noch ums testen geht, sehr sehr viel schneller.
Xorg braucht nicht mehr Hal. Dbus wirst du auch wegen anderer Dinge noch brauchen, aber Xorg muss nicht unbedingt einen laufenden Hal haben.
Xorg kann immer noch mit einer xorg.conf, ich nutze die immer noch, das ist für mich viel einfacher, als der Weg über die neuen kleinen Dateien.

Die Konsolen und deren Darstellung haben nichts mit Xorg zu tun. kern.vty=vt in der /boot/loader.conf kann viele Probleme mit virtuellen Konsolen beseitigen, ich habe aber vergessen, was das eigentlich macht.

Meine HW ist älter, ich habe aber nvidia. Ich würde an deiner Stelle alles deinstallieren, was du nun mehr oder weniger Erfolglos probierst hast. dann mit pkg install xorg und die xorg-drivers installieren. Die Installationsmeldungen lesen! Mit X --configure eine Test-xorg.conf erstellen und diese ansehen. Ich zege mal meine eigene hier, nur als Aufhänger:
Code:
Section "ServerLayout"
    Identifier     "X.org Configured"
    Screen      0  "Screen0" 0 0
    Screen      1  "Screen1" RightOf "Screen0"
    InputDevice    "Mouse0" "CorePointer"
    InputDevice    "Keyboard0" "CoreKeyboard"
EndSection


Section "ServerFlags"
    Option         "AutoAddDevices" "False"
    Option         "AllowEmptyInput" "Off"
EndSection

Section "InputDevice"
    Identifier     "Keyboard0"
    Driver         "kbd"
    Option         "XkbModel" "pc105"
    Option         "XkbLayout" "de"
    Option         "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

Section "InputDevice"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/sysmouse"
    Option         "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Monitor Vendor"
    ModelName      "Monitor Model"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Monitor Vendor"
    ModelName      "Monitor Model"
EndSection

Section "Device"
    Identifier     "Card0"
    Driver         "nvidia"
    BusID          "PCI:1:0:0"
EndSection

Section "Device"

        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
        ### <percent>: "<f>%"
        ### [arg]: arg optional
    Identifier     "Card1"
    Driver         "nvidia"
    BusID          "PCI:1:0:0"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Card0"
    Monitor        "Monitor0"
    SubSection     "Display"
        Viewport    0 0
        Depth       24
    EndSubSection
EndSection

Section "Screen"
    Identifier     "Screen1"
    Device         "Card1"
    Monitor        "Monitor1"
    SubSection     "Display"
        Viewport    0 0
        Depth       24
    EndSubSection
EndSection
Das ist eine Dual-Head-Karte und ich nutze zwei Monitore. Option "AutoAddDevices" "False" bringt meist Erleichterung, falls es Konflikte mit Hal und dessen Eigenleben geben sollte. Option "XkbOptions" "terminate:ctrl_alt_bksp" killt bei mir zuverlässig den X-Server, was du offenbar auch haben möchtest und was in der Testphase wichtig ist. Der laufende X-Server ist ein schwarzer Bildschirm auf schwarzem Hintergrund. Will man das alte Muster mit X-Maus, muss der X-Server mit dem Aufruf der Art erfolgen: Xorg -config -retro /root/xorg.conf.new (sofern ich das noch richtig erinnere).
Nun musst die xorg.conf so lange angepasst werden, bis kein EE mehr im xorg.0.log vorkommt und die gewünschten Treiber geladen werden.
Also ganz, wie früher auch.

Anders als früher, sollte das alles heute besser funktionieren und man kann sich auch Einträge in der xorg.conf sparen oder vollkommen ohne auskommen. Die HW Erkennung und Automagie von X sollte das leisten, wenn die passenden Treiber installiert sind. Doch solche Dinge, wie DE Tastatur oder eben das Killen von X, das bleibt dann jedenfalls unberücksichtigt. Weil das aber doch sehr Vorteilhaft ist, weiche ich auch nicht davon ab und nutze noch immer die eine xorg.conf. Die ist ja nun wirklich nicht unübersichtlich und kompliziert, so dass die Zerlegung in kleinere teile echte Vorteile bringen könnte. Im Gegenteil.
Welche Methode ist aber egal, es muss nur bedacht werden, dass X beim Start die einzelnen Möglichkeiten in einer bestimmten Reihenfolge absucht. Das ist in man X beschrieben und ich glaube, die /etc/X11/xorg.conf steht da ganz weit Vorne.

Noch ein Wort zur schlechten Lesbarkeit des Installers bei FreeBSD11: auch wieder nichts mit X zu tun. Da wird kein X benutzt (soviel ich mich erinnere). FreeBSD geht da vollkommen anders vor, als die meisten GNU/Linux-Distributionen, die ich kennen lernte. Bei diesen wird da eine umfangreiche und selbstständig funktionierende HW-Erkennung durchgeführt, dann eine CD im Live-Modus gebootet und mit Erkenntnissen der HW-Erkennung versorgt. Dann arbeitet man schon in X und dieses ist auch automagisch konfiguriert. Die Installation erfolgt dann aus dieser Umgebung. FreeBSD hat zur Installationszeit noch überhaupt kein X und nichts damit zu tun. Die einzige HW-Erkennung ist jene des Kernels.

https://www.freebsd.org/doc/handbook/x-config.html
 
Also, die Reihenfolge in der nach der configuration gesucht wird, ist in xorg.conf(5) noch besser beschrieben und ich kopiere sie der Bequemlichkeit halber eben mal her:
Code:
DESCRIPTION
       Xorg uses a configuration file called xorg.conf and files ending in the
       suffix .conf from the directory xorg.conf.d for its initial setup.  The
       xorg.conf configuration file is searched for in the following places
       when the server is started as a normal user:

           /etc/X11/<cmdline>
           /usr/local/etc/X11/<cmdline>
           /etc/X11/$XORGCONFIG
           /usr/local/etc/X11/$XORGCONFIG
           /etc/X11/xorg.conf
           /etc/xorg.conf
           /usr/local/etc/X11/xorg.conf.<hostname>
           /usr/local/etc/X11/xorg.conf
           /usr/local/lib/X11/xorg.conf.<hostname>
           /usr/local/lib/X11/xorg.conf

       where <cmdline> is a relative path (with no “..” components) specified
       with the -config command line option, $XORGCONFIG is the relative path
       (with no “..” components) specified by that environment variable, and
       <hostname> is the machine's hostname as reported by gethostname(3).

       When the Xorg server is started by the “root” user, the config file
       search locations are as follows:

           <cmdline>
           /etc/X11/<cmdline>
           /usr/local/etc/X11/<cmdline>
           $XORGCONFIG
           /etc/X11/$XORGCONFIG
           /usr/local/etc/X11/$XORGCONFIG
           /etc/X11/xorg.conf
           /etc/xorg.conf
           /usr/local/etc/X11/xorg.conf.<hostname>
           /usr/local/etc/X11/xorg.conf
           /usr/local/lib/X11/xorg.conf.<hostname>
           /usr/local/lib/X11/xorg.conf

       where <cmdline> is the path specified with the -config command line
       option (which may be absolute or relative), $XORGCONFIG is the path
       specified by that environment variable (absolute or relative), $HOME is
       the path specified by that environment variable (usually the home
       directory), and <hostname> is the machine's hostname as reported by
       gethostname(3).

       Additional configuration files are searched for in the following
       directories when the server is started as a normal user:

           /etc/X11/<cmdline>
           /usr/local/etc/X11/<cmdline>
           /etc/X11/xorg.conf.d
           /usr/local/etc/X11/xorg.conf.d

       where <cmdline> is a relative path (with no “..” components) specified
       with the -configdir command line option.

       When the Xorg server is started by the “root” user, the config
       directory search locations are as follows:

           <cmdline>
           /etc/X11/<cmdline>
           /usr/local/etc/X11/<cmdline>
           /etc/X11/xorg.conf.d
           /usr/local/etc/X11/xorg.conf.d

       where <cmdline> is the path specified with the -configdir command line
       option (which may be absolute or relative).

       Finally, configuration files will also be searched for in a directory
       reserved for system use.  This is to separate configuration files from
       the vendor or 3rd party packages from those of local administration.
       These files are found in the following directory:

           /usr/local/share/X11/xorg.conf.d

       The xorg.conf and xorg.conf.d files are composed of a number of
       sections which may be present in any order, or omitted to use default
       configuration values.
 
Gesegnete Pfingsten an Alle!

Danke schön erstmal auch an Dich pit234a für Deine ausführlichen und tiefgreifenden Erläuterungen.

Es ist mir schon klar, daß heute und morgen hier nicht viel Resonanz zu erwarten ist, da an diesen Tagen die meisten wohl von dem Computerstreß abschalten und mal an etwas anderes denen möchten. Außerdem darf die Familie natürlich nicht zu kurz kommen - und das ist auch gut so!

Dennoch möchte ich jetzt Euch noch über den aktuellen Stand informieren:
Nun, ich habe mir den Rat von pit234a zu Herzen genommen und Xorg nochmals neu aufgesetzt; allerdings habe ich ich das jetzt einfach so gemacht, indem ich die Konfiguration im Port von Xorg (mit allen Abhängigkeiten) auf die Standardwerte zurücksetzte, und beim Neukonfigurieren quasi die Standarderte übernommen habe - bis auf geringfügige Änderungen, bei denen ich genau weiß, was ich damit anrichte. Denn genau das ist ja gerade das schöne an den Ports. Klar, ein Programm zu installieren geht mit pkg schon wesentlich schneller, aber da Xorg ja bereits installiert war...
Jetzt wird auch mein Tastaturlayout akzeptiert. Die Datei /usr/local/etc/hal/fdi/policy/x11-input.fdi benötigt mein System jedoch nicht. Allerdings mußte ich eine Schreibkorrektur vornehmen. Wie bereits erwähnt, habe ich als Vorlage für die Xorg-Konfiguration, die unter Linux erstellte xorg.conf verwendet.
...
Option "XkbVariant" "NoDeadkeys"
...
Aber FreeBSD akzeptiert diese Schreibweise nicht und das US-Standardlayout wurde geladen. Nachdem ich es in nodadkeys (alles in Kleinbuchstaben) umgewandelt habe, wurden alle Parameter übernommen...
Code:
Section "InputDevice"
    Identifier    "Keyboard0"
    Driver        "kbd"
    Option        "XkbModel" "pc105"
    Option        "XkdLayout" "de"
    Option        "XkbVariant" "nodeadkeys"
    Option        "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection


Xorg braucht nicht mehr Hal. Dbus wirst du auch wegen anderer Dinge noch brauchen, aber Xorg muss nicht unbedingt einen laufenden Hal haben.
Das mag zwar im allgemeinen so sein, aber ohne Hal funktioniert meine Maus nicht unter Xorg.


Bleibt also noch das Problem mit der Grafik. Aber auch hierzu habe ich neues zu berichten.
kern.vty=vt in der /boot/loader.conf kann viele Probleme mit virtuellen Konsolen beseitigen, ich habe aber vergessen, was das eigentlich macht.
Ich danke Dir sehr, pit234a, für diesen Hinweis. Der hat mich nämlich mal auf Kurs gebracht (jetzt könnte ich fast sogar schon einen kompletten Artikel in einer Fachzeitschrift über Syscons und Newcons verfassen). Und obwohl ich nicht gerade ein Fan von englisch bin, blies mir dieser Treat https://forums.freebsd.org/threads/39414/ noch die richtige Brise in die Segeln.

Die Konsolen und deren Darstellung haben nichts mit Xorg zu tun.
Das z. B. stimmt zwar, aber doch nicht ganz so, wie ich feststellen durfte; denn sowohl der Konsolenmodus, wie auch Xorg fundieren beide auf sc oder vt (je nachdem, was im Kernel beim Bootvorgang aktiviert wird - ob man im laufenden System da noch was drehen kann, habe ich bisher noch nicht herausfinden können). FreeBSD 11 nutzt nämlich standardmäßig Newcons (vt), und bei FreeBSD 10.x hängt es von der Booteinstellung im BIOS ab, weshalb es bei mir (*freu) Syscons (sc) aktivierte. Jedoch beim Test von Xorg mit dem Intel-Grafiktreiber - den ich zu allem Übel auch noch falsch konfiguriert hatte - harmonierte dieser nicht mit sc, und der Bildschirm wurde abgeschaltet
Der laufende X-Server ist ein schwarzer Bildschirm auf schwarzem Hintergrund. Will man das alte Muster mit X-Maus, muss der X-Server mit dem Aufruf der Art erfolgen: Xorg -config -retro /root/xorg.conf.new
Warum die einem heutzutage einen schwarzen Adler auf schwarzem Grund als Testbild vorsetzen, habe ich nie verstanden; vor allem ist es mir ein Rätsel, was man wie damit testen können soll - aber das nur mal so am Rande erwähnt.
Nein, ich meine damit, er wird richtig deaktiviert und geht in den Bereitschaftsmodus. Als ich aber mit vt bootete, präsentierte mir der Xorg-Test (mit der retro-Option natürlich) zwar auch einen schwarzen Schirm, aber der Monitor blieb aktiviert und anstatt des oben erwähnten schwarzen Adlers hatte ich tatsächlich das X für die Maus auf der Mattscheibe. Um die Anzeigefläche zu kontrollieren, mußte ich also mit der Maus die Ränder alle abfahren. Jedoch beim Umschalten bzw. nach dem Beenden von Xorg wurden meine Konsolen auf 1280x1024 umgestellt. Eine Grundeinstellung von 1024x768 liefert mir nur noch ein schwarzes Bild. Zudem ist unter vt auch mein Tastaturlayout verändert. Zwar konnte ich ein deutsches Tastaturlayout einstellen, aber beim betätigen von [ß] wurde ein Steuerzeichen ausgegeben, das mir dann auch erlaubte, den Eingabe-Prompt zu löschen (zumindest teilweise). Ich weiß, deutsche Sondertasten auf der Konsole sind bei eingefleischten UNIX-Freaks sowieso verpönt, aber selbst wenn man diese nicht nutzen möchte kann man schließlich hin und wieder mal draufkommen. Außerdem funktionieren auch andere tolle Sachen unter vt nicht mehr, wie z. B. der Bildschirmschoner - ja vidcontrol überhaupt wird nicht unterstützt, - und auch beim mc stimmt die Formatierung nicht mehr.

Fazit: Ich bleibe lieber beim etablierten sc.

Hier mal eine Gegenüberstellung (Syscons vs. Newcons) und infos über vt: https://wiki.freebsd.org/Newcons

Obwohl mein Prozessor ein Ivi-Bridged ist, muß ich den Intel-Treiber auf Sandy-Bridged konfigurieren. Und nun habe ich auch wieder meinen grauen Schirm, und andere Auflösungen werden ebenso akzeptiert. Nur beim Umschalten/Beenden habe ich dann wieder meine weis-schwarzgestreifte Anzeige - so wie beim ersten mal, als ich Xorg mit pkg installierte. Nunja, vielleicht ist es ja tatsächlich vorerst nicht so schlimm und es ändert sich sobald die Grafische Benutzeroberfläche erst mal installiert ist - was ich jetzt auch gleich tun werde...
 
Das Ja, Newcons unterstützt nur einen Teil der Funktionalität von Syscons und irgendwie scheint es auch kein großes Interesse daran zu geben, den fehlenden Teil zu implementieren. Stattdessen frickelt zumindest ein Entwickler wieder an Syscons herum, dabei ist das Pferd tot und wird auch nicht wieder aufstehen. Denn die Gründe Syscons abzuschaffen und auf Newcons zu wechseln waren:
  • Syscons funktioniert auf exakt einer Plattform: x86 mit BIOS-Boot. Auch wenn das an Anzahl Installationen sicher noch die verbreitetste Kombination ist, holen andere Plattformen eben schnell auf. Auf x86 ist das der UEFI-Boot und dann sind da auch noch all die anderen Architekturen, vor allem ARM, MIPS und PowerPC.
  • Syscons funktioniert nicht zusammen mit KMS. Das hieß und heißt, dass man mit Syscons keine Konsole mehr hat, sobald das Kernelmodul für die jeweilige GPU geladen wird. Nun ist KMS unter FreeBSD allgemein so eine Sache, aber das wird hoffentlich noch. Und zumindest auf Laptops ist es sowieso unumgänglich.
Daher wäre es besser die Arbeit lieber in Newcons zu investieren. Das es nicht passiert, scheint zu bestätigen, was seinerzeit bei der Einführung argumentiert wurde. Newcons mag alles andere als perfekt sein, aber in Zeiten, wo eh kaum noch jemand auf der Systemkonsole arbeitet, ist es ausreichend. :(
 
Das mag zwar im allgemeinen so sein, aber ohne Hal funktioniert meine Maus nicht unter Xorg

Ich schließe dabei nur von meinen Erfahrungen, das kann immer falsch sein.
Dass du soweit gekommen bist, freut mich ungemein und vor allem auch, wegen deiner Rückmeldung, aus der man was lernen kann. Ich möchte das hier stellvertretend mal sagen, dass mir vollkommen klar ist, dass ich mich nicht gut auskenne mit PCs und Betriebssystemen und dass es dann natürlich merkwürdig erscheinen mag, wenn ich mich quasi erdreiste einem alten Hasen wie Seemann was raten zu wollen. Aber auch da schließe ich von mir selbst auf Andere und habe gelernt, dass man manchmal den Wald vor lauter Bäumen nicht sieht. Bei jeder Frage in einem Forum hat man doch zuvor schon eine Menge Hirnschmalz investiert und viel probiert. Mir hat dabei schon sehr oft etwas geholfen, was auf den ersten Blick nicht richtig zu sein schien oder vielleicht sogar an der Sache vorbei gerichtet. Manchmal hilft es einfach, die Gedanken und Erfahrungen anderer zu lesen, egal wie profiliert die nun zu sein scheinen.

Die Option "XkbVariant" "nodeadkeys" hatte ich lange Jahre auch in meiner xorg.conf und eines Tages las ich die Dokumentation an der Stelle etwas genauer und erkannte, dass ich das gar nicht brauche. Ich sehe auch tatsächlich nicht, was nicht funktionieren würde, aber ich möchte nun auch nicht nachlesen.

Das mit der Maus hat sich in FreeBSD mehrmals geändert, seit ich es nutze. Zunächst gab es gar keinen Hal, dann kam er, dann wurde er verbindlich mit X und nun scheint man ihn wieder nicht unbedingt zu brauchen. Ich hatte auf meinem PC ein FreeBSD 6.x installiert und dieses weiter hochgezogen, bis es bei 8.4 wegen einer Änderung in der HW Erkennung nicht mehr weiter ging. Als ich mich dann schließlich entschieden hatte, weiter bei FreeBSD zu bleiben, war gerade 10.2 aktuell und ich wählte dieses als Neueinstieg. Inzwischen bin ich da bei 11 angekommen. Das erzähle ich, weil ich im Einzelnen nicht mehr weiß, wann mir der Hal abhanden gekommen ist. Ich weiß, dass ich ihn vor nicht allzu langer Zeit noch nutzte und auch glaubte, ihn für irgendeine Sache zu brauchen und ich ich habe ihn auch nicht wirklich ganz eliminiert und nur auskommentiert. Ich scheine also da vorsichtig zu sein. Was ich halt genau sagen kann, dass ich derzeit auf zwei PCs mit FreeBSD 11 keinen Hal laufen habe und trotzdem mit Maus arbeiten kann.
In beiden Fällen habe ich aber eine Section (oder zwei) in der xorg.conf, die meine Maus beschreiben und ich kann zumindest teilweise auch auf der Konsole damit arbeiten. Ich starte normal immer X, arbeite grafisch und nutze Terminal-Programme. Wenn ich aus der laufenden Sitzung auf die System-Konsolen umschalte, dann kann ich die Maus dort auch benutzen, ansonsten habe ich das nun nicht eigens getestet, aber ich glaube, dass ich sie auch schon mal vermisste hatte.
Einer der beiden PCs ist ein kleiner Asus EEE mit eingebautem Touchpad und hier brauchte ich zwei Einträge in der xorg.conf, um einmal dieses zu definieren und einen weiteren Eintrag, für zusätzlich am USB-Port angesteckte Mäuse, die ich sehr gerne nutze, weil das Touchpad ziemlich mies ist. Ich zeige hier mal die beiden Sektionen aus dem Asus:
Code:
Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option	    "Protocol" "auto"
	Option	    "Device" "/dev/sysmouse"
	Option      "Emulate3Buttons" "true"
	Option	    "ZAxisMapping" "4 5 6 7"
EndSection

Section "InputDevice"
        Identifier  "Mouse1"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/psm0"
        Option      "ZAxisMapping" "4 5 6 7"
EndSection
Ich kann im laufenden Betrieb einstecken oder abziehen und beide aktiven Geräte gleichzeitig benutzen. Die Section ServerFlags war dabei wichtig:
Code:
Section "ServerFlags"
    Option         "AutoAddDevices" "False"
    Option         "AllowEmptyInput" "Off"
EndSection
Ohne Option "AutoAddDevices" "False" funktionierte es nicht, wenn ich mich recht erinnere.
 
Zurück
Oben