TheBreton a écrit 928 commentaires

pour urpmi je peut en deduire (a tort peut etre?) que l'install de la mandriva a ete faite avec un seul CD plutot qu'avec les 3 de la version download ?
Si tu as une connexion internet style adsl ou plus tu peut faire urpmi a travers le reseau directement de sous linux.
voir la page :
http://easyurpmi.zarb.org/
suis les instructions et refais urpmi kdevelop

pour QT3 tu dois avoirs installes les libs QT3devel ou un nom comme ca.sinon les QT3 de base ne sont que la partie executable.

pour jext voir la page suivante:
http://www.jext.org/index.php?section=instructions&PHPSE(...)
a savoir que la notion d'installation comme sous windows ou tu clique sur un truc sans savoir les details de ce qui va ce passer n'est pas dans l'esprit linux ou il faut faire les choses soit memes.

pour trouver kdevelop ouvre une console
un coup de su pour passer en root
ensuite
urpmi kdevelop
et laisse toi guider
man urpmi pour en voir les infos.


pour ton fichier .tar.gz il s'agit d'une archive zip, pour la decompresser toujours en ligne de commande
tar -zxvf jext-3.2pre3.tar.gz

pour QT3 il s'agit simplement de specifier dans l'ide les .h et les .lib a linker avec ton appli pour que ca marche.

un grand MERCI ca as l'air d'etre exactement ca qu'il me fallait comme info, reste a voir si la boite noir permet la gestion comme ca..
Une route c'est quoi ca marche comment ?

c'est pas du tout normal que les get_strings echoue.
Je voie deux piste
1) Firmware bugge : voir sur le site sony si une mise a jour est disponible.
2) Si sur ton PC tu as des port USB1.1 d'une part ET 2.0 d'autre part essaye en passant de l'un a l'autre, sous linux c'est des couches logiciel differente qui gere ca (le controleur 2.0 et le controleur 1.1).
Regarde dans dmesg si tu vois des truc comme EHCI,UHCI et OHCI.
3) Mise a jour du kernel a essayer, la mdk 10.0 est en 2.6.3, essaye de passer sur le 2.6.12 (ou 13 qui doit sortir dans les jours suivant)
il y avait des pbs sur l'usb qui ont ete resolu.
ATTENTION: si c'est la premiere fois que tu change de kernel trouve un guide sur lea-linux par exemple pour voir la marche a suivre.

peut etre n'est il pas configurer en mass-storage ton apn ?
un lsusb -v te donnera ces infos d'enumeration post les ici pour pouvoir te dire plus de chose

de rien, bonne continuation

de mémoire usb-skel ne declare a usb-core que la premiere interface du device usb.
Peut etre une coquille dans le code que tu as rajouter pour declarer touts les altinf ?
Sinon sans le code je vois pas d'autre piste. sur le 2.6.11 les pb de selection devrait ne plus exister.

une idée comme ca.
dans usb-skel le "write" est non bloquant :usb_submit_urb retourne immediatement cad avant que l'octet soit parti vers ton device.
Si tout de suite derriere tu fais un set_usb_interface le urb en pending est-il toujours vivant ?je ne saurais le dire.
1) au lieux de faire un fill_urb/submit urb peut tu essayer de faire un usb_ulk_msg ? et ensuite seulement (car la tu est garanti qu'au retour de usb_bulk_msg ton message a ete recu par le device ) de faire ton set_usb_interface.

2)C'est une methode de faire comme cela mais elle n'est pas dans l'esprit de l'usb qui as prevu le control-endpoint afin de gere ce genre de request.

si je resume la led s'allume quand le device recoit un control-packet change_setting.
Plusieurs chose peuvent etre envisagée.
1) Une coquille dans l'enum/core USB indiquant que l'alternate setting que tu tente d'envoyer
- est deja celui encours
- n'existe pas.
- ne correspond pas en terme de nb de endpoint

2)La fonction usb_fill_bulk_urb envoie un packet BULK au device pas un packet control pourquoi l'utilise tu pour l'envoie du control packet?
(voir fonction usb_control_msg ou usb_fill_control_urb)
N'obtient tu pas de cette fonction dans le champ status de ton urb une info ?

3) Un analyseur usb est un appareil en vente dans le commerce permettant de s'intercaler entre un host/device et permettant d'observer les transactions usb. Son prix le reserve au "pro" plus qu'aux particulier.
Tu peut voir avec certain commerciaux pour la location a la journé d'un tel equipement

je peut predire que le pb viens de la ligne 349 de ton fichier .C

Nan plus serieusement pour avoir des réponse le mieux c'est que tu pose des questions non ? et que tu fournisse des elements technique.
De quoi est sorti ton code ? usb-skelton ? form scratch ? du rubiny ?
qu'est ce que tu fais dire que ca marche pas ?
Tu ne vois pas le packet de controle sur l'analyseur usb ?
Comment tu l'envoie d'ailleur ton control-packet ? quel fonction ?
quel version de kernel utilise-tu ?

