Seit heute gibt es den BeRoXM Player auch nun fürs Nokia N900 bzw. Maemo 5 im offziellen Maemo Extras-Devel Repository ( http://repository.maemo.org/ ) und in meinem eigenen Maemo 5 Repository, wo die Repository Daten wie gefolgt lauten:

Katalogname: BeRo

Internetadresse: http://vserver.rosseaux.net/repositories/maemo/

Verteilung: fremantle

Komponenten: main

Oder ihr ruft auf eurem N900 direkt die folgende Install-URL http://vserver.rosseaux.net/repositories/maemo/install/fremantle/main/beroxmplayer.install auf.

Zudem ist BeRoXM Player, zumindest meinem Kenntnisstand nach, auch die erste Multimediaapplikation für Maemo5 bzw. fürs Nokia N900, die in ObjectPascal implementiert ist und mit FreePascal übersetzt wurde, und das ganz ohne Hilfe des offziellen Maemo SDKs.

Viel Spass damit und zudem auch immer schön Bugs reporten bitte :)

Pro N900/Maemo:

• Maemo ist offener als Android hinsichtlich aufs root-Zugriffthema. Sprich rootsh (root lokal) und OpenSSH (root über SSH Verbindung) sind direkt über den Programmmananger installierbar, und schon hat man root-Zugriff, entweder lokal im X-Terminal und/oder über eine SSH Verbindung.
• Es gibt einen inoffziellen Android 2.0.1 Port fürs N900 (siehe maemo.org Forum). Aber das tut hier ja nichts zur Sache.
• Die Anwendungen auf Maemo laufen als native ARM Binaries. Dies bedeutet dass das N900 zumindest für mich optisch um einiges flüssiger erscheint als mein Motorola Milestone mit Dalvik-VM, welches genau die gleiche CPU mit gleichem Takt und gleiche Grafikeinheit wie das N900 hat. Sprich beide haben eine QMAP3430 SoC mit dem gleichen Takt und PowerVR SGX 530 als Grafikeinheit.
• 3D Anwendungen wie z.B. Spiele (OpenGL ES 2.0) laufen erstaunlich flüssiger als auf dem Milestone, obwohl beide die exakt gleiche Grafikeinheit haben. Dennoch könnte ich es noch nicht 1 zu 1 vergleichen. Denn dafür müsste ich erstmal einen identischen kleinen 3D Benchmark schreiben, der dann für beide Plattformen läuft (bei Android dann über JNI für den nativen Code).
• Das N900 hat TV-Out, der erstaunlich gut funktioniert.
• Das N900 hat einen FM-Transmitter.
• Das N900 hat funktioniertes Flash im Gecko-basierten Browser, was auch erstaunlich gut und "flüssig" funktioniert.
• Das Scrollen im Gecko-basierten Internetbrowser beim N900 ist um längen flüssiger als beim Android Webkit-basierten Browser auf dem G1 und Milestone.
• Der Internetbrowser des N900 schluckt auch Firefox Addons wie z.B. AdBlock Plus
• Unter Maemo läuft ein ganz normaler X Server. Sprich wenn es man will, kann man auch normale X Awendungen in einer Debian chroot Umgebung zum laufen bringen und das ohne VNC Forwardingkram (wie es mit dem Debianchrootkram beim G1 der Fall ist), sprich z.B. Gimp 2.0, Firefox, OpenOffice, Audacity, LXDE, Openbox, und und und.
• Maemo ist eine ganz normale Linuxdistribution mit einer völlig normalen Standard Linuxverzeichnisstruktur und ganz normalen Libraries (nur eben halt für ARM als CPU Target übersetzt), was für Entwickler sehr loblich ist, im Gegensatz zu Android mit BOINIC und so.
• Das N900 hat 32GB intern plus zusätzlichen microSD Slot.
• Die meisten Programme werden nach /opt (Symlink zu /home/opt auf einer 2GB NAND Partition unter /home) installiert, also Platz für viele Apps ist genug vorhanden.

Contra N900/Maemo:

• Android Market ist um längen besser gefüllt und bedienbar als der Ovi Store und mit Repositories (für apt-get auf der Konsole und im Maemo Programmmanager) sich herumschlagen möchte sicherlich auch kein 08/15 User.
• Touchscreenfähigkeit/Bedienbarkeit des N900 mit einem resistiven Touchscreen ist stark hinter den Androidgeräten mit kapazitiven Touchscreens. z.B. an vielen Stellen braucht man den Stylus um viele Stellen überhaupt exakt zu treffen.
• Die Maemosteuerung ist etwas an einigen Stellen unlogisch, z.B. wie man in die Programmliste kommt, oder wie man scrollt.
• Das N900 ist im Vergleich zu meinem T-Mobile G1 und Motorola Milestone deutlich um einiges dicker.
• Die Tastatur des N900 ist deutlich hinter der des T-Mobile G1s aber ungefähr auf dem gleichen Level von der des Motorola Milestones.
• Die Bildschirmuflösung des N900 mit 800x480 ist um paar Pixel breite geringer als beim Milestone mit 854x480, was jedoch nicht so besonders stark beim Vergleich ins Gewicht fällt. Und das G1 mit nur 320x480 hat hier eh das Nachsehen.
• Die maximale Lautstärke des internen Lautsprechers ist geringer als bei meinem Motorola Milestone.
• Nokia ist noch unschlüssig, was nun ihr Primär OS ist, ob Symbian oder Maemo. Sprich Maemo hat bislang noch eine ungewisse Marktzukunft für solche wie mich als App-Entwickler.
• Maemo ist derzeit fast ausschliesslich nur im Landscapemode verwendbar bis auf die Telefonanwendung im Portraitmode als Ausnahme.
• Das N900 besitzt keinen digitalen Kompass.

