OpenBSD auf einem ThinkPad T60: Wie und warum? Hier entlang!

[simpel]

Das steht bei so ziemlich jeder Hardware mit drauf.

Das stimmt natürlich - es war auch eher ironisch gemeint

 

[allegutennamenwarenweg]

Erinnert mich an die "Badges" auf Websites Ende der 90er. "Optimized for Netscape". "Best viewed with a computer".

 

[simpel]

Da steht nicht, dass es keins geben wird, nur, dass es das Problem nicht löst, oder?

Auszug einer Antwort, die ich auf meine Anfrage hin erhalten habe:

I think the answer was definitive, as it came from Jonathan Gray, who is an OpenBSD developer ("jsg@").

Unfortunately, most hardware support development requires both a) an interested developer and b) direct access to the hardware by the developer. It's not known to me if any of the developers have the hardware, or have an interest. If you had two of these video cards, and were willing to donate one of them, you might find an interested developer.

Or, you might consider porting the FreeBSD code to OpenBSD. That's the most common way that people become OpenBSD developers and join the project -- they have an unmet need, and an interest, and start learning OpenBSD internals and devising solutions themselves.

 

[allegutennamenwarenweg]

Tja... dann spende eine.

 

[simpel]

öhm, es ist ein Grafikchip, der auf der Hauptplatine fest verlötet sein dürfte ...

P.S.
so ein abgerocktes R40e kann man billig schiessen - ich könnte ja eins käuflich erwerben und es dem guten Jonathan Gray schicken - das Gesicht und seine Freude darüber würde ich gern sehen

 

[simpel]

OpenBSD für Fortgeschrittene

Bin weiterhin am tüfteln, wie man das Grafik-Problem bestmöglich lösen kann (es ist ja auch ein Lernprozess).

Hier nochmal die Ausgabe von dmesg:

...
drm: initializing kernel modesetting (RS200 0x1002:0x4337 0x1014:0x053A).
error: [drm:pid0:radeon_agp_init] *ERROR* Unable to acquire AGP: 22
drm: Forcing AGP to PCI mode
radeondrm0: VRAM: 16M 0x000000003F000000 - 0x000000003FFFFFFF (16M used)
radeondrm0: GTT: 512M 0x0000000040000000 - 0x000000005FFFFFFF
drm: PCI GART of 512M enabled (table at 0x0000000001EC7000).
error: [drm:pid0:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD)
error: [drm:pid0:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
error: [drm:pid0:r100_startup] *ERROR* failed initializing CP (-22).
error: [drm:pid0:r100_init] *ERROR* Disabling GPU acceleration
error: [drm:pid0:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
drm: radeon: cp finalized
drm: Panel ID String: 1024x768                
drm: Panel Size 1024x768
radeondrm0: 1024x768
wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)

wenn ich es richtig verstanden habe, kann man im Kernel radeondrm via config abschalten?

http://www.openbsd.org/faq/faq5.html#config

P.S.
Und macht die Überlegung überhaupt Sinn, wenn im -current Zweig alle paar Wochen der Kernel ausgetauscht wird?

 

[allegutennamenwarenweg]

Ja.

Und du musst nicht jedes Update mitmachen.

 

[simpel]

Ja klingt schon mal gut.
Hattest du genügend Zeit die Errors genau anzuschauen, oder genauer gefragt, kann ich alle Errors mit config beheben?

Ab und zu möchte ich schon gern beispielsweise den Browser aktualisieren. Doch hatte ich es schon, dass ein pkg_add -u jede Menge Abhängigkeitsfehler angezeigt hat, die nur durch ein Snapshot-Update zu beheben waren.
Würde daher ein neuer Kernel die durch config vorgenommenen Änderungen übernehmen, oder sind die futsch? Also gefühlt möchte ich meinen, die werden nicht übernommen...

 

[allegutennamenwarenweg]

Der Binärkernel aus den Snapshots ist selbstverständlich ein anderer als der, den du dir selbst kompilierst.

 

[simpel]

Dann wäre dieser Lösungsansatz doch besser für -stable geeignet - ein Grund mehr -stable zu folgen.

 

[allegutennamenwarenweg]

Da wird dann aber zum Beispiel dein Browser schnell veralten.

 

[simpel]

... also bei -stable geht es nicht ohne Kompilier-Orgien

P-S.
das sollte eine Frage sein.

 

[allegutennamenwarenweg]

Doch, wenn du keinen anderen Kernel brauchst und mit älterem Firefox o.Ä. zufrieden bist.

 

[simpel]

die Situation hatten wir doch schon durch

aber okay, dann ist dieser Lösungsansatz mit config nicht gut genug...

 

[simpel]

Inzwischen bin ich mit OpenBSD auf ein HP Notebook umgezogen. Bei der Installation bin ich der Anleitung des Themenstarters gefolgt - wollte ich doch schon immer mal den Tiling-Fenstermanager awesome testen.

Zeitweise läuft das Notebook in der Dockingstation mit externem Monitor, sowie externer Maus und Tastatur. Unterwegs benutze ich das Touchpad, dabei ist das Touchpad Scrolling unverzichbar. Es soll also an den Konfigurationsdateien von X Hand angelegt werden und dafür muss zunächst eine xorg.conf erstellt werden.

Jedoch gestaltet sich dieses Vorhaben schwieriger als gedacht, denn X wird durch den Display-Manager XDM gestartet. Daher soll XDM vorübergehend deaktiviert werden - in der /etc/ttys wird daher die betreffende Zeile auf off gesetzt:

#
#       $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $
#
# name  getty                           type    status          comments
#
console "/usr/libexec/getty std.9600"   vt220   off secure
ttyC0   "/usr/libexec/getty std.9600"   vt220   [B][COLOR=#ff0000]off[/COLOR][/B] secure
ttyC1   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC2   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC3   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC4   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC5   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC6   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC7   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC8   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC9   "/usr/libexec/getty std.9600"   vt220   off secure
ttyCa   "/usr/libexec/getty std.9600"   vt220   off secure
ttyCb   "/usr/libexec/getty std.9600"   vt220   off secure
tty00   "/usr/libexec/getty std.9600"   unknown off

Folgender Befehl soll X beenden und danach nicht mehr automatisch starten:

# kill -HUP 1

Nachdem die xorg.conf erstellt wurde, wird auf on zurückgesetzt.

Als root soll zunächst die xorg.conf.new erstellt werden:

# Xorg -configure

Es kommt jedoch eine Fehlermeldung, dass X noch aktiv ist - selbst ein Reboot ändert daran nichts? Wo liegt der Fehler?

Harzlichen Gruß

 

[allegutennamenwarenweg]

Warum so umständlich und nicht einfach den Texteditor nehmen?

 

[simpel]

ich denke, von X die xorg.conf-new erstellen zu lassen, und diese dann anzupassen und als xorg.conf zu verwenden, ist der einfachste Weg?

Sei mit deinem Vorschlag doch bitte etwas konkreter...

 

[buddabrod]

Es reicht doch heutzutage eine einfache xorg.conf, z.B.

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
EndSection

Xorg -configure habe ich schon Äonen nicht mehr gebraucht - auch nicht unter *BSD.

 

[simpel]

okay, dann versuche ich es mal so

P.S.
da hält man sich schon mal an das Handbuch...

 

[allegutennamenwarenweg]

Na ja, eine xorg.conf mit deinen Wünschen ist vermutlich manuell nicht wesentlich langsamer erstellt. OpenBSD braucht ja eigentlich keine, um sinnvoll zu funktionieren.