Reprise du message précédent :

 
 
Euh vous avez peur de quoi ?
Qu'on vous vole vos livres dans le métro ??
 
C'est pas un iPhone avec des données précieuses ....
 
Pis bon, les livres restent a la maison...
   

ah ah non, mais bon des types qui s'amusent sans qu'on le veuille dessus j'y tiens pas non plus
et puis on peut faire quelque chose de plus sécure TRES facilement(bon ça reste du telnet...) donc pourquoi s'en priver

C'est certainement très faisable, mais dans un premier temps pilotable en telnet seulement

Quelqu'un a tenté un "lspci" / "lsusb" / "lsscsi" / "cat /proc/cpu" avec les scripts "custom"?

Si tu ne t'en sers pas, je veux bien t'en débarasser  

la vache, 1 pages depuis hier soir
bon si j'ai bien compris, il y a un firmware ici : http://code.google.com/p/e60-open/ [...] isponibles
qui permet d'aller sur le net
ça marche bien? on peut aller lire ses mails par exemple?
 
et cette histoire de webradio ça donne quoi?

Pareil j'avais pris deux dockstars mais j'en ai revendu un, donc je me dis qu'au pire là je ferais pareil. Y'aura toujours qqun d'intéressé je pense.

Oui, mais non   je me dis que je finirais par m'en servir, à la base c'était pour en faire un NAS, mais j'ai acheté un ReadyNas rapidement (pareil là aussi de quoi faire...). Faut que je me re tiennes au courant sur les évolutions qu'il y a eu.

Ah ah, bah je me sens moins seul du coup   mais n'empêche que je me tâte pour un deuxième E60(c'est bon pour l'ODR pour moi)
ce qui me retient : l'écran tactile, ça serait énorme d'en fixer un au mur façon écran domotique/information, mais l'usage au stylet...

cette étape est faite qu'il y ait eu une mise à jour de faite ou non ?

car si fait dans tous les cas : on l'a notre système de commandes exécutées à la demande (juste pour faire une action ponctuelle donc)

J'ai trouvé une solution (certes imparfaite, mais) tout à fait satisfaisante pour mes besoins perso pour lire une bande dessinée.
J'ai récupéré les planches en JPG. Je les ai converties en niveau de gris avec :

Puis, je les ai converties en PDF avec :

J'ai assemblé le tout avec :

Et niveau taille je n'ai pris que 10% par rapport aux JPG originaux...
 
Ensuite, je transfère sur l'e-book par USB dans le dossier Books, et après synchronisation, je peux lire ma BD. Sauf que là, c'est trop petit pour lire confortablement. L'astuce consiste alors à passer en mode rotation 90°. Du coup, on a zéro marge (comme en mode image), la BD prend toute la largeur disponible, et on passe du haut de la page au bas de la page avec les boutons Prev et Next, comme pour tourner une page.
 
Ce n'est pas la solution ultime, car en fonction de la taille des vignettes, on peut se retrouver avec des cases qui n'apparaissent pas en entier ni sur la première ni sur la seconde partie de la page (il y a un recouvrement généralement). Mais, pour la BD avec laquelle j'ai fait mes essais, ça ne gène la lecture que dans un nombre très restreint de cas.
 
A essayer...
 
On perd cependant l'avantage du tri par dossier dont bénéficient les images et la possibilité d'avoir deux "livres" ouverts en parallèle. Cela dit, pour le premier point, la gestion de la bibliothèque par SQLite devrait bientôt changer un peu la donne...

Peux-tu donner un peu plus de détail sur la ligne de commande utilisée pour lancer la compilation ?

Tu te retrouve donc avec un binaire qui s'appelle test
EDIT: wiki mis à jour

 
Ca doit être des algos de wearleveling pour la programmation de la flash.
 
Si c'est bien ça, surtout ne pas toucher !

Si comme moi vous trouvez que lors de la lecture des ebooks la Taille de charactère 1 est vraiment trop petite et que la taille 2 est déjà trop grosse (Mais qui se sert de la taille 5 ?) ; Je pense qu'on va pouvoir ajuster çà là dedans:
 
\usr\local\Trolltech\QtEmbedded-4.5.1-arm\Images\RUIResource
 
Edit: J'ai dit une connerie, mais en faitg RUI , ca pourrait etre "Remote UI" une interface accessible par web sur le bidule. Bon, ca a pas l'air activé évidemment.

L'idéal serait que l'appli récupère la base de données de Calibre (qui est elle aussi en SQLite je crois), et qu'au choix ça créé des "bibliothèques" par auteur/collection ou étiquette.
Parce que s'il faut toujours les gérer "à la main" (même si c'est simplifié par rapport à la méthode actuelle) ça va rester super lourd

 
J'avais vu passer un répertoire "fonts" aussi. (je suis au boulot, je sais plus où il est, exactement )
 
