antistress a écrit 4553 commentaires

ah non, ça ferait un nouvel app store centralisé, il vaut mieux que chaque libraire gère son store

Certains commentateurs y voient de l'ironie http://phoronix.com/forums/showthread.php?55818-The-Linux-Kernel-Power-Issues-Continues-To-Bite-Users#post213861

ah oui, en effet, c'est un peu chien !

J'avais suivi ça vaguement, d'après ce qu'il avait dit il avait à débusquer le lièvre ? Auquel cas il peut s'en vanter.
Je suis pas sûr de comprendre la phrase anglaise

L'embargo sur certains bugs "afin de maximiser les profits"

Je n'ai pas compris ?

Tu peux même reprendre l'affirmation de Dave Airlie : ça ne permet pas l'écriture d'un pilote Mesa/Gallium.
(contrairement à ce qui est écrit dans la dépêche)

Alors Bravo !
C'est ce que j'avais compris quand j'avais fait un billet sur le projet :-)

Moi je suis assidûment Phoronix, le site n'a pas vraiment d'équivalent pour savoir ce qui se passe en cuisine

Je ne dis pas que vous auriez pu faire autrement, mais je soulignais que le commentaire précédent laissait entendre des choses partiellement inexactes.

Si j'ai bien compris TEA permettra d'avoir des app stores décentralisés en reproduisant le modèle des libraires actuelles (chaque librairie pourrait avoir son app store), à la façon du Mozilla Market Place ? Si c'est ça c'est un immense progrès.

Mais je trouve un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.
Oui, il reste un "firmware" fermé et visiblement incontournable, mais c'est déjà le cas pour beaucoup de matériels.

Tant qu'à faire, au lieu d'écrire que Broadcom avait libéré le pilote, ils auraient pu écrire qu'ils libéraient toute l'informatique.
Reconnais que ça aurait été un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.

Tea n'est pas opposé aux DRMs d'après ce que je lis.

Faudrait mettre à jour la dépêche, la fondation rpi a un peu annoncé n'importe quoi au final…

https://github.com/pathscale/pscnv/wiki

(plus d'infos dans une prochaine dépêche)

. KWin décorant lui-même les décorations, les logiciels KDE ne décoreront pas leurs fenêtres ;
. GNOME, Xfce puis les autres suivront probablement la même voie, ne serait-ce que pour que les logiciels KDE lancés sous GNOME aient des décorations.

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 :

This involves better RGBA window support in the toolkit and improved mouse cursor handling.

Concernant KWin

I plan to support server side decorations in KWin. My main concern is inconsistency, I fear that GTK windows will look different than Qt windows and that’s something we should try to prevent IMHO.

Ç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…

Même lien que donné ci-dessus :

We intend to write a portability layer that will allow the BSDs to use as much of the Linux drm code as possible. The developers of X.org / freedesktop.org related graphics drivers have their current efforts focused on Linux because they have to get something working anywhere as fast as possible. It is the BSDs responsibility to keep up with these efforts and to contribute back to these developers to justify the developers continuing to generously license their drm code under terms compatible with those of the BSD licenses.

(je grasse)

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.

It is especially vital for Linux drm GEM, TTM, KMS code to be ported immediately to the BSDs because developers are in the process of removing userland modesetting code from current graphics drivers. To paraphrase what we have been told by freedesktop.org developers, if we do not port this code, very shortly the BSDs will be left only using the simplest VESA driver at 1024 x 768 resolution with no hardware acceleration.

We believe that limiting divergence from Linux's drm code is the clearest path for the BSDs to be able to follow the latest drm developments.

Oui, c'est plus précis dit comme ça

j'ai abandonné les contributions suite à ça …

Ça ressemble quand même à une mauvaise excuse.

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…

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 :)

pareil !

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 !

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)

Sinon on peut lire la dépêche jusqu’au bout :

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.

Comme dirait Ken : X.Org est mort mais il ne le sait pas encore

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é :

Our current planning is to make KWin our Wayland Compositor. […] it seems to me that extending KWin with Wayland support is the only possible solution right now. Now KWin is an X11 based window manager and compositor. It’s development started in a time when nobody expected that there could be anything else than X11, so you could say that it expects that all that exists is X11. This means the difficulty in porting KWin to Wayland is not in adding Wayland support to KWin, but in making it possible to have a KWin without X11 support or at least to be able to start KWin without needing an X Server.

Cependant :

the refactoring work I recently blogged about is an important step on the road towards Wayland. Especially the splitting of the OpenGL compositor is very important. This means that the actual Compositor (SceneOpenGL) does no longer depend on X11. The dependency has been moved into an OpenGLBackend with currently an GlxBackend and EglOnXBackend. This makes it much easier to add further backends in future to e.g. support KWin on top of another Wayland compositor or KWin on top of KMS through libgbm.

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