MS_Totor

salut, regardes le man de la fonction def et de ls, via man def et man ls sous google.

bon sur le 1010+, avec les drivers de base de la gpl, j'ai bien mon driver pwc.ko pour mon antique webcam logitech pro 4000 test> lsmod Module Size Used by pwc 89984 0 compat_ioctl32 9216 1 pwc videodev 34048 1 pwc v4l1_compat 21892 1 videodev v4l2_common 23424 1 videodev May 23 11:09:21 kernel: Linux video capture interface: v2.00 May 23 11:10:01 /opt/sbin/cron[27549]: (root) CMD (/opt/sbin/minitorix.pl update ) May 23 11:10:28 kernel: pwc: Philips webcam module version 10.0.13 loaded. May 23 11:10:28 kernel: pwc: Supports Philips PCA645/646, PCVC675/680/690, PCVC720[40]/730/740/750 & PCVC830/840. May 23 11:10:28 kernel: pwc: Also supports the Askey VC010, various Logitech Quickcams, Samsung MPC-C10 and MPC-C30, May 23 11:10:28 kernel: pwc: the Creative WebCam 5 & Pro Ex, SOTEC Afina Eye and Visionite VCS-UC300 and VCS-UM100. May 23 11:10:28 kernel: usbcore: registered new interface driver Philips webcam je plug la webcam May 23 11:17:17 kernel: usb 8-2: new full speed USB device using uhci_hcd and address 2 May 23 11:17:18 kernel: usb 8-2: configuration #1 chosen from 1 choice May 23 11:17:18 kernel: pwc: Logitech QuickCam 4000 Pro USB webcam detected. May 23 11:17:18 kernel: pwc: Registered as /dev/video0. May 23 11:17:18 kernel: usbaudio: Audio Volume set to 50 (50) May 23 11:17:18 kernel: Got empty serial number. Generate serial number from product. mais il y a deux messages de la par de hotplug May 23 11:17:18 default.hotplug[30063]: couldn't exec /usr/syno/hotplug/sound.agent May 23 11:17:19 default.hotplug[27623]: couldn't exec /usr/syno/hotplug/usb.agent je ferais de plus gros tests un peu plus tard, et je ne crois pas que uvcvideo apporte un driver plus récent dans mon cas pwc: Philips webcam module version 10.0.13. par contre bien entendu pas de support uvc pour l'instant, je mets au chaud ces drivers là, et je vais re essayer pour le support de uvc dans la semaine.... ces drivers en test sont sur le même lien que d'habitude, /tests_x86 avec deux sections, /valide comme validé et /a_tester ceux là doivent d'abords etre tester avant de passer en validation et peuvent être buggés...... PS Sp@ro, je vais voir pour ajouter le support usb vers des lecteurs optiques DVD etc... je dois m'y atteler assez rapidement

pas exactement j'y tiens à mes autres modules étant the first user connu à avoir réussi à compiler des modules pour les syno en x86 à coup de patch... pan sur le nez des autochtones de diverses contrées et vive les ptits français mode chauvin off et vive the linux attitude je n'ai pas mis en ligne la partie multimedia du .config , car le mien ne ressemblait en rien aux vôtres et risquait plus d'embrouiller qu'autre chose. il n'y a la partie video, tun et nfs qui récalcitrent encore..... synology garde bien ces billes, je cherche quand un moment de dispo

v

salut sp@ro tu es pire que moi... prends des notes !! greugneugneu pour l'instant je suis oblig

ca roule et bien content pour toi ou ceux qui en aurons besoins, d'ailleurs sp@ro si tu veux faire un pacquage et mettre en ligne les trois fichiers, ils sont dans le lien que je t'avais envoyé ces derniers temps, sinon je le ferais le week end pour la partie vidéo échec complet et je ne vois pas de solutions pour l'instant, il doit y avoir un truc entre archi x86, le kernel 2.6.24 et les drivers que je ne trouve pas , il faut dire que certains drivers ne sont apparus que vers le kernel 2.6.30 et plus, et n'ont jamais été testé sur un kernel si ancien.....cqfd sans doute.. à termes je reviendrais sur le sujet en patchant avec des fichiers plus anciens et peut être que... PS : dollar(s) rapiat @++

bonjour, pour la led orange cela me le fait de temps

franchement inutile de poser la m

ouffff je commençais à avoir des doutes du coup bon bien content que ca roule pour les remerciements, direction le bar

okayyyy donne dollars maintenant, car le module s'auto détruit dans 58 ' 10........ 58' 9........ ca m'a l'air bon findhostd uses obsolete (PF_INET,SOCK_PACKET) pas de soucis c'est un message d'erreur qui date de longtemps, et je n'y suis pour rien... le reste je suppose que tu lance cette commande en connaissance de cause, et que tu en maitrise le retour ou du moins tu vas rechercher la raison de ce résultat perso comme d'hab je procède toujours par étape et pas à l'arrache. cat /proc/bus/usb/devices cat /proc/devices

mais on fais pleins de choses avec nos synos; m

salut je rajoute juste quelques trucs dans les sources le kernel est sem

