Après environ 6 mois de développement, LCD4Linux "Next Generation" commence a devenir mature pour commencer la phase de beta-test.
Pour ceux qui ne connaissent pas, LCD4Linux permet de piloter des écrans LCD (HD44780, Matrix Orbital, CwLinux, CrystalFontz, ... ou avec Ncurses, X11 ou en sortie PNG), mais contrairement à lcdproc, il n'y a pas de mode client-serveur en réseau, tout est en un binaire.
Cette "NextGen" est le fruit d'une réécriture quasi-totale du code, et une modularisation du tout. Cependant, la version 0.10.0 sera en un seul binaire, la modularisation sous forme de plugins est prévue pour la 0.10.1.
Vous pouvez tester la nextgen sur le CVS de SourceForge :
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/lcd4linux login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/lcd4linux co lcd4linux
Le site http://lcd4linux.sf.net(...) n'est pas à jour pour la documentation de NextGen, car toute la syntaxe du fichier de configuration a changé (voir lcd4linux.conf.sample). De plus, nous avons besoin d'aide pour écrire la documentation, qui est la dernière étape avant la sortie des betas ! Que le message soit entendu ;)
Si vous testez la version CVS et que vous rencontrez un problème, ou que vous trouvez le programme génial, ou que vous voulez nous aider, mailez-nous à lcd4linux-devel@lists.sourceforge.net
# LCD4Linux / lcdproc
Posté par durandal . Évalué à 1.
Moi-même je suis en train de m'amuser avec le HD44780 pour un projet électronique scolaire, mais c'est pas pour le relier à un PC.
Quels sont les avantages de LCD4Linux par rapport à lcdproc ?
C'est plus riche au niveau configurabilité ?
Et ne pas garder le mode client-serveur, c'est sensé être plus intéressant ?
[^] # Re: LCD4Linux / lcdproc
Posté par xavier66 . Évalué à 2.
> Oui c'est sympa, mais c'est super utile, au delà de l'aspect "geek" ;)
Quels sont les avantages de LCD4Linux par rapport à lcdproc ?
> C'est plus riche au niveau configurabilité ?
> Et ne pas garder le mode client-serveur, c'est sensé être plus
> intéressant ?
> LCDProc utilise un mode client-serveur que je trouve assez désagréable à configurer et à utiliser : on ne peut agir que sur ce que le client controle. Impossible pour le client de modifier la vitesse de rotation du ventilo via PWM ou accéder aux GPOs.
Nous avons choisi un mode de fonctionnement "monolithique" pour une meilleure intégration, pour la sécurité (bien que le serveur de LCDProc ne soit pas dangereux) et nous avons séparé le traitement ainsi :
- l'affichage par des 'drivers'
- l'entrée de données via des 'plugins' (le mot est mal choisi, mais c'est pas ma faute :p). Ce système me semble plus puissant, car on peut ajouter le support d'un ioctl ou d'un parseur pour /proc/sys/bidule/truc en écrivant une seule fonction, sans gérer la communication avec le serveur.
- au milieu, l'evaluateur qui fait le lien et gère tout.
- nous prévoyons pour la 0.10.1 une couche d'input qui permettra de gérer des évènements; via des timers, une clavier, le réseau, un gamepad, ... pour modifier le comportement du démon. On pourait par exemple modifier la vitesse de rotation des ventilos via un écran CZ ou MatrixOrbital supportant le PWM selon la température du processeur, ou demander du café à sa cafetière expresso via un GPO si la charge réseau est trop importante ;)
- on peut configurer ce qu'on veut afficher sur son écran via un "layer", alors que je n'ai pas trouvé comment configurer lcdproc pour lui dire de m'afficher une double barre verticale affichant la memoire occupée et le swap occupé ainsi qu'une icone d'éclair quand la charge système s'envole. Je trouve LCD4Linux extrèmenet souple sur ce niveau.
# arf
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.