Reprise du message précédent :
Vofou, retire ton lien avant qu'un Modo passe par là...

Même si je n'y connais rien en programmation, je suis les posts depuis la première page et franchement c'est du bon boulot.
 
Est ce que ca vous semble difficile de faire en sorte que le mode plein écran n'affiche plus de marge ?

Ou trouve t on les logs du boot et la suite, je voudrais voir si l'on a une erreur concernant le SSID caché qui n'est toujours pas trouvable (peut être une mer..de du driver wext ???

Par ailleurs il me semble avoir lu qu'on n'avait pas trace des sons relax d'origines, il sont là : /root/RelaxingSound

Il y a aussi dans root les dicos et le TTS_eng..

edit :

Et que l'on n'ait plus le titre du bouquin en haut de chaque page quand on est en train de lire ce même bouquin...

+10

Ben il suffit d'aller dans le menu demander le plein écran (page 29 de la doc).

Je l'avais mis en spoiler...  
Ca clique sur un spoiler, un modo ?    

Ca vous dit une google list afin d'éviter d'encombrer ce topic avec les discussions entre dev ?
Ou est ce qu'on part du principe u'il y a au final peu à dire sur la liseuse en elle meme, et donc on peux utiliser ce topic pour parler de dev ?

Moi, j'y comprends rien à votre charabia...  
Pourquoi pas un autre topic plutôt tourné vers le dev de FW, et ce topic là pour le feed sur les housses, l'offre de remboursement, les pbs techniques, etc...  

 
non non ... n'en faites rien, c'est très bien comme ça.
je serai incapable de faire une once de ce que vous avez entrepris, c'est très instructif. un peu le prix a payer pour "profier " de votre travail fantastique.
 

En effet, pourquoi pas 2 fils différents, ici. Tout un chacun pourrait ainsi choisir de suivre le/les fils qui lui plaisent et correspondent.

Les stades de dev important pourraient être posté dans les 2 fils, en première page par exemple, ainsi chacun y trouverait son compte et ce serait plus lisible...

Pour info je viens d'installer calibre 0.7.42 (qui date du 21 janvier) avec la commande :
 
sudo python -c "import urllib2; exec urllib2.urlopen('http://status.calibre-ebook.com/linux_installer').read(); main()"
 
Il reconnait automatiquement le Samsung e60 (alors que le calibre packagé dans mon ubuntu ne le reconnaissait pas).

Ce topic va mourir si on y poste plus rien sur le dev

Ou pas.

+1 ca devient de plus en plus dur de s'y retrouver...on perds le fil des discussions ;-)

bon là ça me gonfle :
voici le scipt

 
et l'erreur est la suivante :

 
c'est moi ou à la ligne 3 je lis bien do ???

 
Ca enlève les menus, mais ca n'agrandit pas la zone affichée.
En fait ca sert à rien

top la 1ere page.
 
drap!

Perso, je regrouperai les lignes 2 et 3 en:

avec des ; ça donne quoi ?

edit : un tantinet burnaid

merci pour ta réponse, mais cela ne change rien  

Edit : j'ai rien dit

 
 
Je viens de lancer ce script de test sur Linux et il fonctionne parfaitement
 
 freq=.05
for loop in $(seq 5)
do
# echo write 1 > /proc/power_led
 echo "toto"
 sleep $freq
# echo write 0 > /proc/power_led
 echo "titi"
 sleep $freq
done
 
 
sh ./test
toto
titi
toto
titi
toto
titi
toto
titi
toto
titi
 
Tu dois avoir un caractère masqué bidon en fin de ligne for do... ou do (peut être une histoire ANSI... ???
 
Edit :
Il n'aime peut être pas la commande qui suit do ??? essaye mon shell de test
 
Sinon, peut être un  :
set -x  
en début de shell t'aiderai à y voir plus clair

 
exact..c assez decevant non?
ou alors faut passer en plein ecran et retoucher a la fonte apres ?

J'ai un petit souci pour lire un livre en Vietnamien (alphabet + quelque accents), en format prc.
J'utilise Calibre pour converir en epub:
- Ca marche bien avec le Ebook viewer de calibre
- Lors de transfert au liseuse, il affiche très mal les caractères, même si tout est OK à l'écran d'accueil, dans la partie aperçue du livre récent.
 
J'ai donc converti au format PDF, là ca marche, mais je ne peux lire qu'une dizaine de pages. A partir de la page 13, c'est tout blanc tandis que ca affiche bien sur mon PC.
 
J'ai le firmware 1002 FR, avez vous une idée?

Je viens de faire un copié collé de ton script sur le E60 en virant les N0 de lignes et il fonctionne parfaitement, la led bleu clignote...

freq=.05
for loop in $(seq 20)
do
echo write 1 > /proc/power_led
sleep $freq
echo write 0 > /proc/power_led
sleep $freq
done

Va falloir que je plonge dans le SVN. Je sais comment sortir des choses de ces engins-là, mais pas comment y contribuer.  

Franchement, je ne pense pas que ça soit une si bonne idée, le brick potentiel est trop facile (il suffirait que quelqu'un édite ce fichier avec le mauvais charset et bam, au revoir E60, rebonjour Recovery Mode). J'ai hésité à déporter tout rcS pour cette raison et finalement je ne l'ai pas fait.

En revanche, oui, y'a bien un besoin de triturer ce fichier et je propose donc plusieurs alternative pour le faire :

- Faire une branche du Foxfirmware spéciale développement, avec accès direct à ce genre de fichiers sans autre forme de procès. Les utilisateurs seront invités à prendre la branche normale du truc (qui sera une copie de la branche de dev', mais sans ce genre de liens). Avantage : on pourrait même théoriquement faire carrément un lien de tout le système de fichier (ou presque) vers le home en read-write, quitte à perdre la connexion USB vers le PC et à se connecter systématiquement en Telnet/SSH/etc y compris pour faire passer des fichiers.

- Utiliser le fait que MainApp soit lancé après customrun/permarun à présent : passer une variable dans un script pour qu'au retour sur le rcS MainApp soit ignorée, ou carrément stopper dans un de ces scripts l'exécution de la chaine si faisable (après tout, un sleep impacte déjà tout le chargement, donc pourquoi pas une sorte de halt -?- ou un sleep 99999999999999999999999…9)

- Placer tout le rcS dans un if : s'il existe un rcS perso dans /Custom/, alors utiliser celui-ci, sinon utiliser celui de l'OS.

- Placer le lancement de MainApp dans un if, qui ne sera pas vraiment documenté.
→ Option 1 : si fichier /Custom/System/noMainApp est présent, ne pas lancer MainApp
→ Option 2 : si le fichier /mnt/sd/Custom/System/noMainApp est présent, ne pas lancer MainApp (classe, parce qu'en cas de problème, on retire la µSD et c'est reparti. Mais il faut avoir un µSD déjà)

Je pense qu'on pourrait aussi déplacer le wpa.conf et autres paramétrages du E60 dans un /Custom/System/-, mais j'ai peur que ça empêche le e-reader de se connecter ensuite au PC en stockage de masse.

_______________________________________

Aussi. Si quelqu'un a des connaissances en Reverse Engineering avec IDA, il faudrait tenter d'éclater ce fichu blob qu'est MainApp pour qu'on puisse se permettre des choses plus drôles et pertinentes avec (changement de la taille des polices des epubs, suppression des marges blanches, et j'en passe… deviendraient peut-être possible).

Bonjour
 
En parlant de TTS, serait-il possible d'installer une version française ? Parce que la version anglaise avec du texte français c'est assez particulier...
 
Sinon beau boulot les gars, ça avance bien.

Le plus gros problème reste inhérent au MainApp : l'impossibilité de classer proprement les ebooks...
Il y a bien la possibilité de la librairie mais celle-ci reste très limitée avec un seul niveau et une alimentation manuelle..
 
Vu que la librairie est stockée dans /root/ebook.db, j'ai utilisé le firmware modifié pour la récupérer et codé quelques lignes rapides en PHP pour y inclure tous les livres présents, en créant un répertoire par auteur. Il n'y avait plus alors qu'à remettre le ebook.db modifié à sa place.
 
Bon, c'est crade et mal exploitable... mais c'est un début. Faudrait que je mette ça un peu plus propre et que je le fasse en C pour pouvoir l'intégrer au reader...
 

 
Regarde la modif que j'ai faite ce matin:
Par défaut , si au démarrage on appuie nulle part, mainApp se lance.
Si on appuie sur une touche, un script se lance à la place de MainApp. (on peu choisir un script différent pour chaque touche).
Si le script n'existe pas , on lance MainApp.
ainsi, impossible de bricker quoique ce soit.
 
edit:
http://code.google.com/p/e60-open/ [...] init.d/rcS

Ah bah oui, impeccable comme idée ça.
euh wait
N'importe quelle touche = le Recovery avec Vol.Up fonctionne toujours (normalement, oui, il est là avant même rcS mais bon) ?
Par contre,

lolwut?

J'ai brické Google Code en mettant le strace de MainApp sur le wiki http://code.google.com/p/e60-open/wiki/MainAppStrace
 
Bon donc pour le voir : http://code.google.com/p/e60-open/ [...] trace.wiki
 
C'est relativement intéressant.
 
Sinon j'ai créé un répertoire avec les binaires que je compile (dont le strace si vous voulez vous amuser) : http://code.google.com/p/e60-open/ [...] c_binaries
 
@Mairusu_Prower oui le trunk n'existe pas il faut check out la racine : svn checkout https://e60-open.googlecode.com/svn/

Got it. Bon, j'l'ai checkout mais là faut que je parte donc le commit sera… plus tard.

Y-a pas de trunk, regarde le wiki, il y a un how to

Oui, j'ai vu ton dossier avec les divers binaires, c'est nickel. Est ce qu'on les incorpore par défaut au firmware ? (je l'ai déjà fait pour mplayer).
 
Je suis en train de commiter une arborescence "Sources" avec:
- Un dossier "Supplied by Samsung ": les osurces d'origine
- Un dossier "Additional Softawares" pour les rajouts.
 
L'idée serait de créer dans chaque dossier un script "Compile for E60.sh" avec ce qu'il faut pour que ca cross-compile bien.
 
Là je suis en train de me galérer vaec "fbpad" une appli qui permet d'aficher un terminal en framebuffer. ca compile bien mais je suis emmerdé à l'execution car par defaut l'appli attend un framebuffer de 8,16 ou32bit de profondeur, et nous on doit etre sur 3 bits...

Perso j'arrive pas à écrire sur le framebuffer avec le test de Qt : http://doc.qt.nokia.com/latest/qt- [...] uffer.html
 
A mon avis ça écrit bien mais il faut associer ça à un appel gpio/ioctl/whatever pour dire à l'écran quelle est la zone à écrire.
 
Pour mes binaires y'a pas trop d'intérêt de mettre strace par défaut, mais dbclient et scp oui pour envoyer des données depuis le E60 A mettre dans /usr/bin et aussi un lien /usr/bin/ssh /usr/bin/dbclient

 
Quelqu'un pourrait il m'extraire cette BDD que je regarde quelque chose dessus ??
(ou m'expliquer comment l'extraire à partir de mon E60..)
Merci

bon j'ai testé avec :
- housse compatible gen 3 : trop juste car la housse est pas epaisse donc comme le e60 est plus epais faut forcer pour le rentrer, on accede pas facilement au bouton power le stylet on peut pas le sortir
- housse officielle bookeen gen 3 : la c mieux la housse est plus epaisse, mieux faite donc le e60 rentre plus facilement (on a moins peur de casser l'ecran en forcant le cadre lol) si on le rentre pas a fond il bouge pas et on a acces aux boutons prev/next; par contre le bouton power est tjrs masqué par le renfort en cuir en bas : faudrait découper un peu je pense.
le pb c tjrs le stylet...une fois fermée la housse laisse un espace entre le livre et la bordure donc on pourrait fixer la le stylet si y'avait un emplacement (un peu comme pour le crayon papier des agendas : juste un anneau de cuir...fait avec la découpe ? :-))

je vais poster des photos

c la qu'il faut decouper : ya une ouverture a droite car c la que ya le port usb du gen3...donc faudrait decouper 1-2cm de l'autre coté pour decouvrir le bouton power...qui sera 1 cm a l'interieur de la couverture donc on peut utiliser le stylet en le tenant a l'envers lol

la on voit l'espace a droit entre le livre et la couverture...largement de quoi fixer a l'interieur le stylet non?

ok!
Je vais donc déplacer les binaires dans le firmware sauf strace qui restera à l'extérieur et sera donc optionnel à rajouter à la main.

Bah nan les déplace pas, recopie les juste.

Bof Si on commence à avoir 2 versions d'un meme fichier ca va etre vite le merdier , non ?

C'est pas deux versions c'est deux copies, et moi j'en ai besoin pour dév

OK