Kernel-Werkstatt / ICS Kernel-Diskussion

Da ist es wieder unser magisches Hannsi.
 
Ich frag einfach mal ganz dumm nach:
Kann man im Kernel die PowerButton Routine nicht irgendwie mit einer Schleife umbauen?
In etwa so:
If screen off, schleife enabled.
while screen off, powerbutton pressed by user.
wakeup routine ausführen
wait 3 secs.
screen on? yes -> schleife beenden.
screen off? wakeup routine erneut ausführen.

Wenn der Screen nach einem Schleifen-durchlauf nicht an ist müsste man die schleife beenden und mind. 5 sekunden warten bevor sie erneut ausgeführt wird.

Ist zwar nur eine billige bastellösung, aber der deepsleep funktioniert ja, also warum nicht den eifachen weg gehen?
 
weil Ostern vorbei ist ;)
 
Irgendetwas scheint während des Aufwachens zu lange zu blockieren, so dass das
Pad wegen Inaktivität wieder schlafen geht.
Man könnte ein Wakelock mit Timeout versuchen. Das würde die CPU daran hindern
wieder zurück in den Deep Sleep zu fallen.
Ob das Tablet dann danach aufwacht ist aber fraglich.
Besser wäre es den wirklichen Verursacher zu finden.
 
4dro1d schrieb:
Das Problem mit dem mehrfachen Anschalten nach dem Standby hatte ich bei v12 auch.
Jetzt hatte ich das Pad ca. 45 Mins im Standby gelassen und es wacht beim ersten Drücken auf den PowerButton direkt auf - Touch funktioniert auch sofort.

red-orb schrieb:
Ich konnte jetzt auch mit einmal drücken wecken

gesendet vom Hanns

scheint doch weg zu sein oder?
 
na sag ich doch!!!
 
antibyte schrieb:
Irgendetwas scheint während des Aufwachens zu lange zu blockieren, so dass das
Pad wegen Inaktivität wieder schlafen geht.
Man könnte ein Wakelock mit Timeout versuchen. Das würde die CPU daran hindern
wieder zurück in den Deep Sleep zu fallen.
Ob das Tablet dann danach aufwacht ist aber fraglich.
Besser wäre es den wirklichen Verursacher zu finden.

Wenn ich das richtig verstehe gehst du also davon aus, dass der Kernel sich "richtig" verhält. Irgendein Event veranlasst ihn wieder in den Deep Sleep zu gehen. Ein "Stock-Kernel" würde sich also genauso verhalten.
Genau das kann ich nicht nachvollziehen. Wieso sollten die Entwickler das so gestalten?
Bleiben 3 Möglichkeiten:
1. Der Kernel reagiert auf einen Fehler in einem anderen Bereich richtig.
2. Der Kernel hält etwas fälschlicherweise für einen Fehler und reagiert richtig.
3. Der Kernel reagiert falsch auf irgendein Event (Problemquelle in der wakeup routine).

Ich flashe mir jetzt mal den 12.1, mal sehen ob es einen Unterschied zu 12 macht.

Edit: Wie ist das nochmal mit der LED? Hab sie beim Kernel flashen auf WLAN Status gestellt. Beim booten zeigt sie aber keine FlashDisc Aktivität. Bin bisher davon ausgegangen, dass es ein Problem gab beim Update des Kernels. Hatte auch mal fards drauf.
 
Zuletzt bearbeitet:
nach stundenlangem (lehrreichen) wipen formatieren und restoren funktionieren jetzt die iptables wieder, auch mit DRH Beta1.2 ! :)
Die Lösung lag näher als vermutet, mit fards kernel (aus antibytes v12.x installer) kommt beim aktivieren von Droidwall nicht mehr die Fehlermeldung.
Sehe grad bei slatedroid gab es auch 2 posts dieses Problem betreffend, weiss auch nicht, ob es alle mit v12(und v12.1) betrifft :confused:

Immerhin, so gehts :biggrin:
 
  • Danke
Reaktionen: Zebra1902
Mit v12 hängt sich das Pad manchmal bei eingeschaltetem Bildschirm auf. Problem mit 333MHz? 12.1 nicht getestet.
 
Meine wissensbefreite Theorie zum 'schweren' Aufwecken wäre, das der Governor zu spät wärend der Aufwach-Prozedur umgeschaltet wird. So läuft das Aufwachen praktisch noch im Schlaf ab.
@antibyte: kannst du uns Nichteingeweiten mal erklären. wie das mit dem sleep vs. deepsleep funktioniert? Ich denke das das Pad manchmal deshalb gleich aufwacht, weil es gerade irgendeine Aktivität abgearbeitet hat und noch nicht in den Tiefschlaf zurückgefallen ist. Ich meine wie lange wartet z.B. 'interactive' bevor es in den Tiefschlaf fällt?