Donc devrait y avoir moyen de changer aussi la police

ça se serait bien, une taille 1.5 par exemple, et virer la taille 5, voir la 4 également.

 
La taille 5 doit être sympa pour apprendre à lire à son gosse "çà c'est le E"...

Suggestion pour un futur firmware orienté "devellopement":
2 types de scripts au boot:
 
1) Execution systématique d'un script "runscript.sh" ,dans lequel on pourra mettre par exemple le serveur telnet.
 
2) Customrun:
- Si custom_run est présent :Renommage puis execution du script et on ne démarre pas MainApp.  
- Si custom_run est pas présent, on démmare MainApp normalement.
 
Ca permettrait de develloper un script et/ou une app qui se lancerai à la place de MainApp . On pourrait ainsi commencer à taper dans le framebuffer, lire les pressions de touche, etc...

 
Moi je suis entre la 2 et la 3. Mais c'est un livre converti avec calibre à l'arrache, la 2 sur les livres fournis est déjà mieux. Faudrait que je me penche sur la conversion calibre car là c'est un peu n'importe quoi, genre la numérotation des pages a été prise comme titre de chapitre, du coup je lis tranquille et d'un coup en plein milieu du texte il y a un gros et gras Page 27    
 
Sinon question con mais l'écran est-il réellement 800*600 d'après le système ? Car de ce que j'ai lu sur l'e-ink, c'est très particulier et je me demande si les résolutions "standard" s'y appliquent vraiment. Il est aussi possible que l'écran dise au système qu'il est en SVGA puis interpole l'image à sa propre sauce.

Et les marges, il y a un moyen de les virer ?
Parce que la partie lisible fait juste la taille d'un écran 5"...

moins de truc à lire par page = plus de pages à tourner = plus de consommation sur la batterie...

J'approuve complétement

 
La question qui va vite se poser, C'est la manière d'avancer maintenant qu'on sait que c'est techniquement faisable d'améliorer de manière ambitieuse le bidule:
 
- Soit on se greffe sur un projet existant comme open-inkpot
- Soit on mène notre projet spécifique E60 de notre coté, quitte à utiliser tout ou partie de inkpot.
 
Dans tous les cas , il convient de formaliser la procédure de création du firmware: (nottament les options à passer à mksquashfs et la version à utiliser).

Dans un premier temps je suis plutôt pour la deuxième solution. Déjà on fait marcher -au moins un bout de- OpenInkpot sur le e60.  
 
Ensuite on peux se rapprocher d'eux pour que les modifs qu'on veux faire dessus soient intégrées en mainstream dans le projet et pour avoir une aide de leur part.
 
Concernant la manière de faire, j'en ai ai une idée assez précise. Ce qui serait bien c'est de voir si on peut faire un firmware totalement opensource, même si il ne fait rien, avec un script de génération automatique à partir des sources. Pour ça il faudrait être sûr que Samsung n'a rien ajouté au noyau ou autre dans les sources. A partir de là on peut mettre ça sur GoogleCode.  
 
Je pense que certaines personnes voudrons continuer à travailler sur un firmware avec le MainApp fourni par Samsung, malheureusement ce n'est pas compatible avec GoogleCode, ce n'est peur-être même pas légal, en tout cas ce qui ne l'est pas à coup sûr c'est de redistribuer du code Samsung.

Tout à fait d'accord!
 
Voici une liste (non exhaustive) des possibilités :

• continuer à modifier le firmware Samsung, sachant que le gros est constitué d'un blob binaire (appli Qt) dont les sources ne sont pas disponibles (est-ce qu'il y a  un moyen de savoir si l'appli a été gérée avec Qt GPL ou Qt payant ? Dans le permier cas, Samsung esttenu de livrer tous les sources de l'appli   ). A moins d'avoir les sources de l'appli, il me parait improbable de désassembler une appli de cette taille en C++ et surtout, de pouvoir y apporter des modifs.
• OpenInkPot : c'est une distro orientée e-reader, donc bien adaptée au E60. Il y a déjà une base existante, mais la liste des matériels réellement supportés est courte ! Il manque également le support des notes et gribouilles.
• Android: c'est très "mainstream"   Ça permet de s'affranchir de toute la tripaille BusyBox et d'offrir une plateforme Java... Mais Android est plutôt fait pour les écrans LCD, et pas pour les e-ink avec leur lenteur d'affichage inhérente. Si quelqu'un trouve un écran LCD 6" pas cher qui se connecte sur le connecteur 54 broches supplémentaire de la carte mère, on remplace le e-ink et hop...

