mais sous windows lorsque le driver de la carte graphique part en couille il ne se passe rien de spécial
Ca dépend beaucoup de comment le driver part en couille, et de pourquoi.
Grosso modo on peut définir trois grands cas :
Le pilote se vautre tout seul comme un grand, il y a un bug quelconque dans le pilote, il envoie une série de commande à la carte graphique, la carte graphique répond "beurk", mais reste dans un état parfaitement valable et initialisé, l'application qui est à l'origine de la série de commande fautive se prend une notification d'erreur et suivant les cas réessaye, se vautre ou se ferme proprement. Sous Linux si c'est X11 l'application fautive il va y avoir une série de lignes dans le log et peut-être une fenêtre qui n'aura plus de père. Sous Windows si c'est explorer desktop, il va gentiment mémoriser les fenêtres et les params, se fermer et se relancer. Pas de clignotement écran dans ce cas là, juste la fermeture et la réouverture de la barre des taches et de certaines infobulle et autres icônes de notifications
La carte graphique envoie une réponse qui n'a rien à voir avec ce qui a été demandé. Défaut du pilote ou de la carte, difficile à savoir sans mettre les mains dans le cambouis, toujours est-il qu'il y a un problème. Soit l'erreur est minime et on ferme l'appli, soit l'erreur est plus grave et on tente le double context switch à la sauce windows :
1 - On passe la carte graphique dans un mode non accéléré, éventuellement avec une résolution moindre. (l'écran s'éteint et se rallume)
2 - On valide qu'en mode non accéléré le système graphique repart bien (généralement c'est le cas)
3 - On décharge tout ou partie du pilote de la carte graphique (c'est la partie que Linux ne sait pas faire, X11 peut mais l'archi au niveau kernel ne suit pas)
4 - On recharge un pilote propre et on réinitialise la carte graphique (l'écran s'éteint)
5 - On repasse en mode graphique précédent avec accélération (l'écran se rallume dans).
Parfois il y a des étapes en plus, notamment si il faut décharger tout le pilote, pas juste la partie accélération (comme dans une mise à jour) dans ce cas windows Vista/7 vont passer par un pilote de compatibilité ce qui peut pousser le nombre d'extinction/rallumage à quatre.
La carte graphique a loupé une marche lors d'un context-switch (par exemple passage en plein écran avec d'autres paramètres d'accélération) et attend toujours une info qu'elle ne recevra jamais. En attendant elle est locké en exclusif par une appli et si on tue l'appli il faut aussi refaire le switch de contexte en sens inverse avant de pouvoir repasser en mode graphique. Généralement quand un switch de contexte est demandé sous Windows Vista ou 7, on se prend un message de type "Le mode de couleur des désormais windows 7 de base". ce qui se traduit par "Il y a une appli qui a demandé un type de format de pixels, ou d'accélération que je ne peut pas lui fournir dans le mode graphique actuel. Donc je range mes affaires et je lui passe la main."
Si la carte part en vrille à ce moment là, c'est quasiment écran bleu assuré. Windows 7 va tenter de refaire le coup du passage par un mode non accéléré et reprise, mais si la carte est en attente d'infos de contexte ça a peut de chance de marcher. Sous linux c'est l'équivalent de tenter de passer sous la console, tuer l'appli qui casse les pieds et repasser en X en priant pour que l'affichage fonctionne. Des fois ça marche, souvent ça marche pas. La carte est mal initialisé, et les modes graphiques sont inaccessibles.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 9.
mais sous windows lorsque le driver de la carte graphique part en couille il ne se passe rien de spécial
Ca dépend beaucoup de comment le driver part en couille, et de pourquoi.
Grosso modo on peut définir trois grands cas :
Le pilote se vautre tout seul comme un grand, il y a un bug quelconque dans le pilote, il envoie une série de commande à la carte graphique, la carte graphique répond "beurk", mais reste dans un état parfaitement valable et initialisé, l'application qui est à l'origine de la série de commande fautive se prend une notification d'erreur et suivant les cas réessaye, se vautre ou se ferme proprement. Sous Linux si c'est X11 l'application fautive il va y avoir une série de lignes dans le log et peut-être une fenêtre qui n'aura plus de père. Sous Windows si c'est explorer desktop, il va gentiment mémoriser les fenêtres et les params, se fermer et se relancer. Pas de clignotement écran dans ce cas là, juste la fermeture et la réouverture de la barre des taches et de certaines infobulle et autres icônes de notifications
La carte graphique envoie une réponse qui n'a rien à voir avec ce qui a été demandé. Défaut du pilote ou de la carte, difficile à savoir sans mettre les mains dans le cambouis, toujours est-il qu'il y a un problème. Soit l'erreur est minime et on ferme l'appli, soit l'erreur est plus grave et on tente le double context switch à la sauce windows :
1 - On passe la carte graphique dans un mode non accéléré, éventuellement avec une résolution moindre. (l'écran s'éteint et se rallume)
2 - On valide qu'en mode non accéléré le système graphique repart bien (généralement c'est le cas)
3 - On décharge tout ou partie du pilote de la carte graphique (c'est la partie que Linux ne sait pas faire, X11 peut mais l'archi au niveau kernel ne suit pas)
4 - On recharge un pilote propre et on réinitialise la carte graphique (l'écran s'éteint)
5 - On repasse en mode graphique précédent avec accélération (l'écran se rallume dans).
Parfois il y a des étapes en plus, notamment si il faut décharger tout le pilote, pas juste la partie accélération (comme dans une mise à jour) dans ce cas windows Vista/7 vont passer par un pilote de compatibilité ce qui peut pousser le nombre d'extinction/rallumage à quatre.