[ROM] Comec's MediaPad Custom ROMs

  • 688 Antworten
  • Letztes Antwortdatum
Hi Comec,

ich habe gestern mal die Tweaks aus dem Init.d-Ordner entfernt. Nach dem Reboot scheint die Reaktionsgeschwindigkeit auf Wisch-Bewegungen deutlich schneller zu sein. Vorher gabs gern mal eine Gedenk-Viertel-Sekunde. Ich habe hier die CPU-Einstellungen in Verdacht.

Bin z.Z. selbst am ausprobieren der Tweaks und des CPU-Governors.

Gruß
W.
 
Coldbird schrieb:
Ja das Zittern nervt ein wenig. Aber ich habe mich inzwischen damit arrangiert.

Parkinson? Was für ein Zittern meint ihr?


Was die vorhandenen Tweaks (damit meine ich vor allem die Speichertweaks im zweiten Script, nicht die für den Governor und die "Platten") angeht: Da macht es nicht allzuviel Sinn, an einzelnen Punkten zu drehen. Die Tweaks müssen zueinander passen.
Wer selber mit den Möglichkeiten spielen möchte, sollte IMHO sein Speicher-Tweak-Set ganz frisch aufbauen. Nur eins: Schneller wirds dadurch nicht in Benchs (bei mir nicht, im Vergleich zu den Vorgaben - lahmer bekommt man das Benchergebnis aber immer ;) ) im Endergebnis - allerdings sieht man Unterschiede während des Benches (Quadrant), auch wenn sich das Ergebnis - also der Endwert - nicht vom ungetweakten System unterscheidet.

Tja, der Governor - auf jeden Fall werden einige Einstellungen nicht unterstützt, die sind auch nicht vorhanden. Man kann die Einträge zwar nachholen - aber die werden dann ignoriert (down_threshold z.B.).
io_is_busy (0 oder 1)ist noch ein interessanter Wert.

Ganz kurz noch was zur sampling_rate bei den Governor-Werten.
Noch mal kurz die Beschreibung:
h25p schrieb:
Sampling-Rate
Erklärung: Die Sampling-Rate gibt vor, alle wieviel Mikrosekunden der Governor die aktuelle Auslastung prüft, um die Geschwindigkeit anzupassen.

Vorteil: Eine Reduzierung der Sampling-Rate kann die gefühlten Mini-Lags reduzieren, verbraucht aber selber Rechenzeit.

Man erreicht eine Reduzierung der Überprüfung durch Erhöhung des Wertes - bedeutet das jetzt, dass der Standardwert von Huawei (25000) allgemein weniger zu Lags neigt als der Tweakwert von 15000?
Ist der Takt oben, geht er dadurch nicht so schnell wieder runter - ist er aber unten, geht er mit 15000 schneller wieder hoch als mit 25000.
Es ist also gar nicht mal so einfach. Alles eine Frage, des Betrachtungswinkels.
Werden die Wischer dadurch etwas flutschiger, wenn man die Tweaks löscht ? - obwohl ich keinen Unterschied merke.
Es ist sowieso zum Teil schwer bis unmöglich, etwas von den Änderungen zu merken bzw. zu fühlen. Irgendwann hört man schon die Flöhe husten - dann macht man lieber mal eine Pause von der Testerei. ;)
 
Zuletzt bearbeitet:
OctoCore schrieb:
Parkinson? Was für ein Zittern meint ihr? ...

Das Zittern der Symbole/des Bildschirms. Die Krankheit macht das ganze noch weniger einfach :-/
 
Wenn mal was zittert, dann erst, wenn ich den Homescreen oder ein Icon mit der Fingerspitze gepackt habe und im "Schwebezustand" halte, anstatt zu verschieben - durch die relativ hohe Auflösung werden schon kleine Änderungen beim Fingerabdruck bzw, der Berührungsfläche als Bewegung interpretiert.

Sonst steht eigentlich alles fest.
 
