antistress a écrit 4523 commentaires

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

Je pige pas en quoi l'installateur doit être modifié pour prendre en compte UEFI ? Si UEFI est configuré pour booter sur CD ou USB, ça change quoi par rapport au BIOS vu que rien ne se passe tant que l'un ou l'autre (l'UEFI ou le bIOS) n'a pas rendu la main ?

ETC2 Texture Compression For Intel Is Happening

Before getting too excited, however, this ETC2 support isn't a full implementation for texture compression on the hardware but rather is just immediately decoding the ETC2 data into RGBX data.

Even if these patches aren't the best, at least in time for Mesa 9.1/10.0 in early 2013 we should have proper ETC2 support for at least the open-source Intel driver. They really want OpenGL ES 3.0 in Mesa by time of the next release and with GLES 3.0 comes the hard requirement on ETC2 support.

Par contre une texture ETC1 marche avec les appareils supportant ETC1 ou ETC2 (=un appareil ETC2 peut décoder le ETC1).
Et il est possible de stocker une texture ETC1 et ETC2 dans un même fichier sans pour autant que le fichier ne prenne la place de deux textures (certaines parties, on ne sait quel pourcentage, sont partagées). Voir ce lien.

ETC2 Texture Compression Looks Good For OpenGL

Par ailleurs : ETC2 Texture Compression For Intel Is Happening

Lié ou pas : Intel Mesa To Force On S3TC, Floating-Point Textures