Demo geht jetzt, aber bei python PyDPF.py kommt:
PyDPF.py: cannot connect to X server
das wird doch nicht wirklich nen x-server brauchen?
Demo geht jetzt, aber bei python PyDPF.py kommt:
PyDPF.py: cannot connect to X server
das wird doch nicht wirklich nen x-server brauchen?
Ups, sorry nicht gesehen... Vielen Dank!
Jetzt geht es!
Danke für die Hilfe!
An meiner Dockstar hängt ein Pearl LCD. LCD4linux wird beim booten mitgestartet, so dass CPU etc angezeigt wird.
Jetzt habe ich festgestellt, dass der LCD4linux-Prozess mindestens 12% CPU verbrät. Wenn ich zB ein File auf die dockstar kopiere, geht der Verbrauch sogar auf 30-40%% hoch (dann bleibt für smbd nur noch der Rest...)
wenn ich einmal killall lcd4linux sage und es neu starte mit /etc/init.d/lcd4linux start, ist alles wie gewohnt, unter 2 %.
Ich habe wheezy mit kernel 3.2.0-4 installiert.
Hat jemand eine Idee, woran das liegen könnte?
An meiner Dockstar hängt ein Pearl LCD. LCD4linux wird beim booten mitgestartet, so dass CPU etc angezeigt wird.
Jetzt habe ich festgestellt, dass der LCD4linux-Prozess mindestens 12% CPU verbrät. Wenn ich zB ein File auf die dockstar kopiere, geht der Verbrauch sogar auf 30-40%% hoch (dann bleibt für smbd nur noch der Rest...)
wenn ich einmal killall lcd4linux sage und es neu starte mit /etc/init.d/lcd4linux start, ist alles wie gewohnt, unter 2 %.
Ich habe wheezy mit kernel 3.2.0-4 installiert.
Hat jemand eine Idee, woran das liegen könnte?
Ich weiß nicht, ob es das gleiche Problem ist, aber bei mir hatte der Timercode von LCD4Linux ebenfalls Probleme.
Hintergrund bei mir, die Dockstar hat kein RTC. Damit startet die Uhr immer mit dem 1.1.1970 und wird erst Sekunden später
per NTP aktualisiert, wenn das Netzwerk online ist. Der Orignalkode von LCD4Linux kommt aber mit einem so langen Zeitsprung
nicht klar. Ich habe dies für mich, wie folgt behoben, den Patch aber nie Upstream für eine Review gesendet.