Archlinux.fr [Forums]

bonjour,

j'ai un gros pb d'affichage avec l'option "scale" (ou "transform") de xrandr.
cette option sert à changer les dimensions de l'image de sortie. concrètement elle peut servir à "zoomer" ou à "dé-zoomer" l'écran. je m'en servais sans pb jusqu'à hier. maintenant, inexplicablement, qd je l'utilise il n'y a plus d'affichage. plus précisemment il affiche une image plus ou moins altérée correspondant au moment où la cde a été entrée, mais c'est une image fixe, comme une capture d'écran. seul le curseur de la souris peut bouger. bref, c'est comme si j'avais un écran noir. et je peux continuer à faire des actions en aveugle.

exemple:

[guigui@ctkarch ~]$ xrandr --output VGA-1 --scale 0.9x0.9 --verbose

(zoom léger)
l'écran devient noir pendant une seconde de transition (normal) puis il affiche l'image figée de l'écran au moment de l'entrée de la commande.

si je tape en aveugle: xrandr --output VGA-1 --scale 1x1 --verbose
tout redevient normal.

[guigui@ctkarch ~]$ xrandr --output VGA-1 --scale 0.9x0.9 --verbose
crtc 0: disable
screen 0: 1296x810 335x209 mm 98.11dpi
crtc 0: 1440x900 59.9 +0+0 "VGA-1"
[guigui@ctkarch ~]$ xrandr --output VGA-1 --scale 1x1 --verbose
screen 0: 1440x900 371x232 mm 98.44dpi
crtc 0: 1440x900 59.9 +0+0 "VGA-1"
[guigui@ctkarch ~]$