Fazit:

Maemo ist meiner Meinung nach noch stark hinter Android für den "Mainstream" User, und muss noch stark nachholen. Also Maemo ist eher mehr für Geeks und Android eher mehr für den Mainstreamuser. Unter dem Strich werde ich hauptsächlich weiterhin stärker für Android Programme entwickeln, und nur ab und zu mal was für Maemo entwickeln, bis Maemo sich richtig etabliert hat.

Fotos:

Nokia N900 vs. Motorola Milestone
Nokia N900 vs. T-Mobile G1/HTC Dream mit dem Standard Akku und Deckel (den starkeren dickeren 2600 mAh Akku hab ich vorher für die Fotos durch den Standardakku ausgetauscht und den dickeren Deckel durch den dünneren Standarddeckel ausgetauscht)

Speicherbelegung des N900:

Nokia-N900-51-1:~# df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                  227.9M    160.7M     63.0M  72% /
ubi0:rootfs             227.9M    160.7M     63.0M  72% /
tmpfs                     1.0M     64.0k    960.0k   6% /tmp
tmpfs                   256.0k     84.0k    172.0k  33% /var/run
none                     10.0M     80.0k      9.9M   1% /dev
tmpfs                    64.0M      4.0k     64.0M   0% /dev/shm
/dev/mmcblk0p2            2.0G    112.4M      1.8G   6% /home
/opt/pymaemo/usr/lib/python2.5
                          2.0G    112.4M      1.8G   6% /usr/lib/python2.5
/opt/pymaemo/usr/share/pyshared
                          2.0G    112.4M      1.8G   6% /usr/share/pyshared
/opt/pymaemo/usr/lib/pyshared
                          2.0G    112.4M      1.8G   6% /usr/lib/pyshared
/opt/pymaemo/usr/share/python-support
                          2.0G    112.4M      1.8G   6% /usr/share/python-support
/opt/pymaemo/usr/lib/python-support
                          2.0G    112.4M      1.8G   6% /usr/lib/python-support
/dev/mmcblk0p1           27.0G    227.6M     26.8G   1% /home/user/MyDocs
/dev/mmcblk1p1            7.4G      2.0G      5.4G  27% /media/mmc1

Vorher auf der 160 GB HD war es über einen entsprechenden boot.ini Eintrag auf der versteckten Dell Media Direct Windows XP Embedded Partition gelöst, der dann darauf hin den GRUB Bootsektor lud.

Aber nun hatte ich eine neue leere SSD mit nichts drauf. Ich partitionierte von daher aller erstmal die SSD mit der UBCD in 6 Partitionen. Und zwar so:

Dann installierte ich Ubuntu 9.10 und danach 64-bit Windows 7, und stellte mithilfe LiveCD den GRUB2 MBR wieder her.

Und dann machte ich schliesslich mich ans Werk. Ich lud mir die GRUB2 1.97 Beta 4 Sourcen samt Ubuntu 9.10 Patches herrunter und dann modifizierte ich die /boot/i386/pc/boot.S so, so dass wenn ich "nicht" die MediaDirect Taste zum einschalten drücke, dass dann der MBR den Bootsektor der ersten Partition (/dev/sda1) lädt und ausführt, und das bevor noch der restliche GRUB2 Kram vom MBR nachgeladen wird, sprich nämlich fast ganz am Anfang des MBR Codes. Undwenn ich jetzt die MediaDirect Taste zum einschalten bestätige, wird mein eingepatchter Code per einen Condition Jump übersprungen und der GRUB2 Maincode dann nachgeladen und ausführt. GRUB2 lädt entsprechend näturlich dann den Linux Kernel.

Die Abfrage, ob man die MediaDirect Taste bestätigt hat, ist recht simpel. Also je nachdem, wenn man die MediaDirect Taste bestätigt hat oder nicht, dann setzt das BIOS im CMOS an der Stelle 0x79 das Bit 3 (BItmaske 0x08) oder auch nicht. Das kann man im MBR dann zum Beispiel über folgendem Code recht leicht abfragen (Intel x86 16bit Realmode Syntax):

cli
mov al,0x79
out 0x70,al
nop
nop
nop
in al,0x71
sti
and al,0x08

