Re: GNOME Fehler Log, wo ist es?

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Mon, 25 Jan 2010 13:35:45 +0100 (CET)

Polytropon <freebsd(at)edvax.de> wrote:
> Oliver Fromme wrote:
> > Polytropon <freebsd(at)edvax.de> wrote:
> > > Und nun stell Dir mal vor, was Du machst, wenn Du nicht nur
> > > eine garstige deutsche Tastatur, sondern auch noch eine Maus
> > > mit 3 Tasten (ohne Rad) hast und machen willst, daß die
> > > mittlere Taste sowohl Rad als auch Taste 2 steuert. Na
> > > viel Freude auch. :-)
> >
> > Dafür hat moused(8) die Option -V, die ebenfalls nach dem
> > Update noch funktioniert. Das hat mit Xorg nichts zu tun.
>
> Im Textmodus hat die Maus per moused immer tadellos funktioniert.
> Nur X mußte ich beibiegen, daß die mittlere Taste - je nach
> Kontext - Taste 2 und Mausrad sein sollte. An moused_flags
> habe ich nichts ändern müssen, nur in xorg.conf.

Trotz Option -V beim moused(8)?

Kann natürlich gut sein, dass Xorg da noch was Spezielles
macht. Da ich die Scrollfunktion nur in Opera benötige,
der selbst ein virtuelles Scrolling unterstützt (was im
übrigen viel besser funktioniert als irgendeine Scrollrad-
Emulation), verwende ich -V selber nicht.

> > Es war mir schon immer ein Dorn im Auge, dass ein Userland-
> > Programm (noch dazu so ein komplexes wie ein X-Server)
> > direkt an der Hardware herumfummelt. Sowas gehört in den
> > Kernel und mit einer ordentlichen API versehen. Bei DRM
> > geht das ja auch bereits.
>
> Wenn das dann auch funktioniert (und X nicht nochmal was
> neues erfindet), dann begrüße ich das unter diesem Gesichtspunkt
> natürlich auch. Hoffentlich zeichnet sich die BSD-Implementation
> von KMS durch ein langlebigeres API aus, als ich das sonst
> so aus der Linux-Welt kenne (wo sich, übertrieben gesagt,
> die APIs täglich ändern).

Vermutlich wird die API die gleiche sein wie bei Linux,
oder sich nur geringfügig unterscheiden. So ist es auch
bei DRM. Anderenfalls müsste der entsprechende Code in
Xorg gepatcht (und die Patches dauerhaft gepflegt) werden,
was sicherlich niemand freiwillig machen will.

> > Üblicherweise baue ich trotzdem eigene Kernel, aber das hat
> > ganz andere Gründe: Es gibt eine Reihe von Optionen, die
> > (leider) nicht auf andere Weise angepasst werden können.
>
> Stimmt. Das mußte ich bei der Aktivierung einer TV-Karte
> feststellen. Gefreut hat mich, als ipfw als Kernelmodul
> verfügbar wurde (irgendwann in 5, glaube ich). Es wäre
> toll, wenn das generell ginge, für alle Sachen, also auch
> für spezifische Optionen, wie Du beispielhaft mit MSGBUF_SIZE
> genannt hast; einige FIREWALL-Optionen zählen auch dazu,
> ebenso *DFLT_KEYMAP oder SC_DFLT_FONT.

Ja, das wäre schön, aber leider ist es nicht ganz einfach
(sonst hätte es schon jemand getan). Im Prinzip könnte
man für alle diese Optionen loader-tunables einrichten.

Im Falle der *DFLT*-Optionen wird es schwierig, weil die
Loader-tunables dafür gedacht sind, einzelne Zahlenwerte
oder (kurze) Strings zu übermitteln (siehe die Ausgabe
von kenv(1)), aber keine größeren Binärdateien, wie es
für eine Keymap oder einen Font notwendig wäre.

Da die *DFLT*-Einstellungen im wesentlichen nur für den
Single-User-Mode nützlich sein können, den man ja nicht
besonders häufig braucht, finde ich das jetzt nicht so
schlimm. (Oder übersehe ich da gerade etwas? Ich habe
diese Optionen jedenfalls noch nie benutzt.)

Gruß
   Olli

PS: Du brauchst mir nicht jedesmal eine Kopie an meine
Mailadresse zu schicken (Reply-To ist gesetzt). Ich
brauche nicht alles doppelt ...

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"I learned Java 3 years before Python.  It was my language of
choice.  It took me two weekends with Python before I was more
productive with it than with Java." -- Anthony Roberts
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 25 Jan 2010 - 13:36:06 CET

search this site