Refresh-Rate sehr niedrig

Hallo zusammen

Erstmal Entschuldigung für den blöden Thread-Titel. Ist eventuell etwas ungünstig formuliert, aber beinhaltet eigentlich auch meine Frage

Und zwar hab ich ein Alcatel OT997d. Das ist eigentlich ein gutes Smartphone für den Einsteigerbereich, 1 GHz Dual Core, 1Gb ram, 4,3" Screen mit 800x480. Zu dem Problem: Die Screen-Refresh Rate ist seeeehr niedrig, liegt bei 33,35Hz. Das sorgt für nettes Ruckeln bei....nun ja, eigentlich überall, und deshalb hier meine Frage:

Wie kann ich herausfinden, ob die Screen Refresh-Rate im Falle meines Alcatel von der Hardware vorgegeben wird (was ich weniger glaube) oder ob es eine Softwareseitige Limitierung ist(meine Vermutung deshalb, weil ich via FPS2D bei eingeschaltetem Bildschimr eine Durchschnitts-FPS von 32 bzw 33 erhalte, bei ausgeschaltetem (gelocktem) jedoch über 50 ).

Ich bin jetzt mitlerweile so weit, dass ich eigentlich herausfinden müsste, was für ein Fabrikat mein Screen ist, und da dann am besten die vom Screen mögliche Wiederholungsrate herausfinde.

Nur: Wie finde ich heraus, was für ein Screen verbaut ist ? Müsste ich da im Sourcecode nachschauen, bzw bei den Treibern ? (dann müsste ich mir erstmal ne Menge Wissen über Android aufladen ) oder gibt es da andere Möglichkeiten ?
Meine Vermutung liegt darauf, dass es (wie beim HTC Evo 4G) eine Kernelseitig vorgegeben Refresh-Rate gibt, denn leider ließ sich diese auch nicht durch das ausschalten von Vsync (durch die Build.prop Zeile "debug.gr.swapinterval=0") erhöhen, bzw soweit ich weiß ist die Zeile ab Android 4.0 sowiso nutzlos da es Vsync in der Form nicht mehr gibt wenn ich mich Recht entsinne.

Wäre nett wenn mir einer der Devs hier zumindest nen Tip geben könnte, wie ich herausfinden kann, welcher Screen verbaut ist. Alcatel anzurufen halte ich für eine ziemlich nutzlose Idee

Ach btw: Warum ich das nicht im Alcatel Forum schreibe ? Ich denke hier lesen mehr Leute mit Und es betrifft im Prinzip ja auch das Modden von Android

Ich lasse es mal hier

Du wirst leider da nicht viel dran ändern können. Ich durfte mich letztens mit einem Mediatek Gerät auseinandersetzen. Die Display Einstellungen, also Typ und FPS, werd vom u-boot Bootloader an den Kernel weitergegeben. Solange du nicht den Quellcode des Bootloaders hast, wirst du nichts machen können, da die Werte beim Bootvorgang vom Kernel eingelesen werden.
Welche Werte es genau bei deinem Gerät sind, müsstest du in der Datei /proc/cmdline finden. lcm ist der Display Type, dahinter kommt ne Zahl, die dann zur fps wohl umgerechnet wird.

Hallo Perpe

Danke für die schnelle Antwort

Ok, in cmdline steht bei fps : fps=3349, scheint also /10 geteilt zu werden, der screen ist scheinbar ein 1-hx8369_dsi_6577. Hm, Quellcode vom Bootloader, ich könnte nur mit dem Quellcode des ganzen Gerätes dienen: Klick Ist das der gemeinte Quellcode ? (sorry wegen der Frage, aber ich bin halt noch nicht sooo erfahren mit Android, versuche mich so langsam in die gesamte Materie einzuarbeiten , der Quellcode vom MTK6577 Chipsatz wurde bei git ja schon veröffentlicht, dürfte aber mit dem Sourcecode den du meinst wenig zu tun haben, oder ?)

D.h. aber wenn man den Quellcode des Bootloaders hat, könnte man die FPS-Rate "Nach Gusto" einstellen oder wie darf ich das verstehen ? Natürlich nicht höher als die maximale Bildrate des Bildschirms, das ist klar Aber ich gehe mal davon aus, dass es eigentlich keine Einschränkung durch Hardware gibt, ich denke 50hz gibt ja aktuell eigentlich jeder Screen raus, ausserdem erscheint mit 33,34Hz einfach zu ungerade um eine vom Screen gegebene Limitierung zu sein. 30hz ok, vielleicht, aber 33,34 hz ?

Denn es bringt nix einen Kernel zu kompilieren, der Übertaktungsmöglichkeiten und 15 verschiedene Governors bietet, wenn der Screen das Nadelöhr ist (auf Leistung bezogen )

Gruß
Thomas

Edit: Ok, es scheint sich um einen Himax HX8369-A Chip zu handeln um den es sich hier dreht. Leider hat das Datenblat 320 Seiten und ich hab absolut gar keinen Plan wo ich Suchen muss Mir ist schon klar dass der Chip den Bildschirm nur ansteuert, der Screen ist nochmal ne Nummer für sich, aber da die Ansteuerung ja vom Chip ausgeht, müsste man den ja dazu kriegen, mehr raus zugeben.