Si ton message est correct
[quote]make -C /lib/modules/2.6.11-6mdksmp/build SUBDIRS=/home/nico/Desktop/test/vloopback-0.95 modules
make: *** /lib/modules/2.6.11-6mdksmp/build: No such file or directory. Arrêt.
make: *** [default] Erreur 2[/quote]
J'ai cependant le package kernel-source-2.6 Version : 2.6.11-12mdk installé...

pour moi 2.6.11-6mdksmp et 2.6.11-12mdk sont bien deux version differentes
en clair ton kernel en cours de fonctionnement est le 2.6.11-6mdksmp
et le package des sources installees 2.6.11-12mdk etant different cela ne se compile pas.
Il te faut installer les sources du 2.6.11-6-mdksmp et ca devrait rouler.

1) debranche ta souris
2) rebranche ta souris
3) poste les 20 dernieres lignes de dmesg pour voir les infos de usb core

3 bis) tu peut essayer avant de faire tout ca un "modprobe usb_mouse"
(pour l'orthographe de usb-mouse je suis plus sur, tu peut faire un saut dans ton lib/modules pour voir le nom exact du .ko)

3 ter) tu peut poster le resultat quand ta souris est branché d'un "lsusb -v"

Pour dire ce qu'il entende par la.
pour repondre a ce qu'ils entendent par la
Pour l'usb quatre fils sont obligatoire Vbus,D+,D-,GND.
Vbus est une broche +5V (tres environ puisque ca descend à 4.5V) qui sert d'alimentation fournie par le HOST.
Dans la phase d'enumeration d'un peripherique sur le bus (qui ce produit quand tu branche le device sur le bus) parmi les infos tel que le nom, num produit,serial etc circule la consomation electrique du device.
La norme stipule que le HOST doit calculer la conso requise par ce device plus la conso des autres device branche sur la branche (un prise host=un depart de branche) pour verifier que la conso electrique totale soit compatible a la capacité du host a fournir le courant.
Si le host ne peut pas alimenter ce nouveau device alors il ne l'autorise pas a fonctionner.
Donc je pense que l'alim est presente(vbus est de toute facon obligatoire) mais que le port en question ne peut pas fournir d'alimentation au device qui s'y connecte.
Pour t'en sortir il te faut un hub usb avec sont alim externe pour alimenter tes peripheriques. Quand a savoir a quoi sert un portable qui ne peut pas utiliser une souris usb sans une alim secteur pour alimenter la souris il faut questionner les gars du marketting de dell.



Lexique : HOST le PC, device (clef usb, printer,scanner,keyboard etc)

linux est lancé tu est dans une console ou tu peut saisir des ordres.
ls pour avoir la liste des repertoires present
startx pour lancer une interface graphique ou tu trouveras un espace de travail plus conviviale que la ligne de commande si c'est la premiere fois que tu lance un unix like. car des commandes a part ls ou startx il y en as beaucoup encore.

on est d'accord la dessus, une application n'as pas besoin de savoir comment fonctionne le kernel et surtout pas a faire des ioctl ou des syscall.
Le noyaux et ces interfaces évolue constamment, on as eut 2 version de la couche usb sur le 2.4 et dans le 2.6.x avec x inferieur a 11 un troisieme et une version 4 devrait etre dans le 2.6.12 (pas eut le temps de verifier).
Autant dire que le temps d'ecrire une doc elle serait deja largement out-of-date.
L'API a documenté c'est celle des fonctions de base du C (la libc) et des bibliotheque qui gravite autour comme libthreab ou la pthread et d'autres, mais chacunes des library utilisé contient deja de la documentation.
Lire dans /proc n'est deja pas portable, d'une version a l'autre du kernel ou du module generant ces infos cela peut changer.

Pour les docs un lien vers plusieurs doc specifique.
http://jungla.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html(...)

* Lire des fichiers se trouvant dans /proc (alors qu'il devrais être possible d'obtenir ces informations grâce à des fonctions tel que ioctl....)

Bon la c'est moins simple, ioctl est une porte bidirectionnel entre le noyaux et un programme appli. Par contre chacun est libre de faire passer ce qu'il veut et comme il veut par la, donc a moins de connaitre en detail le module a qui l'on parle on ne ce sert pas des ioctl.
Aucune doc ne pourra jamais ressencer toutes les facons de communiquer de tous les modules ecrit un jour pour linux.

Je me suis dit qu'il doit pourtant exister quelque part une doc qui contient toutes les fonctions que l'on peut utiliser pour interagir avec le noyau (idem pour X,...)
Pour le noyaux en lui meme il n'est responsable que de peut de chose, allocation memoire principallement le reste est a la charge de divers modules construit avec le noyeaux, les appelles systemes de base sont documentées (->google syscall), pour le reste ca depends de chaque modules.

