TheBreton a écrit 928 commentaires

en fait le pb dans une liaison domotique c'est comme de bien entendu le nombre de cable a tirer depuis ton centrale et chacun de tes noeuds(une noeud= un capteur(entree) ou un actionneur(sortie)) ainsi que dans la grande multiplicité du type de noeud(relais, thryristor,interrupteur,moteur....).
Pour simplifier le passage des cables on prefere utiliser un BUS DE TERRAIN qui assure une liaison sur deux ou trois fil et tous le monde ce connecte dessus en general il sont du style un maitre/plusieurs esclaves) dans les protocole utiliser dans l'industrie on peut siter LIN,LONWORK,ECHELON,CAN,VAN,ETHERNET, COURANT PORTEUR.
Les distances attends par ces bus peuvent atteindre plusieurs kilometre a bas debit et quelques metres au mega-bits.
La techno des courants porteurs est la plus interessante en terme de cablage car utilise l'installation electrique existante dans la maison pour supperposer la communication sur l'alimentation des appareils mais demande au dela de 4800bds de debit une analyse de spectre compliqué en dessous de 4800bds on trouve des schema simple sur internet de modems courant-porteur.
Voila , j'espere que ces quelques mots te donneront de nouvelle piste pour ton projets.

(les MOTS EN MAJUSCULE representent des mots clef a utiliser sur google pour avoir plus d'info)

sous red hat 8 je ne sait pas la version du kernel ni si la gestion des clef usb en mass storage est presente dans le kernel que t'utilise.
Normalement quand tu branche ta clef tu doit trouver des infos un peut partout si le systeme la detecte bien.
un "dmesg |less" et regarde les dernieres lignes si tu voit des truc sur l'usb qui aurait detecte un branchement ou quelque chose comme ca.
un petit "lsusb -v" te montrera la config usb de ton pc.
Mais globalement je suis dubbitatif devant le fait que vmware emulerait aussi parfaitement un pc pour te donner plein acces au ressource materiel...(en clair j'ai du mal a croire que ce que tu veut faire soit possible).
Par contre VMware te donne peut etre acces au disque dur present sous windows non auqeul cas tu pourrait acceder a ta clef comme ca?

le flash disk se presente sous quel forme ?
PCMCIA/CF/IDE.....?
si l'interface est standard et qu'il integre un gestionnaire de type IDE ou SCSI c'est ce gestionnaire qui ferras le travail de gestion de ca flash en lecture ecriture donc un simple mkfs,mount et voila.

je me demande si ce n'est pas parce la mise en blockquote detruit la tabulation ou si les sources du kernels sont correctement installe sur ton poste ? essaie ca en respectant les tabulations:

 
ifneq ($(KERNELRELEASE),)
obj-m	:= usbdrv.o
usbdrv-objs := localdrv.o
else
   KDIR	:= /lib/modules/$(shell uname -r)/build
   PWD	:= $(shell pwd)
default:
	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
endif

sinon une lecture interessante pour commencer : http://lwn.net/Kernel/LDD3/(...) voir le chapitre 2 merci a Christophe Lucas qui as fait un journal pour signaler la sortie de ce tres bon bouquin

mais normalement voyant un .o absent le makefile doit chercher le .c correspondant pour le compiler.
quel message t'envoie le make ?
le makefile doit etre utiliser dans le repertoire de tes sources

Ok, pour les 2.6 on ne peut plus compiler un module a la main.
Voici un makefile type pour compilation sur la serie 2.6

ifneq ($(KERNELRELEASE),)
obj-m := usbdrv.ko
usbdrv-objs := localdrv.o
else
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
endif

cela cree a partir d'un fichier localdrv.o un module usbdrv.ko que tu installe par insmod usbdrv.ko dans le kernel.
(j'espere ne pas avoir fais d'erreur car je tape de tete, je suis au taf et n'ai pas mes sources sous la main)

pour quel version de kernel tu compile?
Quel est ton makefile pour compiler ton fichier ?
Sache que si tu travaille a partir d'un tutoriel trouvé sur le net que la compilation des modules du 2.4 au 2.6 a completement changé.
Au temps du 2.4 il y avait un makefile specifique a chaque projet
Maintenant au temps du 2.6 il faut utiliser LE makefile du kernel en lui donnant le repertoire du projet comme source de compilation.
Bref, donne plus d'info et tu auras en retour des infos plus precise.

et en installant grub sur une disquette ?
grub-install /dev/fd0
(je dis ca de tete)
mais comme ca tu pourrais toute de suite rebooter ton linux et faisant un grub-install /dev/hdaX tu remettrairs grub sur ton mbr.

Si c'est uniquement un informaticien il est mort.
Sinon, il ouvre l'ordi, repere le composant EEPROM ou flash contenant le code apellé par le proc sur reception du signal RESET. Il arrache ce composant, et en appliquant des niveaux electrique sur les pattes de la bete (adresse et donné, il doit y arriver avec l'alim du PC +5V et +12V) il commence a coder un basic input output system (bios) qui gere le clavier et l'ecran de sa machine (au minimum). Il y code un VI de base, un editeur Hex de disque dur ou de floppy puis roule.
Ensuite il commence a coder un MBR, un Lilo, un kernel, un X... et ainsi de suite.
Prevoit pas mal de pizza et de coca ainsi q'une prise reseau internet pour lui donner de l'espoir ....

la norme specifie effectivement certaine broches du connecteur (surtout K CAN et alim) mais pas toute. Du coup on retrouve quelque fois sur les broches non utilisés les reseaux autres que bloc-moteur(mais sur chaque vehicule ca change). chez PSa en general il faut debrancher le calculo BSI pour repiquer les resaux VAN pour faire de l'observation sur le bus.

oui il existe deux norme (la 1 et la 2) qui ont pour nom OBD et qui caracterise
1) le brochage de cette prise (et sont emplacement dans la voiture)
2) un certain nombre de trame (surtout anti-pollution) qui doivent etre implenter dans le reseau.
Il existe plusieurs normes de DIAG auto, mais aujourd'hui le terme DIAG sert surtout a nommer le reseau ISO9141(KWP2000).
On peut observer les reseaux CAN et VAN( mais VAN c'est uniquement vehicule PSA et encore c'est un protocole en fin de vie) pour voir passer des infos tres diverses (vitesse, km fait, km avant vidange, tour moteur.....) mais chaque vehicule dispose de sa propre mise en forme des informations.
Bien qu'actuellement l'europe reflechisse a une loi qui imposerait de communiquer ces format a tous le monde on se retrouve aujourd'hui dans l'impossibilité de faire soit meme ca vidange sur certaine voiture (apres un nombre de km trop important depuis la derniere vidange ces voiture bloque le demarrage sous pretexte de ne pas abimer le moteur) on est obliger de passer par un representant de la marque pour remettre a 0 un compteur dans un calculo.
Il existe une boite francaise qui bosse uniquement sur ce sujet mais je ne crois pas qu'il fasse de truc sous linux.
tu peut toujours faire un tour sur www.nsi.fr

