# xorg-server-1.5.3 ein Fazit

## trbl

Nach dem Upgrade auf xorg-server-1.5.3 und dem Grafiktreiber xf86-video-mga-1.4.9 war die 2D-Grafikleistung so stark reduziert, das ein arbeiten in einem Konsolfenster (kde-3.5.9) zu Qual wurde. 

Folgender Artikel beschreibt mein Problem recht gut:

http://www.mail-archive.com/xorg%40lists.freedesktop.org/msg03098.html

und das im Artikel verlinkte Video macht es anschaulich:

http://www.youtube.com/watch?v=N_6cYVLLgNg

Der Unterschied zwischen mir und dem Verfasser des Artikels ist nur, dass er mit Intel-Grafik unter xfce4 arbeitet. Bei der Intelgrafik scheint es am Treiber zu liegen und es gibt anscheinend auch schon Workarounds. Zum gleichen Problem mit einer Matrox-Grafikkarte konnte ich nichts weiter finden. 

Da ein vernünftiges arbeiten mit der schlechten 2D-Leistung nicht mehr möglich war, habe ich einen Downgrade auf xorg-server-1.3.0.0-r6 mit dem Grafiktreiber xf86-video-mga-1.4.6.1 vollzogen. Jetzt läuft alles wieder einwandfrei.

Ein weiteres Problem war die Unverträglichkeit zwischen mga und matroxfb. Sobald X hochgefahren war, war in keiner der Konsolen (tty01-07) ein arbeiten möglich, da keine Zeichen mehr dargestellt wurden. Es wäre aber zu verschmerzen gewesen, mit einer Standard-Konsole zu arbeiten, wäre nicht die schlechte Grafikleistung unter X.

Hoffentlich maskiert keiner den xorg-server-1.3.0.0-r6, bevor die Probleme mit der Grafikleistung im xorg-server >= 1.5.3 behoben sind. In der zwischenzeit setze ich ein Testsystem auf um solch elementare Pakete prüfen zu können, bevor ich sie in mein Produktivsystem einspiele.

-trbl

----------

## SvenFischer

Ich habe wegen KDE 4.2.1 auf meinem Laptop das alles mal ~x86 installiert. Ich habe massive Grafikprobleme und die Geschwindigkeit ist auch im Eimer.

----------

## trbl

Eigentlich nehme ich, mit wenigen Ausnahmen, nur Pakete aus dem Stable-Zweig, um die Produktivität meines Systems nicht zu gefährden. Gerade bei so grundlegenden Dingen wie Kernel, GCC, X und KDE gehe ich keine Risiken mehr ein. Umso verwunderter war ich, als mir beim einspielen von stabil markierten Paketen einige Funktionen garnicht mehr und andere nur mit erheblichen Einschränkungen zur Verfügung standen.

Aber ich sehe es sportlich, die 24h investierte Zeit um erst xorg-server -1.5.3 zum laufen zu bekommen und im Anschluss wieder ein produktives System zu bekommen (mit dem Downgrade), waren nicht ganz umsonst, da ich mein Wissen um die Funktionsweise des Systems wieder etwas aufgefrischen konnte   :Laughing: 

Wenn dein System für dich, im derzeitigen Zustand, nicht oder nur eingeschränkt nutzbar ist, wurde ich den Rückschritt auf den stabilen Zweig in Erwägung ziehen. Es ist nicht ganz einfach aber es geht sicher   :Wink: 

-trbl

----------

## sirro

Hatte weder mit 1.5 noch jetzt mit 1.6 Performance-Probleme. Hab allerdings auch nvidia.

Mein Problem: Die Tastatur-Layouts wollen nicht so 100% wie ich will  :Sad: 

----------

## trbl

hast du schon diese HAL-Dateien, wie folgt unter 'Deutsches Tastaturlayout einstellen' beschrieben, angepasst?

http://wiki.archlinux.de/title/Evdev

-trbl

----------

## pablo_supertux

 *sirro wrote:*   

> Hatte weder mit 1.5 noch jetzt mit 1.6 Performance-Probleme. Hab allerdings auch nvidia.
> 
> Mein Problem: Die Tastatur-Layouts wollen nicht so 100% wie ich will 

 

