[ROM][5.1.1] CyanogenMod 12.1 Beta für das Gigaset QV1030

[Spartaner25]

Das ist unschön zu hören. Ich habe noch eine Vermutung, was eventuell den Fehler verursachen könnte,und zwar die power.macallan.so die, wie noch ein paar andere, aus der Jungsteinzeit stammt und wahrscheinlich mehr Probleme verursacht als löst. Mal schauen.
Aber, viel wichtiger:

I/AudioFlinger(  179): loadHwModule() Loaded primary audio interface from Nvidia Audio HW HAL (audio) handle 1
I/AudioFlinger(  179): Using module 1 has the primary audio interface

Wir haben Audio mit den neuen Blobs, soll heißen, weitere zwei Jahre alte Blobs die mit Kompatiblitätsoptionen noch am Leben gehalten wurden sind draußen .
Wenn ich jetzt noch die Kamera zum laufen überreden kann, steht einer neuen Version wohl nichts im Wege, es sei denn ihr hängt sehr an den Performanceprofiles? Die App stirbt bei mir auch in der aktuellen Version andauernd.

 

[freibooter]

Das klingt doch gut.

Solange du uns keine Performance klaust und das Ding runterdrosselst kann ich gut ohne Performanceprofile leben. CPU-Drosselung spart eh kaum Energie.

Selbst auf die Kamera kann ich zumindest auf's Erste gut verzichten. Fotografieren werden mit dem Ding eh die wenigsten. Skype und Hangouts mit Video wären aber schon ganz nett, Pflicht ist das für mich zumindest kurzfristig nicht.

Wenn ich die Wahl zwischen ständigen Abstürzen und Freezes oder einem stabileren ROM mit einigen Funktionseinschränkungen habe, dann fällt meine Wahl natürlich auf letzteres.

Besteht nicht die Möglichkeit einer Transplanation der power.macallan.so von einem anderen Tegra-Tablet mit besserem Softwaresupport?

Das Asus Transformer TF701 is doch sehr ähnlich ...

 

[Spartaner25]

Das habe ich mir auch gedacht und es wäre auch eine super Idee,aber es gibt da nur ein klitzekleines Problemchen, was nahezu unbedeutend ist: Der Systemserver schmiert ab und das Gerät bootet nicht mit einer anderen power.*.so. (Ich habe jetzt mal die vom Note 7 genommen), leider .
Eine Alternative wäre die Datei komplett weg zu lassen. Sagen wir mal so, es geht. Und in 1 von 10 Fällen funktioniert dann auch der Touchscreen und man kann das Gerät sogar entsperren! Aber das ist noch nicht alles: Habt ihr schon mal Windows auf einem ganz langsamen Rechner gesehen? Wenn sich jedes einzelne Element des Systems einzeln aufbaut und immer so ein paar Sekunden dafür braucht? Und dann auch noch die Farben falsch sind? Das ist auch noch dabei mit ohne power.*.so
Daher gibt es zwei Möglichkeiten: Entweder wir bleiben erstmal bei der alten power.macallan.so oder ich verschiebe das ganz bis ich mal richtig viel Zeit habe um die Datei zu dekompilieren und Nachzubauen (Was bei so Hardwarenahen Sachen eine gewisse Zeit dauern könnte) .

 

[tarjan]

Zum Thema Standby-Bug kann ich (leider) nix beitragen, da ich das Tablet meist immer komplett ausschalte. Wenn dann iss es nur mal kurzzeitig im Standby, aber da war bisher noch nie etwas passiert - zum Glück

 

[freibooter]

Vielleicht liegt der bug doch im GPS-Modul ... seitdem GPS gänzlich deaktiviert ist, gab es keinerlei Abstürze mehr. Mal sehen, ob das so bleibt.

 

[Michy]

Bei mir ist GPS immer aus und trotzdem habe ich diese Freezes. Ich hab das meistens im Zusammenhang mit Chrome aber auch sporadisch während der "normalen" Benutzung des Geräts.

 

[freibooter]

Jo, das ganze tritt so sporadisch auf, dass es extrem schwer festzunageln ist.

 

[freibooter]

Weiterhin Freezes, auch mit deaktiviertem GPS. Leider auch keine Lösung.

Bleibt nur zu hoffen, dass @Spartaner25 demnächst erfolgreich ist.

 

[Spartaner25]