La difference avec windows c'est que tu ne dispose pas des sources donc il te faut utiliser les interfaces que l'on te donne et comme tu ne peut pas lire ce qu'elle font on te fournis une descruption, avec linux on te founit les sources pour que tu puisse lire ce qu'elle fait reelement et si ca ne te convient pas tu peut copier/coller le code dans un autre prog et le modifier a ta guise.

En lecture papier je peut te conseiller les tres bons livres indique sur le premier lien avec une grosse preference personnelle sur les livre alessandro rubini (dont le linux device drivers qui est consultable en ligne ou telechargable en pdf)

Les notions mises en jeux ne sont pas du tout les meme entre un code executé et une realisation en hard (par cablage,fpga ou fpu).
Le deux ne sont pas comparable, pour imager mon exemple, ecris en C une FastFourrierTransform ou une operation SINUS par DL, en code RISC ou CISC assembleur peut importe, et tente de comparer ca avec un composant qui te fait la meme chose en N cycle de l'horloge micro (N etant la limite de ton dl ou de la taille de ta table fft).On se rend parfaitement compte que la realisation cablé en dur est plus rapide d'un facteur 10 minimum.

Certes, on perd le degré de liberté de la reprogrammation, et donc une partie des possibilités offertes par ce genre de plateforme, mais je ne sais pas (je serais curieux de connaître des applications où cela pourrait être utiles) s'il y a beaucoup d'applications qui ne puissent être bien optimisées en se basant sur un bon RISC/CISC plus un ou plusieurs DSP périphérique(s), tout ce petit monde travaillant à une tâche bien particulière en parallèle.

Dans l'absolu tu as raison, en elevant la frequence et le nombre de core on peut arrivé a faire la meme chose. Mais d'un point de vue economique ca ne tiens pas . Un circuit generaliste (DSP ou CPU) utilisé a une fin précise sera sous-utilisé (il y a plein de truc qui ne servent a rien pour cette utilisation et qui sont sur le silicium) et au final revient plus cher qu'un circuit specialisé dédié. Exemple : dans un PC la carte graphique est a base d'asic ou de fpga plutot que de core cpu/dsp.

tu as besoin que les valeurs soit aleatoire ou pas ?
je m'explique, l'entropie de random est basé comme tu l'indique sur les IT interfaces user mais a priori n'importe quel interruption du kernel peut y participer.
donc une IT réseau (je suppose que la machine a au moins un reseau?) ou un module avec une IT sur un timer pourrait y participer.
Le pb de cette methode c'est que les IT etant cyclique le random sera bien rempli mais avec un niveau hazard extremement bas.
Donc si tu ne t'en sert pas c'est une solution, si tu as besoin de vrai valeur aleatoire il existe des cartes d'un prix inferieur a 100euros qui dispose de generateur aleatoire quantique (bruit sur une resistance en generale) qui tu peut inserer dans le pc.

merci pour les infos

j'ai pas vraiment de reponse sur les disques dur silencieux mais le 2.5 pouces est effectivement le format ou tu as le plus de chance d'en trouver.
Ce petit produit a l'air interessant, j'ai deux ou trois question si tu veut bien y repondre.
A quel prix l'as tu trouvé ? et pour ce prix l'alimentation est externe ou interne ?est elle fournie ?
merci

normalement tu peut contourner le probleme dans les fichier tex, les caracteres accentue ne sont pas gerer dans une version anglaise comme celle que j'utilise et pour obtenir les accent je fais un "e" suivi d'un code echappement \ suivi du ' ou du ` suivant que tu veut un accent grave ou aigue. L'avantage est que le meme fichier tex pourra etre traiter sur n'importe quel systeme et distro tex/latex ce qui n'etait pas le cas avec des accents.
Du coup si sous vim tu peut reconfigurer une touche pour quel tape le e+la sequence d'echapement ca devrait resoudre ton probleme.

Si je comprend tout c'est la notion de base du CELL que tu souhaite
un ppc64 et une tripoté de petit processeur vectoriel dans les coins.
Moins rapide que le fpga sur des fonctions cablé, mais plus évolutif (c'est du soft) et leur temps de programmation permet lors du task-switch de recharger leur memoire programme.

voir
http://linuxfr.org/2005/06/29/19228.html(...)
et surtout
http://www.research.ibm.com/cell/(...)

c'est pas tres clair mais mon post precedant ne traitant que de la detection d'un equipement sur un port serie

la vite fait je vois deux methodes

1) ton equipement tire au niveau actif une des deux entree du port serie (CTS ou DSR) normalement inactive quand tu le connecte et donc en faisant une lecture reguliere de tout les ports de ton systeme tu doit detecter si ton equipement est present ou non.

1) en faisant une emission/lecture de la reponse reguliere sur tout les ports de ton systeme tu doit detecter si ton equipement est present ou non.

deux mois sans avoir sortie une paire de ciseaux ca c'est de la patience!