Wie kann ich einen Kernel für das Odys Loox bekommen?

  • 9 Antworten
  • Neuester Beitrag
Diskutiere Wie kann ich einen Kernel für das Odys Loox bekommen? im Root / Hacking / Modding für das Odys Loox im Bereich Odys Loox Forum.
microfink

microfink

Ambitioniertes Mitglied
Also Hintergrund ist folgender:

Ich verfolge schon seit längerem den Beitrag odys-loox-ice-cream-sandwich, weil ich solch ein Loox-Tablet besitze und ich wahnsinnig :)bored: im wahrsten Sinne des Wortes) gerne Android ICS auf dem Tablet hätte.

:unsure: Ich hoffe mit diesem Beitrag niemanden von den Entwicklern auf die Füße zu treten, denn was Ihr da leistet ist Enorm und ich kann nur meinen Hut vor Eurem KnowHow ziehen.

:crying: Leider funktioniert jedoch keiner der zum Download angebotenen Kernel-Images für mein Tablet befriedigend, weil die "Parameter" für die Display-Kalibrierung für mein Tablet nicht ganz passen.
Bei allen Kernel die ich ausprobiert habe - und das sind alle die ich hier finden konnte - habe ich am oberen und unteren Rand einen Versatz des Touch-Punktes um 5mm nach unten, bzw. nach oben (bei den aktuellen Kernel´n genau umgekehrt). Das macht es zum Beispiel unmöglich im Web-Browser vernünftig zu Navigieren.

:sad: Desweiteren kommt es immer wieder zu Fehleingaben. Das Display registriert einfach zu häufig Touches, wo gar keine sind.

