Discussion :

[chrtophe]

Tu as compilé ton propre noyau ?

Que donne les commandes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

xrandr

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

grep "drivers" /var/log/Xorg.0.log

[ctac_]

Bonjour,
Je ne suis pas un spécialiste mais j'ai l'impression que le kernel ne reconnais pas ton écran.
Perso, je ne toucherais pas a grub qui est un monde intermédiaire entre la console et l'écran graphique X et je remettrais les paramètres par défaut.
Une fois ceci fait, tu peux regarder dans grub en console via c la commande vbeinfo qui va te donner toutes les résolutions supportées par ton système.
Je ne me souviens plus s'il existe une commande more pour pouvoir tout lire mais les dernières lignes indiquent la résolution préférée du système, c'est à dire, la meilleure résolution possible.
En général et par défaut, le système se régle sur la meilleure résolution possible et le problème est plutôt inverse, il faut modifier les paramètres pour obtenir quelque chose de lisible donc plus gros.
Ici tu obtiens 640x480, donc la plus basse résolution car il y a un problème.
Comme suggéré par Disedorgue, c'est certainement un problème de font configurable par dpkg-reconfigure console-setup.
En fait, cette commande ne fait, je pense, que modifier le fichier /etc/default/console-setup
Il faudrait voir si ce fichier est modifié aprés la commande et peut être regarder aux niveaux des fonts installées par défaut (pas les fonts X) s'il n'y a pas un probléme.
Ici, ça dépasse légèrement mes compétences et risque de me prendre un certain temps ( dont je ne dispose pas) pour investiger.
Cordialement.

[disedorgue]

Merci.
Au fait, on parle bien des mêmes consoles, celles activées avec Ctrl-Alt-F1...6 et pas lxterminal ou autre xterm, on est d'accord ?

Bah non, c'est bien depuis un xterm

Je plaisante

Sinon, si ça peut aider, moi, coté xrandr, j'ai:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
xrandr
Screen 0: minimum 16 x 16, current 1920 x 1080, maximum 32767 x 32767
XWAYLAND0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 340mm x 190mm
   1920x1080     59.96*+

Et que l'on ne me sorte pas un truc du genre, c'est parce que j'utilise wayland, en X j'ai la même résolution, c'est juste que là, je ne suis pas en X car sinon ma conf utilise la carte nvidia, mais même quand j'étais sous X pour radeon, mes consoles étaient comme maintenant...

[disedorgue]

Comme je sent la question poindre, ma conf de /etc/default/console-setup:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ cat /etc/default/console-setup 
# CONFIGURATION FILE FOR SETUPCON
 
# Consult the console-setup(5) manual page.
 
ACTIVE_CONSOLES="/dev/tty[1-6]"
 
CHARMAP="UTF-8"
 
CODESET="guess"
FONTFACE="Fixed"
FONTSIZE="8x16"
 
VIDEOMODE=
 
# The following is an example how to use a braille font
# FONT='lat9w-08.psf.gz brl-8x8.psf'

[ctac_]

Salut,
J'ai pas franchement le temp, mais j'ai quand même un peu regarder.
J'ai 2 répertoires dans /usr/share :
console-setup
consolefonts

console-setup semble définir les paramètres par défaut pour la console
consolefonts semble définir les polices utilisables pour la console.

Cordialement.

[Jipété]

Bonjour,

merci pour cette avalanche de retours et de pistes.

Avant de répondre à vos questions, juste une petite info : ce matin j'ai booté la machine avec la clé USB qui m'a servi pour l'install d'il y a deux mois et je suis bien en environnement graphique (lxterminal --> xrandr --> 1440x900) mais les consoles sont en 640x480, hé oui !

Dans cet environnement, la commande de chrtophe grep "drivers" /var/log/Xorg.0.log donne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[    11.427] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[    11.492] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[    11.519] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    11.524] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[    11.525] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so

