TFT flimmern

Ich besitze einen 19'' TFT-Monitor (BenQ T903), den ich mit VGA-Kabel am Ausgang meines s262 Notebooks hängen habe, um dieses auf Dualscreen zu betreiben. Hört sich prinzipiell nett an. Leider entschloss sich MSI, wie viele andere Hersteller, beim Netzteil des Notebooks zu sparen. Als Resultat sehe ich die 50Hz Netzfrequenz über meinen Monitor flimmern.  Anfangs störend, treibt es einen irgendwann in den Wahnsinn, vor allem mit dem Wissen, dass man das Flimmern mit einem kräftigen Schlag auf das Netzteil vorrübergehend verringern kann, wird man irgendwann vermutlich das Netzteil zertrümmern. 

Natürlich hört dann das Flimmern auch auf, wenngleich man nach Ablauf der Akkulaufzeit aber auch zwangsläufig für längere Zeit nicht mit dem Notebook arbeiten kann, ohne vorher ein neues Netzteil gekauft zu haben.

Technisch betrachtet dürfte es sich um eine Brummspannung handeln, die auftritt, wenn man eine Masseschleife bildet und sich in dieser bestenfalls auch noch ein Oszillator befindet. Die Masseschleife wird hierbei über den Schutzleiter des TFTs und Notebooks, sowie über das VGA-Kabel geschlossen.

Als Überprüfung, ob dem wirklich so ist, kann man den Schutzleiter am Stecker mit Tesafilm überkleben und dann feststellen, ob es noch flimmert.

Achtung! Auf keinen Fall dauerhaft den Schutzleiter abkleben! 

Dauerhafte Abhilfe schaffen könnte ein Ferritkern, das muss ich allerdings noch versuchen.
Bzw. wurde als Lösung auch angegeben, Monitor- und Notebooknetzteil an getrennte Phasen zu hängen (ist bei mir schlecht möglich).

Informationen dazu finden sich auch hier:
http://www.tecchannel.de/forum/peripherie/5884-tft-flimmert.html

LID-Close-Bug im HP 6720s

Die etwas unangenehme Eigenheit dieses Bugs besteht darin, dass das Notebook im geschlossenen Zustand nach unbestimmter Zeit in den Freeze-Zustand übergeht und völlig stehenbleibt, was beim Nutzer, angefangen beim primitiven Ärgern über Schreien bishin zu unkontrollierten Tobsuchtsanfällen, alle möglichen Zustände verursachen kann.

Glücklicherweise gibt es für diese unbeschreibliche Lästigkeit einen (zugegeben etwas uneleganten) Workaround:

Unter Ubuntu/Mint ist dieser Code in die /etc/rc.local einzufügen:

