DAPI

[fpp]

Au fait, il m'est revenu un truc, pour le soft...

J'ai eu un temps un Nokia N900, qui a son époque était le premier smartphone (commercial) sous Linux (dérivé debian). Avec CPU ARM bien sûr.
Il existait (et existe toujours, je viens de vérifier) une version de Rockbox pour le N900.
Bien sûr il ne s'agit pas de la version "bare metal" qui remplace le firmware/OS d'origine comme sur les DAP, mais d'une version "application" qui tourne sous l'OS existant de l'hôte. Il y a d'ailleurs une version Android en cours de développement.

Cet aspect de Rockbox est a priori fort peu documenté, et je n'ai pas trouvé de projet similaire pour le RPi, mais a priori ça ne semble pas impossible que ça puisse exister.

[tinara]

Le fait de mettre Rockbox sur le RPi a été décrété comme pas possible et inintéressant sur leur mailing-list ou leur forum, je ne sais plus trop où je l'ai lu et notamment car la puce Boardcast (?) n'est pas suffisament de documenté et contient des erreurs dans sa doc, entre autre. De plus, il ne faut pas oublier que de base RB ne gère pas vraiment l'USB-Host donc la sortie numérique qui nous intéresse.
Maintenant, je sais que pour des Linux en CPU ARM, il y en a d'autres que le N900, notamment le YP-R0 où un dev italien, ami de leb', développe(ait?) une LO mais ça tient pas mal du bricolage hardware qu'autre chose et pas facilement répétable.

Je réitère mon opinion comme quoi le plus simple et économe sera sûrement de virer X et de faire tourner un player sur le tty 1 comme moc et de récupérer les informations comme "les albums" et les chansons joués avec des scripts bash et python pour l'envoyer à l'écran via la libraire GPIO mentionnée au premier post.

[fpp]

Le fait de mettre Rockbox sur le RPi a été décrété comme pas possible et inintéressant sur leur mailing-list ou leur forum, je ne sais plus trop où je l'ai lu et notamment car la puce Boardcast (?) n'est pas suffisament de documenté et contient des erreurs dans sa doc, entre autre. De plus, il ne faut pas oublier que de base RB ne gère pas vraiment l'USB-Host donc la sortie numérique qui nous intéresse.

J'ai lu un truc comme ça à un moment aussi. Maintenant, avec Rockbox, il y a toujours l’ambiguïté de savoir de quelle version on parle.
Pour la version "firmware" (genre Clip, Ipod et autres) c'est certainement peine perdue, vu la présence de "blobs" binaires sans source pour des composants non ouverts, sauf à se taper le reverse-engineering du hardware, bof.
Mais dans la mesure où ledit hardware est capable de faire tourner un Linux complet, avec justement les pilotes (ouverts ou pas) pour tous les composants, la version "appli" tournant au-dessus (comme sur le N900) garde tout son sens. J'ai été surpris de ne rien trouver là-dessus, pas même une explication de pourquoi ce serait pas une bonne idée.

Je réitère mon opinion comme quoi le plus simple et économe sera sûrement de virer X et de faire tourner un player sur le tty 1 comme moc et de récupérer les informations comme "les albums" et les chansons joués avec des scripts bash et python pour l'envoyer à l'écran via la libraire GPIO mentionnée au premier post.

On est d'accord, j'ai moi-même mentionné la solution moc+Python.
C'est juste que si Rockbox existait aussi, on pourrait regarder si son interface (en mode texte) ne serait pas également pilotable par boutons et GPIO...

[tinara]

...

J'ai lu un truc comme ça à un moment aussi. Maintenant, avec Rockbox, il y a toujours l’ambiguïté de savoir de quelle version on parle.
Pour la version "firmware" (genre Clip, Ipod et autres) c'est certainement peine perdue, vu la présence de "blobs" binaires sans source pour des composants non ouverts, sauf à se taper le reverse-engineering du hardware, bof.
Mais dans la mesure où ledit hardware est capable de faire tourner un Linux complet, avec justement les pilotes (ouverts ou pas) pour tous les composants, la version "appli" tournant au-dessus (comme sur le N900) garde tout son sens. J'ai été surpris de ne rien trouver là-dessus, pas même une explication de pourquoi ce serait pas une bonne idée.

Bah disons que je pense que ce n'est pas le but des développeurs RB en général hormis pour les rares qui ont développés des versions d'application standalone pour les N900 et Android. Je pense que cela va à l'encontre du but et de ce qu'est en réalité Rockbox comprendre un système d'exploitation alternatif pour les baladeurs mp3 et n'a pas un rôle d'être simplement un player multimédia alternatif dans une foison d'applications mais cela reste un autre débat. D'ailleurs, je crois que ces applications ont du nécessiter une réécriture complète ou partielle de Rockbox (pour l'application Android, j'en suis quasi sûr).

...

On est d'accord, j'ai moi-même mentionné la solution moc+Python.
C'est juste que si Rockbox existait aussi, on pourrait regarder si son interface (en mode texte) ne serait pas également pilotable par boutons et GPIO...