("crtc 0: disable", c'est une piste?)

je ne vois pas de message d'erreur. y compris ds les logs.

je n'ai rien changé à mon système.

les changements de résolution fonctionnent. exemple:

[guigui@ctkarch ~]$ xrandr --output VGA-1 --mode 1280x1024
[guigui@ctkarch ~]$

ça me semble tellement incompréhensible que je me demande si ça ne pourrait pas être un pb matériel partiel et soudain. xrandr solliciterait-il le matériel au point de pouvoir en faire lâcher certains?

[guigui@ctkarch ~]$ xsu lspci -vvv -s 03:00.0
Mot de passe :
03:00.0 VGA compatible controller: NVIDIA Corporation ION VGA (rev b1) (prog-if 00 [VGA controller])
Subsystem: ZOTAC International (MCO) Ltd. Device a108
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 22
Region 0: Memory at fb000000 (32-bit, non-prefetchable)
Region 1: Memory at e0000000 (64-bit, prefetchable)
Region 3: Memory at f8000000 (64-bit, prefetchable)
Region 5: I/O ports at ec00
Expansion ROM at fafe0000 [disabled]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Kernel driver in use: nouveau

[guigui@ctkarch ~]$

écran LG FLATRON W1952TE (1440x900)

[guigui@ctkarch ~]$ uname -a
Linux ctkarch 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 20:05:01 UTC 2012 i686 GNU/Linux
[guigui@ctkarch ~]$

si vous avez des idées je suis preneur.

merci!
guillaume

Le Limule a écrit :Linux ctkarch 3.4.7-1-ARCH

À part que tu n'es pas à jour, pas d'idée.

étrangement il n'y a plus de pb.
étant donné qu'il m'a semblé que la dernière fois où cela avait marché c'était sur une vidéo sur youtube (le cadre de la vidéo dépassait de mon "zoom" puis j'avais mis l'option "plein écran" de la vidéo), je me suis dit que peut-être cela avait perturbé des "références système" (??).
du coup je suis retourné sur youtube, j'ai mis une vidéo en plein écran, puis j'ai quitté le plein écran.

et maintenant l'option scale de xrandr fonctionne comme avant.

je ne sais pas si c'est une coincidence. je touche du bois... £:^)

eh bien non, ça recommence à déconner de la même façon...
je ne comprend pas...
quelqu'un a une idée sur les premières investigations à mener?

Au pif, la dernière mise à jour de nvidia ? (à voir si ça fonctionnait avec une version précédente peut-être: Downgrade)

je n'utilise pas nvidia, j'utilise nouveau.

je viens d'essayer nvidia à la place de nouveau, pour voir.
j'utilise le dépot ARM figé au 3 août. donc c'est nvidia 302.17-4 que j'ai testé.
ça a marché (à part qu'il est d'une lenteur affligeante). mais je n'ai pas testé sur la durée.
je suis repassé à nouveau, et ça marche de nouveau... (pour l'instant donc)

jusqu'à présent je n'ai pas vu de défaillance ou de rétablissement pendant une session; soit ça marche dès le début, soit ça déconne dès le début.
je remarque aussi que suite à l'utilisation de "scale" (et au retour à "l'echelle 1") des polices du système sont plus grosses (exemple, les menus des applications qu'on lance). mais c'est peut-être non-pertinent.

je n'ai pas osé downgradé xf86-video-nouveau (en 0.0.16_git20120512-1) car il a besoin de libdrm-nouveau (obsolète) et que ce dernier est en confict avec libdrm. et comme je ne maitrise pas...

j'ai vu aussi qu'il existe un patch pour le pb de bords limitatifs concernant le curseur souris avec un "scale >1" ("dé-zoom"):
https://bugs.freedesktop.org/show_bug.cgi?id=39949#c20
j'ai aussi ce petit pb (non-génant pour moi) avec le pilote nouveau, mais pas avec le pilote nvidia. il faudra peut-être que j'essaye ce patch pour voir...

je me traine toujours mon pb...

j'ai noté quelques détails supplémentaires:
- j'ai le même pb avec l'option "rotate" de xrandr.
- qd je balade la souris sur l'image écran figée, je vois que la souris détecte les bords de fenêtres et autres éléments interactifs (c'est à dire des éléments de l'écran qui devrait apparaître, écran qui reste complètement masqué par l'image figée).
- j'ai rebasculé sur nvidia; ça a re-marché. j'ai re-basculé sur nouveau; ça n'a pas re-marché.

si vous avez des conseils...

je continue...

j'ai essayé le patch que j'ai indiqué plus haut: il résoud bien le pb pour lequel il a été conçu, mais cela n'a pas d'influence sur mon pb.

j'ai downgradé tout mon sytème à l'état ARM du 17 juin 2012 (pour avoir xf86-video-nouveau en 0.0.16_git20120615-1); mon pb est toujours présent...



toujours personne?...

mon pb n'est pas réapparu depuis que j'ai augmenté ma RAM: de 512mo 687mhz -> 2x512mo 800mhz en dual channel.
ça semble donc être résolu.
(carte mère: Zotac Ion)

Les CTKarch en installation fixes ne sont pas trop faites pour rester sur des repos figés. Le meilleur moyen de régler tes problèmes, c’est de commenter arm dans tes repos, de décommenter des miroirs comme celui d’archlinux.fr, et de lancer pacman. Tu auras une masse de mise à jour, pas mal de boulot demandant de la lecture mais qui dans l’ensemble se passe sans encombre (peut-être importer les clefs de pacman, la retouche de de /usr vers juillet, à coup sûr passer à systemd). Je l’ai fait sans trop de problème (je passe sous silence le remplacement de grub legacy par syslinux sur lequel je me suis arraché les cheveux).

Attention toutefois à bien surveiller les logs de pacman. Quand j’ai actualisé en septembre mon portable issu de ctkarch pas mis à jour depuis juillet et, j’avais oublié qu’il fallait relancer mkinitcpio à la main, du coup j’ai eu le message missing operating system au démarrage. Là, il faut chrooter, pas besoin de réinstaller mais si on peut s’en passer…

Mon conseil: imprime/copie toutes les annonces de la page d’accueil d’archlinux.fr depuis la date à laquelle a été figée ton repos ARM et vas-y doucement.


Tel quel, il n’y a pas grand-monde qui puisse te conseiller, parce que tu utilises des paquets et une configuration que la plupart des usagers du forum n’ont plus sous la main depuis quelque temps…