Benjamin Zores a écrit 75 commentaires

Avec un site franco-francais, ca va etre difficile a diffuser plus large.
Surtout avec un nom de projet qui est un acronyme anglais.
Tu me decois Guigeek ;-)

On ne trouve pas de tablette avec RJ45 … parce qu'Android ne gère pas (correctement) l'Ethernet:
http://www.slideshare.net/gxben/elce-2012-dive-into-android-networking-adding-ethernet-connectivity

Ca marchotte un peu dans le browser mais ça s'arrête là.

Sans qu'il s'agisse réellement d'un problème technique, l'implémentation n'est pas là parce que coder à un coût et comme une tablette avec RJ=45 ne représente pas un marché juteux, tout le monde investit sur d'autres priorités (sauf Intel qui veut faire marcher l'Ethernet sous Android pour fourguer des Android sur ses netbooks/ultrabooks).

La Wii n'a jamais ete supportee officiellement.
Il s'agissait egalement d'un fork chinois, que l'auteur n'a jamais voulu completement reintegrer (a l'epoque ce n'etait pas evident, maintenant avec le framework OpenBricks, ca le serait davantage). Cela dis, je ne crois pas que le developpement ait continue.

En tout cas, ca ne servirait pas a gd chose, il n'a tjs aucun driver video optimise pour la wii et donc a part MPlayer en mode console (ce qui est deja utilise), il n'y a pas gd chose d'autre qui puisse tourner dessus.

De mon cote, je ne nies pas reprendre (a juste titre) des choses faites dans OpenELEC.
C'est un juste retour des choses apres le fork ...

Tres probablement suivre, avec au moins la branche xbmc-pvr pour la version 2.1 de GeeXboX.

Par contre sur ton P3, garde ta bonne vieille version 1.2 et n'essaie pas celle la, ce n'est plus le meme monde :-(

100% d'accord et personnellement la lourdeur d'XBMC me fait un peu peur, mais finalement plus en terme de difficulté d'intégration que de runtime.
Enna, c'etait bien dans le principe, mais comme tu le dis, equipe de devt miniscule.
En gros, le choix etait: Enna ou GeeXboX. C'est également pour ce type de raisons, que le développement de cette version 2.0 à pris tant de temps. Nous avons passé 18 bons mois à écrire du soft plutot qu'à faire de l'intégration, ce qui n'etait pas l'approche initiale.

Sauf que pour cela il faut Mac OS X et pas un Linux, sinon exit le décodage hardware des vidéos (qui cela dis est limité à du 720p). J'attends éventuellement un AppleTV3 ;-)

Ca l'a toujours été donc rien ne change de ce point de vue.
Le cas OpenELEC me frustre beaucoup, car il s'agit d'un fork non avoué de GeeXboX (en gros, un grep de sources mets rapidemment en evidence la paternité mais d'après l'auteur, il s'agit d'une création originale). J'ai essayé de me battre en vain pendant de nombreux mois pour merger la base de développement mais bon ...

C'est exact. TI fournit des librairies OpenMAX pour le décodage hardware, qui fonctionnent relativement bien. Le problème d'OpenMAx c'est que ca n'est pas vraiment générique et XBMC supporte aujourd'hui OpenMAx pour Tegra2, mais pas pour TI. Les versions en cours de developpement d'XBMC devraient cependant avoir un backend GStreamer qui du coup permettrait d'utiliser OpenMAX et l'accélération matérielle efficacement (GST + OMX fonctionne très bien sur Panda).

Alors pour être honnête avec toi, voici l'état:
- ayant pu avoir accès à un N900 très rapidement, j'ai mis un QEMU ARM (Scratchbox), compilé/debiannisé rapidement Enna, les EFL et toutes les libs nécessaires et fait tourner ca sur l'ARM Cortex-A8 de notre cher téléphone. Ca marche, bien que tout est full-s/w.
- Dimanche j'ai enfin ajouté le toolchain ARM à la geexbox donc pour l'instant ca ne va pas très loin vu que pas encore essayé.
- Maintenant je devrais bientot avoir une BeagleBoard pour faire des vrais essais que je puisse tester. Donc le tout sera fourni soit sous forme de sources (classique) à compiler pour ARM, soit un rootfs précompilé (en fait, les 2) pour ARM, mais très probablement optimisé pour Cortex-A8. Pour OpenGL, Enna et les EFL sont suffisamment intelligents pour l'utiliser si dispo et sinon pour faire du software. Il ne me reste plus qu'à comprendre comment marche OpenGL ES sur ces machines, comment j'interface ça avec X.Org / Mesa (je ne sais même pas s'il y a encore le besoin) et si j'ai vraiment besoin du driver xorg-omap3 :-)

Toute aide à ce sujet est la bienvenue, même s'il ne s'agit que de m'expliquer :p

Evidemment sur ARM, si tu fais en soft, tu peux oublier :-)
L'idée est bien sur d'utiliser au max les accelerateurs h/W sinon, point de salut.

Je te dirai ça dès que j'aurai reçu ma BeagleBoard mais pourquoi cela ne serait-il pas le cas ? Ca ne tournera cependant pas en mode "LiveCD" avec un gros RAMdisk, pour des raisons évidentes cela dit. En tout cas, Enna fonctionne déjà sur N900 (sans optimisation particulière pour l'instant, et de manière non officielle).