Ich weiß auch nicht, was es bei diesem ROM hier hinsichtlich des "Zitterns" auszusetzen gibt.
Offenbar kennen die Leutz des HC seinerzeit nicht oder das, was Huawei offiziell released hat...

Könnte -noch- besser sein, ist aber schon sehr, sehr gut!
(habe immer leichte Probleme, wenn ich während der Fahrt versuche, "Dinge" zu treffen :D)

Zu den Tweaks...

Habe mich anfangs auch damit auseinander gesetzt... es dann aber irgendwann aufgegeben.
Dazu gibt es genauso viele fürsprechende Meinungen, wie gegenläufige...
Und dann auch noch zu jedem einzelenen Segment oder noch schlimmer: Parameter - das XDA-Forum ist voll davon.

Ich finde es gut, dass sich Leute wie Comec hinsetzen, ausprobieren und Gesamtpakete schnüren.
Als Nutzer solcher Gesamtpakete entscheidet man dann: passt oder passt nicht.

Jetzt selber darauf los zu gehen und den Sinn oder Unsionn jedes einzelnen Parameters zu erforschen, ist nicht mein Ding.
Vielleicht fehlt mir auch einfach die Zeit dafür... und wohl auch das Hintergrundwissen.

Greets Gunnar

P.S.: was natürlich nicht heißt, dass ich für solche "Gesamtpakete" nicht empfänglich wäre :D
Hat da jemand eine vielversprechenden Kombo aus build.prop und Init.D-Scripts... immer her damit!
 
  • Danke
Reaktionen: Comec
Moin,
das ist der Grund warum ich die init.D Option so klasse finde! Eigentlich wollte ich ja von Anfang an keine Scripte ins ROM legen. Aber ist ja nicht so schlimm, denn man kann sie ja einfach löschen. Welche Scripte nun die Besten sind, kann ich nach vielem hin und her auch nicht wirklich feststellen. Ich habe sogar alle gelöscht und konnte nichts wirklich bemerken. Ich habe fast das Gefühl, dass diese ganze Tuning Sache mehr eine Farce ist! Es fühlen sich die Android User einfach besser damit... Aber hey, ICS ist keine Beta, ich denke die Android Entwickler wissen ganz genau was sie tun. Am System basteln kann auch vieles verschlimmbessern.

Also ich bin so weit: Finger wech und alles lassen. Gefühlt wird es eigentlich eh nicht besser, wenn gibt es 20 Punkte mehr bei Quadrant und wir freuen uns! BIS wir noch mal benchen und es sind 100 Punkte weniger! LoL! :D
 
  • Danke
Reaktionen: ducatisto und gunnarweibrink
Ja, genau so ist es. Ehrlich gesagt knobel ich einfach gern rum, aber die Scripte bringen eigentlich keinen spürbaren Mehrwert oder teilweise sogar das Gegenteil.
Ein Script, welches ich dennoch nutze ist mein "99automount", welches die Spiele- und Navi-Ordner, welche auf der externen SD liegen, in die interne mounted. Auf diese Weise habe ich beide Karten am Start und könnte das Pad auch ohne externe Karte betreiben.
 
Hat das einen besonderen Grund mit der "99" bei den Scripten?
Ich habe mir aus Gründen der Referenz einfach mal die deutsche 167B003 gezogen - die ist ja "nur" von Comec gerootet, mit QWERTZ-Belegung und init.d ausgestattet, wenn ich's noch richtig im Hinterkopf habe.
Ich konnte es aber nicht lassen und habe trotzdem ein kleines Skript geschrieben - wenn auch ohne 99. ;)

Ansonsten: Ja - die Original-Versionen sind schon gut ausgewogen, verbessern im eigentlichen Sinne kann man da nichts mehr - höchstens etwas die Tendenzen ändern: hin zu etwas höherer Dauerleistung (aber nichts an der Höchstleistung an sich), oder noch minimal sparsamer. Aber wirklich spüren tut man davon nichts - Ist eher psychologisch wirksam.
 