tout comme avec le nouveau noyau une fois la clé extraite et la machine rebootée (dont, oui, j'ai un peu tuné le .config avec make menuconfig avant de lancer la compil [90 minutes environ, ouch !]).

En comparaison, voilà ce qu'elle donne dans ma vieille Debian 7 en pleine forme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
[    14.000] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[    14.013] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[    14.109] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[    14.121] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so

Le retour de disedorgue sur cette commande serait utile, on dirait, puisque la différence est l'absence du driver modesetting_drv.so dans l'ancienne machine, qui fonctionne bien.


Quant au fichier /etc/default/console-setup, les différences se situent au niveau des champs CHARMAP et CODESET :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
          |  CHARMAP  | CODESET
disedorgue| UTF-8     | guess
liveUSB   |ISO-8859-15| guess
ancienne  | UTF-8     | Lat15
nouvelle  | UTF-8     | Lat15

La FONT est partout la même.

Comme suggéré par Disedorgue, c'est certainement un problème de font configurable par dpkg-reconfigure console-setup.

à qui j'avais répondu que l'exécution de cette commande n'avait pas eu d'incidence sur le problème.

console-setup semble définir les paramètres par défaut pour la console
consolefonts semble définir les polices utilisables pour la console.

D'accord et merci, cependant, je rappelle qu'un bon paramétrage de Grub fait que les consoles sont parfaites, donc le problème ne vient pas de là.
Le souci dans ce contexte c'est que X ne démarre pas.
La bonne question c'est : pourquoi suis-je obligé de trifouiller dans /etc/default/grub pour avoir des consoles correctes que disedorgue ou mon ancienne machine obtiennent directement ?
Plus l'effet de bord de la perte de X…

Ici tu obtiens 640x480, donc la plus basse résolution car il y a un problème.

Oui, mais où ? C'est là toute la question.

En attendant vos retours inspirés, je vais rejeter un œil au .config.

[Jipété]

Et si c'était ça, la blague ?

.config de l'ancienne machine :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
...
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
...

.config de la nouvelle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
...
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
...

Vues, les 2 nouvelles lignes avec ces valeurs de 1991 ? Allez, je les remets :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25

Allez voir chez vous et dites-nous, ça se trouve dans Device Drivers / Graphics support / Console display driver support ou faites une recherche de CONFIG_DUMMY_CONSOLE dans le .config.

En ce qui me concerne, je vais tenter 640/80=8 donc 1440/8=180 et 480/24=20 donc 900/20=45 +1 = 46 et je vous dis.

[chrtophe]

Dans l'install que tu as faite, xrandr retourne 1440x900 ?
Et j'essayerais avec un noyau d'origine, pas celui que tu as compilé, avec les réglages 1440x900 dans grub.

[Jipété]

Dans l'install que tu as faite, xrandr retourne 1440x900 ?

Ben oui, c'est les caractéristiques natives d'un vieux moniteur (en attendant le passage en prod'), et xrandr le détecte bien.

Et j'essayerais avec un noyau d'origine, pas celui que tu as compilé, avec les réglages 1440x900 dans grub.

C'est ce que j'ai fait en bootant sur la clé USB d'installation, où j'ai le même problème.

Donc, non, je ne touche pas à grub, je vais lancer la compil avec 180 x 46, résultat dans soit 5 minutes, soit une heure et demie...

[disedorgue]

Désolé, mais moi, je n'ai que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[    48.002] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so

Mais pour ma part, c'est normal, puisque mon serveur X me sert pour mon autre carte (nvidia) et je n'utilise pas le serveur "nouveau" mais celui de nvidia:
Wayland pour le gpu radeon intégré (dans ce cas, je peux utiliser ma carte nvidia pour du calcul uniquement)
X pour ma nvidia (dans ce cas, gnome et autre appli graphique sont gérés par la carte et sa pompe un max... cette conf ne me sert que pour éventuellement du jeu)

Après, beaucoup de gens rencontre des difficultés avec wayland, ce qui n'est pas mon cas.

[Jipété]

Bon, ça se passe mal...

Au reboot, pas de démarrage de X et les consoles sont en 180 x 56 : d'où sort ce 56 ? Pas la moindre idée.

Et pourtant, un examen de /sys/bus/platform/devices/uvesafb.0/vbe_modes montre, au milieu d'une vingtaine de lignes, la 1440x900-32 qui m'intéresse.

Mais l'analyse de /var/log/Xorg.0.log montre des choses qui ne me parlent pas, je ne connais rien à X et j'écris ça depuis l'ancienne machine car ce qui devait arriver arriva enfin : j'ai tout cassé ou plutôt, en voulant revenir à l'ancienne version (80x25) j'ai dû me faire un nœud qqpart car maintenant c'est kernel panic dès le début du boot.

Je suspecte un problème dans initrd-img mais c'est très compliqué à regénérer, je ne sais pas trop où je vais, là, car si je tente de booter le vieux noyau qui date de l'install, [EDIT] ça fonctionne en console mais sans X ça fonctionne avec X après récupération des 4 fichiers de la clé USB (config, System.map, initrd-img et vmlinuz) [/EDIT] avec un message au boot "kvm disabled by BIOS" et je voudrais bien savoir d'où ça sort puisque je ne trouve pas d'options kvm dans le BIOS…

Bref, il me faut réparer toute cette pagaille et par cette chaleur, ce n'est pas raisonnable.

[ctac_]

Bonjour,
Malgré tes réponses légèrement désobligeantes, genre je sais tout et j'ai déjà essayé.
je tenterais une réinstallation d'origine sans recompilation et dans un premier temps sans X pour voir si ça fonctionne.
Cordialement.

[Jipété]

... je tenterais une réinstallation d'origine sans recompilation et dans un premier temps sans X pour voir si ça fonctionne.

Si quoi fonctionne ? La réinstallation sans recompilation et sans X ?
Ben oui ça fonctionne, après récupération sur la clé USB des 4 fichiers du dossier /boot du live-cd, et même avec X (puisque c'est construit comme ça) et sans réinstallation, juste la recopie des 4 fichiers.

Et une réinstallation d'origine, de toute façon je ne veux pas en entendre parler pour le moment : j'ai fait une c0nn3r13, il m'appartient de la corriger pour que tout rentre dans l'ordre.
Sans compter qu'une réinstallation d'origine (à la Windows, on efface tout et on recommence ?), non non non, trop de tuning pour faire fonctionner mon imprimante et d'autres bricoles.

Ensuite, quand j'aurais récupéré X (on en parlera demain, j'ai des logs et une ou deux questions), on verra bien comment ça se passe avec les consoles qui, pour le moment, fonctionnent bien (j'ai réglé le pb de kernel panic par un make clean suivi d'une re-création complète du noyau et de ses modules).

Dans l'attente, on peut réfléchir à ce point : si je boote le noyau d'install (non tuné), j'ai X et les consoles en 640x480, si je boote mon noyau tuné aux petits oignons mais avec une erreur, je n'ai pas X mais les consoles sont bonnes. Or les deux noyaux partagent la même arborescence, donc les mêmes configurations de modules, de modules black-listés, de fonts et d'autres choses.
Le problème doit se situer dans les initrg-img qui sont différents, tout comme les System.map. Non ?

@disedorgue : tu les as, ces deux lignes, dans ton .config ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
...
#
# Console display driver support
#
...
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25

Bon, allez, à suivre,

[disedorgue]

Oui...

Est-ce que tu as le fichier /etc/X11/xorg.conf ?

Si oui, renomme le en xorg.conf.ori et reboot (c'est ce que je dois faire si je veux utiliser X11 sans activer ma carte nvidia) .

[Jipété]

Bonjour,

(attention, c'est un peu long)

Bonjour,

Est-ce que tu as le fichier /etc/X11/xorg.conf ?

c'est exactement le genre de question qui me turlupine depuis hier : tu me parles d'un fichier dans un dossier commun à deux noyaux, dont les comportements sont différents. En toute logique il n'est pas possible que ce fichier soit concerné.

Je récapitule : au boot je peux choisir (compliqué, maintenant, c'était mieux avant, quand on avait tout sous les yeux) entre deux noyaux :

• un vierge venant de l'install depuis la clé uzbe et fonctionnant comme il faut sauf pour les consoles,
• et un autre créé depuis un .config (dont je ne me souviens pas d'où il sort) qui a été tuné plusieurs fois et qui a toujours bien fonctionné également (sauf pour les consoles), mais plus depuis deux jours parce que je l'ai tout cassé.

Si oui,

Ça tombe bien, je ne l'ai pas.

---
Concernant l'origine du souci présent (plus de démarrage de X du noyau propre refait hier), je suspecte, comme je travaille avec deux machines sur le même bureau en bois et donc deux claviers l'un devant l'autre et qu'il m'arrive de me mélanger les pinceaux ("mais pourquoi mon texte ne s'affiche pas ? Ah oui, je ne pianote pas sur le bon clavier !"), je suspecte que hier matin, après avoir trifouillé ces options de DUMMY_CONSOLE_COLUMNS et _ROWS, que peut-être pendant que je regardais d'autres options, qu'une erreur de clavier m'aurait désactivé un truc sans que je ne m'en rende compte.

Ensuite enregistrement, make kernel et reboot et pâté.

Plus qu'à trouver ce qui manque dans le .config…
Ou ce qu'il y a en trop, car en regardant deux ou trois trucs et machins, je me gratte la tête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
dmesg | grep uvesa
[    3.288156] uvesafb: (C) 1988-2010, Advanced Micro Devices, Inc., RAVEN, 01.00, OEM: AMD ATOMBIOS, VBE v3.0
[    3.328293] uvesafb: VBIOS/hardware supports DDC2 transfers
[    3.585067] uvesafb: monitor limits: vf = 76 Hz, hf = 81 kHz, clk = 140 MHz
[    3.585154] uvesafb: VBE state buffer size cannot be determined (eax=0x4f00, err=0)
[    3.585162] uvesafb: scrolling: redraw
[    3.586555] uvesafb: mode switch failed (eax=0x34f, err=0) - trying again with default timings
ligne répétée 2 fois
[    3.785893] uvesafb: framebuffer at 0xe0000000, mapped to 0x000000006a67cbd0, using 10350k, total 49152k
[    3.785894] uvesafb: fb0: VESA VGA frame buffer device
[    4.483309] uvesafb: mode switch failed (eax=0x34f, err=0) - trying again with default timings
ligne répétée 4 fois
[   28.987817] uvesafb: mode switch failed (eax=0x34f, err=0) - trying again with default timings

et rien en 4.19.0-9 (celui d'origine qui fonctionne bien sous X)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
cat /sys/bus/platform/devices/uvesafb.0/vbe_modes
(je ne mets pas tout)
640x480-15, 0x0110
800x600-16, 0x0114
1024x768-15, 0x0116
1280x1024-16, 0x011a
1280x960-32, 0x0166
1440x900-16, 0x01d2
1440x900-32, 0x01d4
720x480-32, 0x01d9

Ce fichier n'existe pas en 4.19.0-9

Et il y a des erreurs dans le Xorg.0.log de la 4.19.118 mais pas dans la 4.19.0-9 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
cat /var/log/Xorg.0.log
...
[     9.841] (WW) Falling back to old probe method for fbdev
[     9.841] (EE) Screen 0 deleted because of no matching config section.
Fatal server error:
[     9.841] (EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[     9.841] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[     9.922] (EE) Server terminated with error (1). Closing log file.
ne présente pas ce genre d'erreur en 4.19.0-9, sauf cette ligne, présente dans les deux logs :
[     9.841] (EE) Unable to find a valid framebuffer device

(Maintenant, comment faire confiance à des gens qui me disent de regarder dans "/var/log/Xorg.0.log" for additional information alors que c'est de ce fichier que vient cette info !? )

---
Et je me dis qu'on dirait que le souci viendrait du module uvesafb, que je vais m'employer à désactiver dans la 4.19.118 (la malade).

Actions : je modifie le /etc/initramfs-tools/modules pour commenter l'appel à uvesafb, j'enlève le dièse aux deux lignes vesafb et uvesafb dans /etc/modprobe.d/blacklist-framebuffer.conf et enfin je regénère un initrd-img.
Reboot et… je récupère X !

Mais du coup, retour à la case départ, les consoles sont en 80x25, limite inutilisables.
EDIT : je viens de compter attentivement, en fait c'est 80x30 et la question est d'où sort ce 30 ? /EDIT

[Jipété]

Bonjour,

juste un mot, vit' vit', pour vous tenir au courant.

Ce matin j'ai longuement fouillé dans le forum officiel de Debian (où plein de gens ont des problèmes de résolution avec les consoles), j'ai trouvé des pistes intéressantes, j'ai mis à jour mon système en suivant des posts qui se terminaient par "avec ça vous êtes au top et vous pouvez tout faire" et comme moi, je ne pouvais toujours pas tout faire, j'ai décidé de poster chez eux et donc d'abord de m'inscrire et depuis 11 h 15 j'attends le mail de confirmation…

J'en ai demandé un autre vers 13 h 15 et j'attends toujours…

J'ai testé mon adresse mail depuis un autre compte, elle est parfaitement valide et valable.

Elle est pas belle la vie ?

[disedorgue]

Perso, devant un problème de ce genre, je regarde pour voir si quelqu'un a déjà trouvé une solution mais en général, je me retrouve le bec dans l'eau et donc je cherche par moi même, quitte à devoir allez me taper le code (dans le pire des cas), pour comprendre comment ça fonctionne, voir parfois les specs, quand je les trouve, du hardware qui me pose problème.
Et je peux te dire, que bien souvent, même avec ces informations, on comprend que derrière, il n'y a pas la maîtrise du concepteur et que cela fonctionne à la va comme je te pousse...

Mais bon, c'est pas grave, en un sens, c'est même formateur

[Jipété]

Perso, devant un problème de ce genre, je regarde pour voir si quelqu'un a déjà trouvé une solution mais en général, je me retrouve le bec dans l'eau et donc je cherche par moi même, quitte à devoir allez me taper le code (dans le pire des cas), pour comprendre comment ça fonctionne, voir parfois les specs, quand je les trouve, du hardware qui me pose problème.

Ah oui mais là, je vais en avoir pour 6 mois (au moins) à 10 h / jour, pas très productif…

Et je peux te dire, que bien souvent, même avec ces informations, on comprend que derrière, il n'y a pas la maîtrise du concepteur et que cela fonctionne à la va comme je te pousse...

Et de plus en plus, je trouve. La dernière en date : le bloc-note. Avant on avait leafpad, ultra simplissime et solid as a rock, maintenant "ils" nous l'ont viré, remplacé par mousepad qui, des fois, remet à zéro mes préférences.

Et puis on nous change des trucs juste pour dire qu'il y a eu un changement, mais ça ne nous apporte rien à part une perte de temps comme par exemple la nouvelle version du gestionnaire de fichiers, pcmanfm :
avant (2012-13 environ), pour changer le rendu des icônes, un clic sur "Voir" et un petit menu s'affiche, on descend sur l'option qu'on veut et on clique

maintenant, un clic sur "voir" et il faut descendre sur la ligne qui va afficher le sous-menu et il faut glisser jusqu'au bout pour le faire afficher et monter ou descendre vers l'option voulue. Mais vue la largeur du premier menu, on a toutes le chances de déraper pendant le glissement.

En plus on constate que ce menu "Voir" est beaucoup plus chargé que l'ancien, on passe donc plus de temps à le lire pour trouver (ou pas) ce qu'on veut.

Bref...

[balkany]

Et de plus en plus, je trouve. La dernière en date : le bloc-note. Avant on avait leafpad, ultra simplissime et solid as a rock, maintenant "ils" nous l'ont viré, remplacé par mousepad qui, des fois, remet à zéro mes préférences.

C'est vrai que c'était assez pénible ça
Mais ça a été corrigé l'an dernier : https://bugzilla.xfce.org/show_bug.cgi?id=12298

Si ça n'est toujours pas dispo dans ta distribution, tu peux facilement te faire un script qui remet les préférences d'aplomb : il suffit de mettre la sortie de gsettings list-recursively org.xfce.mousepad dans un fichier en rajoutant gsettings set devant chaque ligne.
Donc par exemple comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
gsettings list-recursively org.xfce.mousepad | sed '1i\#!/bin/bash\n
s/^/gsettings set /' >script && chmod u+x script

Perso j'avais mis ce script en entrée de session, car régulièrement les préférences sautaient à ce moment-là, et puis je le relançais de temps en temps à la main quand il fallait (genre si tu ouvres un fichier dont mousepad ne trouve pas l'encodage, je crois que ça pète )

[Jipété]

Mais ça a été corrigé l'an dernier : https://bugzilla.xfce.org/show_bug.cgi?id=12298

Merci pour le lien.
Et c'est ça qui me casse le moral, en informatique : j'ai lu la page, à la fin tout le monde est content, c'est corrigé avec la 0.4.1, tout va bien, SAUF CHEZ MOI qui suis pourtant aussi en 0.4.1.
La différence c'est que je suis en LXDE alors que le machin serait orienté XFCE. Ça a une telle importance ?

Si ça n'est toujours pas dispo dans ta distribution, tu peux facilement te faire un script qui remet les préférences d'aplomb : il suffit de mettre la sortie de gsettings list-recursively org.xfce.mousepad dans un fichier en rajoutant gsettings set devant chaque ligne.

Je vais donc garder ça dans un coin, merci infiniment et bon week-end,