Jein.

Der Quellcode Pakete auf Sourceforge sind all samt unvollständig. Auf github gibt es mehrer Quellen, oft nur der Kernel. Bei den meisten Quellen lässt sich sogar der Kernel nicht kompilieren. Wirklich vollständig ist nur diese https://github.com/aquila-dev/mt6577_FULL_AOSP_SOURCE Repo und die darauf basierenden, bzw. die von denen es geforkt ist. Frag mich nicht, was zu erst da war. Aber auch die Repo ist nicht wirklich open, ist sehr sehr sehr viel Closed Source drin.
Diese Repo ist jedoch für ein bestimmtes Gerät. Von der Repo lässt sich auch u-boot kompilieren. Damit der Build Vorgang des Projekts sauber durchläuft, muss man jedoch erst einige Bugsfixen und die Codgen Prozedur entfernen. Inwiefer dieser Relevant für die Funktionsfähigkeit ist, weiß ich jedoch nicht. In der Theorie hat es den Anschein als sei es nur Optimierung ohne große Bedeutung, da ich nichts davon geflasht habe, kann ich jedoch nicht sagen, ob ohne auch alles funktioniert.

Wenn du es nun schaffst, Android und u-boot von der Quelle zu erstellen. Hast du erst mal nur den Grundstein, da das erstellte u-boot nicht für dein Gerät ist. Das u-boot ist auf den Kernel abgestimmt, einige Quellcode Dateien werden von Kernel und u-boot genutzt. Du musst dann also aus dem Sourceforge Paket für dein Gerät die relevanten Dateien raussuchen (unter anderem eben auch die für den Display, da kannst du auch den Wert ändern) und damit den Quellcode von u-boot aus dem Github patchen, um es für dein Gerät zu kompilieren.

Wenn du es soweit hast, kannst du es auf eigene Gefahr flashen.

"Nach Gusto" ändern würde ich nicht unbedingt sagen. Die Hersteller werden sich schon was bei dem Wert gedacht haben. Luft nach oben ist meistens, aber ein Schritt für Schritt ändern wäre ratsam und dabei nicht übertreiben.

Nochmals vielen Dank

Das mit dem "nach Gusto" war auch eher so gemeint, dass er dann änderbar wäre. Gut, da müsste ich mich mal einlesen
Zu dem Thema "da werden die sich schon was dabei gedacht haben", kann ich mitlerweile fast nicht mehr Glauben Was bei dem Smartphone alles an Bugs schon aufgetaucht ist/war (zbsp. wurde mal beim Kompass statt dem Magnetfeldsensor der Neigungssensor benutzt, sehr schlau , dazu gibts bei vielen noch Probleme mit der Pin-Abfrage, Leergesaugte Akkus innerhalb von 2 Stunden etc, aber das gehört nicht in den Thread)

Ich hätte eine "Vermutung", es gab ja schon einmal diesen Fall dass ein Smartphone auf 30Fps gecappt wurde, damals das HTC Evo 4G. Damals argumentierte der Hersteller, dass es deswegen sei, weil das Handy einen HDMI Ausgang besitze und viele Fernseher nur mit 30fps arbeiten würden (oder so etwas ähnliches ). Rate mal was das Alcatel auch besitzt Gut, vielleicht ist mein Gedankengang dazu auch viel zu Simpel und einfach, aber beim OT 995D gibt es diese Sperre auch, dort liess sie sich aber mit dem Build.prop Eintrag den ich oben genannt habe ausschalten. Naja, mal schauen, aber schonmal vielen vielen Dank, du hast mir schon sehr weitergeholfen

Gruß
Thomas

Wenn dem so ist, versuche mal was anderes.
Wenn Kernel debugging bei deinem Gerät aktiviert ist, dann schau mal ob /sys/kernel/debug vorhanden ist (bzw. wenn sie vorhanden ist, ist Kernel Debugging aktiviert), dort mal die Datei mtkfb suchen.
Wenn sie da ist kannst sie mal öffnen und den Inhalt lesen. Ich glaube, die fps konnte man darüber nicht ändern. Das Gerät, welches ich da hatte, hatte auch keine HDMI Funktion.
Über diese Datei kann man direkt Anweisung an den Kernel schicken, die dann auf Display/GPU angewendet werden.
Dazu einfach im Terminal mit root eingeben. Die Befehle stehen in der Datei, drin ist meist immer Befehl:Zustand. Kann man z.B. den Display an und aus schalten, auf Standbild schalten... da gab es auch einen Befehl um TV Modus an und auszuschalten. Vielleicht bringt es ja was, da mal bissl rumzuspielen. Ich glaube es zwar nicht, weil wie gesagt, es beim Boot festgelegt wird. Aber vielleicht ist mir ja was entgangen.

Es gibt den Ordner "debug", der ist aber laut meinem Dateimanager leer D.h. Kernel debugging ist wohl nicht wirklich aktiviert ....