Et non car MPlayer n'utilise pas les .po mais la langue est définie à la compilation et donc codée en dur dans le binaire.

a.k.a "alpha" :-)
Pour la météo, l'alpha2 utilisera la géolocalisation IP.
Pour le volume, touches + et - (les touches VolUP et VolDown des claviers multimédias ne sont en effet pas encore prises en compte).

Dans le tout dernier X.Org, avec le MESA pas encore sorti qui dépend du 2.6.33 lui non plus pas encore là. Ca viendra donc bientot mais encore un peu de patience pour que tout ça arrive "naturellement".

En attendant le driver nouveau et de manière à pouvoir profiter de VDPAU, oui hélas.
C'est toujours mieux qu'un driver nv qui ne supporte plus les nouvelles cartes nVidia (ION principalement). Dans la version finale cependant, l'utilisateur aura bien evidemment la possibilité de choisir. Mais il s'agit ici d'une alpha, donc pour tester.

MPlayer n'etant controllable que par son mode "slave" via une FIFO, il est nécessaire de parser la sortie standard pour connaitre son état. Ne voulant pas implémenter un parseur multi-langues pour des raisons evidentes de maintenabilité, il est en effet nécessaire d'avoir MPlayer en anglais.

Concernant VLC, il faut savoir que GeeXboX/Enna utilise une couche d'abstraction multimédia. Il est donc possible de choisir de manière transparente quel est le lecteur à utiliser. Maintenant concernant tel ou tel lecteur, ca dépend beaucoup du type de media que l'on souhaite lire (fichiers, DVD, DVB, streaming ...) et de son OS.

Aucune version Windows n'est prévue d'Enna pour l'instant (MAC _éventuellement_). Non pas que cela ne soit pas possible mais contrairement à XBMC et son armée de développeurs, l'equipe GeeXboX se compte sur les doigts de la(les?) main(s).

Aucun ne s'intéresse à Windows et seul l'intérêt d'un développeur pourrait amener une telle version.

'Générique' dans le sens indépendant de la distribution Linux.
Cela dit, les EFL disposent de multiple backends de sortie vidéo (via Evas) et d'I/O (via Ecore), les rendant disponible pour UNIX (framebuffer, X11), MacOSX et même Windows, ce qui élargit relativement le scope potentiel.

Relativement au support UPnP/DLNA d'une manière générale (i.e. non relatif à Enna), il faut savoir:
- UPnP A/V est une "norme" batarde, tellement souple qu'elle autorise les constructeurs à étendre les profils normalisés pour y ajouter les extensions propriétaires (ce qu'ils ne se cachent pas de faire, principalement Microsoft avec Windows Media Connect mais bon ...). Du coup, on en arrive à une norme "Universelle" (le U de UPnP) où les implémentations doivent supporter les extensions proprio à coup de hack ...
- DLNA se veut une pseudo normalisation/restriction de UPnP A/V pour combler ce problème mais le consortium qui l'a défini à sombré dans l'excès à un point qu'il en devient encore plus difficile d'utilisation, le tout étant beaucoup trop strict.

Tu trouveras davantage d'informations sur le pourquoi du comment sur mon blog ( http://gxben.wordpress.com/2008/08/24/why-do-i-hate-dlna-pro(...) ) si ca t'intéresse, sachant que j'ai, jadis, été sponsorisé pour écrire la lib d'implémentation de référence du protocole DLNA, de laquelle les serveurs open source du moment se sont à un moment ou à un autre, inspirés.

En gros:
- si l'UPnP A/V ne marche pas c'est parce qu'il est trop éloigné du standard
- si DLNA ne marche pas, c'est au contraire parce qu'il est trop proche du standard

Cruelle est la vie :p

Aussi vraie que soit la première partie de ton sarcasme, je te suggère de lire le code de libvalhalla, dont Mathieu est l'auteur. Je serai bien curieux de voir si tu trouves à y redire car je connais très peu de personne se prétendant "développeur" qui prenne un tel soin à réfléchir à l'architecture de son soft et à tester tous les cas avant de se "lâcher" sur le code.

La critique non constructive est évidemment, comme toujours, très facile ...

Avec Enna non plus désormais.
GeeXboX constitue la distribution, Enna l'applicatif, que tu peux utiliser sur ta distrib préférée sans rebooter belle-maman :-)
C'est justement parce que tout le monde ne souhaite pas une distribution dédiée que nous avons conçu Enna pour être "générique".

Tu t'attendais à quoi de plus exactement dans une section "capture d'écrans" ?

Dans un module qui existe déjà en version expérimentale uniquement, il y a un support TV via VDR et Xine. Globalement, plutot que de réinventer la roue, Enna intègrera l'affichage déporté de VDR au sein de son interface. Ainsi, les controles sont reçus par Enna, qui les envoi à libplayer, qui les envoi à Xine, qui, via son plugin VDR, les envoi à VDR (le chemin est un peu long, je sais, mais les performances importent peu à ce niveau).

Cela nécessite cependant une xine-lib 1.2 qui elle aussi, tarde à sortir :p