Au menu des nouveautés :
- Le support du protocole DRI2 ;
- RandR 1.3 ;
- Xinput 1.5 avec le support des propriétés ;
- Une meilleure gestion de l'accélération du pointeur de la souris ;
- Une amélioration des performances de l'architecture d'accélération 2D EXA ;
- Beaucoup de corrections de bogues divers et variés (et probablement quelques nouveaux ;) ).
Pour mémoire, un serveur X implémente la partie serveur du protocole X11, il est donc lancé sur une machine dite « cliente » (poste de travail). La version 1.5 (sortie avec la suite Xorg 7.4) avait notamment apporté une gestion du branchement à chaud des périphériques via HAL. DRI2 est le remplacement de l'ancien protocole DRI (Direct Rendering Interface). Je serais bien en peine de vous en décrire les arcanes mais cette évolution permet entre autre d'envisager de rediriger des fenêtres en rendu direct et ainsi de pouvoir réaliser de la composition avec. Il sera à terme possible d'avoir une application 3D composée avec une autre (par exemple glxgear sur les faces du cube de Compiz).
Pour mémoire, la composition est l'opération consistant à rediriger toutes les fenêtres dans un espace mémoire avant affichage afin de réaliser diverses opérations nécessitant de connaître l'ensemble, comme par exemple, les ombres portées, la vraie transparence, etc.
Description du protocole : http://wiki.x.org/wiki/DRI2
RandR 1.3 est une évolution de l'extension Resize and Rotate. La version 1.2 a permis l'introduction de fonctions comme la gestion du branchement à chaud des écrans doubles, de leurs relations, etc. Toutefois, des manques se sont rapidement fait sentir que les développeurs ont tenté de combler par cette version 1.3.
- Ainsi, on peut maintenant connaître l'état des moniteurs sans sonder les sorties de la carte graphique, on évite ainsi les scintillements voire les flashs sur l'écran ;
- Il est possible de définir un moniteur primaire ;
- Le « panning » est maintenant possible, c'est à dire avoir une surface d'affichage supérieure à la taille de l'écran, la zone visible se déplaçant avec la souris ;
- Des transformations (rotation, changement d'échelle) sont maintenant possibles.
Pour plus de détails, suivez cette présentation de Matthias Hopf, concepteur de la version 1.3 : http://www.vis.uni-stuttgart.de/~hopf/pub/Fosdem_2009_randr1(...) (PDF).
Xinput 1.5 est la dernière évolution de l'extension du même nom avant la très attendue version 2 qui amènera le support des entrées multiples tel le multitouches (comme sur l'iPhone par exemple). Cette version ajoute la gestion des propriétés aux entrées. Tout comme les écrans possèdent une résolution/fréquence/orientation qu'il est possible de faire varier via xrandr ; il est maintenant possible d'obtenir et de gérer un certain nombre de propriétés des périphériques d'entrées comme par exemple, l'attribution des boutons. Le tout grâce à l'utilitaire xinput ( http://www.manpagez.com/man/1/xinput/).
Plus de détails dans le mail de Peter Hutterer ainsi que sur son blog :
http://lists.freedesktop.org/archives/xorg/2008-September/03(...)
http://who-t.blogspot.com/
Predictable Pointer Acceleration est un travail qui remplace totalement l'ancien code d'accélération du pointeur de souris tout en restant compatible. En théorie, le résultat devrait être relativement invisible. Cependant pour ceux qui en ont besoin, il offre une souplesse bien supérieure dans la gestion des caractéristiques du mouvement (ex : accélération, vitesse) avec notamment la possibilité de les modifier à chaud via l'utilitaire xinput ou par le biais d'un fichier de configuration (xorg.conf ou les fichiers fdi de hal).
Description et spécifications : http://www.x.org/wiki/Development/Documentation/PointerAccel(...)
EXA est une architecture actuelle d'accélération des opérations 2D visant à remplacer XAA. Depuis la version 1.2 du serveur X, le code d'EXA a subit de profondes améliorations qui ont permis des gains substantiels de vitesse. La version 1.6 ne déroge pas à la règle puisqu'elle inclut différentes optimisations, en particulier sur le rendu des polices de caractères. Au lieu d'utiliser un pixmap par glyphe, on alloue un pixmap pour un ensemble de glyphes et on compose au moment du rendu (bien mieux expliqué ici : http://blog.fishsoup.net/2008/04/20/fast-text-use-a-single-c(...) ), ce qui permet des gains substantiels en vitesse puisque le moteur de la carte graphique peut traiter les glyphes tous ensemble au lieu de les traiter l'un après l'autre.
L'architecture UXA quant à elle n'est pas incluse dans cette version du serveur X et il n'est pas certain qu'elle apparaisse dans les prochaines versions. Pour mémoire, c'est un dérivé d'EXA développé par Intel et optimisé pour les cartes dépourvues de mémoire dédiée. Elle est très dépendante du gestionnaire de mémoire GEM (développé aussi par Intel), ceci expliquant peut être cela.
La prochaine version du serveur X (1.7) sera la base de X.org 7.5 et est prévu pour avril. Il y a néanmoins peu de chance qu'elle soit disponible avant août ou septembre 2009, les développeurs X étant notoirement connus pour dépasser les dates qu'ils se sont fixés ;).
Bien entendu, toute aide pour respecter ces délais est la bienvenue. Dixit les développeurs, le code du serveur X a beaucoup été remanié ces dernières années et il n'est plus aussi effrayant qu'il a pu l'être. N'ayez pas peur de contribuer si vous le pouvez et le voulez.
Aller plus loin
- L'annonce sur Xorg-annouce (2 clics)
- Site internet du projet X.Org (4 clics)
- X Window System sur Wikipédia (3 clics)
# drivers
Posté par M . Évalué à 6.
Ou alors ces nouveautés sont réservés que pour les dernières cartes graphique (ou pilote bien maintenue).
[1] par exemple qui supporte à ce jour DRI2.
[^] # Re: drivers
Posté par Matthieu . Évalué à 5.
http://wiki.cchtml.com/index.php/Ubuntu_Jaunty_Installation_(...)
[^] # Re: drivers
Posté par scullder . Évalué à 5.
C'est prometteur pour un pilote en développement mais ça ne me convient pas (oui c'est libre, j'ai qu'à prendre mon emacs, toussa).
Du côté des pilotes proprios, ils sont dépassés en 64bits, ça tourne, mais ils sont vieux, buggés et ne gèrent pas les dernières fonctionnalités de Xorg.
Chez archlinux, les mainteneurs des package catalyst ont carrément laché l'affaire :
http://blog.poiroud.fr/marc/index.php/post/2009/03/06/Cataly(...)
http://www.phoronix.com/scan.php?page=news_item&px=NzEwM(...)
http://www.archlinux.org/pipermail/arch-dev-public/2009-Febr(...)
Bref encore une fois dans le petit monde fermé des os libres avec pilotes proprio, il faudra casser le support catalyst dans les distributions pour que ATI daigne sortir une mise à jour (encore que, c'est pas gagné).
[^] # Re: drivers
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: drivers
Posté par Larry Cow . Évalué à 3.
[^] # Re: drivers
Posté par Nonor . Évalué à 10.
Voilà une chose que je comprends pas. Avec les machines actuelles qu'on a, les interfaces qu'on a, comment peut-on aujourd'hui se satisfaire de ça ?
Je suis bloqué avec un chipset intel 915GM moi, l'accélération 3D est bonne, la sortie d'écran, le dual screen à la volée avec XrandR est bon, compiz est fluide, le suspend to ram marche, mais je ne suis PAS satisfait de ces drivers car compositing avec xv/opengl ça donne des choses affreuses.
Trop exigeant ? Peut être... Question de point de vue. Pour moi cette "imperfection" est très gênante.
Je suis et je reste frustré de cette situation qui dure depuis des années alors qu'avant d'avoir ce chip intel je lisais partout sur le net que wow les chip intel sous linux c'est le bonheur parfait.
Bref HEUREUSEMENT le DRI2 arrive et va combler ce retard énorme, combien de temps à attendre encore, le moins possible j'espère...
[^] # Re: drivers
Posté par beagf (site web personnel) . Évalué à 10.
Moi ce qui m'emerde c'est le branchement sur video projecteur. Globalement ça marche à peu près mais c'est toujours l'aventure. Quand je vois des potes qui branchent n'importe qu'el video projecteur sur leur portable sous Windows et qui ont juste à appuier sur une touche (enfin deux puisque c'est souvent une combinaison avec Fn) et "Magie, magie" ça marche direct.
Moi c'est cette imperfection que je trouve génante car à chaque fois que je doit faire une présentation il faut soit que j'arrive plus tôt pour être sûr d'avoir le temps de faire marcher la connexion, soit que je sois sûr qu'il y a un portable sur place pré-configuré.
Donc je partage ta frustration mais pour des raisons différentes...
[^] # Re: drivers
Posté par scullder . Évalué à 2.
[^] # Re: drivers
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: drivers
Posté par scullder . Évalué à 3.
http://www.x.org/wiki/radeonhd
The radeonhd driver, or xf86-video-radeonhd, is an X.org video driver for R500 and newer ATI graphics devices. It is being developed by the X11 community, currently centered around Novell and AMD, with the free documentation provided by AMD.[^] # Re: drivers
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
"It provides the 'ati' driver wrapper which loads one of the 'mach64', 'r128' or 'radeon' sub-drivers depending on the hardware."
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: drivers
Posté par Smarter . Évalué à 3.
[^] # Re: drivers
Posté par Marc Poiroud (site web personnel) . Évalué à 4.
* http://www.x.org/wiki/radeonhd
* http://fr.wikipedia.org/wiki/RadeonHD
[^] # Re: drivers
Posté par Mathieu Segaud . Évalué à 4.
:)
[^] # Re: drivers
Posté par ʭ ☯ . Évalué à 5.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: drivers
Posté par gUI (Mastodon) . Évalué à 2.
Il devrait bien tot en etre de meme avec les versions suivantes (notamment le très courant i965) qui pour l'isntant tournent très bien (basé sur le i915) mais n'utilisent pas encore à fond leurs spécificités (que je ne connais pas exactement d'ailleurs).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: drivers
Posté par auve . Évalué à 9.
Hum hum...
En ce moment c'est quand même pas la joie ; entre tous les bouleversements qui secouent l'infrastructure graphique de Linux/Xorg en ce moment (GEM, DRI2, UXA, KMS...), il a récemment été très difficile d'avoir un couple noyau/espace utilisateur qui offre des performances 3D correctes avec, par exemple, un GMA950. Par « correctes », j'entends comparables aux performances atteintes avec les versions précédentes d'Xorg et du driver intel (< 2.5.x pour ce dernier, si je ne m'abuse). Cela a été documenté entre autres par Phoronix, cf. [0].
Que les développeurs des couches graphiques de Linux bossent et chambardent tout afin qu'on dispose enfin d'une architecture propre et moderne, je trouve ça très bien. Maintenant, le boulot des distributions devrait justement de préserver l'utilisateur de ces phases de transition, autant que faire se peut ; en l'occurrence ça n'a pas du tout été le cas pour un certain nombre d'entre elles (citons en vrac Archlinux[1], Fedora 10[2], la prochaine Ubuntu[4] qui risque de sortir avec cette régression...).
Le bug est connu chez fd.o[3] mais en l'état actuel des choses, virtuellement toutes les distributions Linux récentes sont quasiment infoutues d'offrir des performances 3D normales avec le GMA950, qui si on en croit[5] est quand même extrêmement répandu.
Espérons qu'avec les corrections et nouvelles fonctionnalités dans le noyau 2.6.29, xorg-server 1.6 et les améliorations récentes apportées au driver DRI d'Intel, les choses retournent à la normale. En attendant... Qu'on ne me dise pas que les cartes Intel sont bien supportées en ce moment.
[0] : http://www.phoronix.com/scan.php?page=article&item=intel(...)
[1] : http://bbs.archlinux.org/viewtopic.php?id=62455
[2] : https://bugzilla.redhat.com/show_bug.cgi?id=473179
[3] : https://bugs.freedesktop.org/show_bug.cgi?id=19873
[4] : https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/303(...)
[5] : http://unity3d.com/webplayer/hwstats/pages/web-2009Q1-gfxcar(...)
[^] # Re: drivers
Posté par reno . Évalué à 9.
Uniquement pour les distributions dont le but est de viser la stabilité!!
Fedora liste dans l'ordre de ses priorités en numéro 1 l'avancement rapide du logiciel libre et seulement apres de fournir un environement stable.
En conséquence de quoi ils choisissent souvent d'utiliser des techno 'alpha' (exemple KDE 4.0.3), donc se plaindre de la stabilité de Fedora c'est vouloir le beurre et l'argent du beurre, utilise une autre distribution si tu veux du stable..
Ubuntu, la je suis d'accord que ce n'est pas normal car ils disent vouloir fournir une distribution utilisable par tout le monde.. Mais bon il y a plusieurs années deja, sur mon PC avec Kubuntu, X n'affichait qu'un écran gris alors que Mandriva lui fonctionnait bien, donc ce n'est pas nouveau.
[^] # Re: drivers
Posté par ianux (site web personnel, Mastodon) . Évalué à 4.
En attendant... Qu'on ne me dise pas que les cartes Intel sont bien supportées en ce moment.Justement, j'utilise depuis quelques temps la version testing (1.5.99) sous Archlinux sur un laptop avec un chipset Intel GM965 (dernier driver en date) et je dois dire que c'est le jour et la nuit. J'ai enfin une VRAIE accélération 3D. Je ne parle pas de pseudo-benchmark à la glxgears ou de burô 3D mais de trucs genre Assaultcube (enfin!), Enemy Territory, Google Earth (avec les bâtiments 3D, à moi New York DC!) ou même Celestia (qui ramait grave sur ma bécane). Maintenant ça tourne...
X lui-même semble moins gourmand en mémoire (X lancé avec Awesome ne pompe que 160Mo).
À noter qu'avec le driver Intel, DRI2 n'est activé qu'avec l'accélération UXA
[^] # Re: drivers
Posté par Cédric Chevalier (site web personnel) . Évalué à 3.
T'es sûr que tu utilises Google EARTH ? Ou alors il manque un T à DC mais sinon je ne vois pas du tout où est cette ville.
[^] # Re: drivers
Posté par gpe . Évalué à 2.
Pour Firefox ça semble lié à l'EXA car si je force XAA ça s'affiche bien. Exemple de site qui pose problème (http://www.dpreview.com).
Pour GoogleEarth ça concerne la météo. Les nuages s'affichent en une sorte de labyrinthe...
[^] # Re: drivers
Posté par gUI (Mastodon) . Évalué à 1.
Si, elles le sont et depuis plusieurs mois. Une Ubuntu 8.04 en natif est capable de faire tourner un bureau 3D sur un eeePC701 et son "petit" i915 (je sais, je l'ai fait). Ca marche bien, pas de driver proprio à ajouter. J'appelle ça etre bien supporté.
Ensuite depuis qques semaines je tourne avec un kernel 2.6.28.5, un xorg-server 1.5.3-r2 (sous Gentoo), les drivers intel de base, et j'ai constaté et mesuré des perfs en augmentation de l'ordre de 30%.
Tout ça uniquement avec le GEM, sans encore parler de DRI2 !
En témoigne tout ce thread sur le forum Gentoo : http://forums.gentoo.org/viewtopic-t-737102-postdays-0-posto(...)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: drivers
Posté par auve . Évalué à 1.
Je ne vois pas le rapport, cette distribution aura bientôt un an. Je te suggère de refaire l'expérience avec une Ubuntu 8.10 vanilla. Chez moi ça ne fonctionne absolument pas : les performances sont déplorables, j'atteins péniblement les cinq images par secondes dans OpenArena par exemple.
Ensuite depuis qques semaines je tourne avec un kernel 2.6.28.5, un xorg-server 1.5.3-r2 (sous Gentoo), les drivers intel de base, et j'ai constaté et mesuré des perfs en augmentation de l'ordre de 30%.
Déjà, « quelques semaines », ce n'est pas « quelques mois ». Ensuite, si je lis correctement le fil de discussion que tu cites, tu as un chipset i965. Il me semble que justement, ce sont plus les i915 (GMA950 en tête) qui posent problème depuis quelques temps.
Accessoirement, une augmentation de 30% des performances ne veut rien dire par elle-même si ces dernières ont été divisées par trois il y a quelques mois. Je ne dis pas que c'est ton cas ; mais il s'agit bien de celui des possesseurs de GMA950.
[^] # Re: drivers
Posté par HSimpson . Évalué à 5.
J'imagine que les dev doivent avoir de bons pilotes si ils veulent pouvoir tester leur boulot.
[^] # Re: drivers
Posté par glisse . Évalué à 3.
[^] # Re: drivers
Posté par Naha (site web personnel) . Évalué à 1.
[^] # Re: drivers
Posté par glisse . Évalué à 10.
# Synchro souris/écran lors de la rotation
Posté par gerard delafond . Évalué à 8.
Actuellement, sur les tabletPC, si on tourne l'écran, les mouvements de pointeurs se font à la perpendiculaire des mouvements, ce qui limite l'utilisabilité...
[^] # Re: Synchro souris/écran lors de la rotation
Posté par bubar🦥 (site web personnel) . Évalué à 3.
Concernant le "hack crade" je vois pas trop ce dont il s' agit : sur un vieux Zaurus (distro d' origine + autre et ne disposant pas d' accéléromètre) un click fait basculer l' écran, la souris suit correctement. Dans le genre ancien, ai eu l' occasion de voir un "emperor linux" sur tabletpc : pareil, ça suit correctement.
A moins que tu parles de ça : http://bazaar.launchpad.net/~karl.hegbloom/tabuntu/tablet-sc(...) comme "hack crade" ? (mais la personne précise qu' il est "student". il voit un truc, cherche à la corriger, et ensuite propose son truc, perso j' trouve ça vachement bien, mais bon)
ps : je viens d' essayer sur mon netbook après avoir installé kmachin, tout les mouvements suivent correctement la nouvelle orientation de l' écran. (xrandr 1.2 sur xorg 1.4.2 avec kmachin sur une 2009.0 mnb)
[^] # Re: Synchro souris/écran lors de la rotation
Posté par roduit (site web personnel) . Évalué à 3.
S'il est dans le même cas que moi, le hack crade est qu'il faut faire un script qui tourne l'écran avec xrandr et avec les wacomtools. Par exemple, pour tourner l'écran vers la droite :
xrandr -o rightxsetwacom set "stylus" Rotate 1
Et comme ça, le pointeur de souris tourne aussi...
[^] # Re: Synchro souris/écran lors de la rotation
Posté par gerard delafond . Évalué à 5.
Ce que j'appelle crade, c'est que le système de pointage n'est pas tenu informé de la rotation de l'écran, et qu'il faut lancer un script spécial pour que les deux opérations se fassent en même temps.
[^] # Re: Synchro souris/écran lors de la rotation
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Vous imaginez le résultat avec un ordinateur de bureau et un écran plat pivotant ? On tourne l'écran, et si la souris tourne aussi, là, pour le coup, ça fait des mouvements à 90 degrés.
[^] # Re: Synchro souris/écran lors de la rotation
Posté par Batchyx . Évalué à 4.
On peut supposer qu'il faut tourner que les dispositifs absolus, puisqu'ils doivent être adaptés au moins au ratio hauteur/largeur, et laisser tranquille les dispositifs relatifs.
[^] # Re: Synchro souris/écran lors de la rotation
Posté par benoar . Évalué à 2.
Si c'est pour un écran pivotable, à ce moment là il faudra faire tourner le pointeur _dans le sens inverse_ de rotation de l'écran. Réfléchissez deux secondes. L'écran, quand il est tourné, il apparait toujours comme si il était dans le bon sens pour la CG. Donc si on laisse la souris telle quelle, ça n'ira pas ...
Et tout ça n'a rien à voir avec les périphériques de pointage relatifs ou non, comme expliqué au dessus : je ne vois pas le rapport.
[^] # Re: Synchro souris/écran lors de la rotation
Posté par Antoine . Évalué à 6.
Avec un moteur, oui.
# panning
Posté par Samuel Thibault (site web personnel) . Évalué à 10.
En fait, c'est plutôt _de nouveau_ possible. La fonctionalité
existait depuis des lustres, et avait été supprimée lors de
l'arrivée de Xrandr 1.2.
[^] # Re: panning
Posté par Dring . Évalué à 5.
La souris faisait se déplacer l'écran, c'était magique. En même temps, l'écran était quasiment vide à part un xeyes...
[^] # Re: panning
Posté par dinomasque . Évalué à 3.
Pourtant en 1994 en:xsnow existait déjà ;)
http://dropmix.xs4all.nl/rick/Xsnow/
BeOS le faisait il y a 20 ans !
# Entrées multiples == claviers multiples ?
Posté par Wawet76 (site web personnel) . Évalué à 2.
Actuellement sous X, comme sous Windows, on ne peut pas brancher 2 claviers et leur affecter des keymaps différents. Est-ce que la gestion des entrées multiples annoncée pour XInput 2 permettra de faire ce genre de chose ?
[^] # Re: Entrées multiples == claviers multiples ?
Posté par gerard delafond . Évalué à 3.
Il y avait de gros hacks tordus, et je finissais toujours par bloquer sur une initialisation de carte.
Est-ce que la situation a avancé ?
Mieux : y a-t-il une solution, maintenant qu'on trouve de très grands écrans (26" en 2050 pixels de large) pour une solution
1 ordi + 1 écran + 2 claviers + 2 souris + 2 utilisateurs)
(chacun dans sa fenêtre)
J'ai toujours trouvé curieux que ce genre de solution soit toujours restée quasi-inexistante.
[^] # Re: Entrées multiples == claviers multiples ?
Posté par Guillaume T . Évalué à -3.
Je dis çà, car j'ai toujours trouvé curieux que ce genre de solution soit toujours restée quasi-inexistante
[^] # Re: Entrées multiples == claviers multiples ?
Posté par windu.2b . Évalué à 5.
1 http://pagesperso-orange.fr/lacotte.jean/maroc/divers/autoec(...)
[^] # Re: Entrées multiples == claviers multiples ?
Posté par Tonton Benoit . Évalué à 7.
[^] # Re: Entrées multiples == claviers multiples ?
Posté par soulflyb (Mastodon) . Évalué à 2.
[^] # Re: Entrées multiples == claviers multiples ?
Posté par Anonyme . Évalué à 1.
[^] # Re: Entrées multiples == claviers multiples ?
Posté par IsNotGood . Évalué à 1.
Non. Et c'est peut-être même l'inverse.
Le "multisiège" n'est pas une priorité durant cette période de boulversement de Linux et Xorg. Il n'est pas complètement oublié, il y a quelles rares configurations qui marchent.
La période est rude pour certains utilisateurs. Mais les choses avancent et ça va se calmer.
[^] # Re: Entrées multiples == claviers multiples ?
Posté par Batchyx . Évalué à 3.
[^] # Re: Entrées multiples == claviers multiples ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
J' avais également essayer de faire ceci. Sans trop de difficultés (avec 2 cartes nvidia et une autre avec une nvidia et une matrox. Toujours avec un couple ps2/usb pour les entrées.). Mon soucis se situait dans le reboot / arrêt : ça plantait quasiment à chaque fois. Sans conséquences, mais chiant.
Novell commercialise toujours il me semble une solution pour cela.
Quant à H.P (qui avait également une solution, dans un cadre "bundle éducation")... il me semble qu' ils ont arrêtés ce bundle.
Il semble que l' orientation actuelle soit plutôt à la réduction de consommation électrique (et de place) des postes d' une part, et que l' on tendent plutôt à intégrer 2 souris (voir 2 claviers) sur un seul serveur X (voir une seule application). Non ?
Cdlt.
[^] # Re: Entrées multiples == claviers multiples ?
Posté par Anonyme . Évalué à 1.
Il semble que l' orientation actuelle soit plutôt à la réduction de consommation électrique (et de place) des postes d' une part, et que l' on tendent plutôt à intégrer 2 souris (voir 2 claviers) sur un seul serveur X (voir une seule application). Non ?C'est bien de penser à ceux qui ne veulent pas que leur ordinateur prenne de la place, et c'est très bien de réduire la consommation au minimum.
Reste que je vois pas l'intérêt de brancher deux machines si une seule suffit. Perso j'ai deux écrans, un 4/3 mat pour le bureau et un 16/9 glossy pour les films. Je suis contraint d'utiliser les pilotes nvidia pour ça… et ce n'est qu'un pis aller car je n'ai qu'un curseur, et les claviers sont partagés aussi. En gros si quelqu'un est sur l'ordi de bureau, tout ce qu'on peut faire avec l'autre écran c'est regarder une vidéo (c'est sa fonction première, certes, mais c'est pas l'idéal).
Et si je veux rajouter un vidéo-projecteur ou un troisième écran, je sens que ça sera… amusant (voir pas possible).
[^] # Re: Entrées multiples == claviers multiples ?
Posté par benoar . Évalué à 3.
[^] # Re: Entrées multiples == claviers multiples ?
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
Ce qui m'inquiète personnellement, c'est que cet aspect mutli-utilisateurs est en train de disparaître. On fait du FastUserSwitch alors qu'il n'y a pas de soucis a envoyer une session X sur le tty 8. On impose NetWorkManager, Avahi... On va bientot être obliger d'avoir toute cette daube sur nos serveurs (si serveur avec X d'installé).
J'ai cru voir que la dernière debian installe xauth si on installe ssh ! Moi, je veux pouvoir avoir un serveur sans xauth car je ne veux pas que fenêtre graphique puisse s'ouvrir, même à distance et je ne veux pas sur certain serveur n'avoir qu'un bout de Xorg. Moins de code, moins de bogue.
Bref, c'est bien de faire évolué X et le jour ou X ne tournera plus root, ce sera génial. Mais pensons qu'une machine n'est pas égal a un et un seul utilisateur à la fois !
[^] # Re: Entrées multiples == claviers multiples ?
Posté par Tabalji . Évalué à 2.
Effectivement, avec Lenny xauth est installé par défaut avec ssh. Mais seulement en temps que paquet recommandé d'openssh-client et d'openssh-server. Autrement dit, ce n'est pas une obligation.
apt-get install ssh --no-install-recommends
aptitude install ssh -R
[^] # Re: Entrées multiples == claviers multiples ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Globalement je suis bien d' accord avec ton propos. Et j' ai du mal à cerner où nous sommes emmenés... Quel est l' intérêt par exemple du FastUserSwitch ? J' avoue que je ne vois pas. Sur Xorg en particulier, j' avoue que je ne vois pas son utilité sur des machines Intel destinées à être des Personnals Computers...
En fait, si... mais c' est un peu exprès parceque peut être que la finalité d' utilisation des machines personnelles pour Mr michu est si précise que Xorg semble bien démesuré et plutôt taillé pour les "workstations", avec son adaptabilité à tout Unix et à de nombreuses architectures matérielles.
Bref les utilisations sont tellement diverses et les possibilités offertes pas les *nix si variées qu' il me semble de moins en moins possible de proposer une solution unique pour tout ça... A défaut de TinyX ou autre DirectFB pour les matos récents et personnels, j' espère que WayLand saura combler ce manque.
Comme le dit IsNotGood, "(...) rudes pour certains utilisateurs (...) mais (...) ça va se calmer"
Finalement, ceux disant "distributions spécialisées" il y a qq années ne seraient ils pas les mêmes qui le font ? Wait and See. Perso j' attends en confiance.
mes 2 cents
[^] # Re: Entrées multiples == claviers multiples ?
Posté par benoar . Évalué à 3.
[^] # Re: Entrées multiples == claviers multiples ?
Posté par Batchyx . Évalué à 2.
# Amélioration de l'organistion des drivers
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.