Ich schon   :Confused: , mein Workaround sind wieder mal unstable nvidia-drivers

----------

## sirro

 *trbl wrote:*   

> hast du schon diese HAL-Dateien, wie folgt unter 'Deutsches Tastaturlayout einstellen' beschrieben, angepasst?l

 

Deutsches Layout ist kein Problem. Ich nutze aber "gb,de" also ein Umschaltbares. Und sobald da gb mit drinhaengt macht es komische Sachen. "us,de" geht z.B. fast perfekt (auch noch ein kleiner Fehler drin).

Details gibt es in Best upgrade method to Xserver1.5 with Hal and evdev

Lasse das ganze jetzt einfach von KDE machen, das funktioniert zwar nur in KDE aber besser als ueber xorg.

@pablo_supertux: Das kann sein, ich habe eh den neusten Nvidia-Treiber drauf. Also mit aelteren keine Erfahrung.

----------

## mv

 *sirro wrote:*   

> Deutsches Layout ist kein Problem. Ich nutze aber "gb,de" also ein Umschaltbares. Und sobald da gb mit drinhaengt macht es komische Sachen. "us,de" geht z.B. fast perfekt (auch noch ein kleiner Fehler drin).

 

de,us ist bei mir nicht benutzbar: Nach Umschalten auf us geht die Umschalttaste nicht mehr, ich komme also nie mehr zurück. Mit de,gb hingegen gibt es dieses Problem nicht. Das ist übrigens eine reine Xorg-Geschichte: mit kbd statt evdev gibt es exakt das selbe Verhalten.

Hier mal meine Config:  */etc/hal/fdi/policy/10-x11-input.fdi wrote:*   

> <?xml version="1.0" encoding="utf-8"?>
> 
> <deviceinfo version="0.2">
> 
>    <match key="info.capabilities" contains="input.keys">
> ...

 

Was u.a. damit nicht geht:  Mit NumLock kann man praktisch nicht arbeiten (backspace ist kein backspace mehr u.v.a.). Dieses Problem gibt es schon seit etlichen xkeyboard-configs.  Nach dem Umschalten (CapsLock) wenn man wieder zurück geht, ist es so, als hielte man AltGr permanent gedrückt. Nach nochmaligem HIn- und Herschalten ist das wieder weg. Im Vergleich zu ",us" statt ",gb" (bei dem man, wie erwähnt, gar nicht mehr zurück kommt) ist das ja aber ein harmloser Bug.

----------

## sirro

 *mv wrote:*   

> Nach Umschalten auf us geht die Umschalttaste nicht mehr, ich komme also nie mehr zurück.

 

Benutze die Windows-Taste zum Umschalten. Damit funktionierte alles soweit ich das ausprobiert habe (das us-layout will ich immer schnell loswerden). Das einzige was mir als Fehler aufgefallen ist, es wurde so umgeschaltet: us -> de -> us -> nochmal us -> de -> us -> nochmal us usw.

 *Quote:*   

> Mit de,gb hingegen gibt es dieses Problem nicht.

 

Und das/mein Problem mit den ganzen Sonderzeichen hast du dann nicht?

 *Quote:*   

> Das ist übrigens eine reine Xorg-Geschichte: mit kbd statt evdev gibt es exakt das selbe Verhalten.

 

Jo, auch schon alles probiert. Mit <1.5 ging es aber problemlos. Und kde mit seinen setxkbmap-Aufrufen funktioniert auch jetzt mit 1.6 problemlos.

 *Quote:*   

> Hier mal meine Config

 

Hm, der einzige richtige Unterschied ist "nodeadkeys" als Variante. Da hatte ich gar nichts. Muss ich auch nochmal ausprobieren bevor ich ganz aufgebe und mit dem KDE-only-workaround gluecklich werde.

----------

## mv

 *sirro wrote:*   

>  *Quote:*   Mit de,gb hingegen gibt es dieses Problem nicht. 
> 
> Und das/mein Problem mit den ganzen Sonderzeichen hast du dann nicht?

 