Erfolgreich ist dehnbar, da ich immer noch nicht wirklich weiß, wo der Fehler liegt, ich kann nur mögliche Fehlerursachen eliminieren.
Die Sache mit der PowerHAL ist recht interessant. Wir haben im Moment das Problem, das die verwendete PowerHal nicht nur alt ist, sondern auch mit Parametern arbeiten will, die nicht existieren.
Da Nvidia teilweise ihren Sourcecode veröffentlichen (Was wirklich super ist ) kann man sich hier einen groben Überblick über die Struktur der PowerHAL verschaffen. Hilfreich ist es auch, kurz bei Google vorbei zu gucken, was im vanilla Android von der PowerHal verlangt wird.
Um mal kurz zu erklären worum es dabei geht:
In der init Methode sollen Standartwerte für die CPU Frequenz etc gesetzt werde (muss aber nicht).
Nvidia nutzt diese Methode um die Bootzeit zu verkürzen indem die Frequenz hochgesetzt wird und alle 4 Kerne aktivert werden:

    // Boost to max frequency on initialization to decrease boot time
    pInfo->mTimeoutPoker->requestPmQosTimed("/dev/cpu_freq_min",
                                     pInfo->available_frequencies[pInfo->num_available_frequencies - 1],
                                     s2ns(15));
    pInfo->mTimeoutPoker->requestPmQosTimed("dev/min_online_cpus",
                                     4,
                                     s2ns(15));

Die zweite interessante Methode ist setInteractive die aufgerufen wird, wenn das Gerät in einen aktiven Zustand übergeht (bspw. durhc das aufwecken mittles Powerknop),
Nvidia aktiviert hier einerseits die Eingabegeräte, wechselt den scaling_governor und setzt 2 Kerne aktiv.
Richtig lustig wird es erst mit der power_hint Methode. Hier übergibt das Androidsystem verschiedene "Hinweise" was gerade passiert oder passieren könnte. Das kann eine bevorstehende Interaktion sein, oder auch ein Niedrig Energie zustand. Nvidia hat sich hier richtig ausgetobt und noch ein paar mehr hinzugefügt, unter anderem den POWER_HINT_APP_PROFILE der von der NvCPLSvc.apk ausgeht, die wiederum von den performanceprofiles gesteuert wird und eben verschiedene Parameter ändert.
Der Kasus Knacktus bei uns ist aber, das Nvidia selbst diese erweiterten PowerHAL Funktionen nur dann verwendet, wenn NV_ANDROID_FRAMEWORK_ENHANCEMENTS verwendet wird, was(anscheinend/vermutlich?) nur passiert, wenn man die Android Quellen von Nvidia verwendet (Die dann z.B. auch die vergrösserte Palette an Power hints bieten). Wir verwenden aber eben CM bzw. AOSP und das kann, möglicherweise zu Problemen führen. Muss aber nicht.Was ich machen kann ist, eine wesentlich simplere Implementation der powerHAL verwenden (Selbstverständlich würde Quellcode auch auf Github landen) die nur das nötigste macht (Und dabei dann (hoffentlich) keine (weniger) Fehler macht).

Übrigens die häufiger geäußerte Kritik bzgl. des Kernel-Commits vom 23.August kann ich damit auch entkräften, da, wenn es ein Problem mit den Commits gab, das Problem wohl eher bei den Performaceprofiles zu suchen wäre, da diese eben auf verschiedene Sachen zurückgreifen, die unsere Rom entweder nicht hat oder korrekt unterstützt.

 

[bu22]

Welche Version ist denn die letzte, die nicht vom Standby Bug betroffen ist?

 

[JocklJockl]

Ich hab seit neuestem das Problem, dass jede Bluetooth Tastatur (bereits 4 verschiedene ausprobiert) nach Pairing nach ca. 10-15 Minuten einfach einfriert. Brauche unbedingt eine Tastatur für die Uni, aber es ist einfach super nervig, wenn die Tastatur ständig abbricht und neu verbunden werden muss.
Details siehe Bild.
vielen Dank im Voraus für die Hilfe.

PS: Habe keine Ahnung von irgendwelchen Flags oder Blobs, geschweige den wie man diese umprogrammiert.

 

[Helthehof]

Ich habe das exakt selbe Problem mit meiner BT-Tastatur wie JocklJockl. Wollte mich auch eben deswegen melden (ich weiß, es ist schon länger her, dass Spartaner gefragt hat wegen BT-Problemen... :-S). Bei mir bricht die Verbindung auch ab und lässt sich erst wieder herstellen, wenn ich sowohl einmal BT am Tablet deaktiviert und die Tastatur aus- und wieder eingeschaltet habe.
Ich habe mit Catlog ein logcat erstellt (vom Verbinden bis nach dem Abbruch) und angehängt - ist das in dieser Form wohl brauchbar?

Das Problem hat schon bei der Stockrom bestanden, aber evtl. lässt es sich ja mit nicht all zu großem Aufwand beheben? Das wäre voll genial!