:blink: Ich habe einen Kernel aus dem frühen Entwicklungsstadium des o.g. Beitrages ausprobiert, der noch am wenigsten Fehleingaben produziert.
<6>[ 2.358357] usbcore: registered new interface driver xpad
<4>[ 2.363771] lz300msf_init
<4>[ 2.366415] ---lz300msf start probe---
<6>[ 3.381265] input: lz300msf Touchscreen as /devices/virtual/input/input1
<4>[ 3.388407] threshold value0, 0)
<4>[ 3.394283] ( 50, 50) => ( 50, 51)
<4>[ 3.398245] ( 750, 50) => ( 750, 49)
<4>[ 3.402337] ( 50, 550) => ( 50, 549)
<4>[ 3.406292] ( 750, 550) => ( 750, 551)
<4>[ 3.410265] v_CalcParam.a1=24142
<4>[ 3.410283] v_CalcParam.b1=39
<4>[ 3.410299] v_CalcParam.c1= -2416677
<4>[ 3.410316] v_CalcParam.a2 = 31
<4>[ 3.410333] v_CalcParam.b2 = -17325
<4>[ 3.410351] v_CalcParam.c2 = 69376681
<4>[ 3.410368] v_CalcParam.delta = 115314
<4>[ 3.435330] tp_calib_iface_init---335,3661,3679,3683,341,349,3684,339,2183,
Dieser Kernel besitzt keine Multitouch Fähigkeiten, was mich nicht weiter stört. In diesem Kernel wird allerdings nur die Hälfte des vorhanden Arbeitsspeicher initialisiert, so dass das Loox im laufenden Betrieb nur 50 MB Ram frei hat. :angry: Einfach zu wenig.
<6>[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
<6>[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>[ 0.000000] Memory: 221MB = 221MB total
<5>[ 0.000000] Memory: 205180k/205180k available, 21124k reserved, 0K highmem
:blushing: Selbst wenn ich die Quellen für den Kernel hätte, würde mir das, so glaub ich, nichts nützen, da ich über nur über sehr beschränkte Linux (und Englisch) Kenntnisse verfüge. Ich komme halt aus der Microsoft-Ecke.

:wubwub: Also, wenn jemand Lust hat mit mir und Anderen an diesem Problem weiter zu Arbeiten, ist er hier sehr Willkommen.

Ich habe mal zwei Text-Dateien angehängt, welche die Kernel-Ausgaben beim Booten beinhalten. Dort ist gut ersichtlich, wie unterschiedlich der Arbeitsspeicher und das Display initialisiert werden.

Kernel1.txt ist der ältere OneTouch-Kernel mit halben Arbeitsspeicher, aber den wenigsten Fehleingaben (siehe weiter oben).

Kernel2.txt mit doppelt so viel Arbeitsspeicher, aber häufigen Fehleingaben.
<6>[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
<6>[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>[ 0.000000] Memory: 354MB = 354MB total
...
<4>[ 2.244618] ---lz300msf start probe---
<6>[ 3.261694] input: lz300msf Touchscreen as /devices/virtual/input/input1
<4>[ 3.510292] threshold value2843, 2413)
<4>[ 3.514558] ------------LZ300MSF INIT ok------------
<4>[ 3.519523] threshold value2843, 2413)
<4>[ 3.533739] ( 50, 50) => ( 50, 50)
<4>[ 3.537661] ( 750, 50) => ( 750, 50)
<4>[ 3.541601] ( 50, 550) => ( 50, 550)
<4>[ 3.545523] ( 750, 550) => ( 750, 550)
<4>[ 3.549446] v_CalcParam.a1=19313
<4>[ 3.549450] v_CalcParam.b1=0
<4>[ 3.549454] v_CalcParam.c1= -2680240
<4>[ 3.549457] v_CalcParam.a2 = 0
<4>[ 3.549461] v_CalcParam.b2 = -15305
<4>[ 3.549465] v_CalcParam.c2 = 57742970
<4>[ 3.549469] v_CalcParam.delta = 91491
<4>[ 3.573958] tp_calib_iface_init---378,3471,3694,3471,378,482,3694,482,2036,
Im Windows-Editor werden die Zeilen-Umbrüche nicht dargestellt, deswegen betrachte ich den Inhalt der Text-Dateien immer im Total-Commander mit F3.

Die Kalibrierung unter Android 2.3 erzeugt eine TouchCheck.xml-Datei, welche ich diesem Beitrag auch mal anhänge.

:confused2: Ich nehme an, dass eine nachträgliche Kalibrierung des Display aufgrund der "Hardkodierung" nicht erfolgreich sein kann und eine TSCalibrate.apk aus Android 2.3 nicht an der richtigen Stelle "dreht", bzw. garnicht läuft.

:unsure: Bitte verzeiht meine laienhaften Ausdrücke!

Die Informationen über die verbaute Hardware, findet Ihr hier.


:thumbsup: P.S. Die System-Images des o.g. Beitrag funktionieren - soweit ich getestet habe - alle wunderbar.
 

Anhänge

  • Kernel1.txt
    31,3 KB Aufrufe: 283
  • Kernel2.txt
    29,8 KB Aufrufe: 615
  • TouchCheck.xml.txt
    540 Bytes Aufrufe: 127
Oma7144

Oma7144

Lexikon
microfink schrieb:
Ich habe einen Kernel aus dem frühen Entwicklungsstadium des o.g. Beitrages ausprobiert, der noch am wenigsten Fehleingaben produziert.
Wenn es der für dich tut, dann ist doch prima. Referenzier den doch mal bitte. Die Freigabe des vRAM
(Loox hat ja kein HDMI) sollte kein Problem sein.


:thumbup:
 
microfink

microfink

Ambitioniertes Mitglied
Oma7144 schrieb:
Wenn es der für dich tut, dann ist doch prima. Referenzier den doch mal bitte. Die Freigabe des vRAM
(Loox hat ja kein HDMI) sollte kein Problem sein.


:thumbup:
Hallo Oma7144,

vielen Dank erstmal für Deine rasche Antwort. :thumbsup:

Ich muß gleich aus dem Haus, daher nur schnell geantwortet. Ich hoffe, dass sind die Informationen, die Du haben willst:

Als System habe ich die Version 1.2.5 von Euch/Dir drauf, weil die am schlankesten ist, mit Ausnahme der Kernel.img aus der Version Oma - Odys Loox ICS 4.0.4 v1.2 release.7z.001.

Müßte der Beitrag hier sein.

Wenn ich/Du das RAM vergrößern könnte/st, wäre das schon mal Super. :smile:
Würde mir auf jedenfall weiterhelfen! :drool:

Doch ohne aufdringlich erscheinen zu wollen :unsure:, "tuen" tut es der Kernel mit den Fehleingaben und den "verschobenen" Touchs nur bedingt.
Wie gesagt, von allen Kernel, die ich bekommen konnte, macht dieser (in Relation zu den Anderen betrachtet) die geringsten Probleme.

Habt Ihr in Euren Archiven vielleicht noch eine Kernel.img, welche zwar OneTouch ist, aber den vollen RAM (die zwei Speicherriegel :confused2: ) anspricht?

Danke nochmal, für Deine/Eure Aufmerksamkeit! :wubwub:
 

Anhänge

  • kernel.zip
    3,4 MB Aufrufe: 133
microfink

microfink

Ambitioniertes Mitglied
Oma7144 schrieb:
Schau mal, ob es der Approx Cheesecake Kernel für dich tut.
Leider nein. Was gut funktioniert ist, dass es kein Versatz mehr bei dem Berührungspunkt gibt. Doch leider produziert der Kernel jede Menge Fehleingaben. Wenn man zu leicht drückt, springt der Berührungspunkt wild hin und her. :mad2:
Irgendwie fehlen hier Toleranzwerte für den Berührungsdruck, welche bei dem Stock-Rom vorhanden sein müssen.
Die Kalibrierungswerte des Cheesecake-Kernel kommen zwar den Original-Loox-Werten näher als wie Eure, unterscheiden sich jedoch immer noch minimal.

Der freie Speicher von ca. 120 MB RAM unter JB (wenn man etwas bei den Apps aufräumt und den Heapsize reduziert) wäre erträglich. Wenn die Fehleingaben nicht wären, wärs perfekt. So muss ich jedoch weiterhin mit dem Modding von FluxFlux vorlieb nehmen, welches unschlagbar schnell läuft. :laugh:


Auf jedem Fall Danke für den Hinweis zum Cheesecake Kernel! :thumbsup:
Ich bleib dran. Vielleicht find ich ja noch heraus, wie man die Drucktoleranz nachrüsten kann.

P.S. Das Original ICS-Update für den Cheesecake APPTB701B von Approx läuft bei mir auch auf dem Loox. Mit den gleichen Fehleingaben. Nach meiner Meinung der gleiche Kernel.
Ich frag mich nur, wo die das ICS her haben. Ich fand nämlich eine Gebrauchsanleitung vom Odys Xpress im ROM von Approx. :lol:
 

Anhänge

  • Xpress_Manual_DE.pdf
    1.005,2 KB Aufrufe: 513
F

fluxflux

Stammgast
microfink schrieb:
So muss ich jedoch weiterhin mit dem Modding von FluxFlux vorlieb nehmen, welches unschlagbar schnell läuft. :laugh:
Wenn du dann noch den Hololauncher dazu nimmst, dann schaut es auch noch fast wie ICS oder JB aus ...

Thomas.
 
Zuletzt bearbeitet:
microfink

microfink

Ambitioniertes Mitglied
:wubwub: Hallo, jetzt fühl ich mich aber ernsthaft geehrt!
Der Schöpfer meines Android meldet sich persönlich zu Wort. ;-)

fluxflux schrieb:
Wenn du dann noch den Hololauncher dazu nimmst, dann schaut es auch noch fast wie ICS oder JB aus ...

Thomas.
:tongue: Jau, hab ich und dazu noch den Holo Locker.
Lange Zeit hatte ich den Go Launcher Ex als Favorit im Einsatz, bis ich den Holo Launcher endeckte.
Ich brauchte einen schnelleren Launcher für mein schwaches Jay-Book.

:crying: Ich hätte das ICS nur gerne auf meinem Loox gehabt, wegen den Optimierungen für Tablets und der Farbgebung (Eigentlich noch eher auf meinem Smartbook, weil ich das ausschließlich mit der Maus bediene).
So bedient sich das Loox mit GB eher wie ein Smartphone. Die Cyan-Farbgebung läßt sich geringfügig mit Ultimate Online Theme Kitchen anpassen.

:drool: Im Gegensatz zu ICS läuft Dein System-Ext3-Update flüssiger, bootet schneller und bietet im Schnitt 200 MB freien RAM.

:blushing: Ein wesentlicher Vorteil von OMA´s cRom wäre wohl das CWM und der neuere Browser.
Mit der CWM habe ich mich noch nicht beschäftigt und für den ICS-Browser benutze ich den Boat-Browser unter GB.
Opera wäre auch noch ne Alternative.

:rolleyes2: Ich hätte mal zwei Fragen zu ADB, welches ich unter Deinem System-Ext3-Update nicht zum laufen bekomme. Und zum Bearbeiten des Images unter Windows.
Ich denke aber, dazu schicke ich Dir mal ne PM, wenn ich rauskrieg, wie das geht. :unsure:

Gruß Marc
 
Zuletzt bearbeitet:
F

fluxflux

Stammgast
ADB läuft bei mir problemlos, allerdings nutze ich nur Linux. Und die Images kann man in Windows bearbeiten, das steht hier auch irgendwo im Forum ... ich bin leider kein Windows-Experte ...

Thomas.
 
Zuletzt bearbeitet:
microfink

microfink

Ambitioniertes Mitglied
Ah, OK.
Dann muss es doch irgendwie an meinem Windows liegen.
Wegen der Images werde ich dann mal nach "ext3 images mounten windows" suchen.
Danke für den Hinweis.

Marc

Gesendet von meinem Odys-Loox
 
microfink

microfink

Ambitioniertes Mitglied
fluxflux schrieb:
ADB läuft bei mir problemlos, allerdings nutze ich nur Linux. Und die Images kann man in Windows bearbeiten, das steht hier auch irgendwo im Forum ... ich bin leider kein Windows-Experte ...

Thomas.
Ich hab die boot.img ausgepackt.
Odys XPress: boot.img entpacken/packen

In der default.prop finde ich folgenden Eintrag:
persist.service.adb.enable=0

Und in init.rc folgender:
on property persist.service.adb.enable=0
stop adbd


Kann es sein, das ADB wegen diesen Einträgen nicht läuft?

Womit hast Du eigentlich die boot.img gepackt?
mit gzip konnte ich die img nicht auspacken!

Gruß Marc
 

Anhänge

  • default.prop.txt
    242 Bytes Aufrufe: 141