jnz MediaDirectButtonPressed

   MediaDirectButtonNotPressed:

    .....
MediaDirectButtonPressed:

Und hier ist auch endlich nun der Link zum Patch: http://vserver.rosseaux.net/stuff/m1330boot.diff.txt

Viel Spass damit!

http://vserver.rosseaux.net/projects/brutsd/

BRUTSD sollte aber eigentlich auch für viele andere Touchscreencontroller und bei den vielen anderen Linux Distributionen funktionieren.

Ich hoffe ihr habt Spass damit

Und warum ich diesen Blogpost nun poste, hat auch einen einfachen Grund, welchen ihr hier nachlesen könnt.

#100 (voriger)

#102 (nächster)

BRSMSD enthält einen kompletten MIME Encoder/Decoder mit Support für alle möglichen Charsets inkl. UTF8 und einen HTML-to-TextPlain Konverter, der unter anderem auch Tabellen etc. korrekt zu einer ASCII Grafik konvertiert. Überlange SMS bzw. EMS werden näturlich auch komplett unterstützt.

Die POP3 und SMTP Kommunkation an sich ist in mehreren Threads ausgelagert, und unterstützt bei SMTP die HMAC-MD5 Authentikation und bei POP3 die APOP Authentikation. IMAP-Support war zwar mal geplant aber nach paar Überlegungen kam ich zu dem Entschluss, dass das hier für diesen Einsatz für SMS Mitteilungen doch etwas overkil wäre, zumindest im Verhältnis zum Implementation/Debugging Aufwand.

Zudem gibt es dann noch zwei Kammandozeilen Tools brsmsdread und brsmsdsend. Mit brsmsdread kann man auf einer Shell die Mitteilungen lesen und mit brsmsdsend entweder über die Shell oder als brsmsdsend Parameter z.B. in Bash Scripts auch Mitteilungen versenden.

Und BRSMSD läuft bei mir nicht nur auf dem Gigabyte M912M sondern auch auf  meinem Dell XPS M1330 Subnotebook mit einer Dell WWAN 5520 UMTS/HSDPA MiniPCI Express Card und auf meiner Linksys NSLU2 mit Debian Lenny auf einer 160 GB USB HDD und einem Huawei E172 USB UMTS Stick.

Der einzigste Nachteil, man muss BRSMSD solange beenden, wenn man eine GPRS/UMTS/HSDPA/HSUPA Datenverbindung aufrufen und benutzen will, und danach wieder starten. Ansonsten rennt es hier bisher einwandfrei.

Und hier noch ein kurzer Screenshot dazu:

Als neue WLAN MiniPCI Express Karte kommt die Intel WiFi Link 5100AGN zum Einsatz, die auch unter Linux bei mir direkt out-of-the-box funktioniert, und auch nur zwei statt für Draft-N eigentlich drei Antennen benötigt, so dass die perfekt die alte B/G only Atheros WLAN MiniPCI Express Karte ersetzen kann.

Als GSM/GPRS/EDGE/UMTS/7,2mbitHSDPA/GPS MiniPCI Express Karte kommt die Novatel EU850D zum Einsatz, wo ich vorher noch den PIN 20 Kontakt verkratzt und durchschnitten habe, so dass der PIN 20 keinen Kontakt mehr zur restlichen Elektronik auf der MiniPCI Express Karte hat, damit die EU850D  MiniPCI Express Karte überhaupt im M912M dank einem Hardware Lock funktionieren kann. Das Überkleben des PIN 20 mit einem Isolierband habe ich selbstverständlich vorher auch versucht. Allerdings verrutschte da das Isolierband immer beim Einstecken, so dass der PIN 20 dummerweise dann wieder Kontakt hatte. An der EU850D MiniPCI Express Karte hängen ansonsten zwei Antennen, eine aussen am  6 Zellen  7800 mAh Akku und eine innen direkt gegenüber der EU850D an der Gehäusedeckel Innenseite. Als Grundlage für die Prozedur diente diese Anleitung von jkkmobile

Als RAM kommt ein 2 GB RAM DDR2-667 Riegel von Kingson zum Einsatz.

Als SSD kommt die SuperTalent UltraDrive ME 128GB zum Einsatz, die wirklich richtig flott ist, sogar zum Teil schneller als die 7200rpm Festplatte in meinem Desktop, selbst bei Random Access Read sowie bei Write.

Bluetooth 2.1+EDR ist weiterhin vorhanden, und der ExpressCard34 Slot ist auch weiterhin frei.

Update: Ich habe in der Nacht vom 17. Mai 2008 auf den 18. Mai 2008 noch einige 3G UMTS/HSDPA Speedtest ausgeführt und hier als Screenshots hinzugefügt. Tagsüber bekam ich an dem Tag (17. Mai 2008) nur maximal 500 kbit/s  down und in der Nacht bekam ich aber dann locker bis zu ca. 3,2 mbit/s down.

Und hier die Fotos und Screenshots dazu: