Cher journal,
Je vais m'arracher les cheveux !!!
Ce que je veux faire est simple, de plus ça marche très bien sur un portable standard (ACER aspire 1692).
A savoir : Utiliser l'écran du portable comme DISPLAY=:0.0 et la sortie VGA comme DISPLAY=:0.1 pour pouvoir balancer des vidéos ou des images plein écran sur un vidéopro (par exemple) connecté à la sortie VGA.
Et bien, si mon xorg.conf fonctionne très bien sur le portable ACER, la même config adaptée au chipset i915 du EEEPC ne marche pas ! "No matching instance for BusID 0:2:1" me dit xorg (et il affiche un affichage cloné, même si je lui force la main à coups de BusID "00:2:0" dans chaque section Device)
Grosso modo, j'arrive très bien à faire xrandr --ouput LVDS --left-of VGA, j'ai effectivement du spanning desktop, ça marche bien, mais pour pouvoir déporter une appli sur l'autre écran je ne sais pas comment faire, puisque pour lui les deux écrans sont :0.0, le :0.1 n'existe simplement pas.
Alors je te pose la question cher journal, je sais que le xorg.conf est bon (y'a les screen 0 et 1 là où il faut, bref, en appliquant la même méthode, ça marche sur d'autres chipsets d'autres portables), mais il refuse obstinément de me créer deux displays distincts. Est-ce un bug du driver intel ? une faiblesse du chipset qui ne permet pas cela ? Et enfin, comment faire pour lancer une appli déportée sur l'écran externe quand on ne peut pas passer par export DISPLAY=:0.1 ?
(j'y suis arrivé en faisant un "xterm -geometry -0+0" mais toutes les applis ne supportent pas ce genre de paramètres !!).
Merci d'avance mon journal d'amour....
Journal deux écrans avec le eeepc
20
sept.
2008
# forum
Posté par Maxime (site web personnel) . Évalué à 10.
# Indices
Posté par Aefron . Évalué à 6.
... en outre, depuis le bordel qui a été mis dans le multi-écran depuis RandR 1.2 (même s'il permet la gestion à chaud), on ne peut plus faire tourner qu'un seul serveur X.org (et donc, on ne peut plus utiliser qu'une seule carte : d'ailleurs, en général, le BusId qui se termine par "1" est un périph bidon qui ne sert pas plus qu'il ne fonctionne - tout se passe avec celui qui se termine par 0 : les deux sorties utilisent le même overlay) avec les drivers qui l'utilisent...
Or, le DISPLAY, c'est le numéro du serveur X.org... et vu qu'on n'en a plus qu'un, bah oui ; c'est a priori :0.0... L'indice de l'écran dans RandR et le DISPLAY, ce sont deux choses distinctes.
Pour gérer sur quel écran j'affiche quelle appli, je gère personnellement ça au niveau du Window Manager... par exemple, pour mon HTPC sous KDE (3.5), et son couple LCD 17" 4/3 (pour mouler sur le ouaib) + LCD 42" 16/9 (pour glander devant des videos et cie), je vais dans le centre de configuration-->Bureau-->Paramètres spécifiques à la fenêtre, et je lui dit de toujours mettre MythTV/MPlayer sur un écran et les autres applis sur l'autre.
Sinon, comme tu le dis, si ton appli supporte le paramètre "--geometry", tu peux le spécifier au lancement, en tenant compte du fait que tu as une grosse résolution qui s'étend sur tes deux écrans. Mais toutes les applis ne le supportent pas, et quand elles le font, ce n'est pas toujours de la même manière (taille en caractères, en pixels, ...)...
PS : Ô mes Maîtres, grandes puissances du Chaos Multiforme ! Faites qu'un jour (pas trop lointain s'vous plaît), les "GPU objects" deviennent une réalité, et que RandR puisse enfin supporter plusieurs GPU, afin que le tri-écran de mon bureau puisse de nouveau tourner sur une seule machine (j'suis pas exigeant : je me fous de DRI du moment que Xv fonctionne), plutôt que de devoir utiliser mon vieux barebone pour afficher sur la TV, en plus des deux CRT...
... en vous remerkiant.
[^] # Re: Indices
Posté par Smarter . Évalué à 1.
[^] # Re: Indices
Posté par Aefron . Évalué à 3.
Mais avec RandR 1.2 (donc, des drivers libres, a priori... mais j'avoue ne plus rien connaître aux drivers proprios depuis un bail), le "multiboard", c'est encore sans issue...
... remarque qu'avant, ça ne marchait pas avec DRI activé (enfin, si, mais pas tout le temps :p ... ça plantait aléatoirement une fois sur deux en entrée ou sortie de X.org) ; mais ça marchait en 2D simple... et c'est vraiment une feature dont j'attends avec impatience le retour.
# xrandr
Posté par seginus . Évalué à 0.
xrandr --output VGA --mode 1024x768 --below LVDS
pour mode, tu adaptes évidemment à ton écran, en tapant juste xrandr, tu verras les modes autorisés.
[^] # Re: xrandr
Posté par djibb (site web personnel) . Évalué à -1.
Quelle est la grosse bêtise de dite ici ?
[^] # Re: xrandr
Posté par Amand Tihon (site web personnel) . Évalué à 2.
« Grosso modo, j'arrive très bien à faire xrandr --ouput LVDS --left-of VGA [...] »
[^] # Re: xrandr
Posté par djibb (site web personnel) . Évalué à 0.
je me disais bien ;)
# C'est "normal"
Posté par benoar . Évalué à 4.
[^] # Re: C'est "normal"
Posté par benoar . Évalué à 4.
[^] # Re: C'est "normal"
Posté par Aefron . Évalué à 3.
... ce qui n'empêche pas que selon la distro qu'on utilise, on peut plus ou moins avoir quelque chose de récent : par exemple, Etch est encore avec un X.org 7.1, donc, sans RandR 1.2...
[^] # Re: C'est "normal"
Posté par benoar . Évalué à 2.
[^] # Re: C'est "normal"
Posté par Aefron . Évalué à 5.
... de ce que j'ai vu, MergedFB a disparu avec l'apparition du support Randr 1.2 (logique : ils font la même chose), et Xinerama a encore l'air possible, si l'on utilise "vesa" à la place des drivers qui supportent le nouveau RandR (par contre, pas de cumul des deux, fut-ce sans DRI, a contrario de l'époque pré-RandR 1.2, avec MergedFB).
À terme, toute cette tambouille devrait être remplacée par RandR, avec une abstraction des multiples GPU via les GPU objects... mais les difficultés semblent plus grandes que prévues : au début, ça devait arriver pour X.org 7.3... puis 7.4... maintenant, on n'en parle presque plus, quand bien même c'est une très grosse régression, que de devoir se limiter à un seul GPU (ça fait des années que j'ai horreur d'avoir un nombre pair d'écrans sur mon bureau... c'est moche : du coup, je fais avec deux PC : faute de grives...).
[^] # Re: C'est "normal"
Posté par benoar . Évalué à 2.
[^] # Re: C'est "normal"
Posté par Aefron . Évalué à 2.
... ça ne me dérangerait pas forcément, conceptuellement, de devoir choisir combien de gestionnaire de sessions je veux lancer, et sur quels écrans ils doivent s'afficher... et de le spécifier dans les fichiers de config des-dits gestionnaires de session ; ou quelque chose du genre.
Maintenant, c'est surtout le fait que, à partir du moment où on a ne serait-ce qu'un seul GPU RandR 1.2, on ne puisse plus du tout utiliser plusieurs GPU avec autre chose que "vesa" (d'autant que pour faire du tri-écran, avec vesa, il faut 3 GPU : ça commence à faire beaucoup, et à chauffer dru... et vesa, c'est très très limité), sans que rien n'ait été fait pour gérer la transition (qui dure maintenant depuis au moins un an, et qui va bien encore durer au moins un ou deux ans, en étant 'achement optimiste, tel que c'est parti) qui m'ennuie...
... m'enfin, bon : je n'ai rien à dire... je ne suis qu'un simple utilisateur, qui ne synchronise même plus le GIT pour bugreporter (plus le temps, depuis un moment)... ça m'ennuie juste, c'est tout.
[^] # Re: C'est "normal"
Posté par Jerome Herman . Évalué à 1.
A l'autre limite c'est quand même un peu dommage en cette période de multi-cpu, multi-gpu GPCPU, virtualisation et autres chroot-jail de plomber complètement toute tentative d'avoir deux écrans accélérés indépendamment l'un de l'autre...
Si je veux que mes applis sécurisées s'éxecutent sur le xorg n°1 qui est le principal mais que les applis dont je suis moyennement sur aille sur un autre display, dans un autre xorg qui est lui même protégé et executé avec des droits restreints, là je l'ai dans l'os.
Maintenant ca n'est aussi que le point de vue d'un utilisateur...
[^] # Re: C'est "normal"
Posté par Aefron . Évalué à 2.
... quand un simple reset n'empêche pas de garder des cochonneries dans la RAM des GPU... exemple vécu (plusieurs fois... enfin, pas que avec du Pr0N) : conky sous FVWM (rah, la belle époque où je méprisais les gestionnaires de session et où je startx-ais :) ), matage d'un peu de Pr0N, reboot... et... des bouts de Pr0N à l'emplacement de Conky à son démarrage... sourire en coin...
Quant à la virtualisation et cie, j'ai tendance à repenser à Theo de Raadt lorsqu'il émettait un (attention : litote) doute quant à ce que rajouter une couche de complexité améliore invariablement la sécurité... la facilité à gérer, aucun doute (maintenant, je mets chaque daemon dans un conteneur... je vais même jusqu'à séparer dans deux conteneurs des choses comme privoxy et tor, et à avoir un autre privoxy, dans un autre conteneur, pour le squid, encore dans un autre... et je trouve ça beaucoup plus clean)... la sécurité, dans l'absolu... mouais (dans Debian Lenny, l'installation de gnunet dans un conteneur OpenVZ [testé il y a quelques jours] fait quand même planter l'ensemble de la machine [ça faisait longtemps que je n'avais pas eu un kernel-panic]... la simple installation [même si elle n'aboutit pas])...
Pratiquement, ce qui m'ennuie aussi dans tout ça, c'est qu'on ne peut plus ruser avec plusieurs sessions concurrentes pour faire du multi-seat (en attendant le multi-pointer-X)... ce qui est pourtant d'une utilité impérieuse quand on veut utiliser une machine comme PC "home-cine-à-télécommande" ET comme autre chose en même temps (avec la puissance qu'elles ont maintenant, c'est quand même ridicule), ce qui résoudrait (et résolvait) tous les problèmes de focus inhérents à cette utilisation...
Bon, après, tu soulèves un point important : le frein (non, je ne parle plus de Pr0N) à l'adoption... il est certain que les nouveaux arrivants accrocs aux multi-écrans (ça doit faire 6 ans que j'ai du tri-écran... en ayant commencé avec de l'AGP+PCI - la surcharge de ce dernier étant d'ailleurs ce qui m'a fait passer au PCIe... et je n'ai plus la moindre redmonderie, à part une XBox, première du nom, depuis ~4 ans) doivent pester, en voyant cette (grosse, très grosse m'est avis) faiblesse de X.org, actuellement...
... et non... on n'a pas fini de payer les errements, et du coup, la latence induite, de XFree86... mais bon, gardons espoir : du point de vue de l'utilisateur, voire même du simple mortel (j'imagine qu'être programmeur-X.org est à peu près aussi fou qu'être programmeur-noyau), c'est peu ou prou tout ce qu'on a...
[^] # Re: C'est "normal"
Posté par Jerome Herman . Évalué à 1.
L'idée là c'est surtout de faire passé les applications potentiellement dangereuses sur un autre GPU, pour éviter que le truc s'amuse à faire des impressions écrans de données confidentielles. Ca sécurise quand même un peu au niveau fuite d'information.
j'ai tendance à repenser à Theo de Raadt lorsqu'il émettait un (attention : litote) doute quant à ce que rajouter une couche de complexité améliore invariablement la sécurité
Oui, mais Theo de Raadt parlait de la virtualisation complète, ie mettre plusieurs OS dans des machines virtuelles dédiées. En ce qui concerne la séparation de privilège et la chroot-jail des serveurs, chez OpenBSD ils sont pas les derniers. (A peu près tous les services réseaux sont chrootés par défaut...) A mon sens le contenu d'un display est aussi sensible à l'analyse que le contenu d'un répertoire racine.
[^] # Re: C'est "normal"
Posté par Aefron . Évalué à 2.
... donc, si ce qui se prépare (lentement, mais je le souhaite ardemment, sûrement) permet de gérer de nouveau les GPU multiples, et de le faire mieux que par le passé, y compris en intégrant de manière plus sûre l'abstraction via les GPU objects, tant mieux...
Mais que ça recommence à marcher, déjà... parce que bon : avec la non-remise à zéro de la RAM des GPU et ce genre de choses que j'ai pu observer, la non-sécurité inhérente de X.org, due à une complexité énorme et à un manque de doc de longue date, c'est quand même fermement ancré dans mon inconscient...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.