Eh oui les amis, ça y est, le jour tant attendu est arrivé : Wayland 1.0 est enfin là !
À ce jour, sur tous les ordinateurs de bureau et portables sous GNU/Linux, *BSD ou Solaris de la planète, l’interface graphique — que ce soit KDE, GNOME ou autre — est gérée par X Window System ou X11, dont X.Org est une implémentation (dérivée de XFree86).
Fait tout aussi notable : dans le monde mobile (Android) ou de l’embarqué où GNU/Linux est largement diffusé, X.Org est la plupart du temps absent.
X a été conçu au MIT en 1984 — il y a presque 30 ans ! —, sa version 11 datant, elle, de 1987, ce qui est très vieux pour du code gérant du matériel ayant subi de nombreuses (r)évolutions, avec pour corollaire que X.Org est devenu très difficile à maintenir.
De plus, avec l’avènement des compositeurs (permettant des effets de transparence, d’ombre portée, etc.), le fonctionnement de X.Org pour la gestion graphique ne semble plus optimal, car il constitue une étape supplémentaire entre l’application et le compositeur ainsi qu’entre le compositeur et le matériel.
Plusieurs tentatives pour remplacer X ont eu lieu : Y Window System, Fresco/Berlin… Aucune n’a rencontré le succès escompté.
En 2008, le Danois Kristian Høgsberg a décidé de créer un nouveau serveur d’affichage, à la fois plus moderne et plus simple à maintenir : le projet Wayland était né.
C’est donc finalement le W de Wayland qui succèdera à X !
Pour se donner une petite idée de leurs différences, l’interface de programmation (API) de Wayland est environ 15 fois plus petite que celle de X…
Du côté utilisateur, on nous promet quelques bénéfices immédiats : une plus grande fluidité, un affichage sans cisaillements (tear‐free) quand la décoration est gérée par le client…
Notons enfin que Wayland n’est pas développé contre X.Org, mais avec le plein appui des développeurs de ce dernier qui voient bien l’intérêt de simplifier la maintenance. D’ailleurs, la Fondation X.Org vient de réviser ses statuts en incluant Wayland dans les logiciels qu’elle soutient.
Participants à la rédaction de cette dépêche : reno, antistress, Xavier Claude, Davy Defaud, Patrick_g, Benoît.
Sommaire
- Bref rappel de l’architecture de Wayland
- Débats liés à Wayland
- Différences avec X.Org
- Adaptation des bibliothèques graphiques existantes
- Propos finaux
Bref rappel de l’architecture de Wayland
Wayland est construit au sommet des briques récemment ajoutées à la pile graphique de Linux : DRI 2 (accès direct, sans passer par le serveur X, au processeur graphique pour les applications), GEM (gestionnaire de mémoire graphique commun aux pilotes, utilisé par KMS) et KMS (gestion de la résolution et du nombre de couleurs par le noyau, au lieu du serveur graphique), tous deux utilisés par l’intermédiaire d’EGL.
Le fait que Wayland s’appuie sur KMS entraîne une première conséquence forte : seuls les pilotes libres sont actuellement à même de faire tourner Wayland !
Wayland est le nom du projet et du protocole d’affichage ; le projet contient plusieurs parties :
- une bibliothèque implémentant ce protocole, elle est utilisé par les clients et par le serveur pour communiquer ;
- un serveur d’affichage de référence : Weston ;
- des exemples de clients.
Au début, il était prévu que Weston soit uniquement un prototype utilisé pour tester le protocole, mais il est vraisemblable que Weston sera utilisé en tant que tel dans l’embarqué.
Un serveur Wayland joue à la fois le rôle de compositeur, de gestionnaire de fenêtres et de serveur d’affichage.
Le fonctionnement de Wayland est le suivant : le serveur envoie les événements d’entrée (souris, clavier…) au client concerné. Le client traite l’événement et dessine localement dans un tampon puis envoie la référence du tampon modifié au serveur. Le serveur rassemble les différents tampons pour dessiner l’image finale qui sera affichée. Il est important que le serveur soit le compositeur et aussi le gestionnaire de fenêtres, pour déterminer quelle partie de chaque tampon il doit afficher et à qui envoyer les événements d’entrée.
Débats liés à Wayland
Si Wayland a été globalement bien accepté et souvent salué (par rapport à la fronde que soulève systemd, par exemple… +300 points au trollomètre), il a aussi rencontré des oppositions liées à plusieurs problèmes potentiels :
- la perte de la compatibilité avec X ;
- la perte de la transparence réseau pour des applications natives Wayland ;
- l’homogénéité de l’affichage des fenêtres : avec Weston, il est prévu que ce soit les clients qui dessinent eux‐mêmes leurs décorations.
Ces sujets sont détaillés ci‐dessous.
Compatibilité avec X : XWayland
La compatibilité avec X a été un problème sur lequel les développeurs de Wayland ont travaillé très tôt, en fournissant la possibilité d’avoir un serveur X tournant au dessus de Wayland : c’est tout le but de XWayland (lire les explications détaillées en anglais ici).
Le bonus étant qu’une application écrite pour X tournant sur Wayland avec la couche de compatibilité devrait bénéficier de certaines caractéristiques de la nouvelle infrastructure et finalement mieux tourner que nativement sous X.
Transparence réseau
La transparence réseau pour les applications natives Wayland avait été laissée de côté dans un premier temps, mais ça a évolué.
Notons que l’utilisation du réseau par Wayland pourra être différente de celle de X11 :
le nombre de RTT nécessaire : Kristian Høgsberg a dit qu’il avait fait très attention à avoir un protocole asynchrone minimisant les allers‐retours entre les clients et le serveur*. Ce point pourrait être donc meilleur qu’avec X. Pour rappel, NX avait été créé en grande partie pour améliorer cet aspect de X ;
la bande passante utilisée : là, Wayland ne sera pas forcément bon par rapport à X, car ce sont uniquement des tampons qui sont envoyés, contrairement à X qui peut envoyer des tampons, mais aussi des commandes de dessin. À suivre, donc.
(*) : Cependant, il a précisé qu’il n’avait pas fait de tests en simulant une forte latence.
La décoration des fenêtres par les clients
En fait, la décoration des fenêtres par les clients est une des caractéristiques du serveur d’affichage Weston, pas du protocole Wayland : les développeurs de KDE ont d’ailleurs prévu que ce soit le serveur d’affichage qui affiche les décorations des fenêtres.
En dehors du fait de savoir qui affiche les décorations, notons qu’à l’heure actuelle la question de la cohérence graphique se pose déjà quand on fait tourner une application GNOME sous KDE et vice‐versa, donc ce n’est pas vraiment nouveau.
Différences avec X.Org
Comme nous l’avons écrit plus haut, Wayland permet juste de passer des images (des tampons) entre les clients et le serveur, il n’a donc pas de commandes de dessin comme X. En simplifiant, on peut considérer que Wayland c’est l’extension DRI 2 de X (que l’on doit d’ailleurs à un certain Kristian Høgsberg…).
Wayland peut fournir une notification pour prévenir quand l’image fournie a été affichée, c’est ce qui doit permettre de faire des animations fluides.
Avec Wayland, les applications ne savent pas où le serveur d’affichage met ses fenêtres : pas de coordonnées absolues dans le protocole.
X.Org est implémenté par tous les UNIX, mais Wayland utilise des briques logicielles uniquement disponibles sur Linux actuellement (principalement KMS, nous revenons sur ce point un peu plus loin).
Adaptation des bibliothèques graphiques existantes
Les bibliothèques graphiques Clutter, EFL (Enlightenment Foundation Libraries), GTK+, Qt et SDL (Simple DirectMedia Layer) sont en cours de portage sur Wayland, avec Clutter et EFL qui sont prêts ou quasiment, et GTK+ (le portage est presque complet avec la version 3.4.1), Qt (il faudra la future version 5) et SDL qui sont un peu derrière. Ces portages devraient s’accélérer à présent que l’API de Wayland est stabilisée.
Quant aux applications elles‐mêmes, celles utilisant GTK+ devraient logiquement être prêtes avant celles utilisant Qt, pour la simple raison que GTK+ 3 est là depuis le 10 février 2011 quand Qt 5 n’est pas encore sorti. Théoriquement une application utilisant GTK+ 3 et n’appelant pas directement Xlib devrait être parée pour Wayland.Mesa va rapidement connaître une légère mise à jour pour intégrer les dernières modifications du projet, passant en version 9.0.1.
VA-API dans sa dernière version (1.1.0) est censée également être au point pour Wayland.
Propos finaux
Il n’y a pas que Linux dans la vie !
Une question importante se pose dès lors que Wayland se veut le remplaçant de X.Org : pourra‐t‐il — comme X.Org — bénéficier aux autres Unices (BSD…) ?
La logique de Wayland ne s’y oppose pas, mais son implémentation actuelle le permet‐elle ?
Répondre à cette question implique de regarder si les briques sur lesquelles repose Wayland sont portables ou portées sur les autres systèmes accueillant actuellement X.Org.
KMS obligatoire
FreeBSD est relativement avancé en la matière, avec les portages de GEM et KMS en cours pour les puces Intel, qui devraient se concrétiser avec la version 10 du projet (lire ici, ici et là). KMS pour puces NVIDIA et AMD prendra un peu plus de temps (les pilotes libres correspondants utilisent TTM au lieu de GEM).
Ce travail bénéficie directement à DragonFly BSD où les développements semblent en revanche se concentrer sur les puces AMD pour le moment (lire ici).
Solaris aurait déjà porté KMS pour puces Intel (lire ici).
À noter qu’une réécriture partielle de KMS est prévue par Intel pour la prochaine version 3.7 de Linux, qui devra être transposée dans les portages sus-évoqués…
udev, une dépendance facultative
udev était requis par Weston pour gérer les périphériques envoyant des évènements par evdev (udev et evdev étant spécifiques à GNU/Linux).
Le portage de Wayland sur Android (en cours de réalisation par Pekka Paalanen) a eu pour effet de supprimer la dépendance obligatoire à udev. Ainsi, udev reste une dépendance de Weston sous GNU/Linux, mais pas sous Android.
Si Weston utilise toujours evdev, le remplacer par un système équivalent sur un noyau autre que Linux ne devrait pas être trop difficile semble‐t‐il.
L’architecture de Wayland elle‐même est indépendante de ces questions.
systemd ? Pas indispensable
L’architecture de Wayland utilise la variable d’environnement XDG_RUNTIME_DIR
que systemd implémente actuellement sous GNU/Linux. systemd lui‐même ne sera pas requis si cette variable est implémentée d’une autre manière sur le système cible.
Tout ça c’est bien beau, mais ça arrive quand chez nous ?
Comme le souligne Kristian Høgsberg lui‐même, et contrairement à ce que laisse entendre le titre tapageur de la dépêche, atteindre la version 1.0 ne signifie pas que Wayland va magiquement et instantanément remplacer X.Org dans toutes les distributions.
Wayland va certainement continuer de mûrir un peu et être testé un peu plus sérieusement (c.‐à‐d. à plus grande échelle) avant d’être proposé par défaut dans nos distributions.
En attendant, des CD autonomes (live CDs) sont à votre disposition pour vous faire une idée sans altérer votre système (Rebecca Black Linux ou Fedora, par exemple).
Aller plus loin
- Wayland, le site officiel (2137 clics)
- Pourquoi Wayland veut remplacer X, précédemment publié sur LinuxFr.org (1172 clics)
- Annonce officielle de Wayland 1.0 (211 clics)
- Ce qu’il reste à implémenter (la TODO list du projet) (473 clics)
- « What is the state of Wayland? », sur ChaosReigns.com (179 clics)
# Version 3.7 de Linux ?
Posté par Patrice G. . Évalué à -10.
"À noter qu’une réécriture partielle de KMS est prévue par Intel pour la prochaine version 3.7 de Linux, qui devra être transposée dans les portages sus-évoqués…"
Je suppose qu'il s'agit du noyau en version 3.7 ?
[^] # Re: Version 3.7 de Linux ?
Posté par R. Danell Olivaw . Évalué à 10.
C'est bien ce qui est écris.
[^] # Re: Version 3.7 de Linux ?
Posté par Patrice G. . Évalué à -10.
-- C'est bien ce qui est écris.
Non. Linux, il me semble, n'a pas de numéro de version, le noyau oui.
-- Euh… oui ? Tu imaginais quoi ?
Je n'imaginais rien.
[^] # Re: Version 3.7 de Linux ?
Posté par woprandi . Évalué à 10.
T'es au courant que Linux = noyau ?
[^] # Re: Version 3.7 de Linux ?
Posté par jihele . Évalué à 10.
Linux = noyau et Patrice G. != Patrick_g.
Méfiez-vous des contrefaçons !
[^] # Re: Version 3.7 de Linux ?
Posté par Patrice G. . Évalué à -8.
-- Linux = noyau et Patrice G. != Patrick_g.
-- Méfiez-vous des contrefaçons !
Pas la peine d'être insultant, je ne l'ai pas été en posant ma question.
[^] # Re: Version 3.7 de Linux ?
Posté par jihele . Évalué à 8.
Mon commentaire ne se voulait surtout pas insultant. Désolé si c'est ressenti comme ça. C'est la ressemblance avec le pseudo d'une légende de DLFP qui est amusante, a fortiori dans le contexte. Rien de plus.
Pour faire des citations, on peut utiliser le caractère "supérieur à" en début de ligne.
[^] # Re: Version 3.7 de Linux ?
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 4.
Lurk moar!
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: Version 3.7 de Linux ?
Posté par Patrice G. . Évalué à 10.
-- T'es au courant que Linux = noyau ?
Non, maintenant, oui.
[^] # Re: Version 3.7 de Linux ?
Posté par kowalsky . Évalué à 4.
Mais alors que croyais tu ?
C'est une vrai question, pas une attaque.
[^] # Re: Version 3.7 de Linux ?
Posté par Guillaume Denry (site web personnel) . Évalué à 9.
Sans vouloir jeter de l'huile sur le feu, ce qui m'intrigue, c'est que son compte a été créé en 2003. Et qu'il n'apprend que maintenant que linux est un noyau.
[^] # Re: Version 3.7 de Linux ?
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à -4.
Il faut croire que pour certains lurker pendant 9 ans, ça n'est pas assez.
http://linuxfr.org/users/foid/comments
Patrice G. a écrit 4 commentaires
Lurk moar oldf…riend!
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: Version 3.7 de Linux ?
Posté par gnumdk (site web personnel) . Évalué à 4.
[^] # Re: Version 3.7 de Linux ?
Posté par Strash . Évalué à 5.
Ce qu'essaient de te dire les personnes au dessus est que Linux = Le noyau.
Donc dire "Linux 3.7" est strictement équivalent à dire "Le noyau Linux version 3.7".
Source, par exemple, le sujet du message annonçant la RC2 de Linux 3.7 : https://lkml.org/lkml/2012/10/20/136
[^] # Re: Version 3.7 de Linux ?
Posté par Yth (Mastodon) . Évalué à 5.
Alors remettons les choses au point :
Linux est un noyau.
Il y a moult distributions basées sur ce noyau, on les appelle des distributions Linux, ou par élision et commodité « des Linux » (ou GNU/Linux).
Mais Linux reste le seul noyau.
Et donc Linux - tout court - a bien une version 3.7.
Yth.
[^] # Re: Version 3.7 de Linux ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Distribution Linux et distribution GNU/Linux, ce n'est pas équivalent. Android est une distribution Linux, mais pas GNU.
[^] # Re: Version 3.7 de Linux ?
Posté par Michaël (site web personnel) . Évalué à 7.
Et kfreeBSD est une distribution GNU mais pas Linux!
[^] # Re: Version 3.7 de Linux ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Euh… oui ? Tu imaginais quoi ?
[^] # Re: Version 3.7 de Linux ?
Posté par Xaapyks . Évalué à 10.
Vous n'y connaissez rien ! C'est pas ce que Gérard Mathieu Stellman a dit ! On dit JNU/Linux et il a pas de version parce que le noyau a du posix à micro particules dedans.
A mort le logiciel prioritaire.
[^] # Re: Version 3.7 de Linux ?
Posté par Wawet76 . Évalué à 1.
Faut revoir tes trolls. C'est privateur, pas propriétaire.
[^] # Re: Version 3.7 de Linux ?
Posté par fravashyo . Évalué à 8.
Où as-t-il dit que c'était propriétaire ? (relis bien son commentaire) ;)
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Version 3.7 de Linux ?
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 10. Dernière modification le 23 octobre 2012 à 15:25.
Qu'ils sont bêtes ces rédacteurs : Linux en est à la version 12.10, c'est le noyau qui est à la version 3.7 !
GNU's Not Unix / LINUX Is Not Unix Xernel
# Gestionnaire de fenêtres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 0.
Si j'ai bien compris, pour mettre en œuvre un gestionnaire de fenêtres, il faut coder un serveur Wayland alternatif ? Ça n'a jamais été clair, cette histoire, mais si c'est le cas, c'est bon, Wayland c'est mort pour être adopté, le premiers à résister seront les développeurs, grands utilisateurs de gestionnaires de fenêtres alternatifs.
[^] # Re: Gestionnaire de fenêtres
Posté par gnumdk (site web personnel) . Évalué à 10.
Non, c'est un un serveur d’affichage alternatif, à savoir un équivalent de weston… C'est déjà ce que veut faire le projet KDE. Gnome je sais pas.
[^] # Re: Gestionnaire de fenêtres
Posté par claudex . Évalué à 8.
Enlightment aussi http://trac.enlightenment.org/e/wiki/Wayland
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Gestionnaire de fenêtres
Posté par reno . Évalué à 5.
Pourquoi tu réponds non?
Ce qu'il dit au début est correct (serveur Wayland == serveur d'affichage), donc si tu veux avoir un gestionnaire de fenetre alternatif, il faut en fait créer (par exemple en forkant Weston) un serveur d'affichage complet.
Là ou c'est plus douteux c'est quand il considère que c'est mort puisque KDE et Gnome (etc) bossent pour que leur gestionnaires de fenetres soient des serveur d'affichage Wayland, donc ça me parait bien parti!
[^] # Re: Gestionnaire de fenêtres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
S'ils appellent « serveur d'affichage » un gestionnaire de fenêtres, très bien. En revanche, s'il s'agit d'un serveur complet, dans le même sens que pour X.Org, ça va demander une quantité invraisemblable de travail dupliqué. KDE et Gnome pourront le faire, mais les autres (WindowMaker, awesome, XMonad, wmii, ratpoison…) non. Ça va faire un gros clivage entre les développeurs un peu pointus qui resteront sous X.Org et les autres.
[^] # Re: Gestionnaire de fenêtres
Posté par gnumdk (site web personnel) . Évalué à 10.
Un serveur d'affichage c'est un "compositeur" sous Xorg:
- Compiz
- Kwin
- Mutter
[^] # Re: Gestionnaire de fenêtres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
D'accord, donc c'est moins hénaurme comme travail que de recoder Wayland. Donc ça devrait le faire pour les gestionnaires de fenêtres alternatifs du coup.
[^] # Re: Gestionnaire de fenêtres
Posté par claudex . Évalué à 3.
Et quelle est donc la partie compliquée du serveur Wayland compliquée à réimplémenter te dérange (il ne reste plus grand chose après le compositeur et le gestionnaire de fenêtre) ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Gestionnaire de fenêtres
Posté par Gof (site web personnel) . Évalué à 10. Dernière modification le 23 octobre 2012 à 13:55.
Wayland est un protocole. Tu confonds peut être avec Weston qui est une implementation du compositeur.
X.Org fait aussi beaucoup de chose au niveau graphique qui sont laissées au kernel dans le cas de Weston.
De plus, rien n'empêche aux gestionnaires de fenêtres alternatifs d'utiliser des bibliothèques.
(C'est déjà le cas: Une bibliothèque: http://qt.gitorious.org/qt/qtwayland et un exemple impressionnant de compositeur réalisé avec, http://www.youtube.com/watch?v=_FjuPn7MXMs )
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Gestionnaire de fenêtres
Posté par Olivier Serve (site web personnel) . Évalué à 9.
T'es pas fou d'écrire ça ! Les toolkits saylemal, c'est Benoit Jacob qui le dit !
[^] # Re: Gestionnaire de fenêtres
Posté par reno . Évalué à 3.
Relis l'article "Un serveur Wayland joue à la fois le rôle de compositeur, de gestionnaire de fenêtres et de serveur d’affichage.", et toi tu marque "s'il s'agit d'un serveur complet", pffff.
La source: http://wayland.freedesktop.org/architecture.html
[^] # Re: Gestionnaire de fenêtres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -3.
Ah donc en fait si, c'est bien un serveur complet. Duplication d'effort maximale, GNOME et KDE y arriveront peut-être, les autres resteront sous X.Org.
[^] # Re: Gestionnaire de fenêtres
Posté par Enj0lras . Évalué à 2.
C'est honteux, KDE et GNOME n'utilisent pas le même compositeur et WM, quelle duplication d'effort ! Il faudrait merger mutter et KWin ! Et vite.
Sérieusement, ça serait bien ici que les gens arrêtent de crier au loup sans cesse. Tu vois le diable là ou tu veux bien le voir.
[^] # Re: Gestionnaire de fenêtres
Posté par reno . Évalué à 1.
Tu ne modifie que la partie du serveur qui gère les fenêtres: http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html
[^] # Re: Gestionnaire de fenêtres
Posté par Maxime (site web personnel) . Évalué à 5.
Par curiosité, j'ai tapé "awesome wm wayland" et je suis tombé sur ceci : http://comments.gmane.org/gmane.comp.window-managers.awesome/8581
[^] # Re: Gestionnaire de fenêtres
Posté par antistress (site web personnel) . Évalué à 6. Dernière modification le 23 octobre 2012 à 12:18.
Quand tu regardes Mutter, GNOME a déjà un compositeur-gestionnaire de fenêtres, ils doivent l'adapter à Wayland à mon avis ça devrait pas être trop dur car basé sur Clutter qui est en phase avec Wayland (Intel des deux côtés).
Pour KDE ça risque d'être plus compliqué :
Cependant :
[^] # Re: Gestionnaire de fenêtres
Posté par Xaapyks . Évalué à 5.
http://lists.freedesktop.org/archives/wayland-devel/2012-October/005973.html
Hop déjà un compositeur non KDE ni gnome de "presque" fonctionnel.
[^] # Re: Gestionnaire de fenêtres
Posté par Enj0lras . Évalué à 2.
sinon, tu pourrais prendre la peine de te renseigner avant d'affirmer n'importe quoi.
Il s'agit pas d'un WM appelé serveur d'affichage, ni l'inverse, il s'agit d'un WM qui est un serveur d'affichage ainsi qu'un compositeur. Alors, oui, il faut recoder un serveur d'affichage pour recoder une WM. Mais, il y a plusieurs choses à prendre en compte :
Donc, il y a de fortes chances qu'on voit fleurir des compositeurs waylands adaptés, voire même des ports de wm existants pour X, pour ceux qui on une logique propre comme awesome.
[^] # Re: Gestionnaire de fenêtres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
C'est bon, je crois que je commence à comprendre. Ce ne sera pas aussi simple qu'avec X11 où le gestionnaire de fenêtres et un logiciel indépendant, mais ça n'impliquera pas de tout recoder, simplement de forker et de se faire chier à réintégrer les nouveautés.
Mais franchement, ça ne se devine pas tout seul. Le schéma d'architecture est particulièrement déroutant, il indique clairement que Wayland fait tout, et on en déduit que pour changer la gestion des fenêtres, il faut coder un autre Wayland.
[^] # Re: Gestionnaire de fenêtres
Posté par Larry Cow . Évalué à 3.
Mais bien sûr, et pour rajouter un format d'image à Gimp, il faut coder un autre Gimp.
Quand bien même le ce serait le cas, on peut raisonnablement espérer que Wayland est suffisamment modulaire pour qu'on puisse modifier le comportement de sa gestion de fenêtres sans casser son lien avec la carte graphique, non?
[^] # Re: Gestionnaire de fenêtres
Posté par cedric . Évalué à 3.
Le travail va effectivement etre plutot important pour tous les Window Manager qui n'ont pas de Composite Manager et qui n'utilise pas un toolkit supportant l'ecriture de composite manager. Peut-etre apparaitra-t'il des hacks dans Weston pour brancher leur logique, mais la tache n'est pas negligable pour eux.
[^] # Re: Gestionnaire de fenêtres
Posté par Eric P. . Évalué à 3.
D'apres la FAQ de Wayland:
En gros oui, il faut coder un serveur Wayland alternatif, mais ca devrait etre assez simple. Deja c'est plutot simple en soit, et surtout il y a la bibliotheque Wayland cote serveur qui aide grandement.
Donc j'imagine que KDE va implementer un KWin qui fait serveur Wayland, a utiliser a la place de Weston… Mais je serais interesse par des references a ce propos.
Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
[^] # Re: Gestionnaire de fenêtres
Posté par GnunuX (site web personnel) . Évalué à 2.
Je dois dire que je suis bluffé. En lisant la dépêche je me suis douté que tu avais déjà du lancer un troll stérile, mais de compétitions, avec des threads interminables, avec des arguments invérifiés, douteux ou contradictoires, des rebondissements. J'avais déjà quelque idée de troll imaginable dans la tête.
Et là, mais c'est grandiose ! Bon, en poussant un peu tu aurais pu faire croire que le fork du noyau linux serait nécessaire pour la prochaine version de GTK3, mais c'est déjà pas mal, je me délecte !
Bravo l'artiste (ou pas).
[^] # Re: Gestionnaire de fenêtres
Posté par JoeltheLion (site web personnel) . Évalué à 2.
Avec un peu de chance il vont nous pondre un truc scriptable assez facilement, et les gens pourront mettre en oeuvre ce genre de choses rapidement.
Je ne suis pas très inquiet :)
# Nous n'avons pas les mêmes valeurs
Posté par Christophe Merlet (site web personnel) . Évalué à 7.
Rebecca Romijn ou Claudia Black, OK, mais Rebecca Black, non merci !
[^] # Re: Nous n'avons pas les mêmes valeurs
Posté par Crovax31 . Évalué à 7.
Probablement parce-que vendredi c'est permis…
# Non, Xorg n'est pas (encore) mort...
Posté par lordblackfox . Évalué à -10.
…Pour la simple raison que Wayland ne tourne que sur Linux.
[^] # Re: Non, Xorg n'est pas (encore) mort...
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu as lu la dépêche?
Ca y est, après systemd puis journald, voila les "explications" pourries arriver pour Wayland… Le prochain sera?
[^] # Re: Non, Xorg n'est pas (encore) mort...
Posté par lordblackfox . Évalué à 5. Dernière modification le 23 octobre 2012 à 11:39.
Oui mon chou, par contre on dirait que tu m'as mal lu.
Bon, je m'explique: Wayland n'est pas encore disponible sur d'autres plateformes, donc on a encore besoin de Xorg, donc Xorg n'est pas encore mort. Réaction au titre simplement, d'où le "(encore)" dans le mien.
Pour ton allusion aux "commentaires pourris" de systemd, je n'ai jamais dit saymalwayland, du tout.
Enfin, je dis ça, je dis rien…
[^] # Re: Non, Xorg n'est pas (encore) mort...
Posté par barret benoit . Évalué à 2.
ça a été très vite "débattu" dans la tribune de ré(d)action, où il était "juste" question de trouver/proposer un titre
trollesqueaccrocheur.[^] # Re: Non, Xorg n'est pas (encore) mort...
Posté par antistress (site web personnel) . Évalué à 8. Dernière modification le 23 octobre 2012 à 12:25.
Sinon on peut lire la dépêche jusqu’au bout :
Comme dirait Ken : X.Org est mort mais il ne le sait pas encore
[^] # Re: Non, Xorg n'est pas (encore) mort...
Posté par brendel . Évalué à 9.
Ça à rien avoir, c'est même l'inverse : Wayland est un remplaçant simple à X.org qui est devenu un bloatware, en faisant la même chose (affichage-clavier-souris).
Systemd est un bloatware qui remplace pas mal de chose simple.
Après on peu discuter sur le plan technique, mais je vois peu de reproches à faire à Wayland sur le principe.
En plus franchement, dire que les gens ont des explications "pourries" quand elles ne vont pas dans ton sens…
[^] # Re: Non, Xorg n'est pas (encore) mort...
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
La transparence réseau intégrée dans le coeur du protocole ?
[^] # Re: Non, Xorg n'est pas (encore) mort...
Posté par zebra3 . Évalué à 8.
Faudra juste trouver des mainteneurs, comme pour init…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Instant de fierté
Posté par Creak . Évalué à 10.
Snif… C'est moi qui ait créé l'article Wikipedia la pile graphique de Linux. Il a été largement amélioré par Antistress, merci à lui!
Ca fait plaisir de voir qu'une de ses contributions sert à quelque chose :)
Voilà, c'était mon petit instant de fierté, ça fait du bien :)
Excellent article au demeurant!
Merci aux auteurs!
[^] # Re: Instant de fierté
Posté par antistress (site web personnel) . Évalué à 7. Dernière modification le 23 octobre 2012 à 11:07.
Arf c'était toi ? Le monde est petit ! L'idée était bonne, j'ai saisi la balle au bond quand j'ai écrit un article similaire sur mon blogue :-)
Et dimanche dernier j'ai fait un joli schéma explicatif
[^] # Re: Instant de fierté
Posté par Creak . Évalué à 3.
C'était à force de traîner sur Phoronix et de rien comprendre aux articles parce que chaque paragraphe utilisait au moins 10 éléments de la stack graphique :)
Cool le schéma!! Ca marche bien mieux qu'un long chapitre! :)
[^] # Re: Instant de fierté
Posté par antistress (site web personnel) . Évalué à 3.
pareil !
[^] # Re: Instant de fierté
Posté par Old Geek . Évalué à 2.
Et wikipedia ne t'es pas tombé dessus pour l' "auto-plagiat" ?,
j'ai abandonné les contributions suite à ça …
[^] # Re: Instant de fierté
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5. Dernière modification le 23 octobre 2012 à 15:26.
Quand c'est sous CC-BY-SA à la source, ça ne doit pas déranger Wikipédia…
C'est logique en même temps, quand tu reprends un de tes propres textes sur Wikipédia :
[^] # Re: Instant de fierté
Posté par Old Geek . Évalué à -2.
oui les contraintes de modification de licence du texte d'origine, ou de preuve d'auteur sont rédhibitoires aux contributions.
Je n'ai pas à changer la licence du texte d'origine pour en offrir une copie et puis quoi encore !, ni à prouver quoi que ce soit… Lorsque l'on m'explique que wikipedia vends le contenu qu'on lui donne et que l'on doit lui céder tous nos droits, ce n'est plus vraiment dans l'esprit que je m'en faisait…
[^] # Re: Instant de fierté
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7. Dernière modification le 23 octobre 2012 à 16:03.
Si cette copie en question est sur Wikipédia, elle est sous CC-BY-SA, donc en pratique ça revient à changer le texte de licence, puisqu'il est alors disponible sous deux licence, une propriétaire sur ton site, et une libre sur Wikipédia, et que les gens peuvent donc choisir la licence qu'ils préfèrent respecter parmi ces deux-là.
Si : que tu es bien l'auteur d'origine, puisque lui seul a le droit de relicencier son texte.
Tu sors ça d'où ? Ils ont le droit de le faire, tout le monde a le droit de le faire en fait, et ça ne me choquerait pas, mais je n'ai jamais entendu parler de ça.
Nawak. Tu dois mettre tes textes sous licence CC-BY-SA, aucune cession intégrale ou exclusive là-dedans. Perso mes textes sont sous CC-BY-SA à la base, donc je n'ai pas ces problèmes.
[^] # Re: Instant de fierté
Posté par O'neam Anne . Évalué à 1.
Pour le changement de licence, ce n'est vrai que si la licence en question est strictement plus restrictive que la CC-BY-SA. Si le texte existe ailleurs en CC-BY, par exemple, alors les gens pourront en faire un dérivé sans conserver la licence. Et cet exemple parait un peu stupide parce que n'importe qui peut prendre un texte en CC-BY et le relicencier en CC-BY-SA, à priori, mais si jamais l'auteur donne le choix entre une CC-BY-SA et une licence payante qui permet de relicencier des textes dérivés avec une licence très restrictive, ça peut être plus problématique si Wikipédia demande effectivement de changer la licence du texte d'origine. Mais je doute que ça soit le cas, tant que l'auteur du texte prouve qu'il est d'accord avec la publication en CC-BY-SA.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Instant de fierté
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 23 octobre 2012 à 19:03.
Ou alors, tu n'as absolument rien compris au libre…
Libre != anti-commercial.
l’interdiction de vendre serait d'ailleurs non libre.
Quelle idée du libre tu te faisais? Si c'est du non commercial, tu t'es trompé effectivement, et lourdement.
Super pratique tes exigences.
En pratique, du coup, c'est juste infaisable, car cette non exigence amènerait tellement de procès dans le cul que tu passerait du temps qu'à gérer les procès et pas faire du libre.
Pourquoi rédhibitoire? C'est simple, ça coûte rien (ça sera libre à la fin dans tous les cas), donc rien de rédhibitoire, au contraire!
Plus une mauvaise excuse pour ne pas contribuer plus qu'autre chose, pourquoi ne pas simplement pas dire "pas envie de faire du libre"? Ce n'est pas mal.
[^] # Re: Instant de fierté
Posté par antistress (site web personnel) . Évalué à 6. Dernière modification le 23 octobre 2012 à 18:38.
Ça ressemble quand même à une mauvaise excuse.
# wayland
Posté par modr123 . Évalué à -10.
il fait quoi de mieux qu X.org ?
[^] # Re: wayland
Posté par gnumdk (site web personnel) . Évalué à 10.
A priori, il permet de lire les news sur Linuxfr en entier.
[^] # Re: wayland
Posté par modr123 . Évalué à -1.
pas avec firefox ni chrome tu aurais du lire mieux les liens
[^] # Re: wayland
Posté par reno . Évalué à 9.
En condensé: c'est surtout mieux pour les développeurs, pour le reste Wayland ~= extension DRI2 de X.Org donc perf similaire à X en première approximation(si le toolkit utilise l'extension DRI2) mais il y a quand même quelques différences :
1) serveur Wayland = (serveur d'affichage + compositeur + gestionnaire de fenêtre) donc possibilité d'interagir avec une fenêtre transformée et moins d'IPC donc perf potentiellement légèrement meilleure.
2) l'API de Wayland contient une notification pour prévenir quand l’image fournie a été affichée: possibilité de faire des animations fluides.
3) si la gestion des décorations de fenêtre est faite par le client, le redimensionnement des fenêtres sera 'tear free'/sans cisaillement mais potentiellement saccadé si l'application est lente a répondre.
[^] # Re: wayland
Posté par Jux (site web personnel) . Évalué à 3.
Est-ce que le changement de carte vidéo à chaud (sur les portables qui ont deux cartes) est également facilité avec Wayland ? De mémoire, il me semble que c'était très compliqué à implémenter sous X.org.
[^] # Re: wayland
Posté par reno . Évalué à 3.
Il m'a toujours semblé que c'était plus un problème de Linux et de toolkit que d'X.Org mais les gens aiment bien taper sur X, je ne sais pas pourquoi..
Supposons qu'une application ait obtenu un tampon dans une carte et qu'on souhaite changer de carte --> problème!
[^] # Re: wayland
Posté par Eloi COUTANT . Évalué à 0.
Autrement dit : est-ce que cela pourra éventuellement résoudre le problème du système Optimus… qui n'est censé pas être implémentable avec X.org.
[^] # Re: wayland
Posté par antistress (site web personnel) . Évalué à 8. Dernière modification le 23 octobre 2012 à 12:30.
La bascule entre deux processeurs graphiques distincts au sein d'un même ordinateur portable, en fonction des priorités du moment (performance ou autonomie) sera rendu possible avec X.Org grâce aux derniers développements libres réalisés par Red Hat et Texas Instruments au sein de Linux 3.5 et RandR 1.4 (inclus dans X Server 1.13) + adaptation des pilotes correspondants.
Mais il faut des pilotes libres (couple nouveau/intel par exemple)
[^] # Re: wayland
Posté par modr123 . Évalué à -7.
le truc qui fait les effets ,dont je ne me sers jamais et que je trouve inutile marchait mal, donc on refait x c'est ça ?
[^] # Re: wayland
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Oui ;-(
Et la transparence réseau dont tu ne te sers jamais n'est plus là par défaut ;-)
[^] # Re: wayland
Posté par barret benoit . Évalué à 2.
ça a été débattu sur linuxfr cette année
dans le journal "Pourquoi Wayland veut remplacer X"
# Pilotes graphiques libres
Posté par jihele . Évalué à 5.
Je suis étonné de ne pas avoir vu de commentaire à ce sujet.
Combien sommes nous à avoir la chance de pouvoir utiliser les pilotes libres ? (A moins que ça n'ait déjà été fait récemment, ça peut mériter un sondage.)
Est-ce que ça va condamner les propriétaires de matériel non pris en charge à jeter leur matos ? A rester sur de vieilles versions logicielles lorsque le support de Xorg sera abandonné ?
J'imagine qu'on a du temps devant nous avant l'abandon de Xorg, mais je ne parierai pas que ça va s'arranger rapidement du côté des pilotes de carte graphique.
[^] # Re: Pilotes graphiques libres
Posté par antistress (site web personnel) . Évalué à 5. Dernière modification le 23 octobre 2012 à 12:35.
Les pilotes privateurs çaÿlemal
J'achète des IGP Intel depuis que j'utilise Linux parceque je ne suis pas maso (GMA 950, HD Graphics 4000).
Sinon faut te plaindre à NVidia, pas aux développeurs Linux et co
Heureusement il y a de gros progrès dans les cartons pour Nouveau (attends la dépêche à venir sur linux 3.7)
Bonne idée, le sondage !
[^] # Re: Pilotes graphiques libres
Posté par jihele . Évalué à 2.
Je ne me plains pas, et je ne pointe le doigt sur personne, hein. D'autant que je suis parfaitement content (ou presque) de mon pilote libre. J'essaye juste de prendre en compte les conséquences de la nécessité d'utiliser des pilotes libres.
Je doute d'ailleurs que les développeurs eux-même, qui sont des gens responsables, ne se posent pas ce genre de questions.
Et il ne s'agit évidemment pas, comme j'ai pu le lire plus bas, de bloquer tout développement qui ne serait pas compatible avec les pilotes propriétaires, dont il faudrait évidemment se débarrasser.
C'est fait.
[^] # Re: Pilotes graphiques libres
Posté par antistress (site web personnel) . Évalué à 1.
J'ai pas trouvé le sondage, iléou ?
[^] # Re: Pilotes graphiques libres
Posté par jihele . Évalué à 1.
Ben je l'ai proposé, mais c'est pas moi qui valide. Et je sais pas où on voit la liste des propositions en attente.
[^] # Re: Pilotes graphiques libres
Posté par antistress (site web personnel) . Évalué à 1.
moi non plus
[^] # Re: Pilotes graphiques libres
Posté par jihele . Évalué à 1.
Ici
[^] # Re: Pilotes graphiques libres
Posté par Littleboy . Évalué à 6.
Et que tu n'as que peu de besoins en perf…
[^] # Re: Pilotes graphiques libres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 0.
Traduction en langage commun : parce que tu ne joues pas à des FPS récents. Parce que pour tout le reste, des cartes graphiques intégrées Intel, c'est parfait.
[^] # Re: Pilotes graphiques libres
Posté par lolop (site web personnel) . Évalué à 10.
Les cartes graphiques puissantes ne sont pas utilisées que pour le jeu.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Pilotes graphiques libres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -8.
Et pour quoi d'autre, au juste ? De façon détournée comme coprocesseur pour du calcul de montage 3D, à part ça je ne vois pas.
[^] # Re: Pilotes graphiques libres
Posté par Albert_ . Évalué à 7.
Il commence a y avoir pas mal de monde dans le domaine scientifique qui se servent du GPU pour faire des calculs.
[^] # Re: Pilotes graphiques libres
Posté par R. Danell Olivaw . Évalué à 6.
Il existe d'autre logiciel, plus courant, utilisant CUDA™ ou Opencl™ comme darktable : http://www.darktable.org/2012/03/darktable-and-opencl/
[^] # Re: Pilotes graphiques libres
Posté par Shuba . Évalué à 8.
Il y a pleins d'endroits ou une carte graphique puissante est utile en fait:
Et de manière générale, les cartes devenant de plus en plus programmables, de plus en plus de domaines s'intéressent à l'accélération que peut leur procurer l'utilisation du GPU.
[^] # Re: Pilotes graphiques libres
Posté par xcomcmdr . Évalué à 4.
Pour lire des vidéos en HD via le GPU (c'est sympa pour la batterie, et ça chauffe beaucoup moins) ?
Pour appliquer des filtres graphiques rapidement ?
Pour faire de la 3D ?
Pour faire tourner des moteurs physiques ?
Pour faire des calculs qui passent mal sur un CPU ?
Pour pouvoir utiliser Compiz (qui a des plugins utiles tels que Scale) ou Unity/Gnome Shell ?
etc…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pilotes graphiques libres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Les points les plus courants marchent très bien sur CG Intel, à savoir :
[^] # Re: Pilotes graphiques libres
Posté par lolop (site web personnel) . Évalué à 5.
Un exemple, avec utilisation puissance 3D pour de la 3D: j'ai un collègue qui travaille sur une plateforme d'avatars avec des rendus réalistes temps réel, et il apprécie grandement la puissance des GPU. D'autres collègues travaillent dans une CAVE avec 7 surfaces de projections, bi-stéréo relative… pareil, ça bouffe du calcul pour du rendu 3D.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Pilotes graphiques libres
Posté par moi1392 . Évalué à 7.
Je pousse à bout une quadro 6000 au boulot (un monstre avec 6 Go de ram !!) et je ne bosse pas dans le jeu vidéo, et je suis bien content de pouvoir bosser sous linux (et mes clients aussi !)
Donc non, intel n'est pas parfait du tout pour tout ce qui n'est pas des FPS récents.
[^] # Re: Pilotes graphiques libres
Posté par jihele . Évalué à 2.
mais tu ne nous dis pas dans quel domaine tu bosses…
[^] # Re: Pilotes graphiques libres
Posté par Gabin II . Évalué à 7.
Et ça changerait quoi? Tu doutes que Linux puisse servir à autre chose que Compiz et Xonotic?
Donc, ton Xmonad qui gère ses 50 rxvt transparents illisbles dans lesquels tu suis les logs de ton server Apache qui propulse du Rails n'est pas représentatif de l'utilisation principal d'un ordi sous Linux.
Heureusement que nVIDIA a très tôt supporté Linux et le marché pro est-ce qui a amené ce support.
ps: bien que je te tutoie, je ne m'adresse pas directement à toi, c'est juste qu'il est fréquent de voir des linuxiens réduire l'intérêt du support accélèré de nos chères GPU.
[^] # Re: Pilotes graphiques libres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
C'est nouveau, que ce soit disponible pour GNU/Linux, non ?
[^] # Re: Pilotes graphiques libres
Posté par jihele . Évalué à 4.
Ah non, moi pas du tout, je suis plutôt d'accord. Simplement la question était de savoir quels étaient les usages autre que ceux-là qui nécessitaient du GPU, etc, je vais pas reformuler. Et tu réponds un peu à côté en disant qu'il y en a… mais sans expliciter.
Après, où tu travailles, toi, personnellement, c'est pas mon problème, c'est sûr.
D'accord, d'accord.
[^] # Re: Pilotes graphiques libres
Posté par moi1392 . Évalué à 6.
Rendu d'objets 3D très gros et très complexes (j'ai des vbo de 1 Go par coupe environ…) et simulation (du cuda sur de très gros volumes de données)
En fait, s'ils faisaient des cartes avec plus de 6 Go de ram, je suis sur que nos clients les achèteraient et augmenterait la taille de leurs modèles en conséquence. Parce que pour l'instant, pour les algos qui s'y prêtent, c'est juste incomparable en terme de performance avec les versions cpu.
Et pour te dire, on pousse tellement les cartes à bout, qu'on en arrive même à certifier des gammes de cartes avec des versions de pilotes et récement j'ai même du blacklister une version de bios buggué d'une carte !
[^] # Re: Pilotes graphiques libres
Posté par Prosper . Évalué à 2.
le trading peut etre ?
[^] # Re: Pilotes graphiques libres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Bon, sous la pression populaire, j'amende mon affirmation. Pour les usages courants, hors des FPS récents, une CG intégrée Intel est parfait.
[^] # Re: Pilotes graphiques libres
Posté par moi1392 . Évalué à 3.
Là je suis d'accord :)
D'ailleurs, je suis de l'avis de pas plusieurs personnes qui ont posté ici, si je pouvais avoir les mêmes performances avec un pilote libre, je n'hésiterais pas un instant, même à fonctionnalités moindres.
Du coup, quand dans la pratique, c'est plutôt moins de performances mais plus d'intégration avec X, je comprends que les personnes qui n'ont pas besoin de grosses performances (qui représentent, à la louche, 99,99% des non joueurs de jeux récents), soient très contentes de leurs pilotes libres.
[^] # Re: Pilotes graphiques libres
Posté par Moonz . Évalué à 1.
Et les non joueurs, ça représente combien de % de la population ?
Non, parce que même moi qui me considère pas comme un gros joueur, j’apprécie une LAN de temps en temps entre collègue un vendredi soir…
[^] # Re: Pilotes graphiques libres
Posté par G.bleu (site web personnel) . Évalué à 6.
C'est pas un soucis : Quake 3 (et sa flopée de dérivés libres) tourne très bien sur à peu près n'importe quoi… et de toute façon tout le monde sait que aucun bon jeu n'est sorti depuis 2004 ! ;-)
[^] # Re: Pilotes graphiques libres
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Beaucoup, dès qu'on sort de l'effet de communauté, qui fait que les gens que tu connais te ressemblent assez. Parmi mes parents, mes sœurs, mes amis non geeks : zéro joueur. Après ce n'est pas forcément représentatif non plus, mais les joueurs ne sont qu'une communauté particulière.
[^] # Re: Pilotes graphiques libres
Posté par Moonz . Évalué à 2.
Beaucoup je suis d’accord, j’étais longtemps un non-joueur entouré de non-joueurs d’ailleurs, mais 99.99% ça me surprendrait énormément, c’est ce que je voulais dire.
[^] # Re: Pilotes graphiques libres
Posté par claudex . Évalué à 10.
J'utilise les pilotes libre avec Intel et AMD et ça marche bien, je n'ai pas trop à me plaindre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pilotes graphiques libres
Posté par Phibrizo (site web personnel) . Évalué à 6.
Oui, ça m'a titillé aussi.
Je suis le premier à vouloir des pilotes libres, mais je veux aussi que ça marche. Et, même si cela date maintenant un peu, mes derniers démêles avec les pilotes libres pour l'accélération 3D m'ont laissé de très mauvais souvenirs. En clair, mes jeux marchaient très mal ou pas du tout, tandis que je n'ai jamais eu de problème avec les pilotes propriétaires nvidia.
Je suis prêt à accepter qu'un pilote libre marche (un peu) moins bien et (un peu) moins vite qu'un pilote propriétaire, mais pas qu'il ne marche pas du tout. Donc, si KMS ne permet pas de faire tourner ma carte correctement en 3D, je risque de m'accrocher à X longtemps.
Et, pendant que j'y suis, la compatibilité de wayland avec X permet-elle de faire tourner des applications existantes sans les recompiler ? En somme, est-ce que les jeux 3D que j'ai achetés peuvent espérer fonctionner directement ou dois-je espérer un éventuel patch de leur auteur pour les faire tourner sous Wayland ?
Les devs voient certainement plein d'avantage à passer sous Wayland, mais il faudrait au minimum qu'il n'y ait pas de désavantage pour l'utilisateur final. Si l'unique motivation qui me poussait à utiliser un OS était la pureté du design, je serais sous Hurd aujourd'hui…
[^] # Re: Pilotes graphiques libres
Posté par antistress (site web personnel) . Évalué à 3.
Il faut bien comprendre que les avantages pour les développeurs, à savoir une implémentation simple, claire et facilement maintenable, aura des répercussions sur l'utilisateur qui profitera potentiellement d'un produit moins bogué et plus performant. Ce sont les deux facettes d'une même médaille.
Le but de la couche compatibilité X et de pouvoir continuer à utiliser les applis existantes telles que. Après faudra voir si ça marche…
[^] # Re: Pilotes graphiques libres
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Moins bogué, certes, plus performant, c'est à voir. J'ai pas dis que ça va aller plus vite. La transparence réseau pourrait ne pas être plus performante…
Si on regarde ces dernières années, on nous dis à chaque fois que ça va aller plus vite, que la dernière version est mieux et tout et tout mais on doit au final changer de PC car celui-ci se met à traîner ;-)
[^] # Re: Pilotes graphiques libres
Posté par letsyl . Évalué à 4.
C'est à voir en effet, mais j'aurais tendance à être optimiste sur cet aspect. Le protocole X n'est plus utilisé de la même manière qu'à ses origines.
Les toolkits modernes manipulent principalement des buffers.
Wayland fonctionne sur ce principe et évite certaines contorsions liées à X.
Donc en pratique, on peut espérer un gain en performances, y compris du côté réseau.
[^] # Re: Pilotes graphiques libres
Posté par moi1392 . Évalué à 1.
J'ai plutôt tendance à penser le contraire moi.
Plus performant (architecture proche de DRI pour le rendu 2D, alors que c'était réservé à la 3D avant) mais plus bogué aussi, du moins dans les premiers temps.
Et je vois déjà les râleurs se plaindre des premières versions qui crashent avec de superbes trolls de compétition élevés au grain non ogm et au mille feuille au kirsh !
[^] # Re: Pilotes graphiques libres
Posté par Adrien . Évalué à 4.
pour info, avec le pilote libre radeon, je peux jouer à Xonotic, et presque jouer à 0ad ou flightgear (ça rame beaucoup, 10/15 FPS). Avec le pilote non-libre ça marcherais nickel.
C'est moins bon, mais ça s'améliore d'année en année.
[^] # Re: Pilotes graphiques libres
Posté par GnunuX (site web personnel) . Évalué à -3.
Très convainquant comme commentaire. Comme certains ne sont pas regardant à l'achat de leur matos, il faudrait arrêter toutes évolutions non validées par Nvidia (ou pas en fait).
[^] # Re: Pilotes graphiques libres
Posté par Phibrizo (site web personnel) . Évalué à 10.
Ha mais c'est tout le contraire. Je suis très très regardant sur le matos, j'achète justement celui qui me donnera ce que je recherche. Et pour l'instant, l'unique fabriquant qui me permette vraiment de jouer sous Linux, c'est nvidia. J'ai essayé 2 fois de migrer sous ATI (pilotes libres, toussa), et 2 fois je suis revenu sous nvidia.
Si une alternative libre à une solution propriétaire existe, je suis le premier à l'utiliser. Mais il se trouve que les jeux sont l'unique raison pour laquelle je conserve une partition windows. Ce qui veut dire (pour le moment) que la seule solution qui me permette de ne pas booter Windows trop souvent passe par nvidia. Et par ses pilotes propriétaires.
Pour la première fois peut-être, une floppée de très bon jeux est prévue prochainement pour Linux:
Il y a aussi Chris Roberts qui prévoit de revenir au Space Opéra, et qui hésiterait à porter son jeu sous Linux.
Alors, quel intérêt pour moi d'installer Wayland et des pilotes libres si je ne peut pas y jouer ? Si je dois installer un OS uniquement pour surfer sur internet et relever mes mails, pour la pureté et la gloire du logiciel libre, autant passer à BSD.
Donc, le jour où j'aurais la garantie que Wayland et les pilotes libres ne se mettront pas en travers de ma route, entre moi et mes jeux, j'envisagerait de l'installer. Je serais même prêt à acheter une nouvelle carte graphique juste pour ça s'il le faut. Mais pas avant.
[^] # Re: Pilotes graphiques libres
Posté par Moonz . Évalué à 10. Dernière modification le 23 octobre 2012 à 18:41.
Tu connais beaucoup toi de cartes avec un pilote libre qui aient les mêmes performances sous Linux qu’une Geforce avec les pilotes proprio ?
Si c’est le cas, ça m’intéresse beaucoup.
[^] # Re: Pilotes graphiques libres
Posté par omer666 . Évalué à 3.
J'ai quelques pistes de réflexion à ce sujet :
D'une part, nVidia aurait des plans pour Wayland… j'ai bien dit "aurait"
Lien vers l'article de Phoronix à ce sujet…
Ensuite depuis que Linus les a un peu secoués (:p) ils ont l'air de mettre un peu plus de bonne volonté dans leur support des plate-formes libres. Si une bonne partie des distributions majeures affiche une volonté ferme de passer à Wayland, alors il y a des chances qu'ils s'y mettent. Ils détiennent quand même un quasi-monopole du jeu sur Linux, et qui risque de s'accroitre encore avec l'arrivée de Steam et l'élargissement du marché du jeu sur Linux, ce qui commence donc à représenter un marché suffisamment important pour qu'ils ne s'en séparent pas bêtement. D'autant qu'AMD est bien plus impliqué qu'eux dans le développement des drivers ATI libres.
Alors deux solutions, ou nVidia sort un blob compatible Wayland et tout se passe comme à l'heure actuelle, soit ils quittent le bateau (ou du moins, ils n'embarquent pas) et il y a des chances pour que les Linuxiens se rabattent en masse sur les cartes de la marque rouge pétant (Intel ne constitue pas encore un véritable concurrent pour les joueurs dans la mesure où la puissance développée par leurs chipset est encore bien trop faible comparée à la GeForce la moins chère du marché). La question qui me vient immédiatement est : si ATI rencontre un franc succès, investiront-ils plus dans leurs drivers libre ?
[^] # Re: Pilotes graphiques libres
Posté par Larry Cow . Évalué à 9.
Remarque, si nVidia était plus impliqué qu'AMD dans le développement des drivers ATI libres, ce serait inquiétant.
(pardon)
[^] # Re: Pilotes graphiques libres
Posté par omer666 . Évalué à 2.
Hahaha, oui, c'est vrai. (Je parlais bien sûr de pilotes libres en général)
[^] # Re: Pilotes graphiques libres
Posté par Maclag . Évalué à 2.
Si j'étais un manager de chez nVidia, là tout de suite, tu m'aurais donné une idée machiavélique!! :-[
[^] # Re: Pilotes graphiques libres
Posté par Nonor . Évalué à 8.
Je les vois bien faire ça, nVidia a montré depuis des années sa motivation pour sortir un driver de qualité pour ses chipsets sous linux. Je n'ai pas dit parfait, je n'ai pas dit idéal, je n'ai pas dit en adéquation totale avec le développement du noyau et de ses fonctionnalités (suspend…..), mais j'ai dit de qualité. Ça n'est pas un hasard si pour le jeu sous Linux encore aujourd'hui c'est chipset nVidia + driver proprio qu'il faut pour tenir la route. Bref, ils ont également montré leur volonté à ne pas ouvrir leur blob. Je ne vois pas en quoi Wayland changerait quoi que ce soit à leur "stratégie"…
[^] # Re: Pilotes graphiques libres
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Pour préciser, nvidia sort un driver pour X. Celui-ci est porté sous diverses plate-formes (a ma connaissance, Linux, Solaris, FreeBSD). Je pense qu’économiquement pour Nvidia, Solaris reste encore le marché le plus juteux (On pense aux fermes de serveurs pour le rendu 3D des films …).
[^] # Re: Pilotes graphiques libres
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
A noter qu'il y a aussi tout le coté GPU avec Cuda, domaine important sous GNU/Linux (en plus les cartes TESLA ne sont pas donnée).
Je ne sais pas exactement ce qu'il y a de commun dans tout cela en interne chez nvidia mais je vois mal nvidia faire une croix sur le calcul GPU sous GNU/Linux !
[^] # Re: Pilotes graphiques libres
Posté par antistress (site web personnel) . Évalué à 2.
https://github.com/pathscale/pscnv/wiki
(plus d'infos dans une prochaine dépêche)
[^] # Re: Pilotes graphiques libres
Posté par Tonton Benoit . Évalué à 3.
Que KMS soit en EXPORT_GPL ne me semble pas un gros problème, de toute façon nvidia n'a, à ma connaissance, jamais eu l'intention d’abandonner son architecture unifiée au profit de DRI/KMS.
Personnellement j'utilise nouveau au quotidien et je ne démarre avec les pilotes nVidia que pour X-Plane (pas été cité celui-là comme "gros truc qui demande des performances 3D bien au delà de ce qu'offre les pilotes libres aujourd'hui" ?).
Si Wayland devient majoritaire nVidia portera ses pilotes dessus, j'ai pas trop de soucis à ce sujet, ce sera une bonne occasion de faire évoluer le module noyau en y intégrant la gestion des résolutions et pourquoi pas un framebuffer accéléré, un "KMS équivalent", car aujourd'hui il faut bien avouer qu'à part en 3D les pilotes nVidia sont très en retard sur nouveau et le standard du monde libre en général, pas de transition sans clignotement entre X et les consoles, pas de framebuffer accéléré (et même pas de framebuffer du tout, obligé d'utiliser un framebuffer vesa), moins stables que les pilotes nouveau…
[^] # Re: Pilotes graphiques libres
Posté par moi1392 . Évalué à 2.
Je suis d'accord pôur ce qui est du retard sur les standards et les protocoles de X (XRandR seulement supporté par les dernières versions… ça m'a bien fait chier perso)
Par contre, pour le stabilité (dans X en général), je n'ai jamais eu de gros soucis avec, pourtant je suis souvent très à jour au niveau des pilotes (y compris les version beta).
Il y a eu quelques versions problématiques, mais en règle générale, on pouvait toujours revenir à une ancienne version.
[^] # Re: Pilotes graphiques libres
Posté par Tonton Benoit . Évalué à 2.
Ben moi mes soucis ont commencés avec la fameuse "version problématique", mais ont continués après.
Bon c'est assez rare mais quand-même il arrive que l'écran devienne gris~clignotant et que la seule solution soit un reboot "à l'aveugle".
[^] # Re: Pilotes graphiques libres
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Pourtant c'est cette partie qui est vraiment importante. La fin du matériel géré directement par X c'est quand même un sacré progrès dans la propritude du truc.
[^] # Re: Pilotes graphiques libres
Posté par Tonton Benoit . Évalué à 3.
Oui mais ça ne passe pas forcement par GEM/DRI2/KMS
Rien n'a empêché jusqu'à présent nVidia de mettre la gestion de la mémoire, de la résolution, de l'accélération dans son module noyau, c'est peut-être même déjà le cas (manquerait qu'un framebuffer pour égaler nouveau ?) et si ils ne l'ont pas fait c’est, je pense, parce-qu'ils n'ont as trouvé opportun de "tout casser" du pilote pour X11 alors qu'il va falloir de toute façon refaire le travail pour Wayland.
[^] # Re: Pilotes graphiques libres
Posté par Niniryoku . Évalué à 3. Dernière modification le 23 octobre 2012 à 13:45.
Je ne sais pas combien de personne les utilisent, mais c'est mon cas. Et même pour moi qui suis un libriste intégriste qui n'a pas flash, je le fais par confort.
J'ai une carte Nvidia, et avec le pilote propriétaire, j'ai des ligne blanches horizontales qui défilent sur mon écran. Donc déjà, le pilote libre Nouveau est de meilleure qualité que le pilote propriétaire Nvidia Linux et Windows.
En plus, j'ai pas à galérer à installer/mettre à jour les pilotes propriétaire sur ma Fedora (sois avec le binaire nvidia, soit avec les paquets nvidia dans le dépôt rpmfusion propriétaire qui sont en retard à chaque mise à jour).
Les pilotes libre pour moi, c'est que des avantages. (En plus, Red Eclipse et Urban Terror tournent parfaitement avec les pilotes libres)
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Pilotes graphiques libres
Posté par jbbourgoin (site web personnel) . Évalué à 3.
Oui, enfin il faut quand même dire que les sur certaines cartes les pilotes libres gèrent très mal la gestion de l'énergie => carte qui chauffe.
Et puis certains jeux sont simplement injouables, comme cela a déjà été dit. Je crois que c'est un problème que l'on ne peut pas mettre sous le boisseau comme ça.
[^] # Re: Pilotes graphiques libres
Posté par Maclag . Évalué à 1.
Après la claque à 300M$ que nVidia s'est mangé sur les pilotes non-libres pour les Chinois, je doute que le "on s'en fout, on va filer un blog binaire!" sur les pilotes Libres passe aussi bien qu'avant auprès des grands managers.
Une petite poussette supplémentaire dans le dos d'nVidia pour qu'ils sautent dans le bain, ça ne peut pas faire de mal!
Et quant à ATI, et bien quand ils en auront marre de lire que leurs cartes dédiées font à peine mieux que les Intel intégrées, ils n'auront qu'à bosser sur leurs pilotes Libres également!
Je suis toujours partisan de la méthode forte avec les constructeurs récalcitrants. Attendez de voir un éditeur de grosse solution CAD qui demande une masse de machines très puissantes déclarer qu'il passe sous Wayland et ne fera donc de support que sur [insérer ici constructeur de carte coopératif], ça a toujours son petit effet…
[^] # Re: Pilotes graphiques libres
Posté par Scias . Évalué à 10.
En fait ce n'est pas tout à fait correct. KMS n'est pas strictement obligatoire pour Wayland, en fait d'après Kristian lui-même :
Donc théoriquement les drivers propriétaires peuvent utiliser Wayland sans forcément utiliser KMS/GEM si ils implémentent des mécanismes similaires pour partager les buffers entre les clients et un modesetting noyau.
[^] # Re: Pilotes graphiques libres
Posté par antistress (site web personnel) . Évalué à 4.
Oui, c'est plus précis dit comme ça
[^] # Re: Pilotes graphiques libres
Posté par MTux . Évalué à 9.
Eh bien moi ça m'inquiète cette tendance Linux only que l'on retrouve partout.
Exemple concret :
L'autre jour j'installe FreeBSD, les mains dans les poches parce que "mon ordinateur a une carte graphique Intel, et le Intel saylibre saybien". Et bim, elle n'est pas supportée. La raison ? Le pilote est KMS only, et ça n'est pas encore présent sur FreeBSD. Le pilote AMD est en passe de devenir pareil et ses performances sont complètement à la ramasse (même sur Linux). Donc le seul moyen d'avoir de bons graphismes sur FreeBSD c'est d'acheter une carte Nvidia et de coller le pilote propriétaire.
Sur le coup j'ai pas mal pesté car on marginalise encore plus les systèmes alternatifs à Linux qui vont devoir devenir des Linux-like pour faire du desktop.
[^] # Re: Pilotes graphiques libres
Posté par claudex . Évalué à 10.
C'est la faute de la licence BSD qui nourri le propriétaire.
(Et hop, lancé de troll à 10 points).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pilotes graphiques libres
Posté par patrick_g (site web personnel) . Évalué à 4.
En même temps KMS a été commité en novembre 2008 et a été intégré dans le noyau Linux version 2.6.29 (début 2009).
Est-ce que la fondation FreeBSD n'aurait pas du se pencher sur le sujet un peu plus tôt ?
[^] # Re: Pilotes graphiques libres
Posté par rakoo (site web personnel) . Évalué à 8.
Est-ce que la fondation FreeBSD a les mêmes moyens ?
Est-ce que la fondation FreeBSD place une technologie liée aux performances graphiques assez haut dans la pile des priorités, sachant qu'elle a plutôt tendance à être utilisée en tant que serveur, typiquement headless ?
J'avoue ne pas connaître cet univers par coeur. J'ai l'impression que KMS était optionnel avant mais devient maintenant obligatoire, ce qui pose un réel problème pour ceux qui ne l'ont pas encore. J'ai bon ?
[^] # Re: Pilotes graphiques libres
Posté par rpointel . Évalué à 1.
Oui, tu as bon.
[^] # Re: Pilotes graphiques libres
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 23 octobre 2012 à 23:13.
Un lien de la dépêche qui t’intéressera énonce que les pilotes sont dorénavant KMS et que dragonflybsd a intérêt à coller à KMS pour continuer à avoir des pilotes graphiques.
C'est clairement prioritaire pour eux.
Après, X.Org ou Wayland… X.Org a été modernisé et marche quand même à peu près donc il y a pas urgence à embrasser Wayland, en tout cas moins d'urgence.
[^] # Re: Pilotes graphiques libres
Posté par nud . Évalué à 1.
D'un autre côté, on est dans les drivers, donc dans le noyau. Ça a toujours été Linux-only.
Je comprend les détracteurs de software userland linux-only, mais si le noyau devait lui-même attendre que les autres aient implémenté les mêmes fonctionnalités avant de les utiliser, on en sortirait pas. Surtout que vu que la licence BSD et la GPL sont incompatibles, et que de toute façon l'architecture des noyaux est différente, il faut que BSD réimplémente les fonctionnalités de zéro.
[^] # Re: Pilotes graphiques libres
Posté par antistress (site web personnel) . Évalué à 10.
Même lien que donné ci-dessus :
(je grasse)
[^] # Re: Pilotes graphiques libres
Posté par M . Évalué à 5.
Non les première version de dri était partagé entre linux et bsd.
Mais vu que la plupart du dev était fait sous linux, on pouvait cassé assez facilement le support bsd.
Faux il existe des pilotes sous dual licence GPL et BSD
# Petite correction
Posté par Albert_ . Évalué à 5.
En dehors du fait de savoir qui affiche les décorations, notons qu’à l’heure actuelle la question de la cohérence graphique se pose déjà quand on fait tourner une application GNOME sous KDE et vice‐versa, donc ce n’est pas vraiment nouveau.
Je ne vois absolument pas de quoi tu parles, sous KDE les applications Gnome ont la même tête que les applis KDE. Merci le travail fait le projet KDE pour cela. Si tu as des problemes a ce niveau la, cela se change dans un truc totalement nouveau qui s'appelle "systemconfig". C'est un logiciel qui permet de configurer pas mal de chose sour KDE. Pour la definition de configuration, ne pas aller sur le site de Gnome ou de Apple mais dans un dictionnaire.
:)
Au fait les devs KDE étant super sympa, ils ont aussi fait l'inverse, c'est à dire que les applis KDE ressemble a des applis Gnome sous Gnome…
[^] # Re: Petite correction
Posté par gyscos . Évalué à 2.
Chez moi, il faut que je change le thème gtk (pour QtCurve ou oxygen gtk) pour arriver à ce résultat. Tu est certain que c'est automatisé par kde chez toi ?…
[^] # Re: Petite correction
Posté par Albert_ . Évalué à 4. Dernière modification le 23 octobre 2012 à 22:27.
Par KDE surement pas mais pas ma distribution oui. Si c'est pas le cas change de distribution.
Par contre c'est bien le projet KDE qui permet d'avoir un environnement visuellement coherent avec Gnome. Les gnomiste n'ont jamais pondu la moindre ligne de code pour aider sur le sujet!
[^] # Re: Petite correction
Posté par reno . Évalué à 2.
OK, le texte aurait put être plus clair, mais l'idée était de dire que faire que des appli X ayant un look cohérent dans Y, ça a demandé des efforts et qu'ajouter les décorations dans la liste des choses a adapter, c'est juste un item de plus a rajouter dans la liste des choses a synchroniser pas une nouvelle problématique.
Mais c'est clair que ça fait du boulot de synchro en plus.
[^] # Re: Petite correction
Posté par Albert_ . Évalué à 3.
J'avais bien compris mais l'exemple pris est le mauvais exemple car si il y a deux toolkits qui s'interfacent, graphiquement parlant à peu prés correctement, c'est bien KDE et Gnome et cela grace aux efforts des developpeurs de KDE.
Mais si tu veux utiliser une applis EFL dans KDE ou Gnome, la ca doit etre une sacré cata en effet mais au moins avec les bords de fenêtre similaire ce qui ne sera même plus le cas avec wayland si j'ai bien compris. Ca peut devenir sacrément "funky" le bureau :)
[^] # Re: Petite correction
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 0. Dernière modification le 24 octobre 2012 à 10:38.
Surtout qu'il y a :
Du coup, on se retrouvera avec :
[^] # Re: Petite correction
Posté par Strash . Évalué à 2.
Vous avez lu la dépêche avant de râler ?
Donc si tu ne veux pas avoir de décoration avec ton gestionnaire de fenêtre Tiling-machin-chose, tu peux le faire ! Et si tu veux toujours avoir une décoration uniformisée, tu peux le faire (ce qui est actuellement le choix fait par KDE) !
[^] # Re: Petite correction
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Ah, exact. Dans ce cas, la situation sera différente, en effet :
Du coup, en pratique, ce sera du coup la même situation que sous X11 : presque aucun logiciel ne décorera lui-même ses fenêtres. C'est Weston qui sera marginalisé, avec :
[^] # Re: Petite correction
Posté par brendel . Évalué à 3.
Il ne seront pas doublement décorés : le protocole permet de spécifier si le client doit envoyer la décoration ou pas (si je ne me trompe pas).
[^] # Re: Petite correction
Posté par reno . Évalué à 2.
Je ne sais pas si le logiciel a déjà cette fonctionnalité mais c'est clairement quelque-chose de nécessaire.
[^] # Re: Petite correction
Posté par antistress (site web personnel) . Évalué à 3.
Intéressant, j'ai jeté un œil :
Client Side Decorations est prévu dans GTK+ : pour GNOME, Xfce ou les deux ?
Mais c'était déjà prévu du temps de X.Org, indépendamment de tout plan concernant Wayland
En tout cas c'est toujours noté "to do" sur la roadmap
Bref, difficile de connaître les plans de GNOME et Xfce avec ces éléments
Accessoirement GTK+ relève ces avantages :
Concernant KWin
Ça explique pourquoi d'après chaosreigns, Qt5 prend en charge Wayland sauf client side decorations (mais vu que Qt vise l'embarqué, faudra voir quel compositeur est utilisé là bas).
Bref, on sait que KDE n'utilisera pas Client Side Decorations, à part ça…
[^] # Re: Petite correction
Posté par YBoy360 (site web personnel) . Évalué à 1.
j'utilise Chromium qui n'affiche pas la décoration de Kwin, bon Ok, au début on est pas habitué, mais je m'y suis fait au point de trouver toutes ces décorations identiques entre fenêtres, ennuyeuses.. il y a un gain potentiel de place si les appli dessinent elle-même la décoration, c'est la possibilité de dessiner le menu directement dans la déco, sans passer par des hacks ou Pied ne veut plus rendre ses appli compatible avec petit dragon.
[^] # Re: Petite correction
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Il y a une spec DBus pour ça.
Appmenu permet aux applications d'indiquer leur structure de menus et (entre autres) au WindowManager de l'afficher dans la décoration. C'est ce qu'utilise aussi Unity pour la recherche dans les menus via le Dash.
Bref, pas besoin de décoration cliente pour ça.
[^] # Re: Petite correction
Posté par YBoy360 (site web personnel) . Évalué à 2.
c'est ce que j'appelle, à tord, un hack (c'est tout sauf un hack, puisque justement ça permet d'éviter les customisations), il faut faire une interface dbus, mettre tous les WM d'accord, je me rappelle que KDE et Gnome n'était pas d'accord pour faire une interface dbus commune à un moment. Mais tant qu'on peut se débarrasser de la décoration, il n'y a pas de problèmes.
DBus remplace les XAtoms et les fameux window manager hints très limité, auxquelles je me rappelle avoir été confronté, le tout entre plusieurs Unix. Horrible comme souvenir. Je suis bien content de plus m'occuper de ça!
# Gestionnaire de sessions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Le conception de la pile Wayland est différente d'X11. En particulier, le gestionnaire de fenêtres doit être intégré au serveur, autrement dit un gestionnaire de fenêtres alternatif est en fait un serveur Wayland alternatif, même s'il peut réutiliser du code existant de bibliothèques faites pour.
En revanche, sauriez-vous ce que ça donne pour l'ouverture de session ? Actuellement, en environnement multi-utilisateur graphique sous X11, le serveur est lancé, puis un premier client, le gestionnaire de sessions. Celui-ci laisse les utilisateurs s'identifier, puis lance leur session préférée, qui est constituée d'un gestionnaire de fenêtres, et souvent d'un gestionnaire de bureau.
Et sous Wayland donc ? Si le gestionnaire de fenêtres est intégré au serveur, pour lancer le gestionnaire de fenêtres, autrement dit le serveur préféré de l'utilisateur qui vient de s'identifier, il faudrait remplacer le serveur utilisé par le gestionnaire de sessions ?
[^] # Re: Gestionnaire de sessions
Posté par Gof (site web personnel) . Évalué à 7.
Il y a plusieurs possibilités: La première possibilité est comme tu dis de remplacer un compositeur par un autre.
La seconde possibilité, qui est vraisemblablement celle qui sera choisi est d'emboîter (nest) les compositeurs.
En gros, on a un premier compositeur qui est lancé et affiche l'écran de login. Ensuite, le compositeur de l'utilisateur est lancé par dessus. Cela a comme avantage de permettre le changement rapide d'utilisateur et un verrouillage d'écran sûr.
Tu peux regarder du coté de lightdm qui explore déjà ces pistes
[^] # Re: Gestionnaire de sessions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -2.
Le truc que Linux implémente depuis ses début avec des consoles virtuelles multiples, quoi. Vachement utile de réinventer la roue…
Mmmh, peut-être bien, ce n'est pas bête ça.
[^] # Re: Gestionnaire de sessions
Posté par Gof (site web personnel) . Évalué à 8.
Et qui prends des plombes à faire clignoter l'écran 3 fois.
(Avec KVM c'est un peu mieux, mais quand même)
Alors que là on pourrait même mettre les différentes sessions sur les différentes faces d'un cube.
[^] # Re: Gestionnaire de sessions
Posté par Badeu . Évalué à 8.
Ça c'est THE fonctionnalité pour donner une impression power user à Kévin.
[^] # Re: Gestionnaire de sessions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Avece KVM c'est parfait. Mais pas kikoololesque, c'est vrai…
[^] # Re: Gestionnaire de sessions
Posté par cedric . Évalué à 8.
Les consoles virtuelles sont implementes en cooperatif. Si ton serveur X est dans les choux ou tu as une appli frmebuffer un peu mal code, pas moyen de switcher. C'est un "lege" probleme. Plus cosmetic, quand tu switch d'un utilisateur a un autre, c'est lent et c'est pas beau !
En ayant un top compositeur qui se charge de ca, tu peux regler les deux problemes. D'un point de vue performance ce top compositeur sera surement la plus part du temps dans le mode je switch les buffers du seul fils que j'ai. Donc ca coutera un switch de context, mais ca sera tout. Si ce compositeur est garde simple, il sera donc une source de plus grande stabilite et d'interface plus sympatique. Ca ressemble au progres pour moi.
[^] # Re: Gestionnaire de sessions
Posté par Xaapyks . Évalué à 2.
Je le déplore aussi malheureusement trop souvent, tu as raison sur ce point. Si ton X est bloqué jamais il réagira à Ctrl + Alt + Fx…
Ça ça fait quand même pas mal de temps que c'est fini, enfin si tu utilises des drivers bien intégrés, et avec KMS (pas les blobs quoi)
[^] # Re: Gestionnaire de sessions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Alt + SysRq + R pour rendre le clavier au noyau
Alt + Fn pour passer à la console n.
De rien.
# Gestionnaire de fenêtre et toolkit
Posté par Domi . Évalué à 0.
Y'a un truc que je comprends pas très bien: Wayland incorporerait le gestionnaire de fenêtres, mais avec Weston, ce sont les clients qui dessinent leurs décorations. Il est où le gestionnaire de fenêtre dans tout ça?
De plus, plutôt que de porter les toolkits (gtk, qt, etc, la liste est longue) pour wayland, il aurait été beaucoup plus intéressant et performant qu'un OS moderne se décide enfin à incorporer le toolkit dans le serveur graphique. Cela supprimerait une couche de plus. L'Amiga le faisait déjà, et c'était une des raisons pour lesquelles cette machine était si performante pour son époque et si facile à programmer. Avec les machines actuelles, se serait de la bombe en 3D…
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Gestionnaire de fenêtre et toolkit
Posté par claudex . Évalué à 5.
Je ne comprends ce que tu veux dire avec des toolkits dans le serveur graphique, mais pour le gestionnaire de fenêtre, son but premier n'est pas de décorer les fenêtres mais de les placer sur l'écran et de savoir qui recouvre quoi.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Gestionnaire de fenêtre et toolkit
Posté par SChauveau . Évalué à 2.
D'un point de vue technique, faire gérer la fenêtre par l'application (via le toolkit) ne me choque pas.
Je crains toutefois de voir une belle anarchie s'installer dans ce domaine.
Il ne semble pas y avoir de mécanisme clair permettant d'unifier la gestion des fenêtres entre les applications GTK, GNOME-GTK, XCFE-GTK, QT, QT-KDE, X11 (via le serveur rootless intégré à Wayland), Java, SDL, GLUT, … ?
Non seulement le look risque d'être différent d'un toolkit à l'autre mais les comportements aussi ('click' ou 'follow focus', raccourcis claviers, …).
L'idéal serait d'avoir une lib (ou un service) unique s'occupant de tout les détails du coté client mais je suis près à parier qu'il ne faudra pas attendre 15 jours pour voir apparaitre une lib concurrente ou un toolkit qui refait le truc en 'mieux'.
J'espère que je me trompe mais franchement je m'attends à un beau bordel!
et je n'ose même pas imaginer les applications qui décideront de gérer même leur décorations.
[^] # Re: Gestionnaire de fenêtre et toolkit
Posté par Domi . Évalué à 0.
Mon premier pc décent était un Amiga. Dans l'AmigaOS, il n'y a qu'un seul toolkit qui est intégré dans le serveur graphique. Le toolkit de l'Amiga est l'équivalent de Xlib + toolkit xyz. De plus, une partie était intégré dans le kernel. Ce qui avait l'avantage de la simplicité et d'être rapide même sur un processeur qui ne tournait qu'à 8MHz et disposait que de quelques MB de ram. Le tout en couleur et sonorisé, basé sur un kernel préemptible multitâche. Le meilleur de mes ordis.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Gestionnaire de fenêtre et toolkit
Posté par Gof (site web personnel) . Évalué à 3.
1- Le gestionnaire de fenêtre est un concept X11, Ce concept n'existe plus avec Wayland, tout comme il n'existe pas sous Windows. Mais les fonctionnalités ne sont pas pour autant perdue, puisqu'on peux toujours choisir un compositeur alternatif.
2- les toolkits comme Qt ou glib/GTK ne sont pas juste des éléments graphique, Il correspondent surtout a une façon de programmer différente : Langages différents, API différentes, paradigmes différents.
3- Pourquoi serait-il plus performant de mettre les éléments graphiques coté serveur ? Peut être que pour des applications simple, on gagnerais en latence lors de l'utilisation de la transparence réseau, Mais dans le cas pour lequel Wayland est prévu, je ne vois pas ce qu'il y a à gagner. Les clients Wayland ont justement plus de possibilité quand il peuvent simplement dessiner leur fenêtre de la manière qu'il souhaite.
[^] # Re: Gestionnaire de fenêtre et toolkit
Posté par xcomcmdr . Évalué à 2. Dernière modification le 24 octobre 2012 à 11:45.
Par rapport au 1 : DWM.exe n'est pas justement le gestionnaire de fenêtres de Vista/Seven (et suivants) ?
http://en.wikipedia.org/wiki/Desktop_Window_Manager
(je n'ai pas souvenir de ce genre de processus dans les Windows précédents…)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Gestionnaire de fenêtre et toolkit
Posté par Domi . Évalué à 0.
Si tu lis la FAQ, le gestionnaire de fenêtre existe toujours, simplement, comme dans l'AmigaOS, il est incorporé dans le serveur d'affichage et le compositeur.
Si wayland est bien fait, il doit être possible de gagner beaucoup pour tout ce qui touche à l'affichage. Si je compare aeros (une version libre de l'AmigaOS qui peut être installée comme hôte linux ou en natif), le Gimp se lance 4 ou 5 fois plus rapidement sous aeros installé comme hôte sous linux que Gimp en natif linux dans la même machine. Ce qui ne change pas par contre sont les temps de traitement des filtres sur les images. Mais au niveau du lancement des applications et de la fluidité de X, la différence est impressionnante.
Donc, affaire à suivre. Je pense cependant que pour les applications wayland, cela devrait être rapide. Pour les applications X lancées sous wayland, c'est à voir. Quand à lancer X sous wayland, ce sera (d’après la FAQ) un petit peu plus lent.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Gestionnaire de fenêtre et toolkit
Posté par reno . Évalué à 2.
Oui, une partie des fonctionnalités du gestionnaire de fenêtre "a la X" est faite par le client (le dessin et la gestion des décorations des fenêtres) quand on utilise Weston, mais il reste le déplacement des fenetres (le client détecte que l'utilisateur veut déplacer la fenetre et dit à Weston "je suis en mode de déplacement" qui déplace ensuite la fenetre de manière autonome jusqu'à ce que l'utilisateur relache le boutton puis il rend la main), prendre la main sur les clients qui ne "ping" plus, etc.
M'étonnerait, tu perds en souplesse et (sauf en cas distant) je ne pense pas que tu gagne beaucoup en performance.
# X.Org mériterait un peu plus d'égards.
Posté par Gabin II . Évalué à 10.
Outre l'aspect je traine des casseroles depuis 30 piges c'est quand même un serveur graphique qui a fait les beaux jours de Linux (et *BSD) et qui fonctionne très bien sur mon matériel tantôt nVIDIA proprio tantôt GMA4500.
Certes une reconception du serveur graphique était necessaire mais c'est pas comme si on utilisait de la merde depuis 10 ans.
X.Org n'est pas mort, il se retire après avoir servi fièrement* le monde du libre.
ciao l'artiste!
*et d'achever les dernier cheveux de pas mal de codeurs. :)
# comparaison taille API
Posté par djano . Évalué à 10.
On en reparlera dans 30 ans si W est toujours là! ^_^
[^] # Re: comparaison taille API
Posté par Xaapyks . Évalué à 2.
Je doute fortement que l'API grossisse tant que ça pour en arriver à celle de Xorg.
Xorg fait 50 fois plus de choses, et je pense que c'est surtout les méthodes de rendu qui explosent le compteur. Chose qui n'est pas prévue pour Wayland.
[^] # Re: comparaison taille API
Posté par El Titi . Évalué à 4.
On en reparlera dans 25 ans si L est toujours là _^
# Pas d'OpenGL?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
D'après la FAQ de Wayland:
Ca veut dire que sous Wayland, on va devoir se contenter du OpenGL handicapé (GLES)?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas d'OpenGL?
Posté par Shuba . Évalué à 3.
Il me semble que ça signifie seuleument que le compositeur devra utiliser GLES, si tu veux qu'une de tes applis utilise un GL complet tu pourras, mais il faudra aller chercher les dépendances nécessaires.
[^] # Re: Pas d'OpenGL?
Posté par Maclag . Évalué à 3.
Et il me semble que OpenGL ES n'enlève pas tant de possibilités que ça. La grosse différence viendrait de l'épuration des fonctions gardées dans OpenGL par souce de compatibilité ascendante. Ce serait donc d'abord une mise au propre moderne de OpenGL puis un compromis légèreté/fonctionalités.
(Attention, je n'ai pas dit que ça n'enlevait rien d'utile du tout!)
[^] # Re: Pas d'OpenGL?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Un gros avantage d'OpenGL, c'est que les vieux programmes écrit il y a 15 ans sur mon Pentium 75 sans carte 3d fonctionnent toujours avec, les nouveaux pouvant profiter des extensions.
Mais un jour certains ont prétexté qu'il fallait une API designed for embedded system (dont le plus minable représentant est certainement plus puissant que mon P75), mais surtout designed pour pas se faire chier à implémenter.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# X -> W : retour vers le futur ?
Posté par chla . Évalué à 9.
Salut,
article très intéressant.
Je me suis amusé en lisant :
Car au départ X était l'évolution de W, voir la partie History de http://en.wikipedia.org/wiki/X_Window_System :
D'où le titre de mon commentaire ;-)
# directFB
Posté par YBoy360 (site web personnel) . Évalué à 3. Dernière modification le 24 octobre 2012 à 10:28.
comment peut-on comparer Wayland à DirectFB? Je crois que directFB impose un gestionnaire de fenêtre (un peu comme Weston, ou une implémentation alternative du protocole)?
J'ai l'impression surtout que directFB n'utilise pas EGL, ou que la différence doit être de cet ordre…
# x.org est mort
Posté par modr123 . Évalué à -1.
mais Xfree NON
[^] # Re: x.org est mort
Posté par Didrik Pining . Évalué à 3.
Et Félicie, aussi.
# XDG_RUNTIME_DIR
Posté par Didrik Pining . Évalué à 3.
Sans vouloir la ramener, il me semble que le terme approprié est "définit". Défini la variable et éventuellement implémente un mécanisme.
Selon la spec, ca me fait penser à un $HOME/tmp/ qu'il suffirait d'exporter dans le .profile.
[^] # Re: XDG_RUNTIME_DIR
Posté par Misc (site web personnel) . Évalué à 3.
Le lien vers la spec : http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Et en fait, je vois pas ce que vient faire systemd la dedans ( part que c'est sans doute logind qui rajoute le répertoire ). C'est trivialement implémentable dans /run/. D'ailleurs, oh tiens :
$ echo $XDG_RUNTIME_DIR
/run/user/500
Actuellement, xorg mets ça dans /tmp ( genre /tmp/.X11-unix/X0 ).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.