De ce que j'ai compris, la gestion de l'écran par GPIO va nécessiter d'envoyer les infos au fur et à mesure des modifications (déplacements, sélections des boutons). Après, si ça se trouve, je me plante complètement de manière de faire mais je voyais les choses ainsi :
Démarrage et lancement automatique de moc via un autostart.sh ou n'importe quoi du genre. Et copie du dossier "/home/music" dans un fichier texte qui sera envoyé partiellement à l'écran via un script maître qui gère la communication entre écran (nombre de lignes affichés, etc.) et le système et avec un focus qui est géré par le script aussi en communiquant avec les boutons. Il faudrait aussi que l'action des boutons soient appliqués sur le lecteur en lui-même pour pouvoir modifier son état et ainsi le récupérer. Bref, j'ai l'impression qu'une poignée de scripts en Bash et Python interagissant pourrait suffir à rendre le système viable. Mais ce n'est qu'une vague idée d'organisation et je pense qu'il y a sûrement de nombreuses autres possbilités sur lesquels on devrait réfléchir et évoquer afin de tirer celle qui semblera la plus viable.

[fpp]

Il y a sûrement plein de façons de faire, oui : une vague requête Google m'en a retourné quelques-une de crédibles sans plus creuser que ça, donc en cherchant mieux...

Mais je pense plus sage de suivre la "méthode raf" et de procéder par étapes, en vérifiant la faisabilité des fondamentaux un par un avant de se lancer dans le codage d'une interface, qui arrive en dernier (et qui peut éventuellement être différente d'un utilisateur à l'autre, encore un mérite potentiel du DAPi :-).

[raf]

Ouip. Par contre, ces derniers temps, pas eu le temps de mettre a jour le wiki et compagnie. Je n'ai pas encore recu mon RPI. Et j'ai pas encore zieute l'ecran. J'espere avoir le temps de le faire ce long weekend de paques.
J'aime bien la methode par etapes, comme ca on oublie rien, et on valide petit a petit. Sinon c'est un trop grand chantier pour nos emplois du temps trop charges. Heureusement que Vic va m'aider pour la soudure, j'ai pas de fer sous la main. Sinon je valide le point 5, c'est effectivement un point tres important. On verra comment on fera d'ici la, mais c'est vrai que le mettre en veille ou l'eteindre, il faudra alors un bouton pour ca, pour le mettre en gestion d'economie d'energie ou un truc du genre, un peu comme la veille prolongee de Windows. Faut voir si ca existe sur unix/linux.

[tinara]

Oui, la veille prolongée existe sous Linux, je m'en sers tous les jours. Par contre, pour l'éteindre ça va être plus compliqué vu qu'a priori on souderait la batterie qui elle n'a pas d'interrupteur par contre, on pourra avoir un suivi de son état via un système de LED qui donne l'état de celle-ci. À confirmer mais dans mes souvenirs de la batterie, c'était ça.

[Vic]

Mettre un interrupteur entre la batterie et le Pi n'est pas un souci

[fpp]

...en revanche le temps de démarrage en est un :-)

[tinara]

Ça ne sera pas instantanée, c'est sûr mais sans grub, sans X... ça devrait être relativement raisonnable àma, je miserai dans les 5 à 10 sec.

[Tutut]

Oui, la veille prolongée existe sous Linux, je m'en sers tous les jours. Par contre, pour l'éteindre ça va être plus compliqué vu qu'a priori on souderait la batterie qui elle n'a pas d'interrupteur par contre, on pourra avoir un suivi de son état via un système de LED qui donne l'état de celle-ci. À confirmer mais dans mes souvenirs de la batterie, c'était ça.

Le Raspberry supporte les commandes halt et shutdown en étant alimenté par l'USB, pourquoi ne le ferait il pas avec une batterie ?
La veille peut se faire avec la commande apm --standby ou --suspend, il suffit de dédier des touches ou des combinaisons de touche à ces commandes.

Ça ne sera pas instantanée, c'est sûr mais sans grub, sans X... ça devrait être relativement raisonnable àma, je miserai dans les 5 à 10 sec.

Je crois que tu es un peu optimiste, c'est une carte SD.

[raf]

Au lieu de supputer, il vaut mieux tester, et on verra apres

[Tutut]

Je n'ai pas cherché à optimiser les temps de boot sur la révision B que j'ai eu entre les mains, mais je pense que les premières choses à faire, sont de prendre une carte SD rapide et virer les modules inutiles au démarrage, en espérant qu'il n'y aie pas trop de drivers compilés en dur dans le noyau, sinon, ça demande une recompilation du noyau pour améliorer les performances.

[raf]

Recompilation de noyau? houlala! Ya pas une VM pour ca?
Hum, bon je vais commander une carte SD speciale rapide.

[Tutut]

Je vais un peu vite, avant de voir le noyau, il faut voir aussi l'init, regarder ce qui traine dans /etc/init et /etc/init.d , pour les drivers au démarrage voir /etc/modules.