Tu pourrais peut etre poster les logs ou alors les mettres sur le site gna ?

Le voila

Section "Monitor"
Identifier "monitor1"
VendorName "Plug'n Play"
ModelName "Sony CPD-100SX"
HorizSync 30.0-65.0
VertRefresh 50.0-120.0

# Sony Vaio C1(X,XS,VE,VN)?
# 1024x480 @ 85.6 Hz, 48 kHz hsync
ModeLine "1024x480" 65.00 1024 1032 1176 1344 480 488 494 563 -hsync -vsync

# TV fullscreen mode or DVD fullscreen output.
# 768x576 @ 79 Hz, 50 kHz hsync
ModeLine "768x576" 50.00 768 832 846 1000 576 590 595 630

# 768x576 @ 100 Hz, 61.6 kHz hsync
ModeLine "768x576" 63.07 768 800 960 1024 576 578 590 616
EndSection

Section "Monitor"
Identifier "tv"
HorizSync 30.0-50.0
VertRefresh 50.0-60.0
EndSection

Section "Device"
Identifier "nvidia0"
VendorName "nVidia Corporation"
BusID "PCI:1:0:0"
BoardName "NVIDIA GeForce2 DDR (generic)"
Driver "nvidia"
Screen 0
#Option "DPMS"
Option "nologo" "1"
Option "CursorShadow" "1"
#Option "SecondMonitorHorizSync" "30-50"
#Option "SecondMonitorVertRefresh" "60"
#Option "Metamodes" "1024x768, 800x600"
Option "ConnectedMonitor" "CRT"
#Option "TVStandard" "PAL-N"
EndSection