Leider habe ich aber (wie ich nicht müde werde zu bestätigen) echt - keine - Ahnung
 
marc---O schrieb:
nach stundenlangem (lehrreichen) wipen formatieren und restoren funktionieren jetzt die iptables wieder, auch mit DRH Beta1.2 ! :)
Die Lösung lag näher als vermutet, mit fards kernel (aus antibytes v12.x installer) kommt beim aktivieren von Droidwall nicht mehr die Fehlermeldung.
Sehe grad bei slatedroid gab es auch 2 posts dieses Problem betreffend, weiss auch nicht, ob es alle mit v12(und v12.1) betrifft :confused:

Immerhin, so gehts :biggrin:

Hallo Marc---O

Das Problem ist nicht nur bei Droidwall zu finden. Andere Security-Apps haben auch Probleme mit den IP Tables. Heißt das, Du nutzt FARDS Kernel und es funktioniert oder bist Du anschließend wieder auf Antibytes Kernel zurück ?
Also wie geht´s genau ? Vielen Dank !
Gruß
Zebra
 
so sollte die Konfiguration des Netfilters aussehen
Code:
CONFIG_NETFILTER=y 
 CONFIG_NETFILTER_ADVANCED=y 
 
# 
 # Core Netfilter Configuration 
 # 
 CONFIG_NF_CONNTRACK=y 
 CONFIG_NF_CONNTRACK_MARK=y 
 CONFIG_NETFILTER_XTABLES=y 
 CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y 
 CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y 
 CONFIG_NETFILTER_XT_MATCH_STATE=y 
 
# 
 # IP: Netfilter Configuration 
 # 
 CONFIG_NF_CONNTRACK_IPV4=y 
 CONFIG_NF_CONNTRACK_PROC_COMPAT=y 
 CONFIG_IP_NF_IPTABLES=y 
 CONFIG_IP_NF_FILTER=y 
 CONFIG_NF_NAT=y

vielleicht kann antibyte sie ja im Kernel aktivieren
Da meine Kernel irgendwie nicht booten wollen
 
  • Danke
Reaktionen: marc---O und Zebra1902
Touchscreen Controler Sleep?

Mir ist aufgefallen das der Touch-Screen sehr gut reagiert solange der Zeitraum zwischen 2 Berührungen unter einer Sekunde bleibt. Sobald die Pause länger ist werden kurze Berührungen nicht mehr erkannt. Wenn die Berührung länger dauert reagiert das System, aber mit einer spürbaren Verzögerung.

Frage: Kann man diesen Zeitraum verlängern?
 
Mir ist gestern aufgefallen, dass ich keine AVIs mehr mit HW schauen kann.
Ich habe gestern ein paar AVIs für die Kids auf dem Hannsi abgespielt allerdings meldet der MX-Video-Player, dass HW nicht unterstützt wird.
Die gleichen Filme habe ich unter Hannstitan schon laufen gehabt und da ging HW.
Die Videos sind mit Xvid codiert
 
Kann ich bestätigen. Hat funktioniert. Geht jetzt nicht mehr. H/W sollte kompatibel sein. Wahrscheinlich doch noch ein PIN verbogen....
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: red-orb
Zebra1902 schrieb:
Heißt das, Du nutzt FARDS Kernel und es funktioniert oder bist Du anschließend wieder auf Antibytes Kernel zurück ?
Also wie geht´s genau ? Vielen Dank !
Gruß
Zebra

Ja, einfach antibytes letzten kernel flashen (d.h. Den Aroma Installer starten) und bei der Auswahl fards Kernel auswählen, dann ein reboot und alle iptable abhängigen Apps laufen wie sie sollen..

Also auch Adaware oder andere Firewalls. :)

edit: dank antibytes Installer behält man dabei die funktionierenden HW Tasten :D
edit 2: Wlan/Notification LED geht unter fards natürlich nicht, aber dafür das sofortige Anschalten (auf kosten des deep sleep).
Werd erstmal dabei bleiben..
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: Zebra1902
Ah xD Wird zeit mal die 1.2 und den 10.2er Kernel zu Flashen um zu sehen ob der GFX Bug noch besteht. Rückmeldung folgt ;)


Mara
 
wir sind aber schon beim V12.1
 

Ähnliche Themen

L
Antworten
1
Aufrufe
1.214
slickor
slickor
4dro1d
  • Angepinnt
  • 4dro1d
Antworten
15
Aufrufe
25.866
pepadk
P
Lecter
Antworten
102
Aufrufe
23.316
red-orb
red-orb
Zurück
Oben Unten