_Quid des applications qui plantent sous X obligeant à relancer le serveur X ? _
Elles claqueront pareil sous Wayland, a moins que l'on modifie complètement toute l'architecture sous-jacente DRI/Pilote graphique. Ce n'est pas un problème de Xorg/XFree, encore moins un problème de X11R6 - c'est juste que les cartes graphiques grand public ne sont pas prévue pour gérer les switch de context autrement qu'à la sauce windows. Après la carte graphique se bloque, et X ne peut plus rien y faire.
Est ce que l'adressage mémoire actuel est capable de gérer 2 applis qui utilisent chacun une carte graphique ? Non ! Est-ce que ça sera implanté sous X ? " incompatible par nature "
X11R6 incompatible par nature avec la gestion de plusieurs applis chacune sur carte graphique différente, voire plusieurs machine différentes ? Faut le dire vite à SGI. La force de X11R6 est justement qu'on peut gérer chaque sous fenêtre d'une appli depuis une source différente, du moment que ça peut pondre un "drawable" ça marche. Et sinon c'est pas les extensions de bypass et d’accès direct qui manquent.
Mais, non, en fait, manque de pot, dans 4 heures, tes distributions favorites vont te forcer la mise à jour vers Wayland en virant X. T'as plus que 4 heures à utiliser ssh -X .
Tu es passé à coté du problème. Bien sur la mise à jour ne vas pas se faire en trente secondes, mais il y a quand même un vrai problème : si il est acceptable que Wayland puisse pendant une période de transition utiliser un wrapper X11, c'est un luxe que ne vont pas trop pouvoir se payer les logiciels de prise de main à distance, à moins de vouloir rendre leur code très complexe. Donc soit on lance un serveur Wayland complet pour chaque prise de main, soit il faut que les applis elle même soient bi-compatibles X/Wayland. J'y crois moyen. Pendant tout un temps on aura des prises de main à distance sauce wayland pour lancer des applis wayland et des prises de main à distance sauce X11 pour lancer des applis X11. Ca me fait saliver d'avance.
mmh, les biblio GTK, Qt, les EFL sont en cours de portage pour Wayland. Si les dev ont travaillés avec les bibliothèques concernés, normalement, ça devrait être transparent, exactement comme quand on est passé de XAA à EXA, ou comme lorsque XRender est arrivé, ou comme quand DBus est arrivé.
Ou comme quand Fleury Michon a mis moins de sel dans son jambon à l'os ou comme quand Pluton n'a plus été considéré comme une planète...
Tu as idée de la différence de surface qu'il y a entre X11R6 et ses différentes révisions/implémentation et le EXA ? Tu ne vois pas la différence qu'il y a entre "certains pilote libre n'auront plus d’accélération graphique" et "Il faut recompiler toutes les applications graphiques en mettant à jour toutes les libs grpahiques et en priant pour qu'il n'y ait pas trop de code à réécrire."
Non sincèrement. Toutes les autres applications que tu cites sont optionnelles. Si je ne veux pas m'en servir, ben je m'en sers pas et ça roule pareil qu'avant. Si vraiment je veux absolument utiliser DBus au lieu de /proc ou EXA au lieu de XAA j'ai un endroit dans le code à modifier pour le faire (si mon code est propre).
Avec Wayland, une application graphique doit gérer la souris, la saisie, les décorations de fenêtres, les buffers Wayland etc. Le tout en cassant tout le code d'affichage précédent. Je n'ai pas vu de système de gestion de souris ou de gestion de décoration de fenêtre dans GTK. Donc même si mon code GTK aujourd'hui est très très propre (grosso-modo je n'ai pas un seul widget perso, pas une surcharge de (pseudo)classe, pas un accès direct à des buffers vidéos), il faudra quand même que je recode le tout. Et personnellement je doute fort que GTK2 et QT3 passe à Wayland, et pourtant j'ai pleins d'applis GTK2 et QT3 que j'aime bien.
Certaines applis utilisent encore la XLib
Oui quelques unes. XLib, XMotif ou TK, ca doit faire quoi 75/80% du parc existant grand maximum. Une paille. Il y a pas que le Desktop de hobbyiste dans la vie.
moui quelle perte de temps. 10 ans que les applis OpenGL plantent
Et 20 ans que SGI ne s'en est pas rendu compte.
4 ans que les premiers ordis OPTIMUS sont sortis
Ca c'est l'argument qui tue. C'est clair, dès que le Desktop Linux va passer sous Wayland, NVidia va libérer les specs des hold buffers. Mais attention elle ne va les libérer que pour Wayland, interdiction de les utiliser pour xorg.
2 ans que des dev X11 disent qu'il faut passer à Wayland, et toujours rien
C'est clair que Wayland a reçu le soutien massif des devs X11 et du X consortium en général. Bon la plupart des devs X11 et des membres du X Consortium sont chez Intel c'est pour ça que ça se voit pas trop. Mais c'est massif comme mouvement.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 4.
_Quid des applications qui plantent sous X obligeant à relancer le serveur X ? _
Elles claqueront pareil sous Wayland, a moins que l'on modifie complètement toute l'architecture sous-jacente DRI/Pilote graphique. Ce n'est pas un problème de Xorg/XFree, encore moins un problème de X11R6 - c'est juste que les cartes graphiques grand public ne sont pas prévue pour gérer les switch de context autrement qu'à la sauce windows. Après la carte graphique se bloque, et X ne peut plus rien y faire.
Est ce que l'adressage mémoire actuel est capable de gérer 2 applis qui utilisent chacun une carte graphique ? Non ! Est-ce que ça sera implanté sous X ? " incompatible par nature "
X11R6 incompatible par nature avec la gestion de plusieurs applis chacune sur carte graphique différente, voire plusieurs machine différentes ? Faut le dire vite à SGI. La force de X11R6 est justement qu'on peut gérer chaque sous fenêtre d'une appli depuis une source différente, du moment que ça peut pondre un "drawable" ça marche. Et sinon c'est pas les extensions de bypass et d’accès direct qui manquent.
Mais, non, en fait, manque de pot, dans 4 heures, tes distributions favorites vont te forcer la mise à jour vers Wayland en virant X. T'as plus que 4 heures à utiliser ssh -X .
Tu es passé à coté du problème. Bien sur la mise à jour ne vas pas se faire en trente secondes, mais il y a quand même un vrai problème : si il est acceptable que Wayland puisse pendant une période de transition utiliser un wrapper X11, c'est un luxe que ne vont pas trop pouvoir se payer les logiciels de prise de main à distance, à moins de vouloir rendre leur code très complexe. Donc soit on lance un serveur Wayland complet pour chaque prise de main, soit il faut que les applis elle même soient bi-compatibles X/Wayland. J'y crois moyen. Pendant tout un temps on aura des prises de main à distance sauce wayland pour lancer des applis wayland et des prises de main à distance sauce X11 pour lancer des applis X11. Ca me fait saliver d'avance.
mmh, les biblio GTK, Qt, les EFL sont en cours de portage pour Wayland. Si les dev ont travaillés avec les bibliothèques concernés, normalement, ça devrait être transparent, exactement comme quand on est passé de XAA à EXA, ou comme lorsque XRender est arrivé, ou comme quand DBus est arrivé.
Ou comme quand Fleury Michon a mis moins de sel dans son jambon à l'os ou comme quand Pluton n'a plus été considéré comme une planète...
Tu as idée de la différence de surface qu'il y a entre X11R6 et ses différentes révisions/implémentation et le EXA ? Tu ne vois pas la différence qu'il y a entre "certains pilote libre n'auront plus d’accélération graphique" et "Il faut recompiler toutes les applications graphiques en mettant à jour toutes les libs grpahiques et en priant pour qu'il n'y ait pas trop de code à réécrire."
Non sincèrement. Toutes les autres applications que tu cites sont optionnelles. Si je ne veux pas m'en servir, ben je m'en sers pas et ça roule pareil qu'avant. Si vraiment je veux absolument utiliser DBus au lieu de /proc ou EXA au lieu de XAA j'ai un endroit dans le code à modifier pour le faire (si mon code est propre).
Avec Wayland, une application graphique doit gérer la souris, la saisie, les décorations de fenêtres, les buffers Wayland etc. Le tout en cassant tout le code d'affichage précédent. Je n'ai pas vu de système de gestion de souris ou de gestion de décoration de fenêtre dans GTK. Donc même si mon code GTK aujourd'hui est très très propre (grosso-modo je n'ai pas un seul widget perso, pas une surcharge de (pseudo)classe, pas un accès direct à des buffers vidéos), il faudra quand même que je recode le tout. Et personnellement je doute fort que GTK2 et QT3 passe à Wayland, et pourtant j'ai pleins d'applis GTK2 et QT3 que j'aime bien.
Certaines applis utilisent encore la XLib
Oui quelques unes. XLib, XMotif ou TK, ca doit faire quoi 75/80% du parc existant grand maximum. Une paille. Il y a pas que le Desktop de hobbyiste dans la vie.
moui quelle perte de temps. 10 ans que les applis OpenGL plantent
Et 20 ans que SGI ne s'en est pas rendu compte.
4 ans que les premiers ordis OPTIMUS sont sortis
Ca c'est l'argument qui tue. C'est clair, dès que le Desktop Linux va passer sous Wayland, NVidia va libérer les specs des hold buffers. Mais attention elle ne va les libérer que pour Wayland, interdiction de les utiliser pour xorg.
2 ans que des dev X11 disent qu'il faut passer à Wayland, et toujours rien
C'est clair que Wayland a reçu le soutien massif des devs X11 et du X consortium en général. Bon la plupart des devs X11 et des membres du X Consortium sont chez Intel c'est pour ça que ça se voit pas trop. Mais c'est massif comme mouvement.