Section "Device"
Identifier "nvidia1"
Driver "nvidia"
BusID "PCI:1:0:0"
Screen 1
Option "nologo" "1"
Option "CursorShadow" "1"
Option "ConnectedMonitor" "TV"
#Option "TVStandard" "PAL-N"
EndSection

Section "Screen"
Identifier "screen1"
Device "nvidia1"
Monitor "tv"
Option "TVStandard" "PAL-N"
Option "ConnectedMonitor" "TV"
Option "TVOutFormat" "Composite"
DefaultColorDepth 24
Subsection "Display"
Modes "800x600" "Interlace"
Depth 24
EndSubsection
EndSection


Section "Screen"
Identifier "screen0"
Device "nvidia0"
Monitor "monitor1"
DefaultColorDepth 24

Subsection "Display"
Depth 8
Virtual 1024 768
EndSubsection

Subsection "Display"
Depth 15
Virtual 1024 768
EndSubsection

Subsection "Display"
Depth 16
Virtual 1024 768
EndSubsection

Subsection "Display"
Depth 24
Virtual 1024 768
EndSubsection
EndSection

Section "ServerLayout"
Identifier "layout0"
InputDevice "Keyboard1" "CoreKeyboard"
InputDevice "Mouse1" "CorePointer"
Screen 0 "screen0"
Screen 1 "screen1" Above "screen0"
EndSection

bon les grand moyens.
tu recupere les sources de bttv-0.9.15 que tu decompress dans un repertoire en etant root.
dans le fichier
bttv-cards.c l
ligne 34, passe les 3 ligne en commentaitre

//#ifdef CONFIG_FW_LOADER
//# include <linux/firmware.h>
//#endif
et ajoute
#ifdef CONFIG_FW_LOADER
#undef CONFIG_FW_LOADER
#endif

fais dans ce repertoire un coup de make
tu doit recuperer un .ko
modprobe ce .ko et qu'est ce qui ce passe ?

la question est comment est configuré ton kernel.
Si tu as 'Y' dans la configuration de hotplug lorsque tu as recompilé ton kernel alors le module utilise hotplug.
(CONFIG_FW_LOADER)
si tu mets 'N' et que tu recompile le tout le modules utilise l'acienne maniere de faire et va chercher " /usr/lib/video4linux/hcwamc.rbf"
pour charger le firmware (ou ce que tu defini par la ligne de commande)

Maintenant, de là à fournir le source du firmware en question...
ce n'est pas tellement ce que les modifications dans le kernel cherche a induire. Que le micro de la carte PVR ait besoin de code bin ou de source recompiler avec le kernel n'est pas la question. Cette modification (supression de toute trace de firmware proprio dans le kernel) est motivé par la volonté d'avoir un kernel 100% libre (pas de trace de code qui un jour pourrait poser pb de license)...le pb de propriété/license du firmware est transféré a l'utilisateur qui achete un matériel.

il faut bien sur lire
/usr/lib/hotplug/firmware/hcwamc.rbf

Apres avoir lu les sources de bttv voici ce que je peut en dire.
Avant on liait simplement les firmware dans les drivers mais ce n'est pas bien on ne doit plus le faire(pas de code non source dans le kernel il a dis mrs linus) voir affaire avec la webcam philips par exemple.
Le fichier que bttv cherche a charger doit etre maintenant

/lib/hotplug/firmware/hcwamc.rbf