Was hier stand war aber Falsch Fscaps hat wohl trotz dem "caps" im Namen nix mit ner Begrenzung der FPS zu tun

Gruß
Thomas

Nein, das hat damit nichts zu tun.

Ok, d.h. also um es zusammen zu fassen: Bootloader aus der Aosp github repo erstellen und den dann mit dem Sourcecode des Alcatel Patchen. Phuu, naja mal sehen. Ich werd mich mal einlesen...irgendwie hab ich nur das Gefühl desto mehr ich über Android lerne, desto komplizierter kommt es mir vor Trotzdem hab ich in der Letzten Woche wohl mehr gelernt als in meiner gesamten schulischen Laufbahn Vielen Dank für deine Tipps Perpe

Gruß
Thomas

Gesendet von meinem ALCATEL ONE TOUCH 997D mit der Android-Hilfe.de App

Na, kompliziert ist Android nicht. Wenn du aber meinst ins System eingreifen zu müssen, Teile neu kompilieren, dann schon. Ist aber nicht Androids Schuld, so ist nun mal programmieren.
Das dein Hersteller mit dem System Mist gebaut hat, kannst auch nicht Android in die Schuhe schieben.

Du kannst es mal mit init.d versuchen. Ich glaube zwar nicht, dass es was bringt, da zu späte ausgeführt, aber ich kann mich auch irren.
init.d sind Scripte, die beim Booten ausgeführt werden. Mit der App im Thread [MOD][APK+SCRIPT+ZIP] Enable Init.d for Any Phones w/o Need of Custom Kernels!!! - xda-developers kannst du deiner ROM init.d Support hinzufügen, falls es das nicht hat. Dann erstellst du einen Script im init.d Ordner, der die cmdline überschreibt, z.B. Dieser Script wird dann immer während dem Booten ausgeführt. Wie gesagt, ich glaube nicht das es was bringt, da zu spät ausgeführt. Wenn du es testen magst, nur zu.

Kam es wirklich so rüber dass ich Android die Schuld dafür gebe ? Falls ja, sorry, war nicht so gemeint, ich bin mir bewusst darüber dass alcatel da, nun ja, Mist gebaut hat. Mir ist auch klar dass ich vermutlich nicht dazu kommen werde, einen neuen Bootloader zu kompilieren, da mir einfach das Wissen dazu fehlt, und ich ja nicht nur für Android leben kann (Schule muss nebenbei ja auch noch erledigt werden ). Init.d werde ich mal ausführen, aber ich glaube auch nicht daran wenn du sagst dass alle Werte vom Bootloader eingelesen werden, die init.d scripte kommen dann ja erst beim booten. Naja, ausprobieren


Gruß
Thomas

Edit: Ok, Init.d support hab ich schon, da läuft bereits die Infinity Engine. So, mal die Cmdline erstellen
Sorry, noch ne Frage (noobfrage ) Ähm kann ich dein Script genauso übernehmen ? in "deine neue cmdline" würde ich dann einfach via Copy/paste die Alte einsetzen und fps dann auf meinetwegen 3400 setzen. Wäre das Richtig ?

Nein, kam nicht so rüber, muss man trotzdem sagen

Nein,, die cmdline wird nicht vom Bootloader eingelesen, sie wird vom Bootlloader an den Kernel übergeben und dieser verarbeitet es dann. Aber eben sehr früh beim Booten, init.d müsste danach ausgeführt werden.

Hm, wenn du das so sagst müsste mann doch (eigentlich) einfach die cmdline verändern oder darf man das nicht weil es sich dann mit anderen Files überschneidet ?

Gruß
Thomas

ja, die cmdline überschreiben. Nichts anderes macht das Script, das ich vorhin gepostet habe.
Das Problem ist, das die cmdline sehr früh beim booten eingelesen wird. Danach kannst du sie so oft überschreiben wie du willst und es würde nichts bringen, da schon verarbeitet.
Daher musst du wahrscheinlich den Bootloader ändern, da die cmdline dort hardcoded ist. Wenn du sie dort änderst, wird sie richtig an den Kernel übergeben und verarbeitet. Alles später, müsste zu spät sein, da der Kernel es schon abgearbeitet hat.

Ok, dein Script hat nichts gebracht. Gut dass die Erwartungen nicht zu Hoch waren Naja, ich schau mir mal den Bootloader an. Vielleicht finde ich ja was. Mal sehen. Vielen Dank für deine Mühen

Gruß
Thomas

Ich sehe gerade, ihr habt einen Custom Kernel samt Developer.

Es gibt noch einen anderen Weg
Statt den Wert aus der cmdline zu nehmen, könnte euer Developer einen Kernel erstellen, in dem der Wert festgelegt ist.
Dazu muss er in der Datei mediatek/source/kernel/drivers/video/mtkfb.c die Funktion mtkfb_probe suchen (bei mir Zeile 3030). Die Funktion ändert er dann so ab, das statt des fps Wertes aus der cmdline ein von ihm festgelegter benutzt wird.

Kannst ihn ja mal auf den Thread aufmerksam machen