D'autres idées ?

 
D'accord avec toi sur le principe. Ca parait plus raisonable.
 
J'ai pas regardés tous les tgz des sources, mais de ce que j'ai vu ce sont des sources génériques donc on ne connait pas les options de compilations appliqués pour le E60. Je ne pense pas qu'on connaisse non plus tous les patchs appliqués...
Et bien évidemment, on a pas les source de la partie propriétaire... (toute l'appli graphique).
Dans un premier temps, on peut continuer à travailler comme on le fait en tapant dans le firmware original quitte à rajouter des executables dans le firmware.
Je ne pense pas qu'on ait toutes les cartes en main pour tout régénérer "from scratch".
 
Première étape pour moi ce week end si j'ai le temps , afficher quelque chose sur /dev/fb en lieu et place de MainApp.
 
Idée de devellopement qui doit etre faisable pour ceux qui veulent garder l'appli d'origine:
Utiliser le bluetooth pour piloter le E60 et lancer des applis qui tourneront en tache de fond (exemple une webradio).
Il suffirant d'envoyer des commandes avec une petite appli qui tourne sur un téléphone.

J'avais pensé à Android, pourquoi pas après tout peut-être qu'Android rends bien sur de l'eInk. En tout cas le matériel le permet.

 
Ça va pas la tête?

Y'a pas moyen que je remplace l'écran à encre électronique ( ) par un pov' LCD qui va me pourrir les yeux

Pour Android en général ça va être tendu : celui-ci a été développé pour des écrans tactiles. Je suis pas sûr que ce soit agréable à utiliser avec le stylet du e60

Je suis le premier à ne pas vouloir remplacer l'écran de mon e60 non plus. Par contre avec un home adapté et des applis triées sur le volet ça pourrait le faire

 
Oui!  
Moi ce qui me plairait bien c'est une petite appli qui se lance au boot qui permet de faire ce que l'appli d'origine ne fait pas ou ne fait pas bien: client mail, webradio, navigateur web ? et de prévoir un bouton qui lance l'appli propriétaire.
Bien entendu l'inconvénient c'est qu'il faut rebooter pour revenir à l'appli custom.

Peut-être qu'une installation ou un portage de FBReader aurait de l'intérêt aussi.

 
on peut remplacer toutes les applis du menu? parce que on vire le market l'agenda et le dico (si on a google ça sert plus à rien) et voilà

 
de ce que j'ai compris il n'y a qu'une seule application visible dans le système, et la modification est délicate.
on est plus proche de la solution remplacement de l'ensemble de l'interface et/ou créer un système de bascule entre le logiciel custom et l'officiel.

Non, En fait c'est une seule appli monolithique et closed source, donc on peux rien faire de ce coté là.

Apparemment ils utilisent Qt 4.5 (si on en croit le path d'installation) Et Qt 4.5 et suivants sont aussi en LGPL. Donc raté pour les sources ;-)
 

c'est ce qui me semble le mieux, mais c'est vrai que c'est dommage de perdre des fonctionalités

ça ne me semble pas vraiment pertinent android, mais pourquoi pas. (de toute façon, pour l'instant je n'ai rien fait donc je ne suis pas la personne qui doit faire les choix ;-) )
 
Dans tous les cas, même si plusieurs options sont explorées en parallèle, le travail sur les couches basses pourra être partagé.
 
Edit : mise en page désolé, ça fait longtemps que j'ai pas utilisé de bbcode

Peut-être y'a-t-il des connaisseurs en QT Embedded ?
Ca ne doit pas être bien compliqué de programmer une appli qui prendrait la place de la MainApp pour lancer tout ce qu'on souhaite, et lancer la MainApp si on souhaite avoir les features de base du E60...

Je le sais parfaitement.
Mon lancement de telnetd se fait dans le fichier curstormrun.sh à la "racine USB" de la mémoire flash.
Au boot, le rcS modifié détecte ce script, le renomme, le lance : ça fonctionne vu qu'ensuite si je connecte le reader en USB, je vois le script renommé avec la date.
 
Par contre le serveur telnet (lancé via /usr/sbin/telnetd -l /bin/sh ) me refuse la connexion.

Bon, je suis en train d'alimenter le svn sur google code. (pour l'instant avec l'archive vanilla de samsung)
 
Edit: (Attendez que j'ai terminé et que j'indique ici pour récupérer le contenu).

 
Effectivement je pense qu'on peut se brosser pour les sources !

Les sources d'une appli n'ont pas vocation à être libres même si on utilise un framework en GPL, vous avez vu ça où ?

Attention je pense que l'archive vanilla de Samsung n'est pas distribuable. Notamment ce qui est dans image.zip.

En fait j'ai surtout des doutes pour MainApp et mkpackage.