(voir ici un exemple http://at76c503a.berlios.de/fw_dl.html(...))

suis au taf' je poste mon xf86config demain

et chez moi tout va bien. Le site est Up

que ceux qui ont eut le dvd en cadox de noel comprenne....
pour repondre a la question c'est tout a fait possible d'avoir en lancant une seule session X un affichage different sur la TV et sur le moniteur (il ne s'agit pas de deux session differente sur laquel on switch avec F8 et F8).
Par contre ca marche sur les Nvidia pour l'avoir fait (fonctionnement TwinView), mais sur les ATi pas la moindre idée....

n'attend pas de reponse precise

va voir la l'histoire d'un gars qui la fait
http://hardware.mcse.ms/message110936.html(...)

et la pour voir comment faire pour une gc75 (mais ce doit globalement faire pareil pour la gc79)
http://www.internecik.com/?p1=howto&a1=se_gc75linux(...)

globalement une fois le module pcmcia activé dans le kernel la carte ce comporte comme un modem standard repondant au commande AT&T

mais voici quelques elements de réponses.
Il se trouve que ces drivers ne sont compatible qu'avec une version 2.4.20. Nous avons tenté de le mettre sur des versions de kernel plus récentes mais sans succès (2.6 out, 2.4.26 out).
par curiosité, les drivers sont sous quelles forme ? binaire pure ?

Ce qui faut tenir compte pour les pb de drivers:
Le kernel est en version 2.6 et le developpeur travaille dessus, le materiel récent (ou pas encore porté sur Linux) est/sera donc en écriture pour le 2.6, il n'y as pas (ou a de rare exeception) de portage de nouveau materiel pour le 2.4.x, le 2.4.x est maintenu (correction de bug) et c'est tout.

Il est possible moyennant quelques efforts pour vous de faire du downgrade de drivers plus recent (SATA, nouveau matos) pour la version de kernel 2.4.x (c'est en cela une grande force de l'open source,recuperez des sources du 2.6 puis les retoucher pour en faire du 2.4) (mais c'est peut etre plus simple de passer par un prestataire externe specialisez la dedans...)

J'ai souvenir que sous Unix, on pouvait au moment du boot d'installation spécifier l'utilisation de drivers spécifiques, via un support externe. Cela permettait par exemple de supporter des cartes ou des disques scsi qui n'étaient pas pris en charge par dans le noyau par défaut ... Est ce que c'est possible sous GNU/Linux ?
Oui, au moment de l'install (selon la distrib) on demande si le support de 'third party software' doit etre activé, si on repond oui alors la distrib demande une disquette contenant les modules a chargé (et les param a utiliser)

Et ou peut on se procurer ces fameux drivers
meme reponse qu'au dessus, soit ils existent, soit ils faut les creer

Je suis désolé de ne pas pouvoir repondre plus precisément mais j'espere que ces éléments vous permettrons de vous y retrouver

une nouvelle boite en bas pour poster un commentaire...
bon, pour ta question
-note : les .o sont des modules pour kernel 2.2,2.4 si tu est en 2.6 il te vaut un .ko

pour les jpgl_findHeader et autres, c'est un probleme qui a ete discuté ici
http://linuxprocess.free.fr/MHonArc/May-2004/threads.html#00000(...)

[lpdiscuss] Re: Portage kernel2.4 / kernel 2.6
[lpdiscuss] nw802 (suite),

avec la soluction a apporter. Je te souhaite une bonne lecture

le driver vesa implemente la norme vesa qui donne acces a la memoire video et c'est tout.
Pour obtenir l'acceleration materiel il faut que tu utilise le driver specifique a ta carte, qui par exemple pour bouger une zone rectangulaire de l'ecran va envoyer les bonnes commandes au processeur graphique de ta carte (GPU) pour que le lui fasse le boulot. Le drivers VESA ferait la meme operation mais avec le CPU en copiant la memoire graphique vers ta ram, fait l'operation, copie la ram vers la memoire graphique.(Plus d'operation donc au final plus lent).
Il faut plus se pencher sur les crash de X avec le drivers qui est prevue pour ta carte si tu veux.
Lance X, laisse le planter puis regarde les messages dans le fichier
X***.log situe dans /var/log/