Donc effectivement si personne n'utilise cette place memoire un programme s'executant en user=root peut faire un mmap sur une zone libre
voir l'exemple ici
je ne vois pas trop exactement ce que tu veux faire et ne pas faire.
Pour autant que je me rapelle il existe plusieurs facon dans la ligne de commande du kernel de lui dire de ne pas acceder a une zone memoire (ISA hole) par exemple ou reserver la zone memoire acessible (lui dire d'acceder 128MO meme si 512Mo sont present sur la machine).
MAIS (le voila) tout ceci servait a l'epoque de l'ISA (et de la gestion des 16 permier Mo de la memoire) a adresser des cartes ISA directement par adresse. Tout ceci n'est PAS utilisable avec des cartes PCI.
Une appli standard ne peut pas acceder a une zone memoire de sont choix sans passer par une passerelle situer dans le kernel.
En clair ton peripherique c'est quoi ? car il est tout a fait possible qu'une tel techno soit existante dans le kernel et qu'il te faille juste savoir comment la declencher ?
a l'heure actuel c'est une technologie en cours d'echantillonage dans des tailles de 16Mb (soit 2Mo) par boitier (depuis juin dernier voir infineon, en 4Mb pour motorola). Autant dire que l'on est tres loin dans le rapport (taille,cout)/(densite) d'un disque dur.
Les premiers composants valident les resultat attendue , mais leur SOP (start of production) est planifié pour 2010. Avant de trouver une densité d'inter-connexion suffisante pour tenir dans un boitier taille 3p1/2 il faudra attendre encore. En terme de debit ca devrait mathematiquement exploser les performances des ordinateurs de leur epoque (bande d'acces mémoire superieurs d'un facteur 10 au memoire DRAM actuel) tout en assurant le stockage permanent des infos (disque dur) SAUF qu'as l'heure actuel le bus processeur n'est bon qu'as gere la bande passante que pour de la memoire dynamique (en clair les Ix86 serait jete a la poubelle pour passer sur des PPC).
Dans une si lointaine perspective (p.d.v. evolutation informatique de table) cela reste du stade conjoncture et l'embarque (telephone portable..etc.. devrait en beneficier dans de proches annees)
plus d'info sur l'annonce ici http://www.infineon.com/cgi/ecrm.dll/jsp/showfrontend.do?lang=EN&am(...)
>combien ça va pouvoir coûter ?
sans doute un max de brouzouf...c'est du matos de pro > Est-ce que 2 millions de cycles c'est suffisant ou pas
c'est un nombre de cycle en ecriture @25°C, en lecture en general on a des temps de retentions d'info de l'ordre de 10ans.
Sur ce genre de matos evite de mettre une bdd, du swap ou autre joyeuseté.
La bonne solution pour un mini system c'est de tourner en RAM pour tous ce qui est ecriture et de sauver les fichiers sur le support a l'extinction du systeme.
>J'en veux un !!!
si le bruit te gene et que tu est pres a mettre 300euros dans un disque dur 2Go regarde du coté des compacts flash+adaptateur IDE et d'investir dans de la RAM, tu peut facilement mettre un linux dessus et sauver tes user-data. Tu peux coupler avec un disque dur dont tu commande la mise sous tension pour swapper les fichiers a backup de second niveau (ou les appli rarement utiliser).
La croissance de densitée des flash ne rattrape pas encore les disques dur, mais tu commence a pouvoir monté des OS complets (encore une fois tous les fichiers de log, et les fichiers souvent acceder en ecriture doivent etre dans la ram systeme) permette des petit poste sympa en basse conso.
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:
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
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
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.
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
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....
[^] # Re: gni?
Posté par TheBreton . En réponse au message dev/mem mémoire physique. Évalué à 2.
voir l'exemple ici
http://www.tldp.org/LDP/khg/HyperNews/get/devices/fake.html(...)
# gni?
Posté par TheBreton . En réponse au message dev/mem mémoire physique. Évalué à 2.
Pour autant que je me rapelle il existe plusieurs facon dans la ligne de commande du kernel de lui dire de ne pas acceder a une zone memoire (ISA hole) par exemple ou reserver la zone memoire acessible (lui dire d'acceder 128MO meme si 512Mo sont present sur la machine).
MAIS (le voila) tout ceci servait a l'epoque de l'ISA (et de la gestion des 16 permier Mo de la memoire) a adresser des cartes ISA directement par adresse. Tout ceci n'est PAS utilisable avec des cartes PCI.
Une appli standard ne peut pas acceder a une zone memoire de sont choix sans passer par une passerelle situer dans le kernel.
En clair ton peripherique c'est quoi ? car il est tout a fait possible qu'une tel techno soit existante dans le kernel et qu'il te faille juste savoir comment la declencher ?
[^] # Re: on peut toujours rever...
Posté par TheBreton . En réponse au journal Disque dur état solide. Évalué à 10.
Les premiers composants valident les resultat attendue , mais leur SOP (start of production) est planifié pour 2010. Avant de trouver une densité d'inter-connexion suffisante pour tenir dans un boitier taille 3p1/2 il faudra attendre encore. En terme de debit ca devrait mathematiquement exploser les performances des ordinateurs de leur epoque (bande d'acces mémoire superieurs d'un facteur 10 au memoire DRAM actuel) tout en assurant le stockage permanent des infos (disque dur) SAUF qu'as l'heure actuel le bus processeur n'est bon qu'as gere la bande passante que pour de la memoire dynamique (en clair les Ix86 serait jete a la poubelle pour passer sur des PPC).
Dans une si lointaine perspective (p.d.v. evolutation informatique de table) cela reste du stade conjoncture et l'embarque (telephone portable..etc.. devrait en beneficier dans de proches annees)
plus d'info sur l'annonce ici
http://www.infineon.com/cgi/ecrm.dll/jsp/showfrontend.do?lang=EN&am(...)
# on peut toujours rever...
Posté par TheBreton . En réponse au journal Disque dur état solide. Évalué à 6.
sans doute un max de brouzouf...c'est du matos de pro
> Est-ce que 2 millions de cycles c'est suffisant ou pas
c'est un nombre de cycle en ecriture @25°C, en lecture en general on a des temps de retentions d'info de l'ordre de 10ans.
Sur ce genre de matos evite de mettre une bdd, du swap ou autre joyeuseté.
La bonne solution pour un mini system c'est de tourner en RAM pour tous ce qui est ecriture et de sauver les fichiers sur le support a l'extinction du systeme.
>J'en veux un !!!
si le bruit te gene et que tu est pres a mettre 300euros dans un disque dur 2Go regarde du coté des compacts flash+adaptateur IDE et d'investir dans de la RAM, tu peut facilement mettre un linux dessus et sauver tes user-data. Tu peux coupler avec un disque dur dont tu commande la mise sous tension pour swapper les fichiers a backup de second niveau (ou les appli rarement utiliser).
La croissance de densitée des flash ne rattrape pas encore les disques dur, mais tu commence a pouvoir monté des OS complets (encore une fois tous les fichiers de log, et les fichiers souvent acceder en ecriture doivent etre dans la ram systeme) permette des petit poste sympa en basse conso.
# mes 2cts
Posté par TheBreton . En réponse au message Linux et la domotique... Évalué à 4.
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)
# mes 2 cts
Posté par TheBreton . En réponse au message clef usb sur red hat via vmware. Évalué à 1.
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?
# interface ?
Posté par TheBreton . En réponse au message Linux et les flash disques. Évalué à 1.
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.
[^] # Re: plus d'info please
Posté par TheBreton . En réponse au message Compilation du usb-skeleton.c. Évalué à 1.
[^] # Re: plus d'info please
Posté par TheBreton . En réponse au message Compilation du usb-skeleton.c. Évalué à 1.
quel message t'envoie le make ?
le makefile doit etre utiliser dans le repertoire de tes sources
[^] # Re: plus d'info please
Posté par TheBreton . En réponse au message Compilation du usb-skeleton.c. Évalué à 2.
Voici un makefile type pour compilation sur la serie 2.6
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)
# plus d'info please
Posté par TheBreton . En réponse au message Compilation du usb-skeleton.c. Évalué à 2.
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.
# floppy
Posté par TheBreton . En réponse au message Créer une disquette d'amorçage et restaurer Grub. Évalué à 1.
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.
# boot time
Posté par TheBreton . En réponse au journal L'oeuf ou la poule ?. Évalué à 10.
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 ....
[^] # Re: OBD etait sont nom...
Posté par TheBreton . En réponse au journal Prise DIAG, réseaux CAN, VAN, .... Évalué à 2.
# OBD etait sont nom...
Posté par TheBreton . En réponse au journal Prise DIAG, réseaux CAN, VAN, .... Évalué à 3.
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
[^] # Re: :(
Posté par TheBreton . En réponse au message Scanner Canoscan 5000F et Mandrake 10.1. Évalué à 1.
[^] # Re: j'y crois car c'est le jeux de la vie...
Posté par TheBreton . En réponse au message un X sur le moniteur, et un X sur la TV. Évalué à 2.
[^] # Re: s/bttv/ivtv/ ?
Posté par TheBreton . En réponse au message bttv & Firmware dans le kernel 2.6.10. Évalué à 1.
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
fais dans ce repertoire un coup de make
tu doit recuperer un .ko
modprobe ce .ko et qu'est ce qui ce passe ?
[^] # Re: s/bttv/ivtv/ ?
Posté par TheBreton . En réponse au message bttv & Firmware dans le kernel 2.6.10. Évalué à 1.
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)
[^] # Re: s/bttv/ivtv/ ?
Posté par TheBreton . En réponse au message bttv & Firmware dans le kernel 2.6.10. Évalué à 1.
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.
[^] # aie pas la tete
Posté par TheBreton . En réponse au message bttv & Firmware dans le kernel 2.6.10. Évalué à 1.
/usr/lib/hotplug/firmware/hcwamc.rbf
[^] # Re: s/bttv/ivtv/ ?
Posté par TheBreton . En réponse au message bttv & Firmware dans le kernel 2.6.10. Évalué à 1.
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(...))
[^] # Re: j'y crois car c'est le jeux de la vie...
Posté par TheBreton . En réponse au message un X sur le moniteur, et un X sur la TV. Évalué à 1.
# 10h20
Posté par TheBreton . En réponse au journal gentoo-stats hacké ?. Évalué à -1.
# j'y crois car c'est le jeux de la vie...
Posté par TheBreton . En réponse au message un X sur le moniteur, et un X sur la TV. Évalué à 1.
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....