Un article sur un site de matériel ( http://www.hardware.fr/news/9012/1-plantages-vista-5-dus-x-g(...) ) m'a appris que Windows Vista sait détecter et récupérer un plantage de la carte graphique ( au niveau pilotes ou matériel ). Vu la complexité croissante de cet élément périphérique, qui est passé en quelques années d'une zone mémoire à lire ou écrire à un ensemble de calcul complet (processeur indépendant plus mémoire), cette approche me semble importante : de même qu'on fait de la gestion d'erreurs dans un flux ethernet entre deux machines, pourquoi ne pas profiter de l'indépendance de X pour migrer les applications ouvertes vers une nouvelle instance.
Ma question à 2 balles :
- est-ce possible à l'heure actuelle? (De migrer une fenêtre d'un DISPLAY :0 vers :1 par exemple)
L'intérêt serait de faire un Ctrl+Alt+Backspace et de tout retrouver sans problème ;-)
Journal Comment mieux gérer les plantages de carte graphique
20
août
2007
# rediriger le DISPLAY
Posté par left . Évalué à 2.
[^] # Re: rediriger le DISPLAY
Posté par Bertrand Mathieu . Évalué à 4.
> apt-cache show teleport
[...]
Description: moves running applications between displays
Teleport allows some applications to be moved between X displays without
being closed and restarted. It uses X properties to request that applications
which support the display migration protocol move to another display.
Seul hic, il faut donc que l'application (généralement le toolkit sous-jacent: gtk, qt, ...) supporte ça. Personnellement sur Feisty je ne l'ai pas vu fonctionner (ayant 2 display: 0.0 et 0.1).
# xmove NOW !
Posté par jjl (site web personnel) . Évalué à 2.
Je connais xmove qui est sensé pouvoir faire cela.
En fait il s'agit d'un "proxy" Xwindow qui s'intercale entre ton appli et les "vraix" serveurs X. Tu as aussi un programme permettant de contrôler et déplacer les fenêtres (xmovectrl je crois)
J'ai un peu joué avec à un moment, j'avais même dvlp une petite appli graphique pour faire cela facilement. Ca marchait pas trop mal, mais j'ai vite abandonné à cause de bugs génants. (si je me souviens bien je n'arrivais pas à identifier les fenêtres des que j'en avait plus de deux, ce qui est gênant pour savoir laquelle déplacer)
Cela dit, mes tests étaient en ubuntu dapper cela a peut-être changé depuis. Mais ce n'est pas sur vu que le dev est arrêté.
[^] # Re: xmove NOW !
Posté par Aldoo . Évalué à 10.
En attendant, ça pourrait être aussi le boulot des distrib de proposer l'intégration de cette fonctionnalité en tant que proof of concept en attendant que ça se standardise (comme ça s'était fait chez Novel il y a un an et demi pour Xgl et Compiz, par exemple).
En tout cas ce serait un plus indéniable pour la distrib qui le fera en premier.
[^] # Re: xmove NOW !
Posté par Pinaraf . Évalué à 2.
Novell n'est pas à l'origine de Xgl et Compiz.
Sinon, pour les plantages, y'a des trucs qui rendent ça impossible ou presque :
1- les applis utilisant GLX ou XVideo (ou tout ce qui fait du rendu direct) : à mon avis Xmove marche pas pour ça et marcherait pas pour ça avant un bout de temps...
2- l'absence de gestion des modes de l'écran dans le noyau pour lui permettre de remettre la carte graphique dans un état potable avant de relancer X.
(Le deuxième problème est en cours de résolution, mais ça va prendre un certain temps...)
[^] # Re: xmove NOW !
Posté par Aldoo . Évalué à 2.
Pour le 2... moui, ce serait l'idéal. M'enfin, nombre de plantages n'imposent pas de réinitialiser la carte video pour relancer X. Et puis, après tout, pourquoi la réinitialisation ne se ferait-elle pas en userland ?
Bon, je n'y connais pas grand chose, à part la théorie, mais j'ai l'impression que le problème n'est pas tellement où ça se passe, mais plutôt ce qu'il faut faire exactement (quelles instructions, quels registres toucher ?).
[^] # Re: xmove NOW !
Posté par Pinaraf . Évalué à 2.
Sinon, pour GLX et XVideo, ça m'étonnerait que ça soit faisable. Il faudrait au minimum faire une sauvegarde de la mémoire vidéo utilisée par un programme, la restaurer de la bonne façon, s'occuper des shaders et de toutes les joyeusetés disponibles... Bref, truc bien lourd.
# Violence des plantages versus leur fréquence.
Posté par satan . Évalué à 4.
[^] # De l'intérêt des Magic system Request Key
Posté par Vincent (site web personnel) . Évalué à 8.
Ces commandes permettent de redemarrer un linux planté de façon clean.
Les Magic Keys requièrent l'emploi d'une combinaison de trois touches à la fois.
La touche "ALT" (à gauche de la barre d'espacement, à ne pas confondre avec la touche "ALT Gr"), la touche "SysRq" (System Request), cette touche n'est rien d'autre que la touche appelée et désignée par "Impr écran syst" (en haut à droite des touches F1 à F12), et enfin d'une troisième touche parmi les lettres suivantes :
* R : Raw Met le clavier en mode "raw" (brut). Essayez d'accéder à nouveau à votre clavier.
* S : Sync Synchronisation du disque. Essaie d'écrire toutes les données non sauvegardées.
* E : tErm SIGTERM. Envoie un signal de terminaison à tous les processus, sauf à init.
* I : kIll SIGKILL. Envoie un signal de fin à tous les processus, sauf à init.
* U : Umount Remonte tous les systèmes de fichiers en mode lecture seule. Empêche une vérification du système de fichiers au redémarrage
* B : reBoot Redémarre le système. Plus propre que l'appui sur "reset".
* O : Out Arrête le système.
* L : kilL SIGKILL. Envoie un signal de fin à tous les processus, y compris à init.
* K : Key Envoie un signal de fin à tous les processus de la console virtuelle courante.
* P : Print Affiche le contenu des registres et des drapeaux (flags) dans la console.
* M : Memory Affiche le contenu de la mémoire dans la console.
* T : Task Affiche le contenu des tâches en cours d'exécution et des informations qui les concernent.
* 0-9 : Number Paramètre le niveau de la console de log.
* H : Help Affiche une aide sur les codes touches.
[^] # Re: De l'intérêt des Magic system Request Key
Posté par abramov_MS . Évalué à 2.
[^] # Re: De l'intérêt des Magic system Request Key
Posté par z a . Évalué à 3.
[^] # Re: De l'intérêt des Magic system Request Key
Posté par Olivier Serve (site web personnel) . Évalué à 2.
[^] # Re: De l'intérêt des Magic system Request Key
Posté par Omnisilver . Évalué à 2.
Et je les connais bien : http://forum.ubuntu-fr.org/viewtopic.php?id=12149 (sujet similaire au tien mais moins complet)
[^] # Re: De l'intérêt des Magic system Request Key
Posté par Olivier Serve (site web personnel) . Évalué à 4.
Ça permet 'facilement' de savoir si c'est X qui est planté et 'bloque' le clavier ou bien si c'est vraiment le kernel qui déconne.
[^] # Re: De l'intérêt des Magic system Request Key
Posté par Aldoo . Évalué à 2.
[^] # Re: De l'intérêt des Magic system Request Key
Posté par inico (site web personnel) . Évalué à 1.
Au motif de l'userfriendly.
Hum ...
[^] # Re: De l'intérêt des Magic system Request Key
Posté par dinomasque . Évalué à 2.
Je n'ai pas d'avis sur le sujet, mais si les développeurs du noyeau me disent de bien faire attention avant d'activer une option du noyeau et de ne le faire que si je suis sur de moi, je préfère m'abstenir.
BeOS le faisait il y a 20 ans !
[^] # Re: De l'intérêt des Magic system Request Key
Posté par inico (site web personnel) . Évalué à 2.
Ce n'est effectivement pas définis par default.
Mais il n'y a rien de vraiment dangereux avec cette option.
il faut juste eviter de l'activer sur une machine en libre accés.
[^] # Re: De l'intérêt des Magic system Request Key
Posté par khivapia . Évalué à 2.
sans rire, ces touches posent un gros problème de sécurité quand la machine est d'accès semi-public, parce qu'en gros n'importe qui peut alors faire un DoS local.
Mandriva, dans les petits livrets qui accompagn(ai)ent les boîtes indiquait, comme tout constructeur de matériel, une petite procédure à suivre en cas de panne, et les Magic Keys en faisaient partie (un peu comme "l'appareil ne s'allume pas -> vérifiez qu'il est bien branché").
C'était amusant (mes premiers pas sous Linux... souvenirs, souvenirs...), ça donnait vraiment l'impression que ça doit marcher comme le matériel, c'est à dire sans problèmes récurrents et out of the box !
[^] # Re: De l'intérêt des Magic system Request Key
Posté par Batchyx . Évalué à 2.
[^] # Re: De l'intérêt des Magic system Request Key
Posté par PoFMaN . Évalué à 1.
Le must à mon avis reste quand même d'inverser la souris et le clavier (quand ils sont tous les deux en PS2, ce qui est de plus en plus rare)
[^] # Re: De l'intérêt des Magic system Request Key
Posté par eMerzh (site web personnel) . Évalué à 3.
[^] # Re: De l'intérêt des Magic system Request Key
Posté par Dr BG . Évalué à 3.
[^] # Re: De l'intérêt des Magic system Request Key
Posté par PoFMaN . Évalué à 1.
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Alexandre (site web personnel) . Évalué à 2.
Toi aussi, vote non aux souris de base dell qui prennent un port USB pour rien, alors qu'elles méritent à peine un port ps2.
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je suis pour le clavier et la souris USB, cela simplifie la machine qui ne parle que USB et plus le PS2. Je ne vois pas l'intérêt du PS2 alors que l'USB fait la même chose. C'est même moins cher de ne faire que de l'USB car tu n'as qu'un jeu de composant électronique et qu'une pile logiciel (USB) à gérer.
Bref, vive l'USB, je trouve que DELL à raison d'avoir supprimer le PS2.
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Guillaume Knispel . Évalué à 2.
Pas besoins de "pile" logicielle. Il suffit d'envoyer des octets sur un port et de faire 2/3 configs sur un autre.
"parler" l'usb est beaucoup, beaucoup plus compliqué.
Maintenant qu'il est si répandu, c'est pas trop un problème. Mais devans la simplicité du PS2 ca ne me choque pas du tout d'en voir persister.
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Batchyx . Évalué à 2.
Avec tout les problèmes que pose l'USB sous windows (drivers des contrôleurs foireux) et sous linux (lorsque l'implémentation acpi est buggé), sans compter les ''mon matériel n'est reconnu qu'une fois sur deux'' (qui ont plus l'air d'être des problèmes d'électronique), les ''erreur : vos ports USB ne peuvent pas fournir plus de courant, débranchez des périphériques'' ...
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par briaeros007 . Évalué à 2.
Chez moi, tout ces périphériques sont rapides.
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Batchyx . Évalué à 2.
Dans la spécification de l'USB 1.1 il était explicitement indiqué que cette norme à pour but de simplifier la vie à l'utilisateur et que pour que ça soit efficace il faut que ça soit massivement utilisé (dommage la spec n'est plus en ligne, mais ça devait être ça en gros)
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par briaeros007 . Évalué à 2.
Pour le dd, pour du stockage on peut le ralentir, pour le système l'utilisateur va rler a nouveau ;)
Je suis d'accord que le but de l'usb est bien de simplifier la vie et qu'en ce sens il est très bien.
Mais pour des dd externes, rien ne vaut l'esata, pour les écrans du dvi/hdmi/displayport/ ...
Dire qu'il y a 10 ans, tu brancher juste l'écran au secteur et l'uc (qui avait le clavier) à l'écran et voila ca marcher:D
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Cela n'empêche qu'avoir tous les composants en USB simplifie pas mal les choses. On peut brancher sa souris sur un hub USB...
En pratique, cela signifie 2 prises USB de plus à l'arrière du PC et non deux prises USB de moins. Voila pourquoi je n'étais pas d'accord avec le premier argumentaire.
Au niveau matériel, même si le PS2 est trivial, il faut continuer à avoir des périphériques parlant le PS2. Alors qu'avec l'effet de volume, avoir un composant parlant USB n'est pas beaucoup plus cher et permet d'unifier tout cela.
C'est comme ethernet comme bus rapide qui est en train de bouffer petit à petit les autres. Je trouve cela bien. Cela limite le nombre de câble. Par exemple, on a pour le stockage l'iSCSI ou le PoE et de plus en plus de caméra rapide sont connecté en ethernet et plus en firewire. Ne plus avoir de câble SCSI ne me dérange pas, au contraire. Avoir du RJ45 à la place du firewire non plus.
Cette simplification me semble une bonne chose.
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par briaeros007 . Évalué à 2.
Et pas l'AoE ?
qui est quand meme bien plus simple que l'iscsi et bien moins cher a mettre en place.
(par contre pas routable, donc répond pas forcément aux meme problématiques).
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par inico (site web personnel) . Évalué à 3.
Alors qu'en PS/2, ca passe vraiment dans n'importe quelle situation (du moment que Bios et la CM sont intactes).
Par contre, pourquoi retrouve-t-on encore de l'ISA sur des cartes mére pour AMD64 ?
Qu'est-ce qui tourne uniquement en ISA et qui impose ce bridge PCI->ISA ?
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Cela fait des années que je n'est pas booté en single user.
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par inico (site web personnel) . Évalué à 2.
Il y a un module qui fait oopser le kernel et je dois à chaque fois l'effacer de /lib/modules (le blacklistage ne fonctionne pas :-( ).
* D'ailleur il y en a une là.
/me prepare le clavier ps/2 ...
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Nicolas Schoonbroodt . Évalué à 4.
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par inico (site web personnel) . Évalué à 2.
Mais comme je l'ai evoqué dans le message précedant, je l'ai fait (même si je garde le clavier ps/2 à porté parce qu'il va forcement y avoir un pb ...).
[^] # Re: De l'intérêt des souris qui squatent les ports usb
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.