Liebe Grüße und auch schon einmal vielen Dank!
Helthehof

 

[Spartaner25]

Ich traue es mich ja kaum zu sagen: Aber das Problem ist bekannt, und es gibt wohl keine Lösung.
Das Problem liegt in diesen Zeilen:

bt-btif ( 5224): dm_pm_timer expires
dm_pm_timer expires 0
proc dm_pm_timer expires

Und es kommt von hier.
Wenn ihr "dm_pm_timer expires" googlet findet ihr einiges dazu, aber keine endgültige Lösung.
Aber vielleicht eventuell möglicherweise könnt es sein (ihr merkt worauf ich hinaus will) dass sich das mit Android 6 sprich CN 13 ändert, da der Broadcomchip nicht mehr mit Bluedroid arbeitet, sondern mit android_system_bt arbeitet. Ich kann es euch aber nicht versichern.

Und für den Rest von euch hab ich auch was, und zwar eine neue Version!
Download wie immer auf der Githubseite.
Neben der Tatsache das das die erste mit dem "neuen" Kernel ist, sind ebenfalls fast alle Binaries auf dem Stand des Tegra Note 7. Leider musste ich die Performanceprofiles deaktivieren, da die zugehörige APK immer abstürzte (und möglicherweise eine Quelle für frühere Probleme darstellen könnte). Für einen genaueren "Changelog" dürft ihr gerne auf die Githubseite gehen .

 

[weltraumpapst86]

Erstmal Danke für die neue Version. Habe grade die neue Version geflasht. Ich wollte die Pixeldichte in den Einstellungen anpassen. Zuerst einmal geht es nur bis 200 dpi (und nicht bis 320 dpi) und was noch viel schwerer wiegt ist die Tatsache, das jetzt alles winzig klein ist, egal welche dpi-Zahl ich danach auswähle.

Chrome will auch nicht mehr so recht.

 

[freibooter]

Auch von mir ein dickes Dankeschön, aber weltraumpapst86 hat leider recht, irgendwas ist bei den dpi Einstellungen mächtig schief gelaufen. Im Google Launcher drängen sich die nun winzigen Icons in der Horizontalen dicht an dicht, dafür sind sie im App Drawer riesengroß.

Möglicherweise hast du hier etwas zu viel vom 7 Zoll Note übernommen?

Es dürfte jedoch hoffentlich ein leichter Fix sein. Sonst läuft alles auf den ersten Blick recht rund.

 

[Spartaner25]

Nö, das hat mit dem Note 7 nichts zu tun, sondern damit dass ich leider nicht immer intuitiv weiß, was in CM immer alles geändert wird und was ich dementsprechend ändern muss um "Schritt zu halten".
Ein "Quick Fix" wäre erstmal folgendes mittels ADB zu übergeben:

adb shell wm density 320

Die Default Density ist schon falsch, es müssten eigentlich 320 sein.
Damit das der Fall ist, muss ich das aber explizit angeben, was ich nicht wusste (Bis jetzt).
Ich schreibe es mir für die nächste Version auf, vll. kommen noch ein paar Bugs zusammen.

 

[freibooter]

Danke, Spartaner25.

Das allein ist allerdings nicht ausreichend, Grid und Icongröße des Google Now Launchers passen weiter partout nicht zu Seitenverhältnis und Auflösung. Mit 320 ist das Tablet zumindest wieder benutzbar, aber die Fehlerursache liegt tiefer.

 

[Spartaner25]

Meinst du das die Icons ein bisschen zu gross sind?
Das kann ich bestätigen, aber 320 dpi ist für das QV1030 eigentlich auch zu viel, es ist aber eben die nächst Standard dichte von 300 dpi aus gesehen.

 

[freibooter]

Nein, mit der DPI gab es in vorherigen builds überhaupt keine Probleme.

In dieser build wählt der Google Launcher ein völlig falsches Grid von 7x7 im Hoch- und Querformat statt vorher 6x5 im Quer und 5x6 im Hochformat, er scheint also weiterhin falsche DPI und Aspect Ratio Infos zu bekommen.

Als Resultat sind die Launcher-Icons total zusammengequetscht und die im App-Drawer absurd groß.

Vorher stimmte alles. Zur Demonstration:

 

[Spartaner25]

Ok, mit den Bilder verstehe ich was du meinst. Also beim Aspect Ratio dürfte kein Problem vorliegen. Die Frage ist eben jetzt, wo der "Sweetspot" bei den DPI liegt.
Also das 320 dpi etwas zu groß sind stimmt wohl, aber es liegt halt näher an den 297 dpi die das Tablet hat.