Unter NetBSD habe ich es ein paar mal erlebt, dass nach der
Installation des Betriebssystems die Grafik sowohl auf der Console als
auch unter Xorg sehr schlecht war: Auf der Console waren die
Schriftzeichen viel zu gross und unter Xorg war die Auflösung miserabel
und weit unterhalb von Full HD, also 1920x1080.
Meine Lösung war dann immer, die gop-Einstellung in der /boot.cfg zu
ändern. Der Parameter gop ändert dabei Einstellungen im Graphics
Output Protocol (GOP).
Um den richtigen Wert für gop zu ermitteln, wird NetBSD gebootet und
dabei im Bootmenü die Auswahl Drop to boot prompt gewählt.
Am Boot Prompt dann zunächst die möglichen Parameter für gop abfragen:
gop list zeigt nun die Möglichkeiten an. Für Full HD war es bei mir
zuletzt der Eintrag 6, der 1920x1080 anbot. Das kann aber auch eine
andere Zahl sein, abhängig von der verbauten Grafikkarte.
Mit gop set 6 wird dieser Parameter übergeben und dann mit boot
frisch gebootet. Jetzt kann im realen System überprüft werden, ob die
Einstellungen auf der Console und unter Xorg OK sind.
Um diese Einstellung dauerhaft zu machen, wird dann die Datei
/boot.cfg geändert. Dazu muss ein Menü-Eintrag in /boot.cfg
entweder geändert oder ein neuer Menüpunkt erstellt werden. Ich habe
den Standard-Eintrag angepasst, sodass NetBSD einfach durchstarten kann
und nicht jedesmal der neue Menüpunkt explizit eingegeben werden muss.
Meine /boot.cfg sieht dann so aus:
menu=Boot normally:gop 6;rndseed /var/db/entropy-file;boot
menu=Boot single user:rndseed /var/db/entropy-file;boot -s
menu=Drop to boot prompt:prompt
default=1
timeout=5
clear=1
Wie unschwer zu erkennen ist, hat jetzt der erste Eintrag (Boot
normally) den Eintrag gop 6 dazu bekommen. Jetzt hat das System
überall eine vernünftige Auflösung.
Auf einem meiner Rechner mit ASUS F2A85M-Board hatte ich sporadische Probleme, die nur unter OpenBSD auftraten. Es gab völlig unregelmäßig Hänger in allen möglichen Anwendungen, besonders aber in Firefox und Google Chrome. Dabei hat die Anwendung nicht mehr reagiert und die HD-LED des Rechners leuchtete dabei dauerhaft. Die Hänger lagen zwischen ca. 3 und 30 Sekunden. Danach ging alles normal weiter.
Ein zweites Problem waren ebenso sporadische Abstürze von Firefox: Zack, einfach weg. Dabei gab es keine Einträge in irgendwelchen Logs.
Mein erster Verdacht war ein Hardware-Problem. Ein neues Board, eine neue SSD und ein Netzteil lagen schon bereit. Durch eine Diskussion in bsdforen.de kam ich aber auf eine andere Spur. Tests mit glxgears -info und WebGL Samples liessen mich mich in Richtung Grafik weiter suchen.
Die Lösung: Etwa vor 2 Jahren hat OpenBSD die device nodes für die Grafik geändert von /dev/drm0 auf /dev/dri/card0. Alle dafür releveanten Änderungen hätten bei einem Upgrade angepasst werden sollen - und das hat wohl nicht immer korrekt funktioniert. Der xenodm beispielsweise hätte die Dateiattribute von /dev/dri/card0 auf den Benutzer von Xorg beim Start ändern müssen. Hat er aber nicht.
Bei mir hat heut nacht ein einfaches sysmerge gereicht, das in Ordnung zu bringen. Seitdem sieht die Ausgabe von glxgears - info auch vernünftig aus:
[berni@tc58 ~] $ glxgears -info
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER = AMD ARUBA (DRM 2.50.0 / 7.2, LLVM 13.0.0)
GL_VERSION = 3.1 Mesa 22.1.7
GL_VENDOR = X.Org
VisualID 1288, 0x508
306 frames in 5.0 seconds = 61.149 FPS
301 frames in 5.0 seconds = 60.003 FPS
301 frames in 5.0 seconds = 59.998 FPS
Zur einfachen Überprüfung reicht ein Blick auf /dev/dri/card0: Nach dem Start von Xorg via xenodm muss der Eigentümer dieser Datei der entsprechende Benutzer sein, also der, der Xorg gestartet hat. Wenn nach wie vor root der Eigentümer ist, ist was faul. Dann mal ein sysmerge laufen lassen.