Archlinux.fr [Forums]

j'ai remarqué un bug sur ma config depuis samedi 13 octobre et la mise à jour de ces paquets :

xf86-video-ati (1:6.14.6-1 -> 1:6.14.6-2)
xorg-server-common (1.12.4-1 -> 1.13.0-2)
xorg-server (1.12.4-1 -> 1.13.0-2)
ati-dri (8.0.4-3 -> 9.0-1)
mesa (8.0.4-3 -> 9.0-1)

en gros dès que je redemarre KDE 4 après avoir joué à un jeu 3D ou lu une vidéo ( déconnexion de kde, puis je retape "startx -- vt1" ) alors le bureau se charge bien mais dès que je bouge la souris j'ai un écran noir ( le son reste présent ), plus d'image et aucune possibilité d’accéder à une console, je suis obligé de faire un ctrl-alt-del pour tuer X et redémarrer archlinux,

à noter que lors de la première connexion à KDE ( "startx -- vt1" ) je n'ai pas d'écran noir, tout est Ok, ce n'est uniquement qu'après une déconnexion du bureau KDE et une reconnexion ( via startx -- vt1 ) que j'ai l'écran noir dès que je bouge la souris,

vous pensez que ça vient de quel paquet ?
xorg-server ?

avant les mises à jour du samedi 13 octobre je n'avais pas ce problème,

je précise que j'ai un vieux portable pentium 4, carte vidéo ati radeon 9000 AGP ( rv250 M9, pilote r200 ) et que j'utilise systemd ( mais j'ai fait le test avec initscripts et j'ai le même problème )


j'ai essayé de downgrader xorg mais c'est impossible car il y a trop de dépendances à downgrader,

un moyen de contourner le problème est de se connecter via KDM,

en gros chez moi le problème n’apparaît qu'avec l'utilisation de startx

Elbarto a écrit :un moyen de contourner le problème est de se connecter via KDM,

en gros chez moi le problème n’apparaît qu'avec l'utilisation de startx

Pour contourner, il te suffirait d'activer la connexion automatique dans KDM (si tu es en mono-utilisateur et que tu n'as pas d'autres sessions graphiques).
Si tu tiens à démarrer en mode console, je ne sais pas trop pour ton problème (je ne me suis pas penché du tout sur ce type de choses...).

est-ce que tu penses que le coupable serait xorg ? ( j'ai vu que des gens avaient pas mal de bugs divers depuis la mise à jour du samedi 13 octobre au niveau de xorg )

ou bien le paquet ati-dri ( car j'utilise dri2 ) et j'ai l'impression que les bugs type "écran noir mais tout le reste fonctionne type son, activité disque dur" sont des caractéristiques d'un bug de DRI ?

quand l'écran noir apparaît j'ai essayé de taper à l'aveugle les commandes suivantes pour avoir le log de dmesg et xorg :
mais tout semble normal au niveau des logs, c'est très étonnant,

en tout cas avec kdm je n'ai aucun soucis, même lorsque je le lance manuellement depuis une console ( systemctl start kdm ), aucun problème d'écran noir lors d'une seconde reconnexion,

j'ai remarqué aussi que si je lance un startx avec ces options tout en étant dans tty1:
alors tout est ok au niveau de la seconde reconnexion ( pas d'écran noir quand je bouge la souris ), par contre je perds les options de mise en veille et d'hibernation dans le menu quitter de kde4,

je me demande si ça vaut le coup d'ouvrir un bug dans le bugzilla de xorg ?

un bug lié au moins au fait de possèder une carte ati radeon 9000 agp ( car sous virtualbox je n'arrive pas à reproduire le bug )

Elbarto a écrit :est-ce que tu penses que le coupable serait xorg ? ( j'ai vu que des gens avaient pas mal de bugs divers depuis la mise à jour du samedi 13 octobre au niveau de xorg )

ou bien le paquet ati-dri ( car j'utilise dri2 ) et j'ai l'impression que les bugs type "écran noir mais tout le reste fonctionne type son, activité disque dur" sont des caractéristiques d'un bug de DRI ?

Je ne sais pas.
Regarde aussi sur un log de session (obtenu avec startx &> ~/kdeviastartx.log). Peut-être en le comparant avec le ~/.xsession-errors obtenu par un lancement avec KDM.

Salut,
J'ai rencontré un problème similaire dans ma machine VBox hébergeant ArchLinux; depuis le passage à xorg-server-common -1.13.0-2, xorg-server-1.13.0-2 et xf86-input-evdev-2.7.3-2 :

Pour y remédier, j'ai dû downgrader les 3 paquets suivants : En espérant que cela te serve

j'ai essayé de downgrader mais à chaque fois je devais répondre "oui/non" à la désinstallation d'autres paquets donc j'ai pas osé aller plus loin,

de plus j'avais fait un "pacman -Sc" ce qui avait supprimé les paquets de l'ancienne version, j'ai dû télécharger à la main les 5 paquets sur un dépot non synchronisé,

donc tu confirmes que le problème vient bien de xorg ?

il faudra alors ouvrir un rapport bug dans le bugzilla de xorg sinon le bug risque encore d'être présent, vu que startx est de moins en moins utilisé il se peut que les bétas testeurs de xorg n'aient jamais remarqué ce bug

Dans mon cas, il s'agirait plus d'un problème de version du driver vboxvideo et celle attendue par le nouveau xorg; qui sera certainement réglé avec les prochains modules clients virtualBox.

Elbarto a écrit :j'ai essayé de downgrader mais à chaque fois je devais répondre "oui/non" à la désinstallation d'autres paquets donc j'ai pas osé aller plus loin,

de plus j'avais fait un "pacman -Sc" ce qui avait supprimé les paquets de l'ancienne version, j'ai dû télécharger à la main les 5 paquets sur un dépot non synchronisé,

Si tu as besoin, passe par ARM plutôt. Downgrade

Fif91 a écrit :Dans mon cas, il s'agirait plus d'un problème de version du driver vboxvideo et celle attendue par le nouveau xorg; qui sera certainement réglé avec les prochains modules clients virtualBox.

il faut que tu me confirmes que tu avais ce comportement avec startx :

1) démarrage nouvelle session avec "startx -- vt1"

2) dans cette session on joue à un jeu 3D ( ou on lance glxgears dans une console )

3) on se déconnecte ( menu quitter, déconnexion de KDE4 ), on revient alors dans la console d'origine tty1

4) on relance "startx -- vt1" depuis cette même console

5) le bureau KDE se charge puis on bouge la souris --> écran noir mais l'activité disque dur continue et on entend le son de fin de chargement du bureau KDE

le bug devrait aussi se produire quelque soit l'environnement de bureau ( gnome, xfce4 )

FoolEcho a écrit :

Elbarto a écrit :j'ai essayé de downgrader mais à chaque fois je devais répondre "oui/non" à la désinstallation d'autres paquets donc j'ai pas osé aller plus loin,

de plus j'avais fait un "pacman -Sc" ce qui avait supprimé les paquets de l'ancienne version, j'ai dû télécharger à la main les 5 paquets sur un dépot non synchronisé,

Si tu as besoin, passe par ARM plutôt. Downgrade

interessant, merci de l'astuce