Subsciption liste@tlug.de

[Christoph 'Mehdorn' Weber]

Christian Ordig wrote:

> ich denke es ist irgendwie momentan recht ruhig hier ... wieso auch 
> immer. 

  Nun, ändern wir das.

  Ich habe aktuell nämlich drei vielleicht interessante Probleme.

  Problem 1: Auf einem Debian-stable-Rechner möchte ich screen als
Login-Shell benutzen. Dabei ist es aber so, daß Screen beim Start
automatisch eine laufende Session krallt. Sofern ich mich auf einer
Konsolen einlogge, etwa um permanent centericq auf im Vordergrund laufen
zu lassen, und mich dann auf einer anderen Konsole zum Arbeiten
einlogge, bekomme ich automatisch die centericq-Session attached und
kann dann auf beiden Konsolen im centericq herumrühren. Kann man dieses
lästige Auto-Attach ohne Rekompilation irgendwie abschalten? Die Manpage
hat dazu nichts gesagt, auch nicht die FAQ.

  Zudem funktionieren solche Späße wie "setterm -foreground green
-store" nicht mehr, d. h. die Vordergrundfarbe bleibt Standard-Grau.
TERM=screen wird durch Screen automatisch gesetzt. Auch dazu schwieg die
FAQ. Ideen, was da nicht hinhaut?

  Problem 2: Debian-stable-Rechner, diesmal ein relativ neues, seltsames
P3-Teil mit Onboard-Grafik und XFree 4.1.0 läuft an sich fast gut,
solange ich nicht in den Grafikmodus gehe. Dort schmiert so ziemlich
jedes Programm ab, unter anderem auch eine Reihe Window-Manager etc.
Entweder melden sie einen Segfault oder einen Divisions-
/Float-Überlauf-Fehler. Es ist alles ziemlich merkwürdig unter X.
Theoretisch hätte ich ja auch gern ein Xfree 3.3.6 genommen, wie auf
fast allen anderen meiner Rechner. Das läuft eigentlich überall recht
gut und flott. Allerdings kommt das mit der Onboard-Karte nicht zurecht.

  Jedenfalls ist das alles ziemlich merkwürdig, und da selbst xvidtune
nicht mag, hängt das Bild halb über die Bildschirm-Ecke. Das will man
sich dann doch nicht antun. Derzeit bringe ich das System mal auf
testing -- mal sehen, ob das hilft. Ich zweifele noch.

  Zu dem Problem suche ich allerdings weniger eine direkte Lösung,
sondern vielmehr Hinweise zur Umgehung.


  Und, schließlich:

  Problem 3:

  Der angesprochene P3 hat irgendwie Probleme mit der seriellen Maus,
die über so eine Umschalt-Box angeschlossen ist. Die Maus allein spricht
schon einen einigermaßen ekligen Akzent, und die Kabel-Verlängerung, die
durch die Box bedingt wird, scheint es noch schlimmer zu machen.
Jedenfalls habe ich jetzt mal probeweise eine nette Logitech-PS/2-Maus
angesteckt. Auf dem System läuft ein Kernel 2.4.24 (Eigenbau), wo ich
zunächst PS/2-Mäuse als Modul eingebunden hatte. Nach einem "make clean
dep", "make -j 32 bzImage modules" und "make modules_install" fand ich
allerdings kein Modul für den psaux-Krimskrams. Das war schon recht
merkwürdig.

  Daher habe ich den Spaß mal fest eingebaut, seither existiert psaux
auch im devfs. Schön, dachte ich, schmeiße ich also gpm einmal an. Mit
gpm-mouse-test wollte ich mal eben das Protokoll der Maus genauer
ermitteln (bei Logitech gibt es ja da ein paar Varianten), allerdings
funktionierte das ziemlich gar nicht, da er beim Versuch der
Baudraten-Erkennung einfach stecken blieb. Die Maus anschließend fest
auf "-t ps2" und Device "/devfs/misc/psaux" zu konfigurieren hat
ebenfalls nichts gebracht. Eine Überprüfung im BIOS hat gezeigt, daß der
PS/2-Port aber durchaus aktiv ist. Interessant ist vielleicht, daß
weder dmesg, noch lspci noch /proc/interrupts und /proc/ioports auch nur
ein Sterbenswörtchen über psaux verlieren. Ob das normal ist, kann ich
leider nicht verifizieren, weil das mein einziger PS/2-Port-Rechner ist,
abgesehen von einigen 286ern.

  Was könnte man da tun, abgesehen vom Direktanschluß einer seriellen
Maus?

Christoph

-- 
Hmm jedenfalls hat es vor knapp anderthalb Wochen im Siegerland
einen Feldversuch zu taktischen Kleinbussen gegeben. --
War da vor dem Versuch auch schon ein Feld, oder erst danach?
(Michael Groß, Andreas Riedel)