for DOS in /proc/acpi/video/*/DOS
do
echo 1 > ${DOS}
done

Er bewirkt nichts anderes, als ein Flag im Proc-Verzeichnis zu setzen, welches die Abstürze verhindert.

Quelle:

http://www.lundner.com/index.php?news_id=163

HP Compaq 6720s, der tragödie zweiter teil

das notebook ist aufgesetzt mit einem mint daryna 4.0.
die probleme, die es noch zu lösen galt:
die displaybeleuchtung schaltet sich beim schließen des notebookdeckels wieder ein, bei näherer beobachtung bemerkte ich, dass das genau dann passiert, wenn man die maus bewegt, wenn der deckel geschlossen ist.
auch gabs probleme mit der beleuchtung, wenn man das gerät vom stecker nahm. nach einer bestimmten zeit dreht sich die displaybeleuchtung immer wieder fast aufs minimum herunter, selbst wenn man sie manuell vorher hochgestellt hat.
zu ersterem:
nach ein paar versuchen mit dem acpid daemon wird ersichtlich, dass beim schließen des notebookdeckels mittels xset dpms force off die displaybeleuchtung abgeschalten wird.
führt man den befehl manuell aus, so schaltet sich die beleuchtung auch aus. zumindest bis man die maus bewegt. also suchte ich nach einer möglichkeit, die beleuchtung abzuschalten, ohne sie mit der maus zu reaktivieren. fündig wurde ich mit dem befehl vbetool dpms off
blieb nur noch, diesen ins acpi-script einzubauen.
vorweg möchte ich sagen, dass das, was ich gemacht habe, vermutlich nur ein dirty hack ist und es mit sicherheit elegantere möglichkeiten gibt, das zu erreichen.

zuerst betrachtet man /etc/acpi/lid.sh. diese wird ausgeführt, wenn man den deckel schließt (nachzusehen in /etc/acpi/event/lidbtn). von der lid.sh wird ein backup gemacht. anschließend wird die datei neu erstellt und mit folgendem gefüllt:

#!/bin/sh
export XAUTHORITY=`ls -1 /home/*/.Xauthority`
export DISPLAY=:0
grep -q closed /proc/acpi/button/lid/*/state

if [ $? = 0 ]
then
sudo vbetool dpms off
else
sudo vbetool dpms on
fi

die datei nun mit chmod 755 /etc/acpi/lid.sh ausführbar machen.
als nächstes steht man vor dem problem, dass vbetool nur als root ausgeführt werden kann. also muss man dem befehl sudo rechte ohne passwort geben. dies geschieht folgendermaßen: visudo als root ausführen und am ende der datei %users localhost = NOPASSWD: /usr/sbin/vbetool einfügen. (es sei angemerkt, dass das vermutlich etwas unelegant ist)
nun kann man als normaler benutzer sudo vbetool dpms off ausführen, ohne nach dem passwort gefragt zu werden.

als nächstes muss man den gnome-power-manager konfigurieren, denn der überlagert irgendwie acpid mit seinen eigenen befehlen. zum test kann man den gnome-power-manager beenden (killall gnome-power-manager) und dann dürfts schon funktionieren.

man öffnet als normaler benutzer(!!!) gconf-editor und unter apps->gnome-power-manager findet man die einstellungen für das vermaledeite ding. im unterpunkt buttons findet man die schlüssel lid_ac und lid_battery. sie müssten beide auf blank gestellt sein. das schreibt man nun in nothing um. im klartext heißt das, dass gnome-power-manager absolut gar nichts tut, wenn man den deckel schließt und dass soll ja auch so sein, immerhin wird das von acpid übernommen.
damit wäre das gelöst und spätestens bei einem neustart müsste die bildschirmbeleuchtung beim schließen der lid abschalten und auch so bleiben, bis man den deckel wieder hochklappt.

das nächste problem ist relativ einfach ebenfalls mit dem gconf-editor lösbar. im selben abschnitt wie vorher, nur im unterpunkt backlight. der schlüssel dazu heißt: idle_dim_battery. man stellt ihn einfach auf false und schon bleibt die displayhelligkeit erhalten, nachdem man den stecker gezogen hat. das wars auch schon wieder. für die erkenntnis dieser kurzen anleitung habe ich einen ganzen abend benötigt ;)

gehören abstürze zum "guten ton"?

ich muss einfach etwas jammern.
zur zeit regt mich das echt auf!
mein arch-linux auf dem msi-s262 kam vor gut 2 monaten auf die idee, einfach nach unbestimmter zeit den x-server inklusive display abzuschießen. den rechner kann man mit strg-alt-f1 + strg-alt-entf zwar neu starten, aber sehen tut man halt nichts mehr.
das phänomen stieg stetig an und zum schluss verabschiedete sich der xserver schon 3-4s nach dem anmelden. nicht immer, nur manchmal, versteht sich.
nachdem ich im netz noch einen thread gefunden habe, wie gut ubuntu/mint nicht auf dem msi-262 laufen solle, probierte ich es noch einmal. es läuft.
mal freezt es, mal schwarzer schirm, mal x-server weg, worauf er eben momentan lust hat.
das bereits einmal erwähnte hp-compaq 6720s meiner freundin fängt auch seit neuesten zu freezen an, wenn man den deckel schließt. völlig ohne vorher updates getätigt zu haben.
der rechner zu hause fror mit suse andauernd ein, bis ich ihm ubuntu installiert habe. seitdem freezt er unter ubuntu fröhlich weiter.

und irgendwo zwischen black-screen und bildschirmfoto stellt sich mir die frage: gehört das mittlerweile unter linux zum guten ton? wir haben drehende durchsichtige kuben mit allerlei schatteneffekten, passabler ram-, und grafikkartenauslastung, bringen es aber nicht fertig, dass ein rechner funktioniert.
was ist aus dem "stabilen" linux geworden?
streng genommen ist linux ja nur der kernel, streng genommen ist der vielleicht auch stabil.
nur ist das, als hätt ich ein auto, dessen reifen zwar rund sind, aber sich nur teilweise drehen.