Die Ziffern sind praktischer Natur und entstammen eigentlich der Linux-Welt. Sie dienen dort der Festlegung der Reihenfolge, in welcher die Scripte abgearbeitet werden. Auf z.B. einem Ubuntu-System liegen dort für gewöhnlich bereits etliche Systemscripte, die mit 10, 20, 30, usw. beginnen. Damit die Tweaks als letztes ausgeführt werden, stellt man eine 99 voran.

Im Andoid hat die Zahl eigentlich die Bedeutung verloren.
 
  • Danke
Reaktionen: Comec und OctoCore
Hi OctoCore, meinst Du die 99 im Dateinamen?
Ich habe mal gelesen, dass man eine Zahl vergeben soll, sozusagen welches Script zuerst starten soll. Kann natürlich auch sein, dass es quark ist. Es gibt einfach zuviele Leute da draussen, wie sich angeblich damit auskennen... :)

Der ursprüngliche Beitrag von 09:50 Uhr wurde um 09:50 Uhr ergänzt:

Danke whoozy, da war jemand schneller! UUUUnd der kennt sich auch noch aus! :D
 
Ja klar... das macht Sinn, jetzt wo ich whoozys Antwort lese. Comec, du liegst aber auch nicht daneben. ;)
Mache ich im Prinzip auch noch - unter Windows, nur ohne Zahlen, mit alphabetisch angepassten Namen.
Hat sich eben heute dadurch erschwert, dass bei den Geschwindigkeiten die Scripte quasi gleichzeitig starten und/oder ein späteres Script ein früheres "überholen" kann.
Wenn Scripte aufeinander aufbauen sollen, kommt man ohne ein Steuer-Script nicht mehr, das für die richtige Reihenfolge sorgt. Mit den Zahlen für die Übersicht der Ausführungsreihenfolge oder auch für Schleifenkonstrukte, um innerhalb von Shellscripten andere Scripte über die Schleifenvariable anzusprechen. Was weiß ich...Entdecke die Möglichkeiten. ;)
Wie in der guten alten Zeit der Programmiersprachen mit Zeilennummern.
Zumindest stelle ich mir das jetzt so vor.
Aber weil alle mit 99 anfingen, bin ich wohl nicht drauf gekommen. Und wieder was Historisches gelernt. :D
 
Tja Leute, so wie es aussieht ist meine Information veraltet. Hab mir grad den Init.d-Ordner von Ubuntu 12.04 angeschaut ... und es sind keine Ziffern vorangestellt. Auf meiner Synology Diskstation, die auch auf einen Linux-Kernel aufsetzt ist es aber noch so.

Die Welt dreht sich halt auch weiter. Und wieder was gelernt.
 
Hehe... habe mich das auch schon gefragt, es dann aber doch gelassen, um mich nicht noch mehr als Linux-noob zu outen :D
Schon, dass es selbst Experten, wie Euch, nicht anders ergeht...
(und das ganz ohne Häme!)

Da das die einzigen Skripte waren, die in dem Init.D Ordner lagen, habe ich mir da auch keinen großen Kopf drum gemacht, um den Inhalt der beiden Skripte aber schon.

Habe diese jetzt mal dort entfernt und bin so nun schon seit ca. 2 Tagen damit unterwegs... und es hat sich tatsächlich nicht viel verändert. Mir kommt es so vor, als ob jetzt der Homescreen-Wechsel weniger "weich" vonstatten geht... ist vermutlich auch der Grund, warum Google bei JB vSync und TripleBuffer eingeführt hat. Aber der Wechsel ist schnell und ich habe das Gefühl, dass der Anwendungsstart (also die Reaktion auf das Tippen eines Symbols) "besser" funktioniert... schneller ist.

Ich vermute mal, dass es tatsächlich an der "sampling_rate" mit 15000 (99ctweaks) liegt und der "Rest" nur untergeordneten Einfluss hat (was natürlich die 99pmwsdcache mit einschließt).

Vielleicht werde ich genau das einmal ausprobieren... ein "sleep 30" davor und lediglich die sampling_rate.

Greets Gunnar