salut, pour la question des tuners qui sont non désactivables, posées plus haut, cela m'a fait le coup également et parade trouvée. constat perso le kconfig situé dans drivers/media/common/tuners est mal paramétré. pourquoi ? le fichier .config final est généré en lisant les kconfig des diverses sections et doit être lancé à chaque nouveau patch pour inclure de nouvelles options qui seront ensuite proposées via make oldconfig puis make menuconfig. comment ? en modifiant le fichier kconfig de certains drivers, certaines sections de kconfig possèdent une option "default n" d'autres non et la logique actuelle du Kconfig pour tuner, impose sans choix possible désactivable dans menuconfig la validation de tous les tuners solution ? drivers/media/common/tuners/Kconfig modifiez la ligne 22 et l'option "default n" comme non sélectionné par défaut config MEDIA_TUNER ------->tristate -------> default n faire un make oldmenu éditez .config, hop magique l'option Config_media_tuner=m deviens #config_media_tuners is not set. dans le Kconfig c' étais cette option pré réglée, puis des ( if ) qui incluaient toute la cascade des tuners imposés, logiquement le .config est corrigé et cerise, les tuners ne sont plus activés par défaut... bref plus besoin de bricoler avec compat.h pour cette section là... il n'empêche que j'ai toujours un échec de compilation, avec ou sans patch, et cela ne touche que l'archi x86 à priori (vu le malheureux faible taux d'essais de compil concernant le reste des architectures) voir mon précédent post

fichier mct_u232.ko dispo au même endroit bref ce coup ci pas de script du tout, mais bel et bien insertion manuelle de usbserial.ko puis de mct_u232.ko comme décrit pas à pas au dessus. puis si aucune erreur via insmod, alors création du mknode, puis enfin tu plug ton matériel usb/série à brancher toujours dans le même port usb, sinon, tu vas avoir incrémentation du numéro de port série à chaque changement et comme re re re répété tu regarde dmesg pour être sur que le matériel est bien détecté au moment ou tu plug ton matos, et tu nous en donne l'extrait. ( perso c'est le seul truc qui m'importe en premier lieu pour que je puisse valider ces drivers et donc par conséquence valider aussi ma chaine de compil définitivement ) on verras pour le script après

impec avec tout ca je vais trouver facilement

bon pause ce soir d'ici demain regarde la syntaxe de dmesg, car cela est important, et surtout svp ne relance pas le script avant d'avoir une detection, confirm

salut tu as une station sous linux chez toi ?

concernant le fichier compat.h en éditant v4l1-compat.c on remarque dans la section include du début de fichier juste après #include <asm/pgtable.h> #include "compat.h" étrange cette option, cela ne correspond pas ni à un chemin absolu ni à un chemin relatif, ou alors il suffit de faire un ln -s dans le repertoire include vers compat.h ou comme j'ai décompressé l'archive de uvcvideo puis copié compat.h dans source/linux-2.6.24/include/media cela donne #include <media/compat.h> il me reste quand même des erreurs dans la compil drivers/media/video/v4l1-compat.c in function 'poll_one' (ligne 215).error: implicit declaration of function 'poll_shedule' d'où ma recherche d'une version git plus récente que celle que tu m'as filé.... dans mon cas il sagit d'une webcam logitech pro 4000, et donc si je ne m'abuse pas gérée par pwc

MP parti

bien pris cela concerne je suppose les h

idem que sp@ro tu nous fait quoi là ? j'ai l'impression que tu ne suis pas le conseil donné plus haut.. hors un conseil demande de l'effort à formuler, fais en autant ... cette impression est due au fait que d'une part, tu télécharge les deux fichiers sans trop savoir ou ils sont mis, puis comme tu es toujours dans le repertoire par défaut, tu charge manuellement les deux modules...... puis tu as une erreur ash, qui est sans plus d'explication de ta part, le résultât du lancement du script directement qui re essaye de charger usbserial et ftdi.....mais en les cherchant dans le mauvais endroit. hors la procédure décrite plus haut dis bien, surtout de lancer le script qu'à la fin. pour ce test on vas se passer du script alors re essayes comme cela tout en manuel , via ssh ou telnet , login=root pass=le même que celui de admin. 1) charger les deux modules manuellement via insmod, d'abord usbserial puis ftdi 2) création du fichier d'échange via mknode 3) plug du matériel usb/série 4) verification via dmesg que le matériel est bien détecte ce qui donne avec la création d'un repertoire de test

cramer du matos ? tu crois que je m'amuserai personnellement à faire des pré tests avant de te les envoyer au risque de cramer d'abord un 1010+ juste pour le plaisir d'aider une communauté d'utilisateurs sur du matos que je n'utilise pas perso ? .... les risques, tu les connais sur un système linux ou windows quand tu teste un driver .... le risque est le même que ceux qui utilisent des firmwares bêtas sur leurs syno, et il faut prendre les mêmes précautions, ce genre de chose devrait se faire sur un vieux dd de test, pour ne pas risquer de perdre de données sur les DD de production, du moins, jamais je ne fais de bêta test sur des DD ou j'ai des données vitales, certains prennent le risque, c'est leurs choix.... il peut arriver un plantage de mémoire tampon, donc reset ou dans le pire des cas, reboot hard, car le shell ne répondra plus, et même cela je l'ai testé comme dit plus haut jusqu'à un certain point seulement, je n'ai pas le matériel usb sinon tu penses bien que je me passerai de demander un test, et cela serait en ligne depuis belle lurette. bien entendu ce genre de test se fait intelligemment, c'est à dire surtout pas avec un script qui se lancera au boot pour pouvoir reprendre la main en cas de soucis imprévu, mais bel et bien via un script exécuté ponctuellement via telnet ou ssh en root et donc non lancé par rc.local ou rc.d, mais uniquement dans un premier temps pour voir si sur ton 710+ un insmod de usbserial puis de ftdi est correct, puis si la détection du matos usb/serie plugué est bien reconnu, puis que le prog cité plus haut ensuite fonctionne correctement sur x86, avec génération de trafic sur le port série et enfin si tout est fonctionnel, alors seulement, démarrer le chargement de ces modules au boot du syno pour qu'ils soient chargés en mémoire de façon permanente tel que désiré au départ. voili voila grosso merdo ce qu'il faut faire pour valider l'ensemble sur x86 bonne soirée, time to dodo

voir ta bo