Wie ich schrieb: Beim ersten Zurückschalten ist es so, als wenn man AltGr permanent gedrückt hielte (statt "home" heißt es dann beispielsweise "ħøµe"). Bei zweiten Zurückschalten geht es aber wieder (dann beim dritten wieder nicht usw). Bei "de,us" statt "de,gb" ist das aber alles viel schlimmer: Nach Umschalten in "us" geht da eigentlich gar nichts mehr. Man kommt nicht nur (wie ich schrieb) nicht mehr nach "de" zurück, es geht außer den druckbaren Zeichen praktisch nichts mehr, nicht einmal "return".

----------

## artbody

Dieser Schwachsinn mit xorg und dem hald stößt mir gerade so richtig übel auf

Wie peinlich ist das denn so langsam, wenn man für die richtige Funktion eines Keyboards die Suche im Forum hier, Googel, das wiki von gentoo .... durchkämmen muß, um festzustellen, 

daß alles bei einem anderen Keyboard eventuel, 

aber beim eigenen einfach mal nicht richtig tutut

Cherry Cymotion Linux Master   :Arrow:  glänzt gerade durch völliges fehlen von der Funktionstasten. 

Pfeil- Hoch,links.rechts geht und wenn ich auf Runter drück gibt es ein @ Zeichen - 

die Taste wo das sein sollte tut gar nichts, sondretasten machen auch teilweise Schwachsinn.

also mal wieder der Punkt, wo weder leise noch lautstellen über eine MULTIMEDIATASTATUR funktioniert

Pos1 tut ENDE tutnicht uaaaaaaaaaaaaaaaaaaa

oder muß man das jetzt der xml (müll) hald(e) in xml für jede Taste irgendwie von Hand beibringen

 :Rolling Eyes:   :Razz:   :Embarassed:   :Crying or Very sad:   :Confused:   :Evil or Very Mad:   :Twisted Evil:   :Question:   :Crying or Very sad: 

Welches ******* M$abtrünnige K* Developer *****************

xml kasperle hat sich denn Unfug ausgedacht?

Wizo ist sowas unausgetestetes eigentlich durch die Gentoo QS gekommen?

Wenn ich mir schon allein die unterschiedlichen Schreibweisen in manchen Beiträgen anschaue, wird es mir angst und bange

10-input oder 10-keymap ..............

hey so ein ding steckt man ein und es sollte funktionieren

das ist eine einfache Tastatur...........................

Sagt jetzt bloß nicht ich soll zu Microsoft

ich weiß seit 1998 nicht mehr wie das M$ tut

aber seit 1998 ging meine Tastatur fast immer 

Schei*e ärgert mich sowas

XX Stunden zum eine Tastatur zu konfigurieren und die FAQ's +Forums+ Wikis abzuklappern 

@@@@@@@@@@@@@@@@@@@H@A@S@S@@@@@@@@@@@@@@@@@@@@@@

----------

## artbody

Also ein Teil der sogenannten HALD keyboardfunktionen hab ich dadurch zurückbekommen, indem ich die .Xmodmap (welche in mühevoller Arbeit erst vor nicht allzulanger Zeit erstellt wurde) nach /backups_old verschoben hab   :Wink: 

wenigstens geht mal wieder POS1 und ENDE

Aber lauter und leiser etc geht trotzdem net

 :Embarassed: 

----------

## Mr_Maniac

 *artbody wrote:*   

> Also ein Teil der sogenannten HALD keyboardfunktionen hab ich dadurch zurückbekommen, indem ich die .Xmodmap (welche in mühevoller Arbeit erst vor nicht allzulanger Zeit erstellt wurde) nach /backups_old verschoben hab  
> 
> wenigstens geht mal wieder POS1 und ENDE
> 
> Aber lauter und leiser etc geht trotzdem net
> ...

 

Ich nutze hald gar nicht, sondern die pure xorg.conf mit evdev-input-Treibern.

Meine Multimediatasten werden irgendwie als extra-Eingabegerät unter /dev/input geführt.