>> gesagt, getan :D
Auch das scheint überhaupt gar keinen Einfluß zu haben!
Werden wohl doch eher die Scrolling Tweaks in der build.prop sein...
(und wieder 'wech' damit)

>> öhm... noch was :unsure:
Diese "Dalvik" Tweaks scheinen mir recht interessant... beeinflussen sie doch offenbar die Art und Weise, wie bzw. in welcher Umgebung die Apps ausgeführt werden. Gibts dazu vielleicht vielleicht irgendwo genauere evtl. sogar konkrete Infos? Hmmm...

Nö, an der build.prop schraube ich nicht weiter... das überlasse ich dann doch lieber den Experten.
Aber die beiden Init.D Skripte bleiben vorerst draußen.

Einen habe ich nun doch noch:
Wie bekommt man diesen vollkommen "nervigen" Kamera-Klicken-Sound bei voller Lautstärke weg?
Mit dem Pad kann man 'eh kaum unbobachtet Bildchen von den süßen Nixen am Strand machen, gell? :D
Aber ernsthaft - das nervt echt.
 
Zuletzt bearbeitet:
Moin Gunnar,

sicher dass es besser wird, wenn Du die Scrollimg Tweaks rausnimmst? Also bei mir wurde es dadurch schon bissi besser!

Ich habe auch noch mal folgendes gemacht:

# Scrolling fix
persist.sys.scrollingcache=0
persist.sys.ui.hw=1
video.accelerate.hw=1
debug.performance.tuning=1
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000

Dadurch habe ich auch das Gefühl, dass es noch bissi besser ist. Leider habe ich das auch in den Weiten des Internets gefunden und weiss nicht genau was es macht! :(

Kamera klick Sound deaktivieren habe ich mal hier hin geschrieben:
https://www.android-hilfe.de/forum/...tricks-und-so.170735-page-3.html#post-3710722
 
Bei "video.accelerate.hw=1" steckt womöglich der Menüpunkt "Entwickleroptionen - GPU Rendering erzwingen" dahinter.
 
  • Danke
Reaktionen: Comec
Danke! Mir geht es primär um diesen hier:
persist.sys.scrollingcache=0
 
Für die die es im anderen Fred nicht mitgelesen haben:
der bescheidene Comec hat jetzt einen echten Spendebutton im Startpost.
 
  • Danke
Reaktionen: Comec
Jajaja... Ich wollte des eher heimlich machen! :)

Der ursprüngliche Beitrag von 12:14 Uhr wurde um 13:10 Uhr ergänzt:

mru1 schrieb:
Für die die es im anderen Fred nicht mitgelesen haben:
der bescheidene Comec hat jetzt einen echten Spendebutton im Startpost.

WHOW!:scared:

Vielen lieben Dank für die Spende! Das hätte ich jetzt wirklich nicht erwartet! Echt klasse! Tausend Dank!!! :thumbsup:
 
Hi,

mir ist aufgefallen, dass Suchergebnisse (z.B. in der Youtube App) dem amerikanischen Standort angepasst sind. Soll heißen, es werden nur englische Videos aufgelistet. Die Standort-Nutzung in den Eigenschaften ist angehakt.

Könnte es an der build.prop liegen?

ro.product.locale.language=en
ro.product.locale.region=US


Bin der "alten Comec-Version" waren die Suchergebnisse glaub ich auf DE spezialisiert.

Der ursprüngliche Beitrag von 21:57 Uhr wurde um 22:28 Uhr ergänzt:

Hmm, scheint eigentlich nur die Youtube App betroffen zu sein. Im Chrome passen die Suchergebnisse.
 
Hm, wie meinst Du das? Hast Du mal ein Beispiel nach was ich suchen kann?
 

Ähnliche Themen

M
  • mc_simon
Antworten
1
Aufrufe
1.791
Lomex68
L
L
Antworten
0
Aufrufe
1.440
LoOni3r
L
LordNikon
Antworten
13
Aufrufe
6.148
Tekkhenne
Tekkhenne
Zurück
Oben Unten