Für das alte XOrg war das irgendwie kein Problem (Da habe ich auch noch Option "Name" $Namedesdevices" benutzt und nicht, wie jetzt, Option "Device" /dev/pfad/zum/device).

Auch konnte ich unter dem alten XOrg problemlos zusätzlich eine Maus zu meinem Touchpad anschließen, die sofort funktioniert hat. Jetzt funktionieren irgendwie NUR NOCH Devices, die ich auch in der xorg.conf eingetragen habe...

Und hald installieren, nur um solche Funktionalität wieder zurückzubekommen? Auf meinem Haupt-PC zerschießt mir hald zumindest meinen Marvel-SATA-Controller und eine Festplatte wird dadurch unansprechbar.

----------

## Finswimmer

HAL Unterstützung in Xorg braucht man nur, wenn man dauernd wechselnde Input Geräte hat, die sonst nicht angesprochen werden, da nicht in xorg.conf.

Da Gentoo aber nicht alle Treiber installiert hat, bringt es auch nicht viel, wenn HAL ein Wacom Table entdeckt, die Treiber für X11 aber nicht geladen werden können, da nicht installiert.

Ergo habe ich hal Unterstützung herausgenommen und lasse nun weiter alles über mouse/keyboard laufen.

Klappt super.

Viele Grüße

Tobi

----------

## firefly

 *Mr_Maniac wrote:*   

> 
> 
> Ich nutze hald gar nicht, sondern die pure xorg.conf mit evdev-input-Treibern.
> 
> Auch konnte ich unter dem alten XOrg problemlos zusätzlich eine Maus zu meinem Touchpad anschließen, die sofort funktioniert hat. Jetzt funktionieren irgendwie NUR NOCH Devices, die ich auch in der xorg.conf eingetragen habe...
> ...

 

In der manpage vom evdev treiber gibt es eine Beispiel konfiguration für die xorg.conf mit der man alle Mäuse mit abdecken kann. (zu mindestens das die Mouse an sich funktioniert)

----------

## ChrisJumper

Ich nutze diesen Post einfach mal um mal meine Eindruck zu erleutern.

Generell finde ich ist es eine gute Sache, auch das mit HAL im Xorg. Deswegen wünsche ich mir eine saubere Konfiguration und kein einfaches deaktivieren in X.

Allerdings bereitet die ensprechende Dokumentation nicht ausreichend auf dieses Update vor,  vielleicht sollte hier im Forum noch mal ein Sticky-Thread erstellt werden der eine kleine Einführung gibt und auf die "Probleme hinweist".

Die XML-Configurations-Files sind schon eine klasse Sache und machen auf mich einen saubereren Eindruck, auch wenn man noch mehr tippen muss.

Auf drei von vier Systemen lief das Update ohne Probleme durch. Natürlich ist es beim ersten mal umständlich die fdi-Datei zu erstellen, aber das war bei meiner ersten xorg.conf auch so. Allerdings muss ich EOF recht geben. All dies wirkt noch ein wenig zusammengeschustert. Es gibt scheinbar keine Auto-Erkennung, welche dann die entsprechenden Werte auswähl. Oder fragt welche Tastatur-Layouts man möchte usw. Das finde ich schade.

Zur Zeit hab ich nur noch ein Problem mit dem Microsoft Natural Ergonomy Keyboard 4000 V1.0. Das einrichten meiner anderen Geräte funktionierte einwandfrei.

Grüße

----------

## Josef.95

Auch ich kam mit der Umstellung eigentlich Problemlos zurecht, Ok für die Erstellung einer passenden hal Policy musste ich mich auch zunächst etwas im INet umschauen, ich benötigte zunächst aber "nur" eine Anpassung aufs Deutsche Tastaturlayout.

Die hal Policy fürs "de" Layout schaut hier zZt so aus 

```
$ cat /etc/hal/fdi/policy/10-x11-input.fdi
```

```
<?xml version="1.0" encoding="utf-8"?>

<deviceinfo version="0.2">

<match key="info.capabilities" contains="input.keys">

<merge key="input.x11_options.XkbRules" type="string">xorg</merge>

<merge key="input.x11_options.XkbModel" type="string">evdev</merge>

<merge key="input.x11_options.XkbLayout" type="string">de</merge>

<merge key="input.x11_options.XkbVariant" type="string">nodeadkeys</merge>

</match>

</deviceinfo>
```

Mein gutes altes Logitech diNovo Keyboard mit MX900 Maus funktionierte auf Anhieb, mitsamt all ihren ca. 24  Multimedia-Tasten, auch sämtliche Tasten der Maus (ca.9 Stück) waren sofort korrekt zugeordnet.

Eine Canon Ixus Kamera konnte dank udev-rule und hal-Policy, welche mit digikam installiert wurde sofort korrekt genutzt werden.

Ich denke hauptsächlich für Mobile PC,s wo man ja doch hin und wieder fremde Geräte ansteckt ist dies Hot-Plugging via hal eine gute Sache.

Prima auch das man weiterhin die Wahl hat (dank Use-Flag oder einem Eintrag in der xorg.conf), kann man ja auch weiterhin die Variante über Xorg nutzen.

Ok, von dem xml-Format der Policies bin ich auch nicht grad begeistert, eine einfache Textdatei wäre mir auch lieber gewesen.

Und ja, etwas mehr Dokumentation zu der ganzen Geschichte würde ich mir auch wünschen..

EDIT: Ergänzung / Korrektur

Die udev-rule und hal-Policy für die erwähnt Canon Kamera wurde nicht von digikam sondern von "media-libs/libgphoto2" installiert. (durch gesetzte "gphoto2" Use-Flag im Paket digikam)

MfGLast edited by Josef.95 on Wed Apr 22, 2009 1:29 pm; edited 1 time in total

----------

## musv

Wie Finswimmer hab ich hal ebenfalls runtergeschmissen.

Einziges Problem: 

Bei meinem Notebook funktioniert das Scrollen nicht mehr. Dazu hab ich aber im Moment keine Zeit. 

Ansonsten hab ich ehrlichgesagt noch keinen einzigen Grund gefunden, warum ich HAL benutzen sollte. Ist in meinen Augen nur 'ne unnötige Fehlerquelle mehr auf dem System.

----------

## misterjack

Ich finde es ziemlich witzig, wie sinnvolle Neuerungen als Schwachsinn deklariert werden. Dabei ist es für manuelle Konfigurierer es ganz leicht darauf zu verzichten:

```
man xorg.conf
```

```
Option "AutoAddDevices" "boolean"

              If this option is disabled, then no devices will be  added  from

              HAL events.  Enabled by default.
```

Dokumentationen zu lesen stellt anscheinend einige Kollegen hier vor schwerwiegenden Problemen.

Auf meinen Laptop brauch ich mir um Mausgeschichten keine Gedanken mehr zu machen, xorg.conf wird auch schlanker. Finde ich sehr praktisch.

Übrigens auch mit der Cymotion Master Linux unterwegs ohne Probleme.

----------

## avx

Na komm, "sinnvoll" ist ja mal rein subjektiv und wenn HAL so toll wäre, warum bastelt man an einem Ersatz? IMHO ist HAL unnötiger Bloat und nimmt mir persönlich keine Arbeit ab - ob ich jetzt eine xorg.conf oder zig .fdi-Files schreiben muss, nimmt sich nur in sofern was, dass die xorg.conf weniger Tipperei ist als das XML-Gedöns.

----------

## Josef.95

@ph030

Eine Menge fdi-Files muss man idR doch nicht schreiben, für viele Geräte werden die fdi-Files doch schon passend mitgeliefert,

zb aus dem Paket "hal-info" siehe zb unter  /usr/share/hal/fdi/*

Nur wenn ein fdi-File nicht 100%ig passt kann eine eigene angepasstes fdi-File unter /etc/hal/fdi/policy/ die "Standard" Werte überschreiben.

Und wie schon erwähnt, man muss hal ja nicht zwingend nutzen wenn man nicht mag..

MfG

----------

## avx

Nuja, allein für mein Notebook: 1x interne Tastatur, 1x externe Tastatur, 1x Touchpad, 1x externe Maus, 1x Wacom Intuos, 1x Wacom Bamboo - da kam schon einiges zusammen, denn die mitgelieferten .fdis erfüllen größtenteils nicht einmal annähernd meine Bedürfnisse. Natürlich, xorg.conf ist auch einiges an Aufwand gewesen, aber zumindest kein XML-Gedöns mit dauerndem <blub=""> - da bekommt man ja nen Krampf im Finger :p

Mich stört an HAL, dass es für mich keinerlei Vorteile bringt - jedenfalls ist mir noch nichts aufgefallen. Wieder ein Dienst mehr beim Booten, entsprechend längerer Startup, noch ein paar mehr Deps im System(xml-parser,...) - genauso wie HAL find ich übrigens auch udev ziemlich besch...eiden und hoffe, dass @mdeininger sein dev9 bald mal als usable announced.

Ich hab ja nichts gegen das Prinzip von HAL und denke, dass es für einige Leute ev. sinnvoll sein könnte, allein die Umsetzung ist es, was mich grausen lässt. Bin gespannt, ob das mit dem DeviceKit besser wird, kann's mir aber ehrlich gesagt nicht vorstellen. IMHO wird da Manpower an Sachen verschwendet, die man andernorts besser einsetzen könnte.

----------

## musv

 *ph030 wrote:*   

> IMHO wird da Manpower an Sachen verschwendet, die man andernorts besser einsetzen könnte.

 

Seh ich genauso. Wozu sollte HAL eine Unmenge an Devices verwalten, wenn gerademal die xorg.conf die Input-Devices davon ausliest. 

Bei udev kann man sich über den Sinn streiten. Klar ist es bequem, wenn ich einen eigenen Mountpunkt speziell für ein Device konfiguriert hab, und ich das Teil immer benutz. Wenn ich aber öfters mal externe Festplatten anderer Leute anstöpsel, wird das schon wieder etwas umständlicher (Mountpoints für jede Partition usw.) Nüchtern betrachtet ist das eigentlich zu umständlich. Den Umweg über die Desktopenvirenments und plugdev-Manager seh ich eher als Workaround aber icht als Lösung des Problems.

Die nächste Entwicklung, die ich bei Linux nicht mag, ist die besonders von Ubuntu vorangetriebene Soundlösung von alsa + pulseaudio.

----------

## ChrisJumper

Ok, hier kommt mein Senf Nr2:

Diese Art der Konfiguration zielt doch genau darauf ab:

"User schließt ein Gerät an und wenn es bekannt ist, schaue in der Datenbank nach. Wenn ja lade das FDI-File und alles Funktioniert einwandfrei ohne eine Konfiguration!".

Quasi sollte der Aufwand auf lange Sicht dies bezüglich vereinfacht und genauer angepasst werden. Und ich verstehe nicht was ihr gegen diese Entwicklung habt. Sicherlich ist es neu, noch etwas ungewohnt und es treten gerade einige Nebeneffekte auf. Aber generell ist das Prinzip doch toll. Es zielt darauf ab das man eben keine Konfiguration der xog.conf vornehmen muss. Sondern nur bei bedarf wenn es mal etwas besonderes ist.

Wenn jemand schon eine für dieses Gerät eine Konfiguration geschrieben hat, wird dies in (hoffentlich naher Zukunft) alles automatisch funktioniert.

Zum jetzigen Zeitpunkt, ist das allerdings recht unglücklich gelaufen. Eben was den Informationsfluss betrifft, bzw. kam ich noch nicht auf die Idee die Manpages zu lesen, dachte auf der Xorg-Homepage finde ich diese Informationen aber das war wohl falsch. Auch dachte ich die Manual-Pages sind diesbezüglich noch nicht Aktualisiert.

 *Josef.95 wrote:*   

> Eine Menge fdi-Files muss man idR doch nicht schreiben, für viele Geräte werden die fdi-Files doch schon passend mitgeliefert,
> 
> zb aus dem Paket "hal-info" siehe zb unter /usr/share/hal/fdi/* 

 

Super danke :)

----------

## misterjack

Man mag über Entwicklungen denken was man will. Aber man hat die Wahl bei Gentoo und an all die Nörgler: Warum installiert ihr euch Hal, wenn ihr es nicht wollt? Niemand zwingt euch die Nutzung auf. -hal und gut ist. Lasst doch den anderen den Fortschritt.

----------

